1. 17 Dec, 2018 40 commits
    • Pan Bian's avatar
      hfs: do not free node before using · 5ee5fa61
      Pan Bian authored
      [ Upstream commit ce96a407 ]
      
      hfs_bmap_free() frees the node via hfs_bnode_put(node).  However, it
      then reads node->this when dumping error message on an error path, which
      may result in a use-after-free bug.  This patch frees the node only when
      it is never again used.
      
      Link: http://lkml.kernel.org/r/1542963889-128825-1-git-send-email-bianpan2016@163.com
      
      
      Fixes: a1185ffa2fc ("HFS rewrite")
      Signed-off-by: default avatarPan Bian <bianpan2016@163.com>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Joe Perches <joe@perches.com>
      Cc: Ernesto A. Fernandez <ernesto.mnd.fernandez@gmail.com>
      Cc: Viacheslav Dubeyko <slava@dubeyko.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5ee5fa61
    • Wei Yang's avatar
      mm/page_alloc.c: fix calculation of pgdat->nr_zones · c7aafad0
      Wei Yang authored
      [ Upstream commit 8f416836 ]
      
      init_currently_empty_zone() will adjust pgdat->nr_zones and set it to
      'zone_idx(zone) + 1' unconditionally.  This is correct in the normal
      case, while not exact in hot-plug situation.
      
      This function is used in two places:
      
        * free_area_init_core()
        * move_pfn_range_to_zone()
      
      In the first case, we are sure zone index increase monotonically.  While
      in the second one, this is under users control.
      
      One way to reproduce this is:
      ----------------------------
      
      1. create a virtual machine with empty node1
      
         -m 4G,slots=32,maxmem=32G \
         -smp 4,maxcpus=8          \
         -numa node,nodeid=0,mem=4G,cpus=0-3 \
         -numa node,nodeid=1,mem=0G,cpus=4-7
      
      2. hot-add cpu 3-7
      
         cpu-add [3-7]
      
      2. hot-add memory to nod1
      
         object_add memory-backend-ram,id=ram0,size=1G
         device_add pc-dimm,id=dimm0,memdev=ram0,node=1
      
      3. online memory with following order
      
         echo online_movable > memory47/state
         echo online > memory40/state
      
      After this, node1 will have its nr_zones equals to (ZONE_NORMAL + 1)
      instead of (ZONE_MOVABLE + 1).
      
      Michal said:
       "Having an incorrect nr_zones might result in all sorts of problems
        which would be quite hard to debug (e.g. reclaim not considering the
        movable zone). I do not expect many users would suffer from this it
        but still this is trivial and obviously right thing to do so
        backporting to the stable tree shouldn't be harmful (last famous
        words)"
      
      Link: http://lkml.kernel.org/r/20181117022022.9956-1-richard.weiyang@gmail.com
      Fixes: f1dd2cd1
      
       ("mm, memory_hotplug: do not associate hotadded memory to zones until online")
      Signed-off-by: default avatarWei Yang <richard.weiyang@gmail.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Reviewed-by: default avatarOscar Salvador <osalvador@suse.de>
      Cc: Anshuman Khandual <anshuman.khandual@arm.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c7aafad0
    • Larry Chen's avatar
      ocfs2: fix deadlock caused by ocfs2_defrag_extent() · df2055c0
      Larry Chen authored
      [ Upstream commit e21e5744 ]
      
      ocfs2_defrag_extent may fall into deadlock.
      
      ocfs2_ioctl_move_extents
          ocfs2_ioctl_move_extents
            ocfs2_move_extents
              ocfs2_defrag_extent
                ocfs2_lock_allocators_move_extents
      
                  ocfs2_reserve_clusters
                    inode_lock GLOBAL_BITMAP_SYSTEM_INODE
      
      	  __ocfs2_flush_truncate_log
                    inode_lock GLOBAL_BITMAP_SYSTEM_INODE
      
      As backtrace shows above, ocfs2_reserve_clusters() will call inode_lock
      against the global bitmap if local allocator has not sufficient cluters.
      Once global bitmap could meet the demand, ocfs2_reserve_cluster will
      return success with global bitmap locked.
      
      After ocfs2_reserve_cluster(), if truncate log is full,
      __ocfs2_flush_truncate_log() will definitely fall into deadlock because
      it needs to inode_lock global bitmap, which has already been locked.
      
      To fix this bug, we could remove from
      ocfs2_lock_allocators_move_extents() the code which intends to lock
      global allocator, and put the removed code after
      __ocfs2_flush_truncate_log().
      
      ocfs2_lock_allocators_move_extents() is referred by 2 places, one is
      here, the other does not need the data allocator context, which means
      this patch does not affect the caller so far.
      
      Link: http://lkml.kernel.org/r/20181101071422.14470-1-lchen@suse.com
      
      Signed-off-by: default avatarLarry Chen <lchen@suse.com>
      Reviewed-by: default avatarChangwei Ge <ge.changwei@h3c.com>
      Cc: Mark Fasheh <mark@fasheh.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: Joseph Qi <jiangqi903@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      df2055c0
    • Lorenzo Pieralisi's avatar
      ACPI/IORT: Fix iort_get_platform_device_domain() uninitialized pointer value · 8e3f3c06
      Lorenzo Pieralisi authored
      [ Upstream commit ea2412dc ]
      
      Running the Clang static analyzer on IORT code detected the following
      error:
      
      Logic error: Branch condition evaluates to a garbage value
      
      in
      
      iort_get_platform_device_domain()
      
      If the named component associated with a given device has no IORT
      mappings, iort_get_platform_device_domain() exits its MSI mapping loop
      with msi_parent pointer containing garbage, which can lead to erroneous
      code path execution.
      
      Initialize the msi_parent pointer, fixing the bug.
      
      Fixes: d4f54a18
      
       ("ACPI: platform: setup MSI domain for ACPI based
      platform device")
      Reported-by: default avatarPatrick Bellasi <patrick.bellasi@arm.com>
      Reviewed-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Cc: Sudeep Holla <sudeep.holla@arm.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8e3f3c06
    • Sagi Grimberg's avatar
      nvme: flush namespace scanning work just before removing namespaces · 9407fd14
      Sagi Grimberg authored
      [ Upstream commit f6c8e432
      
       ]
      
      nvme_stop_ctrl can be called also for reset flow and there is no need to
      flush the scan_work as namespaces are not being removed. This can cause
      deadlock in rdma, fc and loop drivers since nvme_stop_ctrl barriers
      before controller teardown (and specifically I/O cancellation of the
      scan_work itself) takes place, but the scan_work will be blocked anyways
      so there is no need to flush it.
      
      Instead, move scan_work flush to nvme_remove_namespaces() where it really
      needs to flush.
      Reported-by: default avatarMing Lei <ming.lei@redhat.com>
      Signed-off-by: default avatarSagi Grimberg <sagi@grimberg.me>
      Reviewed-by: default avatarKeith Busch <keith.busch@intel.com>
      Reviewed by: James Smart <jsmart2021@gmail.com>
      Tested-by: default avatarEwan D. Milne <emilne@redhat.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9407fd14
    • Colin Ian King's avatar
      fscache, cachefiles: remove redundant variable 'cache' · 0859bb25
      Colin Ian King authored
      [ Upstream commit 31ffa563
      
       ]
      
      Variable 'cache' is being assigned but is never used hence it is
      redundant and can be removed.
      
      Cleans up clang warning:
      warning: variable 'cache' set but not used [-Wunused-but-set-variable]
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0859bb25
    • NeilBrown's avatar
      fscache: fix race between enablement and dropping of object · 38026d1a
      NeilBrown authored
      [ Upstream commit c5a94f43
      
       ]
      
      It was observed that a process blocked indefintely in
      __fscache_read_or_alloc_page(), waiting for FSCACHE_COOKIE_LOOKING_UP
      to be cleared via fscache_wait_for_deferred_lookup().
      
      At this time, ->backing_objects was empty, which would normaly prevent
      __fscache_read_or_alloc_page() from getting to the point of waiting.
      This implies that ->backing_objects was cleared *after*
      __fscache_read_or_alloc_page was was entered.
      
      When an object is "killed" and then "dropped",
      FSCACHE_COOKIE_LOOKING_UP is cleared in fscache_lookup_failure(), then
      KILL_OBJECT and DROP_OBJECT are "called" and only in DROP_OBJECT is
      ->backing_objects cleared.  This leaves a window where
      something else can set FSCACHE_COOKIE_LOOKING_UP and
      __fscache_read_or_alloc_page() can start waiting, before
      ->backing_objects is cleared
      
      There is some uncertainty in this analysis, but it seems to be fit the
      observations.  Adding the wake in this patch will be handled correctly
      by __fscache_read_or_alloc_page(), as it checks if ->backing_objects
      is empty again, after waiting.
      
      Customer which reported the hang, also report that the hang cannot be
      reproduced with this fix.
      
      The backtrace for the blocked process looked like:
      
      PID: 29360  TASK: ffff881ff2ac0f80  CPU: 3   COMMAND: "zsh"
       #0 [ffff881ff43efbf8] schedule at ffffffff815e56f1
       #1 [ffff881ff43efc58] bit_wait at ffffffff815e64ed
       #2 [ffff881ff43efc68] __wait_on_bit at ffffffff815e61b8
       #3 [ffff881ff43efca0] out_of_line_wait_on_bit at ffffffff815e625e
       #4 [ffff881ff43efd08] fscache_wait_for_deferred_lookup at ffffffffa04f2e8f [fscache]
       #5 [ffff881ff43efd18] __fscache_read_or_alloc_page at ffffffffa04f2ffe [fscache]
       #6 [ffff881ff43efd58] __nfs_readpage_from_fscache at ffffffffa0679668 [nfs]
       #7 [ffff881ff43efd78] nfs_readpage at ffffffffa067092b [nfs]
       #8 [ffff881ff43efda0] generic_file_read_iter at ffffffff81187a73
       #9 [ffff881ff43efe50] nfs_file_read at ffffffffa066544b [nfs]
      #10 [ffff881ff43efe70] __vfs_read at ffffffff811fc756
      #11 [ffff881ff43efee8] vfs_read at ffffffff811fccfa
      #12 [ffff881ff43eff18] sys_read at ffffffff811fda62
      #13 [ffff881ff43eff50] entry_SYSCALL_64_fastpath at ffffffff815e986e
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      38026d1a
    • Kees Cook's avatar
      pstore/ram: Correctly calculate usable PRZ bytes · b718d6be
      Kees Cook authored
      [ Upstream commit 89d328f6 ]
      
      The actual number of bytes stored in a PRZ is smaller than the
      bytes requested by platform data, since there is a header on each
      PRZ. Additionally, if ECC is enabled, there are trailing bytes used
      as well. Normally this mismatch doesn't matter since PRZs are circular
      buffers and the leading "overflow" bytes are just thrown away. However, in
      the case of a compressed record, this rather badly corrupts the results.
      
      This corruption was visible with "ramoops.mem_size=204800 ramoops.ecc=1".
      Any stored crashes would not be uncompressable (producing a pstorefs
      "dmesg-*.enc.z" file), and triggering errors at boot:
      
        [    2.790759] pstore: crypto_comp_decompress failed, ret = -22!
      
      Backporting this depends on commit 70ad35db
      
       ("pstore: Convert console
      write to use ->write_buf")
      Reported-by: default avatarJoel Fernandes <joel@joelfernandes.org>
      Fixes: b0aad7a9
      
       ("pstore: Add compression support to pstore")
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Reviewed-by: default avatarJoel Fernandes (Google) <joel@joelfernandes.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b718d6be
    • Igor Druzhinin's avatar
      Revert "xen/balloon: Mark unallocated host memory as UNUSABLE" · b9c242b4
      Igor Druzhinin authored
      [ Upstream commit 12366410 ]
      
      This reverts commit b3cf8528.
      
      That commit unintentionally broke Xen balloon memory hotplug with
      "hotplug_unpopulated" set to 1. As long as "System RAM" resource
      got assigned under a new "Unusable memory" resource in IO/Mem tree
      any attempt to online this memory would fail due to general kernel
      restrictions on having "System RAM" resources as 1st level only.
      
      The original issue that commit has tried to workaround fa564ad9
      ("x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 00-1f, 30-3f,
      60-7f)") also got amended by the following 03a55173
      
       ("x86/PCI: Move
      and shrink AMD 64-bit window to avoid conflict") which made the
      original fix to Xen ballooning unnecessary.
      Signed-off-by: default avatarIgor Druzhinin <igor.druzhinin@citrix.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b9c242b4
    • Srikanth Boddepalli's avatar
      xen: xlate_mmu: add missing header to fix 'W=1' warning · f02e0d5f
      Srikanth Boddepalli authored
      [ Upstream commit 72791ac8
      
       ]
      
      Add a missing header otherwise compiler warns about missed prototype:
      
      drivers/xen/xlate_mmu.c:183:5: warning: no previous prototype for 'xen_xlate_unmap_gfn_range?' [-Wmissing-prototypes]
        int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
            ^~~~~~~~~~~~~~~~~~~~~~~~~
      Signed-off-by: default avatarSrikanth Boddepalli <boddepalli.srikanth@gmail.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Reviewed-by: default avatarJoey Pabalinas <joeypabalinas@gmail.com>
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f02e0d5f
    • Y.C. Chen's avatar
      drm/ast: fixed reading monitor EDID not stable issue · 6ee9b4de
      Y.C. Chen authored
      [ Upstream commit 30062562
      
       ]
      
      v1: over-sample data to increase the stability with some specific monitors
      v2: refine to avoid infinite loop
      v3: remove un-necessary "volatile" declaration
      
      [airlied: fix two checkpatch warnings]
      Signed-off-by: default avatarY.C. Chen <yc_chen@aspeedtech.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1542858988-1127-1-git-send-email-yc_chen@aspeedtech.com
      
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6ee9b4de
    • shaoyunl's avatar
      drm/amdgpu: Add delay after enable RLC ucode · cc92ade5
      shaoyunl authored
      [ Upstream commit ad97d9de
      
       ]
      
      Driver shouldn't try to access any GFX registers until RLC is idle.
      During the test, it took 12 seconds for RLC to clear the BUSY bit
      in RLC_GPM_STAT register which is un-acceptable for driver.
      As per RLC engineer, it would take RLC Ucode less than 10,000 GFXCLK
      cycles to finish its critical section. In a lowest 300M enginer clock
      setting(default from vbios), 50 us delay is enough.
      
      This commit fix the hang when RLC introduce the work around for XGMI
      which requires more cycles to setup more registers than normal
      Signed-off-by: default avatarshaoyunl <shaoyun.liu@amd.com>
      Acked-by: default avatarFelix Kuehling <Felix.Kuehling@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cc92ade5
    • Pan Bian's avatar
      net: hisilicon: remove unexpected free_netdev · 8a69edb8
      Pan Bian authored
      [ Upstream commit c7589401
      
       ]
      
      The net device ndev is freed via free_netdev when failing to register
      the device. The control flow then jumps to the error handling code
      block. ndev is used and freed again. Resulting in a use-after-free bug.
      Signed-off-by: default avatarPan Bian <bianpan2016@163.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8a69edb8
    • Josh Elsasser's avatar
      ixgbe: recognize 1000BaseLX SFP modules as 1Gbps · 689dee4b
      Josh Elsasser authored
      [ Upstream commit a8bf879a ]
      
      Add the two 1000BaseLX enum values to the X550's check for 1Gbps modules,
      allowing the core driver code to establish a link over this SFP type.
      
      This is done by the out-of-tree driver but the fix wasn't in mainline.
      
      Fixes: e23f3336 ("ixgbe: Fix 1G and 10G link stability for X550EM_x SFP+”)
      Fixes: 6a14ee0c
      
       ("ixgbe: Add X550 support function pointers")
      Signed-off-by: default avatarJosh Elsasser <jelsasser@appneta.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      689dee4b
    • Yunjian Wang's avatar
      igb: fix uninitialized variables · 9966f78a
      Yunjian Wang authored
      [ Upstream commit e4c39f79
      
       ]
      
      This patch fixes the variable 'phy_word' may be used uninitialized.
      Signed-off-by: default avatarYunjian Wang <wangyunjian@huawei.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9966f78a
    • Kiran Kumar Modukuri's avatar
      cachefiles: Fix page leak in cachefiles_read_backing_file while vmscan is active · 7b99a0d7
      Kiran Kumar Modukuri authored
      [ Upstream commit 9a24ce5b
      
       ]
      
      [Description]
      
      In a heavily loaded system where the system pagecache is nearing memory
      limits and fscache is enabled, pages can be leaked by fscache while trying
      read pages from cachefiles backend.  This can happen because two
      applications can be reading same page from a single mount, two threads can
      be trying to read the backing page at same time.  This results in one of
      the threads finding that a page for the backing file or netfs file is
      already in the radix tree.  During the error handling cachefiles does not
      clean up the reference on backing page, leading to page leak.
      
      [Fix]
      The fix is straightforward, to decrement the reference when error is
      encountered.
      
        [dhowells: Note that I've removed the clearance and put of newpage as
         they aren't attested in the commit message and don't appear to actually
         achieve anything since a new page is only allocated is newpage!=NULL and
         any residual new page is cleared before returning.]
      
      [Testing]
      I have tested the fix using following method for 12+ hrs.
      
      1) mkdir -p /mnt/nfs ; mount -o vers=3,fsc <server_ip>:/export /mnt/nfs
      2) create 10000 files of 2.8MB in a NFS mount.
      3) start a thread to simulate heavy VM presssure
         (while true ; do echo 3 > /proc/sys/vm/drop_caches ; sleep 1 ; done)&
      4) start multiple parallel reader for data set at same time
         find /mnt/nfs -type f | xargs -P 80 cat > /dev/null &
         find /mnt/nfs -type f | xargs -P 80 cat > /dev/null &
         find /mnt/nfs -type f | xargs -P 80 cat > /dev/null &
         ..
         ..
         find /mnt/nfs -type f | xargs -P 80 cat > /dev/null &
         find /mnt/nfs -type f | xargs -P 80 cat > /dev/null &
      5) finally check using cat /proc/fs/fscache/stats | grep -i pages ;
         free -h , cat /proc/meminfo and page-types -r -b lru
         to ensure all pages are freed.
      Reviewed-by: default avatarDaniel Axtens <dja@axtens.net>
      Signed-off-by: default avatarShantanu Goel <sgoel01@yahoo.com>
      Signed-off-by: default avatarKiran Kumar Modukuri <kiran.modukuri@gmail.com>
      [dja: forward ported to current upstream]
      Signed-off-by: default avatarDaniel Axtens <dja@axtens.net>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7b99a0d7
    • Taehee Yoo's avatar
      netfilter: nf_tables: deactivate expressions in rule replecement routine · 397727e7
      Taehee Yoo authored
      [ 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=201791
      
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      397727e7
    • Marek Szyprowski's avatar
      usb: gadget: u_ether: fix unsafe list iteration · b641ee14
      Marek Szyprowski authored
      [ Upstream commit c9287fa6 ]
      
      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: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b641ee14
    • Lorenzo Bianconi's avatar
      net: thunderx: fix NULL pointer dereference in nic_remove · ff791c9e
      Lorenzo Bianconi authored
      [ Upstream commit 24a6d2dd ]
      
      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: default avatarLorenzo Bianconi <lorenzo.bianconi@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ff791c9e
    • Yi Wang's avatar
      x86/kvm/vmx: fix old-style function declaration · 7fdd58de
      Yi Wang authored
      [ 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: default avatarYi Wang <wang.yi59@zte.com.cn>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7fdd58de
    • Yi Wang's avatar
      KVM: x86: fix empty-body warnings · bb3f8691
      Yi Wang authored
      [ 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: default avatarYi Wang <wang.yi59@zte.com.cn>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      bb3f8691
    • Artemy Kovalyov's avatar
      IB/mlx5: Fix page fault handling for MW · 8f859b27
      Artemy Kovalyov authored
      [ Upstream commit 75b7b86b ]
      
      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: default avatarArtemy Kovalyov <artemyko@mellanox.com>
      Signed-off-by: default avatarMoni Shoua <monis@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8f859b27
    • Alin Nastac's avatar
      netfilter: ipv6: Preserve link scope traffic original oif · 97f04803
      Alin Nastac authored
      [ Upstream commit 508b0904
      
       ]
      
      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: default avatarAlin Nastac <alin.nastac@gmail.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      97f04803
    • Christian Hewitt's avatar
      drm/meson: add support for 1080p25 mode · f47b8824
      Christian Hewitt authored
      [ Upstream commit 31e1ab49 ]
      
      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: default avatarChristian Hewitt <christianshewitt@gmail.com>
      Acked-by: Neil Armstrong's avatarNeil Armstrong <narmstrong@baylibre.com>
      Signed-off-by: Neil Armstrong's avatarNeil Armstrong <narmstrong@baylibre.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1542793169-13008-1-git-send-email-christianshewitt@gmail.com
      
      Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f47b8824
    • Aaro Koskinen's avatar
      USB: omap_udc: fix rejection of out transfers when DMA is used · ca993dea
      Aaro Koskinen authored
      [ Upstream commit 069caf59 ]
      
      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: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ca993dea
    • Aaro Koskinen's avatar
      USB: omap_udc: fix USB gadget functionality on Palm Tungsten E · 72c982a3
      Aaro Koskinen authored
      [ Upstream commit 2c2322fb
      
       ]
      
      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: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      72c982a3
    • Aaro Koskinen's avatar
      USB: omap_udc: fix omap_udc_start() on 15xx machines · e68f6cb9
      Aaro Koskinen authored
      [ Upstream commit 6ca6695f
      
       ]
      
      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: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e68f6cb9
    • Aaro Koskinen's avatar
      USB: omap_udc: fix crashes on probe error and module removal · 09eb2b90
      Aaro Koskinen authored
      [ Upstream commit 99f70036
      
       ]
      
      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: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      09eb2b90
    • Aaro Koskinen's avatar
      USB: omap_udc: use devm_request_irq() · 11f8633c
      Aaro Koskinen authored
      [ Upstream commit 286afdde
      
       ]
      
      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: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      11f8633c
    • Xin Long's avatar
      ipvs: call ip_vs_dst_notifier earlier than ipv6_dev_notf · 57dea380
      Xin Long authored
      [ 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: default avatarLi Shuang <shuali@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarJulian Anastasov <ja@ssi.bg>
      Acked-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      57dea380
    • Martynas Pumputis's avatar
      bpf: fix check of allowed specifiers in bpf_trace_printk · 9209043b
      Martynas Pumputis authored
      [ Upstream commit 1efb6ee3 ]
      
      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: default avatarMartynas Pumputis <m@lambda.lt>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9209043b
    • Pan Bian's avatar
      exportfs: do not read dentry after free · 42cb0b9e
      Pan Bian authored
      [ 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: default avatarPan Bian <bianpan2016@163.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      42cb0b9e
    • Peter Ujfalusi's avatar
      ASoC: omap-dmic: Add pm_qos handling to avoid overruns with CPU_IDLE · bdafd18e
      Peter Ujfalusi authored
      [ Upstream commit ffdcc363
      
       ]
      
      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: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Acked-by: default avatarJarkko Nikula <jarkko.nikula@bitmer.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      bdafd18e
    • Peter Ujfalusi's avatar
      ASoC: omap-mcpdm: Add pm_qos handling to avoid under/overruns with CPU_IDLE · 997a8d6c
      Peter Ujfalusi authored
      [ Upstream commit 373a500e
      
       ]
      
      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: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Acked-by: default avatarJarkko Nikula <jarkko.nikula@bitmer.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      997a8d6c
    • Peter Ujfalusi's avatar
      ASoC: omap-mcbsp: Fix latency value calculation for pm_qos · 4a3fa2a5
      Peter Ujfalusi authored
      [ Upstream commit dd2f52d8
      
       ]
      
      The latency number is in usec for the pm_qos. Correct the calculation to
      give us the time in usec
      Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Acked-by: default avatarJarkko Nikula <jarkko.nikula@bitmer.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4a3fa2a5
    • Kamal Heib's avatar
      RDMA/rdmavt: Fix rvt_create_ah function signature · a625d3e3
      Kamal Heib authored
      [ 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: default avatarKamal Heib <kamalheib1@gmail.com>
      Reviewed-by: default avatarDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a625d3e3
    • Majd Dibbiny's avatar
      RDMA/mlx5: Fix fence type for IB_WR_LOCAL_INV WR · 9692eefb
      Majd Dibbiny authored
      [ Upstream commit 074fca3a ]
      
      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: default avatarMajd Dibbiny <majd@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9692eefb
    • Robbie Ko's avatar
      Btrfs: send, fix infinite loop due to directory rename dependencies · 67080eb2
      Robbie Ko authored
      [ Upstream commit a4390aee
      
       ]
      
      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: default avatarRobbie Ko <robbieko@synology.com>
      Reviewed-by: default avatarFilipe Manana <fdmanana@suse.com>
      [Wrote changelog with example and more clear explanation]
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      67080eb2
    • Romain Izard's avatar
      ARM: dts: at91: sama5d2: use the divided clock for SMC · b254f11c
      Romain Izard authored
      [ Upstream commit 4ab7ca09
      
       ]
      
      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: default avatarRomain Izard <romain.izard.pro@gmail.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b254f11c
    • Artem Savkov's avatar
      objtool: Fix segfault in .cold detection with -ffunction-sections · 5ce4164f
      Artem Savkov authored
      [ 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: default avatarArtem Savkov <asavkov@redhat.com>
      Signed-off-by: default avatarJosh 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.com
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5ce4164f