1. 25 Aug, 2019 13 commits
    • Linus Torvalds's avatar
      Merge branch 'akpm' (patches from Andrew) · f47edb59
      Linus Torvalds authored
      Mergr misc fixes from Andrew Morton:
       "11 fixes"
      
      Mostly VM fixes, one psi polling fix, and one parisc build fix.
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>:
        mm/kasan: fix false positive invalid-free reports with CONFIG_KASAN_SW_TAGS=y
        mm/zsmalloc.c: fix race condition in zs_destroy_pool
        mm/zsmalloc.c: migration can leave pages in ZS_EMPTY indefinitely
        mm, page_owner: handle THP splits correctly
        userfaultfd_release: always remove uffd flags and clear vm_userfaultfd_ctx
        psi: get poll_work to run when calling poll syscall next time
        mm: memcontrol: flush percpu vmevents before releasing memcg
        mm: memcontrol: flush percpu vmstats before releasing memcg
        parisc: fix compilation errrors
        mm, page_alloc: move_freepages should not examine struct page of reserved memory
        mm/z3fold.c: fix race between migration and destruction
      f47edb59
    • Linus Torvalds's avatar
      Merge tag 'dma-mapping-5.3-5' of git://git.infradead.org/users/hch/dma-mapping · e67095fd
      Linus Torvalds authored
      Pull dma-mapping fixes from Christoph Hellwig:
       "Two fixes for regressions in this merge window:
      
         - select the Kconfig symbols for the noncoherent dma arch helpers on
           arm if swiotlb is selected, not just for LPAE to not break then Xen
           build, that uses swiotlb indirectly through swiotlb-xen
      
         - fix the page allocator fallback in dma_alloc_contiguous if the CMA
           allocation fails"
      
      * tag 'dma-mapping-5.3-5' of git://git.infradead.org/users/hch/dma-mapping:
        dma-direct: fix zone selection after an unaddressable CMA allocation
        arm: select the dma-noncoherent symbols for all swiotlb builds
      e67095fd
    • Andrey Ryabinin's avatar
      mm/kasan: fix false positive invalid-free reports with CONFIG_KASAN_SW_TAGS=y · 00fb24a4
      Andrey Ryabinin authored
      The code like this:
      
      	ptr = kmalloc(size, GFP_KERNEL);
      	page = virt_to_page(ptr);
      	offset = offset_in_page(ptr);
      	kfree(page_address(page) + offset);
      
      may produce false-positive invalid-free reports on the kernel with
      CONFIG_KASAN_SW_TAGS=y.
      
      In the example above we lose the original tag assigned to 'ptr', so
      kfree() gets the pointer with 0xFF tag.  In kfree() we check that 0xFF
      tag is different from the tag in shadow hence print false report.
      
      Instead of just comparing tags, do the following:
      
      1) Check that shadow doesn't contain KASAN_TAG_INVALID.  Otherwise it's
         double-free and it doesn't matter what tag the pointer have.
      
      2) If pointer tag is different from 0xFF, make sure that tag in the
         shadow is the same as in the pointer.
      
      Link: http://lkml.kernel.org/r/20190819172540.19581-1-aryabinin@virtuozzo.com
      Fixes: 7f94ffbc ("kasan: add hooks implementation for tag-based mode")
      Signed-off-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Reported-by: default avatarWalter Wu <walter-zh.wu@mediatek.com>
      Reported-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      00fb24a4
    • Henry Burns's avatar
      mm/zsmalloc.c: fix race condition in zs_destroy_pool · 701d6785
      Henry Burns authored
      In zs_destroy_pool() we call flush_work(&pool->free_work).  However, we
      have no guarantee that migration isn't happening in the background at
      that time.
      
      Since migration can't directly free pages, it relies on free_work being
      scheduled to free the pages.  But there's nothing preventing an
      in-progress migrate from queuing the work *after*
      zs_unregister_migration() has called flush_work().  Which would mean
      pages still pointing at the inode when we free it.
      
      Since we know at destroy time all objects should be free, no new
      migrations can come in (since zs_page_isolate() fails for fully-free
      zspages).  This means it is sufficient to track a "# isolated zspages"
      count by class, and have the destroy logic ensure all such pages have
      drained before proceeding.  Keeping that state under the class spinlock
      keeps the logic straightforward.
      
      In this case a memory leak could lead to an eventual crash if compaction
      hits the leaked page.  This crash would only occur if people are
      changing their zswap backend at runtime (which eventually starts
      destruction).
      
      Link: http://lkml.kernel.org/r/20190809181751.219326-2-henryburns@google.com
      Fixes: 48b4800a ("zsmalloc: page migration support")
      Signed-off-by: default avatarHenry Burns <henryburns@google.com>
      Reviewed-by: default avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: Henry Burns <henrywolfeburns@gmail.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Shakeel Butt <shakeelb@google.com>
      Cc: Jonathan Adams <jwadams@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      701d6785
    • Henry Burns's avatar
      mm/zsmalloc.c: migration can leave pages in ZS_EMPTY indefinitely · 1a87aa03
      Henry Burns authored
      In zs_page_migrate() we call putback_zspage() after we have finished
      migrating all pages in this zspage.  However, the return value is
      ignored.  If a zs_free() races in between zs_page_isolate() and
      zs_page_migrate(), freeing the last object in the zspage,
      putback_zspage() will leave the page in ZS_EMPTY for potentially an
      unbounded amount of time.
      
      To fix this, we need to do the same thing as zs_page_putback() does:
      schedule free_work to occur.
      
      To avoid duplicated code, move the sequence to a new
      putback_zspage_deferred() function which both zs_page_migrate() and
      zs_page_putback() call.
      
      Link: http://lkml.kernel.org/r/20190809181751.219326-1-henryburns@google.com
      Fixes: 48b4800a ("zsmalloc: page migration support")
      Signed-off-by: default avatarHenry Burns <henryburns@google.com>
      Reviewed-by: default avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: Henry Burns <henrywolfeburns@gmail.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Shakeel Butt <shakeelb@google.com>
      Cc: Jonathan Adams <jwadams@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1a87aa03
    • Vlastimil Babka's avatar
      mm, page_owner: handle THP splits correctly · f7da677b
      Vlastimil Babka authored
      THP splitting path is missing the split_page_owner() call that
      split_page() has.
      
      As a result, split THP pages are wrongly reported in the page_owner file
      as order-9 pages.  Furthermore when the former head page is freed, the
      remaining former tail pages are not listed in the page_owner file at
      all.  This patch fixes that by adding the split_page_owner() call into
      __split_huge_page().
      
      Link: http://lkml.kernel.org/r/20190820131828.22684-2-vbabka@suse.cz
      Fixes: a9627bc5 ("mm/page_owner: introduce split_page_owner and replace manual handling")
      Reported-by: default avatarKirill A. Shutemov <kirill@shutemov.name>
      Signed-off-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f7da677b
    • Oleg Nesterov's avatar
      userfaultfd_release: always remove uffd flags and clear vm_userfaultfd_ctx · 46d0b24c
      Oleg Nesterov authored
      userfaultfd_release() should clear vm_flags/vm_userfaultfd_ctx even if
      mm->core_state != NULL.
      
      Otherwise a page fault can see userfaultfd_missing() == T and use an
      already freed userfaultfd_ctx.
      
      Link: http://lkml.kernel.org/r/20190820160237.GB4983@redhat.com
      Fixes: 04f5866e ("coredump: fix race condition between mmget_not_zero()/get_task_mm() and core dumping")
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Reported-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Reviewed-by: default avatarAndrea Arcangeli <aarcange@redhat.com>
      Tested-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Cc: Peter Xu <peterx@redhat.com>
      Cc: Mike Rapoport <rppt@linux.ibm.com>
      Cc: Jann Horn <jannh@google.com>
      Cc: Jason Gunthorpe <jgg@mellanox.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      46d0b24c
    • Jason Xing's avatar
      psi: get poll_work to run when calling poll syscall next time · 7b2b55da
      Jason Xing authored
      Only when calling the poll syscall the first time can user receive
      POLLPRI correctly.  After that, user always fails to acquire the event
      signal.
      
      Reproduce case:
       1. Get the monitor code in Documentation/accounting/psi.txt
       2. Run it, and wait for the event triggered.
       3. Kill and restart the process.
      
      The question is why we can end up with poll_scheduled = 1 but the work
      not running (which would reset it to 0).  And the answer is because the
      scheduling side sees group->poll_kworker under RCU protection and then
      schedules it, but here we cancel the work and destroy the worker.  The
      cancel needs to pair with resetting the poll_scheduled flag.
      
      Link: http://lkml.kernel.org/r/1566357985-97781-1-git-send-email-joseph.qi@linux.alibaba.comSigned-off-by: default avatarJason Xing <kerneljasonxing@linux.alibaba.com>
      Signed-off-by: default avatarJoseph Qi <joseph.qi@linux.alibaba.com>
      Reviewed-by: default avatarCaspar Zhang <caspar@linux.alibaba.com>
      Reviewed-by: default avatarSuren Baghdasaryan <surenb@google.com>
      Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7b2b55da
    • Roman Gushchin's avatar
      mm: memcontrol: flush percpu vmevents before releasing memcg · bb65f89b
      Roman Gushchin authored
      Similar to vmstats, percpu caching of local vmevents leads to an
      accumulation of errors on non-leaf levels.  This happens because some
      leftovers may remain in percpu caches, so that they are never propagated
      up by the cgroup tree and just disappear into nonexistence with on
      releasing of the memory cgroup.
      
      To fix this issue let's accumulate and propagate percpu vmevents values
      before releasing the memory cgroup similar to what we're doing with
      vmstats.
      
      Since on cpu hotplug we do flush percpu vmstats anyway, we can iterate
      only over online cpus.
      
      Link: http://lkml.kernel.org/r/20190819202338.363363-4-guro@fb.com
      Fixes: 42a30035 ("mm: memcontrol: fix recursive statistics correctness & scalabilty")
      Signed-off-by: default avatarRoman Gushchin <guro@fb.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      bb65f89b
    • Roman Gushchin's avatar
      mm: memcontrol: flush percpu vmstats before releasing memcg · c350a99e
      Roman Gushchin authored
      Percpu caching of local vmstats with the conditional propagation by the
      cgroup tree leads to an accumulation of errors on non-leaf levels.
      
      Let's imagine two nested memory cgroups A and A/B.  Say, a process
      belonging to A/B allocates 100 pagecache pages on the CPU 0.  The percpu
      cache will spill 3 times, so that 32*3=96 pages will be accounted to A/B
      and A atomic vmstat counters, 4 pages will remain in the percpu cache.
      
      Imagine A/B is nearby memory.max, so that every following allocation
      triggers a direct reclaim on the local CPU.  Say, each such attempt will
      free 16 pages on a new cpu.  That means every percpu cache will have -16
      pages, except the first one, which will have 4 - 16 = -12.  A/B and A
      atomic counters will not be touched at all.
      
      Now a user removes A/B.  All percpu caches are freed and corresponding
      vmstat numbers are forgotten.  A has 96 pages more than expected.
      
      As memory cgroups are created and destroyed, errors do accumulate.  Even
      1-2 pages differences can accumulate into large numbers.
      
      To fix this issue let's accumulate and propagate percpu vmstat values
      before releasing the memory cgroup.  At this point these numbers are
      stable and cannot be changed.
      
      Since on cpu hotplug we do flush percpu vmstats anyway, we can iterate
      only over online cpus.
      
      Link: http://lkml.kernel.org/r/20190819202338.363363-2-guro@fb.com
      Fixes: 42a30035 ("mm: memcontrol: fix recursive statistics correctness & scalabilty")
      Signed-off-by: default avatarRoman Gushchin <guro@fb.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c350a99e
    • Qian Cai's avatar
      parisc: fix compilation errrors · bbcb03a9
      Qian Cai authored
      Commit 0cfaee2a ("include/asm-generic/5level-fixup.h: fix variable
      'p4d' set but not used") converted a few functions from macros to static
      inline, which causes parisc to complain,
      
        In file included from include/asm-generic/4level-fixup.h:38:0,
                         from arch/parisc/include/asm/pgtable.h:5,
                         from arch/parisc/include/asm/io.h:6,
                         from include/linux/io.h:13,
                         from sound/core/memory.c:9:
        include/asm-generic/5level-fixup.h:14:18: error: unknown type name 'pgd_t'; did you mean 'pid_t'?
         #define p4d_t    pgd_t
                          ^
        include/asm-generic/5level-fixup.h:24:28: note: in expansion of macro 'p4d_t'
         static inline int p4d_none(p4d_t p4d)
                                    ^~~~~
      
      It is because "4level-fixup.h" is included before "asm/page.h" where
      "pgd_t" is defined.
      
      Link: http://lkml.kernel.org/r/20190815205305.1382-1-cai@lca.pw
      Fixes: 0cfaee2a ("include/asm-generic/5level-fixup.h: fix variable 'p4d' set but not used")
      Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Reported-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      bbcb03a9
    • David Rientjes's avatar
      mm, page_alloc: move_freepages should not examine struct page of reserved memory · cd961038
      David Rientjes authored
      After commit 907ec5fc ("mm: zero remaining unavailable struct
      pages"), struct page of reserved memory is zeroed.  This causes
      page->flags to be 0 and fixes issues related to reading
      /proc/kpageflags, for example, of reserved memory.
      
      The VM_BUG_ON() in move_freepages_block(), however, assumes that
      page_zone() is meaningful even for reserved memory.  That assumption is
      no longer true after the aforementioned commit.
      
      There's no reason why move_freepages_block() should be testing the
      legitimacy of page_zone() for reserved memory; its scope is limited only
      to pages on the zone's freelist.
      
      Note that pfn_valid() can be true for reserved memory: there is a
      backing struct page.  The check for page_to_nid(page) is also buggy but
      reserved memory normally only appears on node 0 so the zeroing doesn't
      affect this.
      
      Move the debug checks to after verifying PageBuddy is true.  This
      isolates the scope of the checks to only be for buddy pages which are on
      the zone's freelist which move_freepages_block() is operating on.  In
      this case, an incorrect node or zone is a bug worthy of being warned
      about (and the examination of struct page is acceptable bcause this
      memory is not reserved).
      
      Why does move_freepages_block() gets called on reserved memory? It's
      simply math after finding a valid free page from the per-zone free area
      to use as fallback.  We find the beginning and end of the pageblock of
      the valid page and that can bring us into memory that was reserved per
      the e820.  pfn_valid() is still true (it's backed by a struct page), but
      since it's zero'd we shouldn't make any inferences here about comparing
      its node or zone.  The current node check just happens to succeed most
      of the time by luck because reserved memory typically appears on node 0.
      
      The fix here is to validate that we actually have buddy pages before
      testing if there's any type of zone or node strangeness going on.
      
      We noticed it almost immediately after bringing 907ec5fc in on
      CONFIG_DEBUG_VM builds.  It depends on finding specific free pages in
      the per-zone free area where the math in move_freepages() will bring the
      start or end pfn into reserved memory and wanting to claim that entire
      pageblock as a new migratetype.  So the path will be rare, require
      CONFIG_DEBUG_VM, and require fallback to a different migratetype.
      
      Some struct pages were already zeroed from reserve pages before
      907ec5fca3c so it theoretically could trigger before this commit.  I
      think it's rare enough under a config option that most people don't run
      that others may not have noticed.  I wouldn't argue against a stable tag
      and the backport should be easy enough, but probably wouldn't single out
      a commit that this is fixing.
      
      Mel said:
      
      : The overhead of the debugging check is higher with this patch although
      : it'll only affect debug builds and the path is not particularly hot.
      : If this was a concern, I think it would be reasonable to simply remove
      : the debugging check as the zone boundaries are checked in
      : move_freepages_block and we never expect a zone/node to be smaller than
      : a pageblock and stuck in the middle of another zone.
      
      Link: http://lkml.kernel.org/r/alpine.DEB.2.21.1908122036560.10779@chino.kir.corp.google.comSigned-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Acked-by: default avatarMel Gorman <mgorman@techsingularity.net>
      Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
      Cc: Oscar Salvador <osalvador@suse.de>
      Cc: Pavel Tatashin <pavel.tatashin@microsoft.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      cd961038
    • Henry Burns's avatar
      mm/z3fold.c: fix race between migration and destruction · d776aaa9
      Henry Burns authored
      In z3fold_destroy_pool() we call destroy_workqueue(&pool->compact_wq).
      However, we have no guarantee that migration isn't happening in the
      background at that time.
      
      Migration directly calls queue_work_on(pool->compact_wq), if destruction
      wins that race we are using a destroyed workqueue.
      
      Link: http://lkml.kernel.org/r/20190809213828.202833-1-henryburns@google.comSigned-off-by: default avatarHenry Burns <henryburns@google.com>
      Cc: Vitaly Wool <vitalywool@gmail.com>
      Cc: Shakeel Butt <shakeelb@google.com>
      Cc: Jonathan Adams <jwadams@google.com>
      Cc: Henry Burns <henrywolfeburns@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d776aaa9
  2. 24 Aug, 2019 8 commits
  3. 23 Aug, 2019 17 commits
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma · 9140d8bd
      Linus Torvalds authored
      Pull rdma fixes from Doug Ledford:
       "No beating around the bush: this is a monster pull request for an -rc5
        kernel. Intel hit me with a series of fixes for TID processing.
        Mellanox hit me with a series for their UMR memory support.
      
        And we had one fix for siw that fixes the 32bit build warnings and
        because of the number of casts that had to be changed to properly
        silence the warnings, that one patch alone is a full 40% of the LOC of
        this entire pull request. Given that this is the initial release
        kernel for siw, I'm trying to fix anything in it that we can, so that
        adds to the impetus to take fixes for it like this one.
      
        I had to do a rebase early in the week. Jason had thought he put a
        patch on the rc queue that he needed to be there so he could base some
        work off of it, and it had actually not been placed there. So he asked
        me (on Tuesday) to fix that up before pushing my wip branch to the
        official rc branch. I did, and that's why the early patches look like
        they were all committed at the same time on Tuesday. That bunch had
        been in my queue prior.
      
        The various patches all pass my test for being legitimate fixes and
        not attempts to slide new features or development into a late rc.
        Well, they were all fixes with the exception of a couple clean up
        patches people wrote for making the fixes they also wrote better (like
        a cleanup patch to move UMR checking into a function so that the
        remaining UMR fix patches can reference that function), so I left
        those in place too.
      
        My apologies for the LOC count and the number of patches here, it's
        just how the cards fell this cycle.
      
        Summary:
      
         - Fix siw buffer mapping issue
      
         - Fix siw 32/64 casting issues
      
         - Fix a KASAN access issue in bnxt_re
      
         - Fix several memory leaks (hfi1, mlx4)
      
         - Fix a NULL deref in cma_cleanup
      
         - Fixes for UMR memory support in mlx5 (4 patch series)
      
         - Fix namespace check for restrack
      
         - Fixes for counter support
      
         - Fixes for hfi1 TID processing (5 patch series)
      
         - Fix potential NULL deref in siw
      
         - Fix memory page calculations in mlx5"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: (21 commits)
        RDMA/siw: Fix 64/32bit pointer inconsistency
        RDMA/siw: Fix SGL mapping issues
        RDMA/bnxt_re: Fix stack-out-of-bounds in bnxt_qplib_rcfw_send_message
        infiniband: hfi1: fix memory leaks
        infiniband: hfi1: fix a memory leak bug
        IB/mlx4: Fix memory leaks
        RDMA/cma: fix null-ptr-deref Read in cma_cleanup
        IB/mlx5: Block MR WR if UMR is not possible
        IB/mlx5: Fix MR re-registration flow to use UMR properly
        IB/mlx5: Report and handle ODP support properly
        IB/mlx5: Consolidate use_umr checks into single function
        RDMA/restrack: Rewrite PID namespace check to be reliable
        RDMA/counters: Properly implement PID checks
        IB/core: Fix NULL pointer dereference when bind QP to counter
        IB/hfi1: Drop stale TID RDMA packets that cause TIDErr
        IB/hfi1: Add additional checks when handling TID RDMA WRITE DATA packet
        IB/hfi1: Add additional checks when handling TID RDMA READ RESP packet
        IB/hfi1: Unsafe PSN checking for TID RDMA READ Resp packet
        IB/hfi1: Drop stale TID RDMA packets
        RDMA/siw: Fix potential NULL de-ref
        ...
      9140d8bd
    • Linus Torvalds's avatar
      Merge tag 'for-linus-20190823' of git://git.kernel.dk/linux-block · b9bd6806
      Linus Torvalds authored
      Pull block fixes from Jens Axboe:
       "Here's a set of fixes that should go into this release. This contains:
      
         - Three minor fixes for NVMe.
      
         - Three minor tweaks for the io_uring polling logic.
      
         - Officially mark Song as the MD maintainer, after he's been filling
           that role sucessfully for the last 6 months or so"
      
      * tag 'for-linus-20190823' of git://git.kernel.dk/linux-block:
        io_uring: add need_resched() check in inner poll loop
        md: update MAINTAINERS info
        io_uring: don't enter poll loop if we have CQEs pending
        nvme: Add quirk for LiteON CL1 devices running FW 22301111
        nvme: Fix cntlid validation when not using NVMEoF
        nvme-multipath: fix possible I/O hang when paths are updated
        io_uring: fix potential hang with polled IO
      b9bd6806
    • Linus Torvalds's avatar
      Merge tag 'for-5.3/dm-fixes-2' of... · dd469a45
      Linus Torvalds authored
      Merge tag 'for-5.3/dm-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
      
      Pull device mapper fixes from Mike Snitzer:
      
       - Revert a DM bufio change from during the 5.3 merge window now that a
         proper fix has been made to the block loopback driver.
      
       - Fix DM kcopyd to wakeup so failed subjobs get completed.
      
       - Various fixes to DM zoned target to address error handling, and other
         small tweaks (SPDX license identifiers and fix typos).
      
       - Fix DM integrity range locking race by tracking whether journal has
         changed.
      
       - Fix DM dust target to detect reads of badblocks beyond the first 512b
         sector (applicable if blocksize is larger than 512b).
      
       - Fix DM persistent-data issue in both the DM btree and DM
         space-map-metadata interfaces.
      
       - Fix out of bounds memory access with certain DM table configurations.
      
      * tag 'for-5.3/dm-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
        dm table: fix invalid memory accesses with too high sector number
        dm space map metadata: fix missing store of apply_bops() return value
        dm btree: fix order of block initialization in btree_split_beneath
        dm raid: add missing cleanup in raid_ctr()
        dm zoned: fix potential NULL dereference in dmz_do_reclaim()
        dm dust: use dust block size for badblocklist index
        dm integrity: fix a crash due to BUG_ON in __journal_read_write()
        dm zoned: fix a few typos
        dm zoned: add SPDX license identifiers
        dm zoned: properly handle backing device failure
        dm zoned: improve error handling in i/o map code
        dm zoned: improve error handling in reclaim
        dm kcopyd: always complete failed jobs
        Revert "dm bufio: fix deadlock with loop device"
      dd469a45
    • Linus Torvalds's avatar
      Merge tag 'xfs-5.3-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux · f576518c
      Linus Torvalds authored
      Pull xfs fixes from Darrick Wong:
       "Here are a few more bug fixes that trickled in since the last pull.
        They've survived the usual xfstests runs and merge cleanly with this
        morning's master.
      
        I expect there to be one more pull request tomorrow for the fix to
        that quota related inode unlock bug that we were reviewing last night,
        but it will continue to soak in the testing machine for several more
        hours.
      
         - Fix missing compat ioctl handling for get/setlabel
      
         - Fix missing ioctl pointer sanitization on s390
      
         - Fix a page locking deadlock in the dedupe comparison code
      
         - Fix inadequate locking in reflink code w.r.t. concurrent directio
      
         - Fix broken error detection when breaking layouts"
      
      * tag 'xfs-5.3-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
        fs/xfs: Fix return code of xfs_break_leased_layouts()
        xfs: fix reflink source file racing with directio writes
        vfs: fix page locking deadlocks when deduping files
        xfs: compat_ioctl: use compat_ptr()
        xfs: fall back to native ioctls for unhandled compat ones
      f576518c
    • Andre Przywara's avatar
      KVM: arm/arm64: VGIC: Properly initialise private IRQ affinity · 2e16f3e9
      Andre Przywara authored
      At the moment we initialise the target *mask* of a virtual IRQ to the
      VCPU it belongs to, even though this mask is only defined for GICv2 and
      quickly runs out of bits for many GICv3 guests.
      This behaviour triggers an UBSAN complaint for more than 32 VCPUs:
      ------
      [ 5659.462377] UBSAN: Undefined behaviour in virt/kvm/arm/vgic/vgic-init.c:223:21
      [ 5659.471689] shift exponent 32 is too large for 32-bit type 'unsigned int'
      ------
      Also for GICv3 guests the reporting of TARGET in the "vgic-state" debugfs
      dump is wrong, due to this very same problem.
      
      Because there is no requirement to create the VGIC device before the
      VCPUs (and QEMU actually does it the other way round), we can't safely
      initialise mpidr or targets in kvm_vgic_vcpu_init(). But since we touch
      every private IRQ for each VCPU anyway later (in vgic_init()), we can
      just move the initialisation of those fields into there, where we
      definitely know the VGIC type.
      
      On the way make sure we really have either a VGICv2 or a VGICv3 device,
      since the existing code is just checking for "VGICv3 or not", silently
      ignoring the uninitialised case.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Reported-by: default avatarDave Martin <dave.martin@arm.com>
      Tested-by: default avatarJulien Grall <julien.grall@arm.com>
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      2e16f3e9
    • Linus Torvalds's avatar
      Merge tag 'modules-for-v5.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux · e3fb13b7
      Linus Torvalds authored
      Pull modules fixes from Jessica Yu:
       "Fix BUG_ON() being triggered in frob_text() due to non-page-aligned
        module sections"
      
      * tag 'modules-for-v5.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux:
        modules: page-align module section allocations only for arches supporting strict module rwx
        modules: always page-align module section allocations
      e3fb13b7
    • Linus Torvalds's avatar
      Merge tag 'ceph-for-5.3-rc6' of git://github.com/ceph/ceph-client · 4e563944
      Linus Torvalds authored
      Pull ceph fixes from Ilya Dryomov:
       "Three important fixes tagged for stable (an indefinite hang, a crash
        on an assert and a NULL pointer dereference) plus a small series from
        Luis fixing instances of vfree() under spinlock"
      
      * tag 'ceph-for-5.3-rc6' of git://github.com/ceph/ceph-client:
        libceph: fix PG split vs OSD (re)connect race
        ceph: don't try fill file_lock on unsuccessful GETFILELOCK reply
        ceph: clear page dirty before invalidate page
        ceph: fix buffer free while holding i_ceph_lock in fill_inode()
        ceph: fix buffer free while holding i_ceph_lock in __ceph_build_xattrs_blob()
        ceph: fix buffer free while holding i_ceph_lock in __ceph_setxattr()
        libceph: allow ceph_buffer_put() to receive a NULL ceph_buffer
      4e563944
    • Bernard Metzler's avatar
      RDMA/siw: Fix 64/32bit pointer inconsistency · c536277e
      Bernard Metzler authored
      Fixes improper casting between addresses and unsigned types.
      Changes siw_pbl_get_buffer() function to return appropriate
      dma_addr_t, and not u64.
      
      Also fixes debug prints. Now any potentially kernel private
      pointers are printed formatted as '%pK', to allow keeping that
      information secret.
      
      Fixes: d941bfe500be ("RDMA/siw: Change CQ flags from 64->32 bits")
      Fixes: b0fff731 ("rdma/siw: completion queue methods")
      Fixes: 8b6a361b ("rdma/siw: receive path")
      Fixes: b9be6f18 ("rdma/siw: transmit path")
      Fixes: f29dd55b ("rdma/siw: queue pair methods")
      Fixes: 2251334d ("rdma/siw: application buffer management")
      Fixes: 303ae1cd ("rdma/siw: application interface")
      Fixes: 6c52fdc2 ("rdma/siw: connection management")
      Fixes: a5319752 ("rdma/siw: main include file")
      Reported-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Reported-by: default avatarJason Gunthorpe <jgg@ziepe.ca>
      Reported-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarBernard Metzler <bmt@zurich.ibm.com>
      Link: https://lore.kernel.org/r/20190822173738.26817-1-bmt@zurich.ibm.comSigned-off-by: default avatarDoug Ledford <dledford@redhat.com>
      c536277e
    • Linus Torvalds's avatar
      Merge tag 'drm-fixes-2019-08-23' of git://anongit.freedesktop.org/drm/drm · 1374a22e
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "Live from the laundromat after my washing machine broke down, we have
        the 5.3-rc6 fixes. Changelog is in the tag below, but nothing too
        noteworthy in here:
      
        rcar-du:
         - LVDS dual-link mode fix
      
        mediatek:
         - of node refcount fix
         - prime buffer import fix
         - dma max seg fix
      
        komeda:
         - output polling fix
         - abfc format fix
         - memory-region DT fix
      
        amdgpu:
         - bpc display fix
         - ioctl memory leak fix
         - gfxoff fix
         - smu warnings fix
      
        i915:
         - HDMI mode readout fix"
      
      * tag 'drm-fixes-2019-08-23' of git://anongit.freedesktop.org/drm/drm:
        drm/amdgpu/powerplay: silence a warning in smu_v11_0_setup_pptable
        drm/amd/display: Calculate bpc based on max_requested_bpc
        drm/amdgpu: prevent memory leaks in AMDGPU_CS ioctl
        drm/amd/amdgpu: disable MMHUB PG for navi10
        drm/amd/powerplay: remove duplicate macro smu_get_uclk_dpm_states in amdgpu_smu.h
        drm/amd/powerplay: fix variable type errors in smu_v11_0_setup_pptable
        drm/amdgpu/gfx9: update pg_flags after determining if gfx off is possible
        drm/i915: Fix HW readout for crtc_clock in HDMI mode
        drm/mediatek: mtk_drm_drv.c: Add of_node_put() before goto
        drm: rcar_lvds: Fix dual link mode operations
        drm/mediatek: set DMA max segment size
        drm/mediatek: use correct device to import PRIME buffers
        drm/omap: ensure we have a valid dma_mask
        drm/komeda: Add support for 'memory-region' DT node property
        drm/komeda: Adds internal bpp computing for arm afbc only format YU08 YU10
        drm/komeda: Initialize and enable output polling on Komeda
      1374a22e
    • Mikulas Patocka's avatar
      dm table: fix invalid memory accesses with too high sector number · 1cfd5d33
      Mikulas Patocka authored
      If the sector number is too high, dm_table_find_target() should return a
      pointer to a zeroed dm_target structure (the caller should test it with
      dm_target_is_valid).
      
      However, for some table sizes, the code in dm_table_find_target() that
      performs btree lookup will access out of bound memory structures.
      
      Fix this bug by testing the sector number at the beginning of
      dm_table_find_target(). Also, add an "inline" keyword to the function
      dm_table_get_size() because this is a hot path.
      
      Fixes: 512875bd ("dm: table detect io beyond device")
      Cc: stable@vger.kernel.org
      Reported-by: default avatarZhang Tao <kontais@zoho.com>
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      1cfd5d33
    • Linus Walleij's avatar
      gpio: Fix irqchip initialization order · 48057ed1
      Linus Walleij authored
      The new API for registering a gpio_irq_chip along with a
      gpio_chip has a different semantic ordering than the old
      API which added the irqchip explicitly after registering
      the gpio_chip.
      
      Move the calls to add the gpio_irq_chip *last* in the
      function, so that the different hooks setting up OF and
      ACPI and machine gpio_chips are called *before* we try
      to register the interrupts, preserving the elder semantic
      order.
      
      This cropped up in the PL061 driver which used to work
      fine with no special ACPI quirks, but started to misbehave
      using the new API.
      
      Fixes: e0d89728 ("gpio: Implement tighter IRQ chip integration")
      Cc: Thierry Reding <treding@nvidia.com>
      Cc: Grygorii Strashko <grygorii.strashko@ti.com>
      Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
      Reported-by: default avatarWei Xu <xuwei5@hisilicon.com>
      Tested-by: default avatarWei Xu <xuwei5@hisilicon.com>
      Reported-by: default avatarAndy Shevchenko <andy.shevchenko@gmail.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Link: https://lore.kernel.org/r/20190820080527.11796-1-linus.walleij@linaro.org
      48057ed1
    • Darrick J. Wong's avatar
      xfs: fix missing ILOCK unlock when xfs_setattr_nonsize fails due to EDQUOT · 1fb254aa
      Darrick J. Wong authored
      Benjamin Moody reported to Debian that XFS partially wedges when a chgrp
      fails on account of being out of disk quota.  I ran his reproducer
      script:
      
      # adduser dummy
      # adduser dummy plugdev
      
      # dd if=/dev/zero bs=1M count=100 of=test.img
      # mkfs.xfs test.img
      # mount -t xfs -o gquota test.img /mnt
      # mkdir -p /mnt/dummy
      # chown -c dummy /mnt/dummy
      # xfs_quota -xc 'limit -g bsoft=100k bhard=100k plugdev' /mnt
      
      (and then as user dummy)
      
      $ dd if=/dev/urandom bs=1M count=50 of=/mnt/dummy/foo
      $ chgrp plugdev /mnt/dummy/foo
      
      and saw:
      
      ================================================
      WARNING: lock held when returning to user space!
      5.3.0-rc5 #rc5 Tainted: G        W
      ------------------------------------------------
      chgrp/47006 is leaving the kernel with locks still held!
      1 lock held by chgrp/47006:
       #0: 000000006664ea2d (&xfs_nondir_ilock_class){++++}, at: xfs_ilock+0xd2/0x290 [xfs]
      
      ...which is clearly caused by xfs_setattr_nonsize failing to unlock the
      ILOCK after the xfs_qm_vop_chown_reserve call fails.  Add the missing
      unlock.
      
      Reported-by: benjamin.moody@gmail.com
      Fixes: 253f4911 ("xfs: better xfs_trans_alloc interface")
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Tested-by: default avatarSalvatore Bonaccorso <carnil@debian.org>
      1fb254aa
    • Dave Airlie's avatar
    • Lyude Paul's avatar
      drm/nouveau: Don't retry infinitely when receiving no data on i2c over AUX · c358ebf5
      Lyude Paul authored
      While I had thought I had fixed this issue in:
      
      commit 342406e4 ("drm/nouveau/i2c: Disable i2c bus access after
      ->fini()")
      
      It turns out that while I did fix the error messages I was seeing on my
      P50 when trying to access i2c busses with the GPU in runtime suspend, I
      accidentally had missed one important detail that was mentioned on the
      bug report this commit was supposed to fix: that the CPU would only lock
      up when trying to access i2c busses _on connected devices_ _while the
      GPU is not in runtime suspend_. Whoops. That definitely explains why I
      was not able to get my machine to hang with i2c bus interactions until
      now, as plugging my P50 into it's dock with an HDMI monitor connected
      allowed me to finally reproduce this locally.
      
      Now that I have managed to reproduce this issue properly, it looks like
      the problem is much simpler then it looks. It turns out that some
      connected devices, such as MST laptop docks, will actually ACK i2c reads
      even if no data was actually read:
      
      [  275.063043] nouveau 0000:01:00.0: i2c: aux 000a: 1: 0000004c 1
      [  275.063447] nouveau 0000:01:00.0: i2c: aux 000a: 00 01101000 10040000
      [  275.063759] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000001
      [  275.064024] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000000
      [  275.064285] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000000
      [  275.064594] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000000
      
      Because we don't handle the situation of i2c ack without any data, we
      end up entering an infinite loop in nvkm_i2c_aux_i2c_xfer() since the
      value of cnt always remains at 0. This finally properly explains how
      this could result in a CPU hang like the ones observed in the
      aforementioned commit.
      
      So, fix this by retrying transactions if no data is written or received,
      and give up and fail the transaction if we continue to not write or
      receive any data after 32 retries.
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      c358ebf5
    • Alex Deucher's avatar
      drm/amdgpu/powerplay: silence a warning in smu_v11_0_setup_pptable · 75710f08
      Alex Deucher authored
      I think gcc is confused as I don't see how size could be used
      unitialized, but go ahead and silence the warning.
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Reviewed-by: default avatarEvan Quan <evan.quan@amd.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190822032527.1376-1-alexander.deucher@amd.com
      75710f08
    • Dave Airlie's avatar
      Merge tag 'drm-misc-fixes-2019-08-22' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes · cf3627fb
      Dave Airlie authored
      Fixes for v5.3-rc6:
      - dma fix for omap.
      - Make output polling work on komeda.
      - Fix bpp computing for AFBC formats in komeda.
      - Support the memory-region property in komeda.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      
      From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/5f1fdfe3-814e-fad1-663c-7279217fc085@linux.intel.com
      cf3627fb
    • Dave Airlie's avatar
      Merge tag 'drm-intel-fixes-2019-08-22' of... · dd89c112
      Dave Airlie authored
      Merge tag 'drm-intel-fixes-2019-08-22' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
      
      drm/i915 fixes for v5.3-rc6:
      - fix hardware state readout for 10 bpc HDMI
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      From: Jani Nikula <jani.nikula@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/87sgptd114.fsf@intel.com
      dd89c112
  4. 22 Aug, 2019 2 commits