1. 17 12月, 2018 40 次提交
    • T
      netfilter: nf_tables: deactivate expressions in rule replecement routine · e5f42e06
      Taehee Yoo 提交于
      [ Upstream commit ca089878 ]
      
      There is no expression deactivation call from the rule replacement path,
      hence, chain counter is not decremented. A few steps to reproduce the
      problem:
      
         %nft add table ip filter
         %nft add chain ip filter c1
         %nft add chain ip filter c1
         %nft add rule ip filter c1 jump c2
         %nft replace rule ip filter c1 handle 3 accept
         %nft flush ruleset
      
      <jump c2> expression means immediate NFT_JUMP to chain c2.
      Reference count of chain c2 is increased when the rule is added.
      
      When rule is deleted or replaced, the reference counter of c2 should be
      decreased via nft_rule_expr_deactivate() which calls
      nft_immediate_deactivate().
      
      Splat looks like:
      [  214.396453] WARNING: CPU: 1 PID: 21 at net/netfilter/nf_tables_api.c:1432 nf_tables_chain_destroy.isra.38+0x2f9/0x3a0 [nf_tables]
      [  214.398983] Modules linked in: nf_tables nfnetlink
      [  214.398983] CPU: 1 PID: 21 Comm: kworker/1:1 Not tainted 4.20.0-rc2+ #44
      [  214.398983] Workqueue: events nf_tables_trans_destroy_work [nf_tables]
      [  214.398983] RIP: 0010:nf_tables_chain_destroy.isra.38+0x2f9/0x3a0 [nf_tables]
      [  214.398983] Code: 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 8e 00 00 00 48 8b 7b 58 e8 e1 2c 4e c6 48 89 df e8 d9 2c 4e c6 eb 9a <0f> 0b eb 96 0f 0b e9 7e fe ff ff e8 a7 7e 4e c6 e9 a4 fe ff ff e8
      [  214.398983] RSP: 0018:ffff8881152874e8 EFLAGS: 00010202
      [  214.398983] RAX: 0000000000000001 RBX: ffff88810ef9fc28 RCX: ffff8881152876f0
      [  214.398983] RDX: dffffc0000000000 RSI: 1ffff11022a50ede RDI: ffff88810ef9fc78
      [  214.398983] RBP: 1ffff11022a50e9d R08: 0000000080000000 R09: 0000000000000000
      [  214.398983] R10: 0000000000000000 R11: 0000000000000000 R12: 1ffff11022a50eba
      [  214.398983] R13: ffff888114446e08 R14: ffff8881152876f0 R15: ffffed1022a50ed6
      [  214.398983] FS:  0000000000000000(0000) GS:ffff888116400000(0000) knlGS:0000000000000000
      [  214.398983] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  214.398983] CR2: 00007fab9bb5f868 CR3: 000000012aa16000 CR4: 00000000001006e0
      [  214.398983] Call Trace:
      [  214.398983]  ? nf_tables_table_destroy.isra.37+0x100/0x100 [nf_tables]
      [  214.398983]  ? __kasan_slab_free+0x145/0x180
      [  214.398983]  ? nf_tables_trans_destroy_work+0x439/0x830 [nf_tables]
      [  214.398983]  ? kfree+0xdb/0x280
      [  214.398983]  nf_tables_trans_destroy_work+0x5f5/0x830 [nf_tables]
      [ ... ]
      
      Fixes: bb7b40ae ("netfilter: nf_tables: bogus EBUSY in chain deletions")
      Reported by: Christoph Anton Mitterer <calestyo@scientia.net>
      Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914505
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=201791Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e5f42e06
    • M
      usb: gadget: u_ether: fix unsafe list iteration · 6d665dab
      Marek Szyprowski 提交于
      [ Upstream commit c9287fa657b3328b4549c0ab39ea7f197a3d6a50 ]
      
      list_for_each_entry_safe() is not safe for deleting entries from the
      list if the spin lock, which protects it, is released and reacquired during
      the list iteration. Fix this issue by replacing this construction with
      a simple check if list is empty and removing the first entry in each
      iteration. This is almost equivalent to a revert of the commit mentioned in
      the Fixes: tag.
      
      This patch fixes following issue:
      --->8---
      Unable to handle kernel NULL pointer dereference at virtual address 00000104
      pgd = (ptrval)
      [00000104] *pgd=00000000
      Internal error: Oops: 817 [#1] PREEMPT SMP ARM
      Modules linked in:
      CPU: 1 PID: 84 Comm: kworker/1:1 Not tainted 4.20.0-rc2-next-20181114-00009-g8266b35ec404 #1061
      Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      Workqueue: events eth_work
      PC is at rx_fill+0x60/0xac
      LR is at _raw_spin_lock_irqsave+0x50/0x5c
      pc : [<c065fee0>]    lr : [<c0a056b8>]    psr: 80000093
      sp : ee7fbee8  ip : 00000100  fp : 00000000
      r10: 006000c0  r9 : c10b0ab0  r8 : ee7eb5c0
      r7 : ee7eb614  r6 : ee7eb5ec  r5 : 000000dc  r4 : ee12ac00
      r3 : ee12ac24  r2 : 00000200  r1 : 60000013  r0 : ee7eb5ec
      Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
      Control: 10c5387d  Table: 6d5dc04a  DAC: 00000051
      Process kworker/1:1 (pid: 84, stack limit = 0x(ptrval))
      Stack: (0xee7fbee8 to 0xee7fc000)
      ...
      [<c065fee0>] (rx_fill) from [<c0143b7c>] (process_one_work+0x200/0x738)
      [<c0143b7c>] (process_one_work) from [<c0144118>] (worker_thread+0x2c/0x4c8)
      [<c0144118>] (worker_thread) from [<c014a8a4>] (kthread+0x128/0x164)
      [<c014a8a4>] (kthread) from [<c01010b4>] (ret_from_fork+0x14/0x20)
      Exception stack(0xee7fbfb0 to 0xee7fbff8)
      ...
      ---[ end trace 64480bc835eba7d6 ]---
      
      Fixes: fea14e68 ("usb: gadget: u_ether: use better list accessors")
      Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      6d665dab
    • L
      net: thunderx: fix NULL pointer dereference in nic_remove · 227b1745
      Lorenzo Bianconi 提交于
      [ Upstream commit 24a6d2dd263bc910de018c78d1148b3e33b94512 ]
      
      Fix a possible NULL pointer dereference in nic_remove routine
      removing the nicpf module if nic_probe fails.
      The issue can be triggered with the following reproducer:
      
      $rmmod nicvf
      $rmmod nicpf
      
      [  521.412008] Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000014
      [  521.422777] Mem abort info:
      [  521.425561]   ESR = 0x96000004
      [  521.428624]   Exception class = DABT (current EL), IL = 32 bits
      [  521.434535]   SET = 0, FnV = 0
      [  521.437579]   EA = 0, S1PTW = 0
      [  521.440730] Data abort info:
      [  521.443603]   ISV = 0, ISS = 0x00000004
      [  521.447431]   CM = 0, WnR = 0
      [  521.450417] user pgtable: 4k pages, 48-bit VAs, pgdp = 0000000072a3da42
      [  521.457022] [0000000000000014] pgd=0000000000000000
      [  521.461916] Internal error: Oops: 96000004 [#1] SMP
      [  521.511801] Hardware name: GIGABYTE H270-T70/MT70-HD0, BIOS T49 02/02/2018
      [  521.518664] pstate: 80400005 (Nzcv daif +PAN -UAO)
      [  521.523451] pc : nic_remove+0x24/0x88 [nicpf]
      [  521.527808] lr : pci_device_remove+0x48/0xd8
      [  521.532066] sp : ffff000013433cc0
      [  521.535370] x29: ffff000013433cc0 x28: ffff810f6ac50000
      [  521.540672] x27: 0000000000000000 x26: 0000000000000000
      [  521.545974] x25: 0000000056000000 x24: 0000000000000015
      [  521.551274] x23: ffff8007ff89a110 x22: ffff000001667070
      [  521.556576] x21: ffff8007ffb170b0 x20: ffff8007ffb17000
      [  521.561877] x19: 0000000000000000 x18: 0000000000000025
      [  521.567178] x17: 0000000000000000 x16: 000000000000010ffc33ff98 x8 : 0000000000000000
      [  521.593683] x7 : 0000000000000000 x6 : 0000000000000001
      [  521.598983] x5 : 0000000000000002 x4 : 0000000000000003
      [  521.604284] x3 : ffff8007ffb17184 x2 : ffff8007ffb17184
      [  521.609585] x1 : ffff000001662118 x0 : ffff000008557be0
      [  521.614887] Process rmmod (pid: 1897, stack limit = 0x00000000859535c3)
      [  521.621490] Call trace:
      [  521.623928]  nic_remove+0x24/0x88 [nicpf]
      [  521.627927]  pci_device_remove+0x48/0xd8
      [  521.631847]  device_release_driver_internal+0x1b0/0x248
      [  521.637062]  driver_detach+0x50/0xc0
      [  521.640628]  bus_remove_driver+0x60/0x100
      [  521.644627]  driver_unregister+0x34/0x60
      [  521.648538]  pci_unregister_driver+0x24/0xd8
      [  521.652798]  nic_cleanup_module+0x14/0x111c [nicpf]
      [  521.657672]  __arm64_sys_delete_module+0x150/0x218
      [  521.662460]  el0_svc_handler+0x94/0x110
      [  521.666287]  el0_svc+0x8/0xc
      [  521.669160] Code: aa1e03e0 9102c295 d503201f f9404eb3 (b9401660)
      
      Fixes: 4863dea3 ("net: Adding support for Cavium ThunderX network controller")
      Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      227b1745
    • Y
      x86/kvm/vmx: fix old-style function declaration · bf1b47f3
      Yi Wang 提交于
      [ Upstream commit 1e4329ee ]
      
      The inline keyword which is not at the beginning of the function
      declaration may trigger the following build warnings, so let's fix it:
      
      arch/x86/kvm/vmx.c:1309:1: warning: ‘inline’ is not at beginning of declaration [-Wold-style-declaration]
      arch/x86/kvm/vmx.c:5947:1: warning: ‘inline’ is not at beginning of declaration [-Wold-style-declaration]
      arch/x86/kvm/vmx.c:5985:1: warning: ‘inline’ is not at beginning of declaration [-Wold-style-declaration]
      arch/x86/kvm/vmx.c:6023:1: warning: ‘inline’ is not at beginning of declaration [-Wold-style-declaration]
      Signed-off-by: NYi Wang <wang.yi59@zte.com.cn>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      bf1b47f3
    • Y
      KVM: x86: fix empty-body warnings · d6b1692d
      Yi Wang 提交于
      [ Upstream commit 354cb410 ]
      
      We get the following warnings about empty statements when building
      with 'W=1':
      
      arch/x86/kvm/lapic.c:632:53: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
      arch/x86/kvm/lapic.c:1907:42: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
      arch/x86/kvm/lapic.c:1936:65: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
      arch/x86/kvm/lapic.c:1975:44: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
      
      Rework the debug helper macro to get rid of these warnings.
      Signed-off-by: NYi Wang <wang.yi59@zte.com.cn>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d6b1692d
    • L
      KVM: VMX: Update shared MSRs to be saved/restored on MSR_EFER.LMA changes · 3c7670d5
      Liran Alon 提交于
      [ Upstream commit f48b4711dd6e1cf282f9dfd159c14a305909c97c ]
      
      When guest transitions from/to long-mode by modifying MSR_EFER.LMA,
      the list of shared MSRs to be saved/restored on guest<->host
      transitions is updated (See vmx_set_efer() call to setup_msrs()).
      
      On every entry to guest, vcpu_enter_guest() calls
      vmx_prepare_switch_to_guest(). This function should also take care
      of setting the shared MSRs to be saved/restored. However, the
      function does nothing in case we are already running with loaded
      guest state (vmx->loaded_cpu_state != NULL).
      
      This means that even when guest modifies MSR_EFER.LMA which results
      in updating the list of shared MSRs, it isn't being taken into account
      by vmx_prepare_switch_to_guest() because it happens while we are
      running with loaded guest state.
      
      To fix above mentioned issue, add a flag to mark that the list of
      shared MSRs has been updated and modify vmx_prepare_switch_to_guest()
      to set shared MSRs when running with host state *OR* list of shared
      MSRs has been updated.
      
      Note that this issue was mistakenly introduced by commit
      678e315e ("KVM: vmx: add dedicated utility to access guest's
      kernel_gs_base") because previously vmx_set_efer() always called
      vmx_load_host_state() which resulted in vmx_prepare_switch_to_guest() to
      set shared MSRs.
      
      Fixes: 678e315e ("KVM: vmx: add dedicated utility to access guest's kernel_gs_base")
      Reported-by: NEyal Moscovici <eyal.moscovici@oracle.com>
      Reviewed-by: NMihai Carabas <mihai.carabas@oracle.com>
      Reviewed-by: NLiam Merwick <liam.merwick@oracle.com>
      Reviewed-by: NJim Mattson <jmattson@google.com>
      Signed-off-by: NLiran Alon <liran.alon@oracle.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3c7670d5
    • T
      netfilter: nf_conncount: remove wrong condition check routine · 8038f92d
      Taehee Yoo 提交于
      [ Upstream commit 53ca0f2f ]
      
      All lists that reach the tree_nodes_free() function have both zero
      counter and true dead flag. The reason for this is that lists to be
      release are selected by nf_conncount_gc_list() which already decrements
      the list counter and sets on the dead flag. Therefore, this if statement
      in tree_nodes_free() is unnecessary and wrong.
      
      Fixes: 31568ec0 ("netfilter: nf_conncount: fix list_del corruption in conn_free")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8038f92d
    • T
      netfilter: nat: fix double register in masquerade modules · 5517d4c6
      Taehee Yoo 提交于
      [ Upstream commit 095faf45e64be00bff4da2d6182dface3d69c9b7 ]
      
      There is a reference counter to ensure that masquerade modules register
      notifiers only once. However, the existing reference counter approach is
      not safe, test commands are:
      
         while :
         do
         	   modprobe ip6t_MASQUERADE &
      	   modprobe nft_masq_ipv6 &
      	   modprobe -rv ip6t_MASQUERADE &
      	   modprobe -rv nft_masq_ipv6 &
         done
      
      numbers below represent the reference counter.
      --------------------------------------------------------
      CPU0        CPU1        CPU2        CPU3        CPU4
      [insmod]    [insmod]    [rmmod]     [rmmod]     [insmod]
      --------------------------------------------------------
      0->1
      register    1->2
                  returns     2->1
      			returns     1->0
                                                      0->1
                                                      register <--
                                          unregister
      --------------------------------------------------------
      
      The unregistation of CPU3 should be processed before the
      registration of CPU4.
      
      In order to fix this, use a mutex instead of reference counter.
      
      splat looks like:
      [  323.869557] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [modprobe:1381]
      [  323.869574] Modules linked in: nf_tables(+) nf_nat_ipv6(-) nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 n]
      [  323.869574] irq event stamp: 194074
      [  323.898930] hardirqs last  enabled at (194073): [<ffffffff90004a0d>] trace_hardirqs_on_thunk+0x1a/0x1c
      [  323.898930] hardirqs last disabled at (194074): [<ffffffff90004a29>] trace_hardirqs_off_thunk+0x1a/0x1c
      [  323.898930] softirqs last  enabled at (182132): [<ffffffff922006ec>] __do_softirq+0x6ec/0xa3b
      [  323.898930] softirqs last disabled at (182109): [<ffffffff90193426>] irq_exit+0x1a6/0x1e0
      [  323.898930] CPU: 0 PID: 1381 Comm: modprobe Not tainted 4.20.0-rc2+ #27
      [  323.898930] RIP: 0010:raw_notifier_chain_register+0xea/0x240
      [  323.898930] Code: 3c 03 0f 8e f2 00 00 00 44 3b 6b 10 7f 4d 49 bc 00 00 00 00 00 fc ff df eb 22 48 8d 7b 10 488
      [  323.898930] RSP: 0018:ffff888101597218 EFLAGS: 00000206 ORIG_RAX: ffffffffffffff13
      [  323.898930] RAX: 0000000000000000 RBX: ffffffffc04361c0 RCX: 0000000000000000
      [  323.898930] RDX: 1ffffffff26132ae RSI: ffffffffc04aa3c0 RDI: ffffffffc04361d0
      [  323.898930] RBP: ffffffffc04361c8 R08: 0000000000000000 R09: 0000000000000001
      [  323.898930] R10: ffff8881015972b0 R11: fffffbfff26132c4 R12: dffffc0000000000
      [  323.898930] R13: 0000000000000000 R14: 1ffff110202b2e44 R15: ffffffffc04aa3c0
      [  323.898930] FS:  00007f813ed41540(0000) GS:ffff88811ae00000(0000) knlGS:0000000000000000
      [  323.898930] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  323.898930] CR2: 0000559bf2c9f120 CR3: 000000010bc80000 CR4: 00000000001006f0
      [  323.898930] Call Trace:
      [  323.898930]  ? atomic_notifier_chain_register+0x2d0/0x2d0
      [  323.898930]  ? down_read+0x150/0x150
      [  323.898930]  ? sched_clock_cpu+0x126/0x170
      [  323.898930]  ? nf_tables_core_module_init+0xe4/0xe4 [nf_tables]
      [  323.898930]  ? nf_tables_core_module_init+0xe4/0xe4 [nf_tables]
      [  323.898930]  register_netdevice_notifier+0xbb/0x790
      [  323.898930]  ? __dev_close_many+0x2d0/0x2d0
      [  323.898930]  ? __mutex_unlock_slowpath+0x17f/0x740
      [  323.898930]  ? wait_for_completion+0x710/0x710
      [  323.898930]  ? nf_tables_core_module_init+0xe4/0xe4 [nf_tables]
      [  323.898930]  ? up_write+0x6c/0x210
      [  323.898930]  ? nf_tables_core_module_init+0xe4/0xe4 [nf_tables]
      [  324.127073]  ? nf_tables_core_module_init+0xe4/0xe4 [nf_tables]
      [  324.127073]  nft_chain_filter_init+0x1e/0xe8a [nf_tables]
      [  324.127073]  nf_tables_module_init+0x37/0x92 [nf_tables]
      [ ... ]
      
      Fixes: 8dd33cc9 ("netfilter: nf_nat: generalize IPv4 masquerading support for nf_tables")
      Fixes: be6b635c ("netfilter: nf_nat: generalize IPv6 masquerading support for nf_tables")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5517d4c6
    • T
      netfilter: add missing error handling code for register functions · 18218f82
      Taehee Yoo 提交于
      [ Upstream commit 584eab291c67894cb17cc87544b9d086228ea70f ]
      
      register_{netdevice/inetaddr/inet6addr}_notifier may return an error
      value, this patch adds the code to handle these error paths.
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      18218f82
    • A
      IB/mlx5: Fix page fault handling for MW · 4f03e063
      Artemy Kovalyov 提交于
      [ Upstream commit 75b7b86bdb0df37e08e44b6c1f99010967f81944 ]
      
      Memory windows are implemented with an indirect MKey, when a page fault
      event comes for a MW Mkey we need to find the MR at the end of the list of
      the indirect MKeys by iterating on all items from the first to the last.
      
      The offset calculated during this process has to be zeroed after the first
      iteration or the next iteration will start from a wrong address, resulting
      incorrect ODP faulting behavior.
      
      Fixes: db570d7d ("IB/mlx5: Add ODP support to MW")
      Signed-off-by: NArtemy Kovalyov <artemyko@mellanox.com>
      Signed-off-by: NMoni Shoua <monis@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4f03e063
    • A
      netfilter: ipv6: Preserve link scope traffic original oif · 9838090d
      Alin Nastac 提交于
      [ Upstream commit 508b09046c0f21678652fb66fd1e9959d55591d2 ]
      
      When ip6_route_me_harder is invoked, it resets outgoing interface of:
        - link-local scoped packets sent by neighbor discovery
        - multicast packets sent by MLD host
        - multicast packets send by MLD proxy daemon that sets outgoing
          interface through IPV6_PKTINFO ipi6_ifindex
      
      Link-local and multicast packets must keep their original oif after
      ip6_route_me_harder is called.
      Signed-off-by: NAlin Nastac <alin.nastac@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9838090d
    • C
      drm/meson: add support for 1080p25 mode · bf6f1276
      Christian Hewitt 提交于
      [ Upstream commit 31e1ab494559fb46de304cc6c2aed1528f94b298 ]
      
      This essential mode for PAL users is missing, so add it.
      
      Fixes: 335e3713 ("drm/meson: Add support for HDMI venc modes and settings")
      Signed-off-by: NChristian Hewitt <christianshewitt@gmail.com>
      Acked-by: NNeil Armstrong <narmstrong@baylibre.com>
      Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1542793169-13008-1-git-send-email-christianshewitt@gmail.comSigned-off-by: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      bf6f1276
    • M
      thunderbolt: Prevent root port runtime suspend during NVM upgrade · 5dda1e7d
      Mika Westerberg 提交于
      [ Upstream commit 1830b6eeda1fed42d85f2388f79c926331a9b2d0 ]
      
      During NVM upgrade process the host router is hot-removed for a short
      while. During this time it is possible that the root port is moved into
      D3cold which would be fine if the root port could trigger PME on itself.
      However, many systems actually do not implement it so what happens is
      that the root port goes into D3cold and never wakes up unless userspace
      does PCI config space access, such as running 'lscpi'.
      
      For this reason we explicitly prevent the root port from runtime
      suspending during NVM upgrade.
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5dda1e7d
    • A
      USB: omap_udc: fix rejection of out transfers when DMA is used · 9ca88f3c
      Aaro Koskinen 提交于
      [ Upstream commit 069caf5950dfa75d0526cd89c439ff9d9d3136d8 ]
      
      Commit 387f869d ("usb: gadget: u_ether: conditionally align
      transfer size") started aligning transfer size only if requested,
      breaking omap_udc DMA mode. Set quirk_ep_out_aligned_size to restore
      the old behaviour.
      
      Fixes: 387f869d ("usb: gadget: u_ether: conditionally align transfer size")
      Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9ca88f3c
    • A
      USB: omap_udc: fix USB gadget functionality on Palm Tungsten E · b5812813
      Aaro Koskinen 提交于
      [ Upstream commit 2c2322fbcab8102b8cadc09d66714700a2da42c2 ]
      
      On Palm TE nothing happens when you try to use gadget drivers and plug
      the USB cable. Fix by adding the board to the vbus sense quirk list.
      Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b5812813
    • A
      USB: omap_udc: fix omap_udc_start() on 15xx machines · 634395d2
      Aaro Koskinen 提交于
      [ Upstream commit 6ca6695f576b8453fe68865e84d25946d63b10ad ]
      
      On OMAP 15xx machines there are no transceivers, and omap_udc_start()
      always fails as it forgot to adjust the default return value.
      Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      634395d2
    • A
      USB: omap_udc: fix crashes on probe error and module removal · 27b61cba
      Aaro Koskinen 提交于
      [ Upstream commit 99f700366fcea1aa2fa3c49c99f371670c3c62f8 ]
      
      We currently crash if usb_add_gadget_udc_release() fails, since the
      udc->done is not initialized until in the remove function.
      Furthermore, on module removal the udc data is accessed although
      the release function is already triggered by usb_del_gadget_udc()
      early in the function.
      
      Fix by rewriting the release and remove functions, basically moving
      all the cleanup into the release function, and doing the completion
      only in the module removal case.
      
      The patch fixes omap_udc module probe with a failing gadged, and also
      allows the removal of omap_udc. Tested by running "modprobe omap_udc;
      modprobe -r omap_udc" in a loop.
      Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      27b61cba
    • A
      USB: omap_udc: use devm_request_irq() · 66d73a4e
      Aaro Koskinen 提交于
      [ Upstream commit 286afdde1640d8ea8916a0f05e811441fbbf4b9d ]
      
      The current code fails to release the third irq on the error path
      (observed by reading the code), and we get also multiple WARNs with
      failing gadget drivers due to duplicate IRQ releases. Fix by using
      devm_request_irq().
      Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      66d73a4e
    • X
      ipvs: call ip_vs_dst_notifier earlier than ipv6_dev_notf · 28ad9091
      Xin Long 提交于
      [ Upstream commit 2a31e4bd ]
      
      ip_vs_dst_event is supposed to clean up all dst used in ipvs'
      destinations when a net dev is going down. But it works only
      when the dst's dev is the same as the dev from the event.
      
      Now with the same priority but late registration,
      ip_vs_dst_notifier is always called later than ipv6_dev_notf
      where the dst's dev is set to lo for NETDEV_DOWN event.
      
      As the dst's dev lo is not the same as the dev from the event
      in ip_vs_dst_event, ip_vs_dst_notifier doesn't actually work.
      Also as these dst have to wait for dest_trash_timer to clean
      them up. It would cause some non-permanent kernel warnings:
      
        unregister_netdevice: waiting for br0 to become free. Usage count = 3
      
      To fix it, call ip_vs_dst_notifier earlier than ipv6_dev_notf
      by increasing its priority to ADDRCONF_NOTIFY_PRIORITY + 5.
      
      Note that for ipv4 route fib_netdev_notifier doesn't set dst's
      dev to lo in NETDEV_DOWN event, so this fix is only needed when
      IP_VS_IPV6 is defined.
      
      Fixes: 7a4f0761 ("IPVS: init and cleanup restructuring")
      Reported-by: NLi Shuang <shuali@redhat.com>
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NJulian Anastasov <ja@ssi.bg>
      Acked-by: NSimon Horman <horms@verge.net.au>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      28ad9091
    • A
      fsi: master-ast-cf: select GENERIC_ALLOCATOR · 2aad202f
      Arnd Bergmann 提交于
      [ Upstream commit 64999fa7aa2c076ec6d05aee481f11f5296ceb8c ]
      
      In randconfig builds without CONFIG_GENERIC_ALLOCATOR, this driver
      fails to link:
      
      ERROR: "gen_pool_alloc_algo" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
      ERROR: "gen_pool_fixed_alloc" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
      ERROR: "of_gen_pool_get" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
      ERROR: "gen_pool_free" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
      
      Select the dependency as all other users do.
      
      Fixes: 6a794a27 ("fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2aad202f
    • M
      bpf: fix check of allowed specifiers in bpf_trace_printk · 6bfebeda
      Martynas Pumputis 提交于
      [ Upstream commit 1efb6ee3edea57f57f9fb05dba8dcb3f7333f61f ]
      
      A format string consisting of "%p" or "%s" followed by an invalid
      specifier (e.g. "%p%\n" or "%s%") could pass the check which
      would make format_decode (lib/vsprintf.c) to warn.
      
      Fixes: 9c959c86 ("tracing: Allow BPF programs to call bpf_trace_printk()")
      Reported-by: syzbot+1ec5c5ec949c4adaa0c4@syzkaller.appspotmail.com
      Signed-off-by: NMartynas Pumputis <m@lambda.lt>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      6bfebeda
    • Y
      RDMA/hns: Bugfix pbl configuration for rereg mr · 4c7d50c2
      Yixian Liu 提交于
      [ Upstream commit ca088320 ]
      
      Current hns driver assigned the first two PBL page addresses from previous
      registered MR to the hardware when reregister MR changing the memory
      locations occurred. This will lead to PBL addressing error as the PBL has
      already been released. This patch fixes this wrong assignment by using the
      page address from new allocated PBL.
      
      Fixes: a2c80b7b ("RDMA/hns: Add rereg mr support for hip08")
      Signed-off-by: NYixian Liu <liuyixian@huawei.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4c7d50c2
    • P
      exportfs: do not read dentry after free · ad374d10
      Pan Bian 提交于
      [ Upstream commit 2084ac6c ]
      
      The function dentry_connected calls dput(dentry) to drop the previously
      acquired reference to dentry. In this case, dentry can be released.
      After that, IS_ROOT(dentry) checks the condition
      (dentry == dentry->d_parent), which may result in a use-after-free bug.
      This patch directly compares dentry with its parent obtained before
      dropping the reference.
      
      Fixes: a056cc89("exportfs: stop retrying once we race with
      rename/remove")
      Signed-off-by: NPan Bian <bianpan2016@163.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ad374d10
    • P
      ASoC: omap-dmic: Add pm_qos handling to avoid overruns with CPU_IDLE · 0aeda300
      Peter Ujfalusi 提交于
      [ Upstream commit ffdcc3638c58d55a6fa68b6e5dfd4fb4109652eb ]
      
      We need to block sleep states which would require longer time to leave than
      the time the DMA must react to the DMA request in order to keep the FIFO
      serviced without overrun.
      Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      Acked-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0aeda300
    • P
      ASoC: omap-mcpdm: Add pm_qos handling to avoid under/overruns with CPU_IDLE · 38f3a0f0
      Peter Ujfalusi 提交于
      [ Upstream commit 373a500e34aea97971c9d71e45edad458d3da98f ]
      
      We need to block sleep states which would require longer time to leave than
      the time the DMA must react to the DMA request in order to keep the FIFO
      serviced without under of overrun.
      Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      Acked-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      38f3a0f0
    • P
      ASoC: omap-mcbsp: Fix latency value calculation for pm_qos · abf72013
      Peter Ujfalusi 提交于
      [ Upstream commit dd2f52d8991af9fe0928d59ec502ba52be7bc38d ]
      
      The latency number is in usec for the pm_qos. Correct the calculation to
      give us the time in usec
      Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      Acked-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      abf72013
    • J
      tools: bpftool: fix potential NULL pointer dereference in do_load · 1f1aedd6
      Jakub Kicinski 提交于
      [ Upstream commit dde7011a824cfa815b03f853ec985ff46b740939 ]
      
      This patch fixes a possible null pointer dereference in
      do_load, detected by the semantic patch deref_null.cocci,
      with the following warning:
      
      ./tools/bpf/bpftool/prog.c:1021:23-25: ERROR: map_replace is NULL but dereferenced.
      
      The following code has potential null pointer references:
      881             map_replace = reallocarray(map_replace, old_map_fds + 1,
      882                                        sizeof(*map_replace));
      883             if (!map_replace) {
      884                     p_err("mem alloc failed");
      885                     goto err_free_reuse_maps;
      886             }
      
      ...
      1019 err_free_reuse_maps:
      1020         for (i = 0; i < old_map_fds; i++)
      1021                 close(map_replace[i].fd);
      1022         free(map_replace);
      
      Fixes: 3ff5a4dc ("tools: bpftool: allow reuse of maps with bpftool prog load")
      Co-developed-by: NWen Yang <wen.yang99@zte.com.cn>
      Signed-off-by: NWen Yang <wen.yang99@zte.com.cn>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1f1aedd6
    • K
      RDMA/rdmavt: Fix rvt_create_ah function signature · 8653ffc3
      Kamal Heib 提交于
      [ Upstream commit 4f32fb92 ]
      
      rdmavt uses a crazy system that looses the type checking when assinging
      functions to struct ib_device function pointers. Because of this the
      signature to this function was not changed when the below commit revised
      things.
      
      Fix the signature so we are not calling a function pointer with a
      mismatched signature.
      
      Fixes: 477864c8 ("IB/core: Let create_ah return extended response to user")
      Signed-off-by: NKamal Heib <kamalheib1@gmail.com>
      Reviewed-by: NDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8653ffc3
    • S
      RDMA/bnxt_re: Avoid accessing the device structure after it is freed · 59315d0c
      Selvin Xavier 提交于
      [ Upstream commit a6c66d6a08b88cc10aca9d3f65cfae31e7652a99 ]
      
      When bnxt_re_ib_reg returns failure, the device structure gets
      freed. Driver tries to access the device pointer
      after it is freed.
      
      [ 4871.034744] Failed to register with netedev: 0xffffffa1
      [ 4871.034765] infiniband (null): Failed to register with IB: 0xffffffea
      [ 4871.046430] ==================================================================
      [ 4871.046437] BUG: KASAN: use-after-free in bnxt_re_task+0x63/0x180 [bnxt_re]
      [ 4871.046439] Write of size 4 at addr ffff880fa8406f48 by task kworker/u48:2/17813
      
      [ 4871.046443] CPU: 20 PID: 17813 Comm: kworker/u48:2 Kdump: loaded Tainted: G B OE  4.20.0-rc1+ #42
      [ 4871.046444] Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.0.4 08/28/2014
      [ 4871.046447] Workqueue: bnxt_re bnxt_re_task [bnxt_re]
      [ 4871.046449] Call Trace:
      [ 4871.046454]  dump_stack+0x91/0xeb
      [ 4871.046458]  print_address_description+0x6a/0x2a0
      [ 4871.046461]  kasan_report+0x176/0x2d0
      [ 4871.046463]  ? bnxt_re_task+0x63/0x180 [bnxt_re]
      [ 4871.046466]  bnxt_re_task+0x63/0x180 [bnxt_re]
      [ 4871.046470]  process_one_work+0x216/0x5b0
      [ 4871.046471]  ? process_one_work+0x189/0x5b0
      [ 4871.046475]  worker_thread+0x4e/0x3d0
      [ 4871.046479]  kthread+0x10e/0x140
      [ 4871.046480]  ? process_one_work+0x5b0/0x5b0
      [ 4871.046482]  ? kthread_stop+0x220/0x220
      [ 4871.046486]  ret_from_fork+0x3a/0x50
      
      [ 4871.046492] The buggy address belongs to the page:
      [ 4871.046494] page:ffffea003ea10180 count:0 mapcount:0 mapping:0000000000000000 index:0x0
      [ 4871.046495] flags: 0x57ffffc0000000()
      [ 4871.046498] raw: 0057ffffc0000000 0000000000000000 ffffea003ea10188 0000000000000000
      [ 4871.046500] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
      [ 4871.046501] page dumped because: kasan: bad access detected
      
      Avoid accessing the device structure once it is freed.
      
      Fixes: 497158aa ("RDMA/bnxt_re: Fix the ib_reg failure cleanup")
      Signed-off-by: NSelvin Xavier <selvin.xavier@broadcom.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      59315d0c
    • S
      RDMA/bnxt_re: Fix system hang when registration with L2 driver fails · f4515855
      Selvin Xavier 提交于
      [ Upstream commit 3c4b1419c33c2417836a63f8126834ee36968321 ]
      
      Driver doesn't release rtnl lock if registration with
      L2 driver (bnxt_re_register_netdev) fais and this causes
      hang while requesting for the next lock.
      
      [  371.635416] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [  371.635417] kworker/u48:1   D    0   634      2 0x80000000
      [  371.635423] Workqueue: bnxt_re bnxt_re_task [bnxt_re]
      [  371.635424] Call Trace:
      [  371.635426]  ? __schedule+0x36b/0xbd0
      [  371.635429]  schedule+0x39/0x90
      [  371.635430]  schedule_preempt_disabled+0x11/0x20
      [  371.635431]  __mutex_lock+0x45b/0x9c0
      [  371.635433]  ? __mutex_lock+0x16d/0x9c0
      [  371.635435]  ? bnxt_re_ib_reg+0x2b/0xb30 [bnxt_re]
      [  371.635438]  ? wake_up_klogd+0x37/0x40
      [  371.635442]  bnxt_re_ib_reg+0x2b/0xb30 [bnxt_re]
      [  371.635447]  bnxt_re_task+0xfd/0x180 [bnxt_re]
      [  371.635449]  process_one_work+0x216/0x5b0
      [  371.635450]  ? process_one_work+0x189/0x5b0
      [  371.635453]  worker_thread+0x4e/0x3d0
      [  371.635455]  kthread+0x10e/0x140
      [  371.635456]  ? process_one_work+0x5b0/0x5b0
      [  371.635458]  ? kthread_stop+0x220/0x220
      [  371.635460]  ret_from_fork+0x3a/0x50
      [  371.635477] INFO: task NetworkManager:1228 blocked for more than 120 seconds.
      [  371.635478]       Tainted: G    B      OE     4.20.0-rc1+ #42
      [  371.635479] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      
      Release the rtnl_lock correctly in the failure path.
      
      Fixes: de5c95d0 ("RDMA/bnxt_re: Fix system crash during RDMA resource initialization")
      Signed-off-by: NSelvin Xavier <selvin.xavier@broadcom.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f4515855
    • P
      RDMA/core: Add GIDs while changing MAC addr only for registered ndev · 5a49ef98
      Parav Pandit 提交于
      [ Upstream commit d52ef88a9f4be523425730da3239cf87bee936da ]
      
      Currently when MAC address is changed, regardless of the netdev reg_state,
      GID entries are removed and added to reflect the new MAC address and new
      default GID entries.
      
      When a bonding device is used and the underlying PCI device is removed
      several netdevice events are generated. Two events of the interest are
      CHANGEADDR and UNREGISTER event on lower(slave) netdevice of the bond
      netdevice.
      
      Sometimes CHANGEADDR event is generated when netdev state is
      UNREGISTERING (after UNREGISTER event is generated). In this scenario, GID
      entries for default GIDs are added and never deleted because GID entries
      are deleted only when netdev state is < UNREGISTERED.
      
      This leads to non zero reference count on the netdevice. Due to this, PCI
      device unbind operation is getting stuck.
      
      To avoid it, when changing mac address, add GID entries only if netdev is
      in REGISTERED state.
      
      Fixes: 03db3a2d ("IB/core: Add RoCE GID table management")
      Signed-off-by: NParav Pandit <parav@mellanox.com>
      Reviewed-by: NMark Bloch <markb@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5a49ef98
    • M
      RDMA/mlx5: Fix fence type for IB_WR_LOCAL_INV WR · 7c736fee
      Majd Dibbiny 提交于
      [ Upstream commit 074fca3a18e7e1e0d4d7dcc9d7badc43b90232f4 ]
      
      Currently, for IB_WR_LOCAL_INV WR, when the next fence is None, the
      current fence will be SMALL instead of Normal Fence.
      
      Without this patch krping doesn't work on CX-5 devices and throws
      following error:
      
      The error messages are from CX5 driver are: (from server side)
      [ 710.434014] mlx5_0:dump_cqe:278:(pid 2712): dump error cqe
      [ 710.434016] 00000000 00000000 00000000 00000000
      [ 710.434016] 00000000 00000000 00000000 00000000
      [ 710.434017] 00000000 00000000 00000000 00000000
      [ 710.434018] 00000000 93003204 100000b8 000524d2
      [ 710.434019] krping: cq completion failed with wr_id 0 status 4 opcode 128 vender_err 32
      
      Fixed the logic to set the correct fence type.
      
      Fixes: 6e8484c5 ("RDMA/mlx5: set UMR wqe fence according to HCA cap")
      Signed-off-by: NMajd Dibbiny <majd@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7c736fee
    • R
      Btrfs: send, fix infinite loop due to directory rename dependencies · 91f6a9aa
      Robbie Ko 提交于
      [ Upstream commit a4390aee72713d9e73f1132bcdeb17d72fbbf974 ]
      
      When doing an incremental send, due to the need of delaying directory move
      (rename) operations we can end up in infinite loop at
      apply_children_dir_moves().
      
      An example scenario that triggers this problem is described below, where
      directory names correspond to the numbers of their respective inodes.
      
      Parent snapshot:
      
       .
       |--- 261/
             |--- 271/
                   |--- 266/
                         |--- 259/
                         |--- 260/
                         |     |--- 267
                         |
                         |--- 264/
                         |     |--- 258/
                         |           |--- 257/
                         |
                         |--- 265/
                         |--- 268/
                         |--- 269/
                         |     |--- 262/
                         |
                         |--- 270/
                         |--- 272/
                         |     |--- 263/
                         |     |--- 275/
                         |
                         |--- 274/
                               |--- 273/
      
      Send snapshot:
      
       .
       |-- 275/
            |-- 274/
                 |-- 273/
                      |-- 262/
                           |-- 269/
                                |-- 258/
                                     |-- 271/
                                          |-- 268/
                                               |-- 267/
                                                    |-- 270/
                                                         |-- 259/
                                                         |    |-- 265/
                                                         |
                                                         |-- 272/
                                                              |-- 257/
                                                                   |-- 260/
                                                                   |-- 264/
                                                                        |-- 263/
                                                                             |-- 261/
                                                                                  |-- 266/
      
      When processing inode 257 we delay its move (rename) operation because its
      new parent in the send snapshot, inode 272, was not yet processed. Then
      when processing inode 272, we delay the move operation for that inode
      because inode 274 is its ancestor in the send snapshot. Finally we delay
      the move operation for inode 274 when processing it because inode 275 is
      its new parent in the send snapshot and was not yet moved.
      
      When finishing processing inode 275, we start to do the move operations
      that were previously delayed (at apply_children_dir_moves()), resulting in
      the following iterations:
      
      1) We issue the move operation for inode 274;
      
      2) Because inode 262 depended on the move operation of inode 274 (it was
         delayed because 274 is its ancestor in the send snapshot), we issue the
         move operation for inode 262;
      
      3) We issue the move operation for inode 272, because it was delayed by
         inode 274 too (ancestor of 272 in the send snapshot);
      
      4) We issue the move operation for inode 269 (it was delayed by 262);
      
      5) We issue the move operation for inode 257 (it was delayed by 272);
      
      6) We issue the move operation for inode 260 (it was delayed by 272);
      
      7) We issue the move operation for inode 258 (it was delayed by 269);
      
      8) We issue the move operation for inode 264 (it was delayed by 257);
      
      9) We issue the move operation for inode 271 (it was delayed by 258);
      
      10) We issue the move operation for inode 263 (it was delayed by 264);
      
      11) We issue the move operation for inode 268 (it was delayed by 271);
      
      12) We verify if we can issue the move operation for inode 270 (it was
          delayed by 271). We detect a path loop in the current state, because
          inode 267 needs to be moved first before we can issue the move
          operation for inode 270. So we delay again the move operation for
          inode 270, this time we will attempt to do it after inode 267 is
          moved;
      
      13) We issue the move operation for inode 261 (it was delayed by 263);
      
      14) We verify if we can issue the move operation for inode 266 (it was
          delayed by 263). We detect a path loop in the current state, because
          inode 270 needs to be moved first before we can issue the move
          operation for inode 266. So we delay again the move operation for
          inode 266, this time we will attempt to do it after inode 270 is
          moved (its move operation was delayed in step 12);
      
      15) We issue the move operation for inode 267 (it was delayed by 268);
      
      16) We verify if we can issue the move operation for inode 266 (it was
          delayed by 270). We detect a path loop in the current state, because
          inode 270 needs to be moved first before we can issue the move
          operation for inode 266. So we delay again the move operation for
          inode 266, this time we will attempt to do it after inode 270 is
          moved (its move operation was delayed in step 12). So here we added
          again the same delayed move operation that we added in step 14;
      
      17) We attempt again to see if we can issue the move operation for inode
          266, and as in step 16, we realize we can not due to a path loop in
          the current state due to a dependency on inode 270. Again we delay
          inode's 266 rename to happen after inode's 270 move operation, adding
          the same dependency to the empty stack that we did in steps 14 and 16.
          The next iteration will pick the same move dependency on the stack
          (the only entry) and realize again there is still a path loop and then
          again the same dependency to the stack, over and over, resulting in
          an infinite loop.
      
      So fix this by preventing adding the same move dependency entries to the
      stack by removing each pending move record from the red black tree of
      pending moves. This way the next call to get_pending_dir_moves() will
      not return anything for the current parent inode.
      
      A test case for fstests, with this reproducer, follows soon.
      Signed-off-by: NRobbie Ko <robbieko@synology.com>
      Reviewed-by: NFilipe Manana <fdmanana@suse.com>
      [Wrote changelog with example and more clear explanation]
      Signed-off-by: NFilipe Manana <fdmanana@suse.com>
      Signed-off-by: NDavid Sterba <dsterba@suse.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      91f6a9aa
    • R
      ARM: dts: at91: sama5d2: use the divided clock for SMC · b3159470
      Romain Izard 提交于
      [ Upstream commit 4ab7ca092c3c7ac8b16aa28eba723a8868f82f14 ]
      
      The SAMA5D2 is different from SAMA5D3 and SAMA5D4, as there are two
      different clocks for the peripherals in the SoC. The Static Memory
      controller is connected to the divided master clock.
      
      Unfortunately, the device tree does not correctly show this and uses the
      master clock directly. This clock is then used by the code for the NAND
      controller to calculate the timings for the controller, and we end up with
      slow NAND Flash access.
      
      Fix the device tree, and the performance of Flash access is improved.
      Signed-off-by: NRomain Izard <romain.izard.pro@gmail.com>
      Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b3159470
    • M
      phy: qcom-qusb2: Fix HSTX_TRIM tuning with fused value for SDM845 · 4724b50f
      Manu Gautam 提交于
      [ Upstream commit c88520db18ba0b9a41326c3b8680e7c09eb4c381 ]
      
      Tune1 register on sdm845 is used to update HSTX_TRIM with fused
      setting. Enable same by specifying update_tune1_with_efuse flag
      for sdm845, otherwise driver ends up programming tune2 register.
      
      Fixes: ef17f6e2 ("phy: qcom-qusb2: Add QUSB2 PHYs support for sdm845")
      Signed-off-by: NManu Gautam <mgautam@codeaurora.org>
      Reviewed-by: NDouglas Anderson <dianders@chromium.org>
      Reviewed-by: NStephen Boyd <swboyd@chromium.org>
      Acked-by: NVivek Gautam <vivek.gautam@codeaurora.org>
      Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4724b50f
    • M
      phy: qcom-qusb2: Use HSTX_TRIM fused value as is · d801a3ef
      Manu Gautam 提交于
      [ Upstream commit 6e34d358 ]
      
      Fix HSTX_TRIM tuning logic which instead of using fused value
      as HSTX_TRIM, incorrectly performs bitwise OR operation with
      existing default value.
      
      Fixes: ca04d9d3 ("phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips")
      Signed-off-by: NManu Gautam <mgautam@codeaurora.org>
      Reviewed-by: NDouglas Anderson <dianders@chromium.org>
      Reviewed-by: NStephen Boyd <swboyd@chromium.org>
      Acked-by: NVivek Gautam <vivek.gautam@codeaurora.org>
      Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d801a3ef
    • A
      objtool: Fix segfault in .cold detection with -ffunction-sections · 3d2d2ba0
      Artem Savkov 提交于
      [ Upstream commit 22566c16 ]
      
      Because find_symbol_by_name() traverses the same lists as
      read_symbols(), changing sym->name in place without copying it affects
      the result of find_symbol_by_name().  In the case where a ".cold"
      function precedes its parent in sec->symbol_list, it can result in a
      function being considered a parent of itself. This leads to function
      length being set to 0 and other consequent side-effects including a
      segfault in add_switch_table().  The effects of this bug are only
      visible when building with -ffunction-sections in KCFLAGS.
      
      Fix by copying the search string instead of modifying it in place.
      Signed-off-by: NArtem Savkov <asavkov@redhat.com>
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 13810435 ("objtool: Support GCC 8's cold subfunctions")
      Link: http://lkml.kernel.org/r/910abd6b5a4945130fd44f787c24e07b9e07c8da.1542736240.git.jpoimboe@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3d2d2ba0
    • A
      objtool: Fix double-free in .cold detection error path · 79cd7b0e
      Artem Savkov 提交于
      [ Upstream commit 0b9301fb ]
      
      If read_symbols() fails during second list traversal (the one dealing
      with ".cold" subfunctions) it frees the symbol, but never deletes it
      from the list/hash_table resulting in symbol being freed again in
      elf_close(). Fix it by just returning an error, leaving cleanup to
      elf_close().
      Signed-off-by: NArtem Savkov <asavkov@redhat.com>
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 13810435 ("objtool: Support GCC 8's cold subfunctions")
      Link: http://lkml.kernel.org/r/beac5a9b7da9e8be90223459dcbe07766ae437dd.1542736240.git.jpoimboe@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      79cd7b0e
    • K
      ASoC: acpi: fix: continue searching when machine is ignored · a8657e68
      Keyon Jie 提交于
      [ Upstream commit a3e620f8 ]
      
      The machine_quirk may return NULL which means the acpi entries should be
      skipped and search for next matched entry is needed, here add return
      check here and continue for NULL case.
      Signed-off-by: NKeyon Jie <yang.jie@linux.intel.com>
      Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a8657e68
    • T
      PCI: imx6: Fix link training status detection in link up check · 2a031cab
      Trent Piepho 提交于
      [ Upstream commit 68bc10bf ]
      
      This bug was introduced in the interaction for two commits on either
      branch of the merge commit 562df5c8 ("Merge branch
      'pci/host-designware' into next").
      
      Commit 4d107d3b ("PCI: imx6: Move link up check into
      imx6_pcie_wait_for_link()"), changed imx6_pcie_wait_for_link() to poll
      the link status register directly, checking for link up and not
      training, and made imx6_pcie_link_up() only check the link up bit (once,
      not a polling loop).
      
      While commit 886bc5ce ("PCI: designware: Add generic
      dw_pcie_wait_for_link()"), replaced the loop in
      imx6_pcie_wait_for_link() with a call to a new dwc core function, which
      polled imx6_pcie_link_up(), which still checked both link up and not
      training in a loop.
      
      When these two commits were merged, the version of
      imx6_pcie_wait_for_link() from 886bc5ce was kept, which eliminated
      the link training check placed there by 4d107d3b. However, the
      version of imx6_pcie_link_up() from 4d107d3b was kept, which
      eliminated the link training check that had been there and was moved to
      imx6_pcie_wait_for_link().
      
      The result was the link training check got lost for the imx6 driver.
      
      Eliminate imx6_pcie_link_up() so that the default handler,
      dw_pcie_link_up(), is used instead. The default handler has the correct
      code, which checks for link up and also that it still is not training,
      fixing the regression.
      
      Fixes: 562df5c8 ("Merge branch 'pci/host-designware' into next")
      Signed-off-by: NTrent Piepho <tpiepho@impinj.com>
      [lorenzo.pieralisi@arm.com: rewrote the commit log]
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Reviewed-by: NLucas Stach <l.stach@pengutronix.de>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Joao Pinto <Joao.Pinto@synopsys.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Richard Zhu <hongxing.zhu@nxp.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2a031cab