1. 03 Feb, 2023 33 commits
  2. 01 Feb, 2023 7 commits
    • Andrew Morton's avatar
      Sync mm-stable with mm-hotfixes-stable to pick up dependent patches · 5ab0fc15
      Andrew Morton authored
      Merge branch 'mm-hotfixes-stable' into mm-stable
      5ab0fc15
    • Kefeng Wang's avatar
      mm: memcg: fix NULL pointer in mem_cgroup_track_foreign_dirty_slowpath() · ac86f547
      Kefeng Wang authored
      As commit 18365225 ("hwpoison, memcg: forcibly uncharge LRU pages"),
      hwpoison will forcibly uncharg a LRU hwpoisoned page, the folio_memcg
      could be NULl, then, mem_cgroup_track_foreign_dirty_slowpath() could
      occurs a NULL pointer dereference, let's do not record the foreign
      writebacks for folio memcg is null in mem_cgroup_track_foreign_dirty() to
      fix it.
      
      Link: https://lkml.kernel.org/r/20230129040945.180629-1-wangkefeng.wang@huawei.com
      Fixes: 97b27821 ("writeback, memcg: Implement foreign dirty flushing")
      Signed-off-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Reported-by: default avatarMa Wupeng <mawupeng1@huawei.com>
      Tested-by: default avatarMiko Larsson <mikoxyzzz@gmail.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
      Cc: Ma Wupeng <mawupeng1@huawei.com>
      Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
      Cc: Shakeel Butt <shakeelb@google.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      ac86f547
    • ye xingchen's avatar
      Kconfig.debug: fix the help description in SCHED_DEBUG · 1e90e35b
      ye xingchen authored
      The correct file path for SCHED_DEBUG is /sys/kernel/debug/sched.
      
      Link: https://lkml.kernel.org/r/202301291013573466558@zte.com.cnSigned-off-by: default avatarye xingchen <ye.xingchen@zte.com.cn>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Geert Uytterhoeven <geert+renesas@glider.be>
      Cc: Josh Poimboeuf <jpoimboe@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Miguel Ojeda <ojeda@kernel.org>
      Cc: Nathan Chancellor <nathan@kernel.org>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      1e90e35b
    • Longlong Xia's avatar
      mm/swapfile: add cond_resched() in get_swap_pages() · 7717fc1a
      Longlong Xia authored
      The softlockup still occurs in get_swap_pages() under memory pressure.  64
      CPU cores, 64GB memory, and 28 zram devices, the disksize of each zram
      device is 50MB with same priority as si.  Use the stress-ng tool to
      increase memory pressure, causing the system to oom frequently.
      
      The plist_for_each_entry_safe() loops in get_swap_pages() could reach tens
      of thousands of times to find available space (extreme case:
      cond_resched() is not called in scan_swap_map_slots()).  Let's add
      cond_resched() into get_swap_pages() when failed to find available space
      to avoid softlockup.
      
      Link: https://lkml.kernel.org/r/20230128094757.1060525-1-xialonglong1@huawei.comSigned-off-by: default avatarLonglong Xia <xialonglong1@huawei.com>
      Reviewed-by: default avatar"Huang, Ying" <ying.huang@intel.com>
      Cc: Chen Wandun <chenwandun@huawei.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
      Cc: Nanyong Sun <sunnanyong@huawei.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      7717fc1a
    • Zhaoyang Huang's avatar
      mm: use stack_depot_early_init for kmemleak · 993f57e0
      Zhaoyang Huang authored
      Mirsad report the below error which is caused by stack_depot_init()
      failure in kvcalloc.  Solve this by having stackdepot use
      stack_depot_early_init().
      
      On 1/4/23 17:08, Mirsad Goran Todorovac wrote:
      I hate to bring bad news again, but there seems to be a problem with the output of /sys/kernel/debug/kmemleak:
      
      [root@pc-mtodorov ~]# cat /sys/kernel/debug/kmemleak
      unreferenced object 0xffff951c118568b0 (size 16):
      comm "kworker/u12:2", pid 56, jiffies 4294893952 (age 4356.548s)
      hex dump (first 16 bytes):
          6d 65 6d 73 74 69 63 6b 30 00 00 00 00 00 00 00 memstick0.......
          backtrace:
      [root@pc-mtodorov ~]#
      
      Apparently, backtrace of called functions on the stack is no longer
      printed with the list of memory leaks.  This appeared on Lenovo desktop
      10TX000VCR, with AlmaLinux 8.7 and BIOS version M22KT49A (11/10/2022) and
      6.2-rc1 and 6.2-rc2 builds.  This worked on 6.1 with the same
      CONFIG_KMEMLEAK=y and MGLRU enabled on a vanilla mainstream kernel from
      Mr.  Torvalds' tree.  I don't know if this is deliberate feature for some
      reason or a bug.  Please find attached the config, lshw and kmemleak
      output.
      
      [vbabka@suse.cz: remove stack_depot_init() call]
      Link: https://lore.kernel.org/all/5272a819-ef74-65ff-be61-4d2d567337de@alu.unizg.hr/
      Link: https://lkml.kernel.org/r/1674091345-14799-2-git-send-email-zhaoyang.huang@unisoc.com
      Fixes: 56a61617 ("mm: use stack_depot for recording kmemleak's backtrace")
      Reported-by: default avatarMirsad Todorovac <mirsad.todorovac@alu.unizg.hr>
      Suggested-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Signed-off-by: default avatarZhaoyang Huang <zhaoyang.huang@unisoc.com>
      Acked-by: default avatarMike Rapoport (IBM) <rppt@kernel.org>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Tested-by: default avatarBorislav Petkov (AMD) <bp@alien8.de>
      Cc: ke.wang <ke.wang@unisoc.com>
      Cc: Nathan Chancellor <nathan@kernel.org>
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      993f57e0
    • Phillip Lougher's avatar
      Squashfs: fix handling and sanity checking of xattr_ids count · f65c4bbb
      Phillip Lougher authored
      A Sysbot [1] corrupted filesystem exposes two flaws in the handling and
      sanity checking of the xattr_ids count in the filesystem.  Both of these
      flaws cause computation overflow due to incorrect typing.
      
      In the corrupted filesystem the xattr_ids value is 4294967071, which
      stored in a signed variable becomes the negative number -225.
      
      Flaw 1 (64-bit systems only):
      
      The signed integer xattr_ids variable causes sign extension.
      
      This causes variable overflow in the SQUASHFS_XATTR_*(A) macros.  The
      variable is first multiplied by sizeof(struct squashfs_xattr_id) where the
      type of the sizeof operator is "unsigned long".
      
      On a 64-bit system this is 64-bits in size, and causes the negative number
      to be sign extended and widened to 64-bits and then become unsigned.  This
      produces the very large number 18446744073709548016 or 2^64 - 3600.  This
      number when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and
      divided by SQUASHFS_METADATA_SIZE overflows and produces a length of 0
      (stored in len).
      
      Flaw 2 (32-bit systems only):
      
      On a 32-bit system the integer variable is not widened by the unsigned
      long type of the sizeof operator (32-bits), and the signedness of the
      variable has no effect due it always being treated as unsigned.
      
      The above corrupted xattr_ids value of 4294967071, when multiplied
      overflows and produces the number 4294963696 or 2^32 - 3400.  This number
      when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and divided by
      SQUASHFS_METADATA_SIZE overflows again and produces a length of 0.
      
      The effect of the 0 length computation:
      
      In conjunction with the corrupted xattr_ids field, the filesystem also has
      a corrupted xattr_table_start value, where it matches the end of
      filesystem value of 850.
      
      This causes the following sanity check code to fail because the
      incorrectly computed len of 0 matches the incorrect size of the table
      reported by the superblock (0 bytes).
      
          len = SQUASHFS_XATTR_BLOCK_BYTES(*xattr_ids);
          indexes = SQUASHFS_XATTR_BLOCKS(*xattr_ids);
      
          /*
           * The computed size of the index table (len bytes) should exactly
           * match the table start and end points
          */
          start = table_start + sizeof(*id_table);
          end = msblk->bytes_used;
      
          if (len != (end - start))
                  return ERR_PTR(-EINVAL);
      
      Changing the xattr_ids variable to be "usigned int" fixes the flaw on a
      64-bit system.  This relies on the fact the computation is widened by the
      unsigned long type of the sizeof operator.
      
      Casting the variable to u64 in the above macro fixes this flaw on a 32-bit
      system.
      
      It also means 64-bit systems do not implicitly rely on the type of the
      sizeof operator to widen the computation.
      
      [1] https://lore.kernel.org/lkml/000000000000cd44f005f1a0f17f@google.com/
      
      Link: https://lkml.kernel.org/r/20230127061842.10965-1-phillip@squashfs.org.uk
      Fixes: 506220d2 ("squashfs: add more sanity checks in xattr id lookup")
      Signed-off-by: default avatarPhillip Lougher <phillip@squashfs.org.uk>
      Reported-by: <syzbot+082fa4af80a5bb1a9843@syzkaller.appspotmail.com>
      Cc: Alexey Khoroshilov <khoroshilov@ispras.ru>
      Cc: Fedor Pchelkin <pchelkin@ispras.ru>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      f65c4bbb
    • Tom Saeger's avatar
      sh: define RUNTIME_DISCARD_EXIT · c1c551be
      Tom Saeger authored
      sh vmlinux fails to link with GNU ld < 2.40 (likely < 2.36) since
      commit 99cb0d91 ("arch: fix broken BuildID for arm64 and riscv").
      
      This is similar to fixes for powerpc and s390:
      commit 4b9880db ("powerpc/vmlinux.lds: Define RUNTIME_DISCARD_EXIT").
      commit a494398b ("s390: define RUNTIME_DISCARD_EXIT to fix link error
      with GNU ld < 2.36").
      
        $ sh4-linux-gnu-ld --version | head -n1
        GNU ld (GNU Binutils for Debian) 2.35.2
      
        $ make ARCH=sh CROSS_COMPILE=sh4-linux-gnu- microdev_defconfig
        $ make ARCH=sh CROSS_COMPILE=sh4-linux-gnu-
      
        `.exit.text' referenced in section `__bug_table' of crypto/algboss.o:
        defined in discarded section `.exit.text' of crypto/algboss.o
        `.exit.text' referenced in section `__bug_table' of
        drivers/char/hw_random/core.o: defined in discarded section
        `.exit.text' of drivers/char/hw_random/core.o
        make[2]: *** [scripts/Makefile.vmlinux:34: vmlinux] Error 1
        make[1]: *** [Makefile:1252: vmlinux] Error 2
      
      arch/sh/kernel/vmlinux.lds.S keeps EXIT_TEXT:
      
      	/*
      	 * .exit.text is discarded at runtime, not link time, to deal with
      	 * references from __bug_table
      	 */
      	.exit.text : AT(ADDR(.exit.text)) { EXIT_TEXT }
      
      However, EXIT_TEXT is thrown away by
      DISCARD(include/asm-generic/vmlinux.lds.h) because
      sh does not define RUNTIME_DISCARD_EXIT.
      
      GNU ld 2.40 does not have this issue and builds fine.
      This corresponds with Masahiro's comments in a494398b:
      "Nathan [Chancellor] also found that binutils
      commit 21401fc7bf67 ("Duplicate output sections in scripts") cured this
      issue, so we cannot reproduce it with binutils 2.36+, but it is better
      to not rely on it."
      
      Link: https://lkml.kernel.org/r/9166a8abdc0f979e50377e61780a4bba1dfa2f52.1674518464.git.tom.saeger@oracle.com
      Fixes: 99cb0d91 ("arch: fix broken BuildID for arm64 and riscv")
      Link: https://lore.kernel.org/all/Y7Jal56f6UBh1abE@dev-arch.thelio-3990X/
      Link: https://lore.kernel.org/all/20230123194218.47ssfzhrpnv3xfez@oracle.com/Signed-off-by: default avatarTom Saeger <tom.saeger@oracle.com>
      Tested-by: default avatarJohn Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
      Cc: Ard Biesheuvel <ardb@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Dennis Gilmore <dennis@ausil.us>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Masahiro Yamada <masahiroy@kernel.org>
      Cc: Naresh Kamboju <naresh.kamboju@linaro.org>
      Cc: Nathan Chancellor <nathan@kernel.org>
      Cc: Palmer Dabbelt <palmer@rivosinc.com>
      Cc: Rich Felker <dalias@libc.org>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      c1c551be