1. 25 Apr, 2022 14 commits
  2. 20 Apr, 2022 3 commits
  3. 17 Apr, 2022 10 commits
  4. 16 Apr, 2022 6 commits
    • Linus Torvalds's avatar
      Merge tag 'soc-fixes-5.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc · 70a0cec8
      Linus Torvalds authored
      Pull ARM SoC fixes from Arnd Bergmann:
       "There are a number of SoC bugfixes that came in since the merge
        window, and more of them are already pending.
      
        This batch includes:
      
         - A boot time regression fix for davinci that triggered on
           multi_v5_defconfig when booting any platform
      
         - Defconfig updates to address removed features, changed symbol names
           or dependencies, for gemini, ux500, and pxa
      
         - Email address changes for Krzysztof Kozlowski
      
         - Build warning fixes for ep93xx and iop32x
      
         - Devicetree warning fixes across many platforms
      
         - Minor bugfixes for the reset controller, memory controller and SCMI
           firmware subsystems plus the versatile-express board"
      
      * tag 'soc-fixes-5.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (34 commits)
        ARM: config: Update Gemini defconfig
        arm64: dts: qcom/sdm845-shift-axolotl: Fix boolean properties with values
        ARM: dts: align SPI NOR node name with dtschema
        ARM: dts: Fix more boolean properties with values
        arm/arm64: dts: qcom: Fix boolean properties with values
        arm64: dts: imx: Fix imx8*-var-som touchscreen property sizes
        arm: dts: imx: Fix boolean properties with values
        arm64: dts: tegra: Fix boolean properties with values
        arm: dts: at91: Fix boolean properties with values
        arm: configs: imote2: Drop defconfig as board support dropped.
        ep93xx: clock: Don't use plain integer as NULL pointer
        ep93xx: clock: Fix UAF in ep93xx_clk_register_gate()
        ARM: vexpress/spc: Fix all the kernel-doc build warnings
        ARM: vexpress/spc: Fix kernel-doc build warning for ve_spc_cpu_in_wfi
        ARM: config: u8500: Re-enable AB8500 battery charging
        ARM: config: u8500: Add some common hardware
        memory: fsl_ifc: populate child nodes of buses and mfd devices
        ARM: config: Refresh U8500 defconfig
        firmware: arm_scmi: Fix sparse warnings in OPTEE transport driver
        firmware: arm_scmi: Replace zero-length array with flexible-array member
        ...
      70a0cec8
    • Linus Torvalds's avatar
      Merge tag 'random-5.18-rc3-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/crng/random · 92edbe32
      Linus Torvalds authored
      Pull random number generator fixes from Jason Donenfeld:
      
       - Per your suggestion, random reads now won't fail if there's a page
         fault after some non-zero amount of data has been read, which makes
         the behavior consistent with all other reads in the kernel.
      
       - Rather than an inconsistent mix of random_get_entropy() returning an
         unsigned long or a cycles_t, now it just returns an unsigned long.
      
       - A memcpy() was replaced with an memmove(), because the addresses are
         sometimes overlapping. In practice the destination is always before
         the source, so not really an issue, but better to be correct than
         not.
      
      * tag 'random-5.18-rc3-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/crng/random:
        random: use memmove instead of memcpy for remaining 32 bytes
        random: make random_get_entropy() return an unsigned long
        random: allow partial reads if later user copies fail
      92edbe32
    • Linus Torvalds's avatar
      Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · 90ea17a9
      Linus Torvalds authored
      Pull SCSI fixes from James Bottomley:
       "13 fixes, all in drivers.
      
        The most extensive changes are in the iscsi series (affecting drivers
        qedi, cxgbi and bnx2i), the next most is scsi_debug, but that's just a
        simple revert and then minor updates to pm80xx"
      
      * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
        scsi: iscsi: MAINTAINERS: Add Mike Christie as co-maintainer
        scsi: qedi: Fix failed disconnect handling
        scsi: iscsi: Fix NOP handling during conn recovery
        scsi: iscsi: Merge suspend fields
        scsi: iscsi: Fix unbound endpoint error handling
        scsi: iscsi: Fix conn cleanup and stop race during iscsid restart
        scsi: iscsi: Fix endpoint reuse regression
        scsi: iscsi: Release endpoint ID when its freed
        scsi: iscsi: Fix offload conn cleanup when iscsid restarts
        scsi: iscsi: Move iscsi_ep_disconnect()
        scsi: pm80xx: Enable upper inbound, outbound queues
        scsi: pm80xx: Mask and unmask upper interrupt vectors 32-63
        Revert "scsi: scsi_debug: Address races following module load"
      90ea17a9
    • Bartosz Golaszewski's avatar
      Merge tag 'intel-gpio-v5.18-2' of... · 0ebb4fbe
      Bartosz Golaszewski authored
      Merge tag 'intel-gpio-v5.18-2' of gitolite.kernel.org:pub/scm/linux/kernel/git/andy/linux-gpio-intel into gpio/for-current
      
      intel-gpio for v5.18-2
      
      * Couple of fixes related to handling unsigned value of the pin from ACPI
      
      gpiolib:
       -  acpi: Convert type for pin to be unsigned
       -  acpi: use correct format characters
      0ebb4fbe
    • Linus Torvalds's avatar
      Merge tag 'dma-mapping-5.18-2' of git://git.infradead.org/users/hch/dma-mapping · b0086839
      Linus Torvalds authored
      Pull dma-mapping fix from Christoph Hellwig:
      
       - avoid a double memory copy for swiotlb (Chao Gao)
      
      * tag 'dma-mapping-5.18-2' of git://git.infradead.org/users/hch/dma-mapping:
        dma-direct: avoid redundant memory sync for swiotlb
      b0086839
    • Jason A. Donenfeld's avatar
      random: use memmove instead of memcpy for remaining 32 bytes · 35a33ff3
      Jason A. Donenfeld authored
      In order to immediately overwrite the old key on the stack, before
      servicing a userspace request for bytes, we use the remaining 32 bytes
      of block 0 as the key. This means moving indices 8,9,a,b,c,d,e,f ->
      4,5,6,7,8,9,a,b. Since 4 < 8, for the kernel implementations of
      memcpy(), this doesn't actually appear to be a problem in practice. But
      relying on that characteristic seems a bit brittle. So let's change that
      to a proper memmove(), which is the by-the-books way of handling
      overlapping memory copies.
      Reviewed-by: default avatarDominik Brodowski <linux@dominikbrodowski.net>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      35a33ff3
  5. 15 Apr, 2022 7 commits
    • Linus Torvalds's avatar
      Merge branch 'akpm' (patches from Andrew) · 59250f8a
      Linus Torvalds authored
      Merge misc fixes from Andrew Morton:
       "14 patches.
      
        Subsystems affected by this patch series: MAINTAINERS, binfmt, and
        mm (tmpfs, secretmem, kasan, kfence, pagealloc, zram, compaction,
        hugetlb, vmalloc, and kmemleak)"
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>:
        mm: kmemleak: take a full lowmem check in kmemleak_*_phys()
        mm/vmalloc: fix spinning drain_vmap_work after reading from /proc/vmcore
        revert "fs/binfmt_elf: use PT_LOAD p_align values for static PIE"
        revert "fs/binfmt_elf: fix PT_LOAD p_align values for loaders"
        hugetlb: do not demote poisoned hugetlb pages
        mm: compaction: fix compiler warning when CONFIG_COMPACTION=n
        mm: fix unexpected zeroed page mapping with zram swap
        mm, page_alloc: fix build_zonerefs_node()
        mm, kfence: support kmem_dump_obj() for KFENCE objects
        kasan: fix hw tags enablement when KUNIT tests are disabled
        irq_work: use kasan_record_aux_stack_noalloc() record callstack
        mm/secretmem: fix panic when growing a memfd_secret
        tmpfs: fix regressions from wider use of ZERO_PAGE
        MAINTAINERS: Broadcom internal lists aren't maintainers
      59250f8a
    • Linus Torvalds's avatar
      Merge tag 'for-5.18/dm-fixes-2' of... · ce673f63
      Linus Torvalds authored
      Merge tag 'for-5.18/dm-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
      
      Pull device mapper fixes from Mike Snitzer:
      
       - Fix memory corruption in DM integrity target when tag_size is less
         than digest size.
      
       - Fix DM multipath's historical-service-time path selector to not use
         sched_clock() and ktime_get_ns(); only use ktime_get_ns().
      
       - Fix dm_io->orig_bio NULL pointer dereference in dm_zone_map_bio() due
         to 5.18 changes that overlooked DM zone's use of ->orig_bio
      
       - Fix for regression that broke the use of dm_accept_partial_bio() for
         "abnormal" IO (e.g. WRITE ZEROES) that does not need duplicate bios
      
       - Fix DM's issuing of empty flush bio so that it's size is 0.
      
      * tag 'for-5.18/dm-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
        dm: fix bio length of empty flush
        dm: allow dm_accept_partial_bio() for dm_io without duplicate bios
        dm zone: fix NULL pointer dereference in dm_zone_map_bio
        dm mpath: only use ktime_get_ns() in historical selector
        dm integrity: fix memory corruption when tag_size is less than digest size
      ce673f63
    • Patrick Wang's avatar
      mm: kmemleak: take a full lowmem check in kmemleak_*_phys() · 23c2d497
      Patrick Wang authored
      The kmemleak_*_phys() apis do not check the address for lowmem's min
      boundary, while the caller may pass an address below lowmem, which will
      trigger an oops:
      
        # echo scan > /sys/kernel/debug/kmemleak
        Unable to handle kernel paging request at virtual address ff5fffffffe00000
        Oops [#1]
        Modules linked in:
        CPU: 2 PID: 134 Comm: bash Not tainted 5.18.0-rc1-next-20220407 #33
        Hardware name: riscv-virtio,qemu (DT)
        epc : scan_block+0x74/0x15c
         ra : scan_block+0x72/0x15c
        epc : ffffffff801e5806 ra : ffffffff801e5804 sp : ff200000104abc30
         gp : ffffffff815cd4e8 tp : ff60000004cfa340 t0 : 0000000000000200
         t1 : 00aaaaaac23954cc t2 : 00000000000003ff s0 : ff200000104abc90
         s1 : ffffffff81b0ff28 a0 : 0000000000000000 a1 : ff5fffffffe01000
         a2 : ffffffff81b0ff28 a3 : 0000000000000002 a4 : 0000000000000001
         a5 : 0000000000000000 a6 : ff200000104abd7c a7 : 0000000000000005
         s2 : ff5fffffffe00ff9 s3 : ffffffff815cd998 s4 : ffffffff815d0e90
         s5 : ffffffff81b0ff28 s6 : 0000000000000020 s7 : ffffffff815d0eb0
         s8 : ffffffffffffffff s9 : ff5fffffffe00000 s10: ff5fffffffe01000
         s11: 0000000000000022 t3 : 00ffffffaa17db4c t4 : 000000000000000f
         t5 : 0000000000000001 t6 : 0000000000000000
        status: 0000000000000100 badaddr: ff5fffffffe00000 cause: 000000000000000d
          scan_gray_list+0x12e/0x1a6
          kmemleak_scan+0x2aa/0x57e
          kmemleak_write+0x32a/0x40c
          full_proxy_write+0x56/0x82
          vfs_write+0xa6/0x2a6
          ksys_write+0x6c/0xe2
          sys_write+0x22/0x2a
          ret_from_syscall+0x0/0x2
      
      The callers may not quite know the actual address they pass(e.g. from
      devicetree).  So the kmemleak_*_phys() apis should guarantee the address
      they finally use is in lowmem range, so check the address for lowmem's
      min boundary.
      
      Link: https://lkml.kernel.org/r/20220413122925.33856-1-patrick.wang.shcn@gmail.comSigned-off-by: default avatarPatrick Wang <patrick.wang.shcn@gmail.com>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@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>
      23c2d497
    • Omar Sandoval's avatar
      mm/vmalloc: fix spinning drain_vmap_work after reading from /proc/vmcore · c12cd77c
      Omar Sandoval authored
      Commit 3ee48b6a ("mm, x86: Saving vmcore with non-lazy freeing of
      vmas") introduced set_iounmap_nonlazy(), which sets vmap_lazy_nr to
      lazy_max_pages() + 1, ensuring that any future vunmaps() immediately
      purge the vmap areas instead of doing it lazily.
      
      Commit 690467c8 ("mm/vmalloc: Move draining areas out of caller
      context") moved the purging from the vunmap() caller to a worker thread.
      Unfortunately, set_iounmap_nonlazy() can cause the worker thread to spin
      (possibly forever).  For example, consider the following scenario:
      
       1. Thread reads from /proc/vmcore. This eventually calls
          __copy_oldmem_page() -> set_iounmap_nonlazy(), which sets
          vmap_lazy_nr to lazy_max_pages() + 1.
      
       2. Then it calls free_vmap_area_noflush() (via iounmap()), which adds 2
          pages (one page plus the guard page) to the purge list and
          vmap_lazy_nr. vmap_lazy_nr is now lazy_max_pages() + 3, so the
          drain_vmap_work is scheduled.
      
       3. Thread returns from the kernel and is scheduled out.
      
       4. Worker thread is scheduled in and calls drain_vmap_area_work(). It
          frees the 2 pages on the purge list. vmap_lazy_nr is now
          lazy_max_pages() + 1.
      
       5. This is still over the threshold, so it tries to purge areas again,
          but doesn't find anything.
      
       6. Repeat 5.
      
      If the system is running with only one CPU (which is typicial for kdump)
      and preemption is disabled, then this will never make forward progress:
      there aren't any more pages to purge, so it hangs.  If there is more
      than one CPU or preemption is enabled, then the worker thread will spin
      forever in the background.  (Note that if there were already pages to be
      purged at the time that set_iounmap_nonlazy() was called, this bug is
      avoided.)
      
      This can be reproduced with anything that reads from /proc/vmcore
      multiple times.  E.g., vmcore-dmesg /proc/vmcore.
      
      It turns out that improvements to vmap() over the years have obsoleted
      the need for this "optimization".  I benchmarked `dd if=/proc/vmcore
      of=/dev/null` with 4k and 1M read sizes on a system with a 32GB vmcore.
      The test was run on 5.17, 5.18-rc1 with a fix that avoided the hang, and
      5.18-rc1 with set_iounmap_nonlazy() removed entirely:
      
          |5.17  |5.18+fix|5.18+removal
        4k|40.86s|  40.09s|      26.73s
        1M|24.47s|  23.98s|      21.84s
      
      The removal was the fastest (by a wide margin with 4k reads).  This
      patch removes set_iounmap_nonlazy().
      
      Link: https://lkml.kernel.org/r/52f819991051f9b865e9ce25605509bfdbacadcd.1649277321.git.osandov@fb.com
      Fixes: 690467c8  ("mm/vmalloc: Move draining areas out of caller context")
      Signed-off-by: default avatarOmar Sandoval <osandov@fb.com>
      Acked-by: default avatarChris Down <chris@chrisdown.name>
      Reviewed-by: default avatarUladzislau Rezki (Sony) <urezki@gmail.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Acked-by: default avatarBaoquan He <bhe@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c12cd77c
    • Andrew Morton's avatar
      revert "fs/binfmt_elf: use PT_LOAD p_align values for static PIE" · aeb79237
      Andrew Morton authored
      Despite Mike's attempted fix (925346c1), regressions reports
      continue:
      
        https://lore.kernel.org/lkml/cb5b81bd-9882-e5dc-cd22-54bdbaaefbbc@leemhuis.info/
        https://bugzilla.kernel.org/show_bug.cgi?id=215720
        https://lkml.kernel.org/r/b685f3d0-da34-531d-1aa9-479accd3e21b@leemhuis.info
      
      So revert this patch.
      
      Fixes: 9630f0d6 ("fs/binfmt_elf: use PT_LOAD p_align values for static PIE")
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Chris Kennelly <ckennelly@google.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Fangrui Song <maskray@google.com>
      Cc: H.J. Lu <hjl.tools@gmail.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Mike Kravetz <mike.kravetz@oracle.com>
      Cc: Mike Rapoport <rppt@kernel.org>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Cc: Sandeep Patil <sspatil@google.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Song Liu <songliubraving@fb.com>
      Cc: Suren Baghdasaryan <surenb@google.com>
      Cc: Thorsten Leemhuis <regressions@leemhuis.info>
      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>
      aeb79237
    • Andrew Morton's avatar
      revert "fs/binfmt_elf: fix PT_LOAD p_align values for loaders" · 354e923d
      Andrew Morton authored
      Commit 925346c1 ("fs/binfmt_elf: fix PT_LOAD p_align values for
      loaders") was an attempt to fix regressions due to 9630f0d6
      ("fs/binfmt_elf: use PT_LOAD p_align values for static PIE").
      
      But regressionss continue to be reported:
      
        https://lore.kernel.org/lkml/cb5b81bd-9882-e5dc-cd22-54bdbaaefbbc@leemhuis.info/
        https://bugzilla.kernel.org/show_bug.cgi?id=215720
        https://lkml.kernel.org/r/b685f3d0-da34-531d-1aa9-479accd3e21b@leemhuis.info
      
      This patch reverts the fix, so the original can also be reverted.
      
      Fixes: 925346c1 ("fs/binfmt_elf: fix PT_LOAD p_align values for loaders")
      Cc: H.J. Lu <hjl.tools@gmail.com>
      Cc: Chris Kennelly <ckennelly@google.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Song Liu <songliubraving@fb.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Suren Baghdasaryan <surenb@google.com>
      Cc: Sandeep Patil <sspatil@google.com>
      Cc: Fangrui Song <maskray@google.com>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Mike Kravetz <mike.kravetz@oracle.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Thorsten Leemhuis <regressions@leemhuis.info>
      Cc: Mike Rapoport <rppt@kernel.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>
      354e923d
    • Mike Kravetz's avatar
      hugetlb: do not demote poisoned hugetlb pages · 5a317412
      Mike Kravetz authored
      It is possible for poisoned hugetlb pages to reside on the free lists.
      The huge page allocation routines which dequeue entries from the free
      lists make a point of avoiding poisoned pages.  There is no such check
      and avoidance in the demote code path.
      
      If a hugetlb page on the is on a free list, poison will only be set in
      the head page rather then the page with the actual error.  If such a
      page is demoted, then the poison flag may follow the wrong page.  A page
      without error could have poison set, and a page with poison could not
      have the flag set.
      
      Check for poison before attempting to demote a hugetlb page.  Also,
      return -EBUSY to the caller if only poisoned pages are on the free list.
      
      Link: https://lkml.kernel.org/r/20220307215707.50916-1-mike.kravetz@oracle.com
      Fixes: 8531fc6f ("hugetlb: add hugetlb demote page support")
      Signed-off-by: default avatarMike Kravetz <mike.kravetz@oracle.com>
      Reviewed-by: default avatarNaoya Horiguchi <naoya.horiguchi@nec.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>
      5a317412