linux-toradex.git/mm, branch v5.11-rc6

Revert "mm/slub: fix a memory leak in sysfs_slab_add()"

2021-01-28T17:05:44+00:00

This reverts commit dde3c6b72a16c2db826f54b2d49bdea26c3534a2.

syzbot report a double-free bug. The following case can cause this bug.

 - mm/slab_common.c: create_cache(): if the __kmem_cache_create() fails,
   it does:

	out_free_cache:
		kmem_cache_free(kmem_cache, s);

 - but __kmem_cache_create() - at least for slub() - will have done

	sysfs_slab_add(s)
		-> sysfs_create_group() .. fails ..
		-> kobject_del(&s->kobj); .. which frees s ...

We can't remove the kmem_cache_free() in create_cache(), because other
error cases of __kmem_cache_create() do not free this.

So, revert the commit dde3c6b72a16 ("mm/slub: fix a memory leak in
sysfs_slab_add()") to fix this.

Reported-by: syzbot+d0bd96b4696c1ef67991@syzkaller.appspotmail.com
Fixes: dde3c6b72a16 ("mm/slub: fix a memory leak in sysfs_slab_add()")
Acked-by: Vlastimil Babka 
Signed-off-by: Wang Hai 
Cc: 
Signed-off-by: Linus Torvalds

Revert "mm: fix initialization of struct page for holes in memory layout"

2021-01-26T18:39:46+00:00

This reverts commit d3921cb8be29ce5668c64e23ffdaeec5f8c69399.

Chris Wilson reports that it causes boot problems:

 "We have half a dozen or so different machines in CI that are silently
  failing to boot, that we believe is bisected to this patch"

and the CI team confirmed that a revert fixed the issues.

The cause is unknown for now, so let's revert it.

Link: https://lore.kernel.org/lkml/161160687463.28991.354987542182281928@build.alporthouse.com/
Reported-and-tested-by: Chris Wilson 
Acked-by: Mike Rapoport 
Cc: Andrea Arcangeli 
Cc: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/highmem: prepare for overriding set_pte_at()

2021-01-24T18:34:52+00:00

The generic kmap_local() map function uses set_pte_at(), but MIPS requires
set_pte() and PowerPC wants __set_pte_at().

Provide arch_kmap_local_set_pte() and default it to set_pte_at().

Link: https://lkml.kernel.org/r/20210112170411.056306194@linutronix.de
Signed-off-by: Thomas Gleixner 
Cc: Andreas Larsson 
Cc: "David S. Miller" 
Cc: Michael Ellerman 
Cc: Paul Cercueil 
Cc: Peter Zijlstra 
Cc: Thomas Bogendoerfer 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: fix page reference leak in soft_offline_page()

2021-01-24T18:34:52+00:00

The conversion to move pfn_to_online_page() internal to
soft_offline_page() missed that the get_user_pages() reference taken by
the madvise() path needs to be dropped when pfn_to_online_page() fails.

Note the direct sysfs-path to soft_offline_page() does not perform a
get_user_pages() lookup.

When soft_offline_page() is handed a pfn_valid() && !pfn_to_online_page()
pfn the kernel hangs at dax-device shutdown due to a leaked reference.

Link: https://lkml.kernel.org/r/161058501210.1840162.8108917599181157327.stgit@dwillia2-desk3.amr.corp.intel.com
Fixes: feec24a6139d ("mm, soft-offline: convert parameter to pfn")
Signed-off-by: Dan Williams 
Reviewed-by: David Hildenbrand 
Reviewed-by: Oscar Salvador 
Reviewed-by: Naoya Horiguchi 
Cc: Michal Hocko 
Cc: Qian Cai 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kasan, mm: fix resetting page_alloc tags for HW_TAGS

2021-01-24T18:34:52+00:00

A previous commit added resetting KASAN page tags to
kernel_init_free_pages() to avoid false-positives due to accesses to
metadata with the hardware tag-based mode.

That commit did reset page tags before the metadata access, but didn't
restore them after.  As the result, KASAN fails to detect bad accesses
to page_alloc allocations on some configurations.

Fix this by recovering the tag after the metadata access.

Link: https://lkml.kernel.org/r/02b5bcd692e912c27d484030f666b350ad7e4ae4.1611074450.git.andreyknvl@google.com
Fixes: aa1ef4d7b3f6 ("kasan, mm: reset tags when accessing metadata")
Signed-off-by: Andrey Konovalov 
Cc: Dmitry Vyukov 
Cc: Alexander Potapenko 
Cc: Marco Elver 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Vincenzo Frascino 
Cc: Andrey Ryabinin 
Cc: Peter Collingbourne 
Cc: Evgenii Stepanov 
Cc: Branislav Rankov 
Cc: Kevin Brodsky 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kasan, mm: fix conflicts with init_on_alloc/free

2021-01-24T18:34:52+00:00

A few places where SLUB accesses object's data or metadata were missed
in a previous patch.  This leads to false positives with hardware
tag-based KASAN when bulk allocations are used with init_on_alloc/free.

Fix the false-positives by resetting pointer tags during these accesses.

(The kasan_reset_tag call is removed from slab_alloc_node, as it's added
 into maybe_wipe_obj_freeptr.)

Link: https://linux-review.googlesource.com/id/I50dd32838a666e173fe06c3c5c766f2c36aae901
Link: https://lkml.kernel.org/r/093428b5d2ca8b507f4a79f92f9929b35f7fada7.1610731872.git.andreyknvl@google.com
Fixes: aa1ef4d7b3f67 ("kasan, mm: reset tags when accessing metadata")
Signed-off-by: Andrey Konovalov 
Reported-by: Dmitry Vyukov 
Acked-by: Vlastimil Babka 
Cc: Catalin Marinas 
Cc: Vincenzo Frascino 
Cc: Alexander Potapenko 
Cc: Marco Elver 
Cc: Will Deacon 
Cc: Andrey Ryabinin 
Cc: Peter Collingbourne 
Cc: Evgenii Stepanov 
Cc: Branislav Rankov 
Cc: Kevin Brodsky 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kasan: fix HW_TAGS boot parameters

2021-01-24T18:34:52+00:00

The initially proposed KASAN command line parameters are redundant.

This change drops the complex "kasan.mode=off/prod/full" parameter and
adds a simpler kill switch "kasan=off/on" instead.  The new parameter
together with the already existing ones provides a cleaner way to
express the same set of features.

The full set of parameters with this change:

  kasan=off/on             - whether KASAN is enabled
  kasan.fault=report/panic - whether to only print a report or also panic
  kasan.stacktrace=off/on  - whether to collect alloc/free stack traces

Default values:

  kasan=on
  kasan.fault=report
  kasan.stacktrace=on  (if CONFIG_DEBUG_KERNEL=y)
  kasan.stacktrace=off (otherwise)

Link: https://linux-review.googlesource.com/id/Ib3694ed90b1e8ccac6cf77dfd301847af4aba7b8
Link: https://lkml.kernel.org/r/4e9c4a4bdcadc168317deb2419144582a9be6e61.1610736745.git.andreyknvl@google.com
Signed-off-by: Andrey Konovalov 
Reviewed-by: Vincenzo Frascino 
Reviewed-by: Marco Elver 
Cc: Dmitry Vyukov 
Cc: Alexander Potapenko 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Andrey Ryabinin 
Cc: Peter Collingbourne 
Cc: Evgenii Stepanov 
Cc: Branislav Rankov 
Cc: Kevin Brodsky 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kasan: fix incorrect arguments passing in kasan_add_zero_shadow

2021-01-24T18:34:52+00:00

kasan_remove_zero_shadow() shall use original virtual address, start and
size, instead of shadow address.

Link: https://lkml.kernel.org/r/20210103063847.5963-1-lecopzer@gmail.com
Fixes: 0207df4fa1a86 ("kernel/memremap, kasan: make ZONE_DEVICE with work with KASAN")
Signed-off-by: Lecopzer Chen 
Reviewed-by: Andrey Konovalov 
Cc: Andrey Ryabinin 
Cc: Dan Williams 
Cc: Dmitry Vyukov 
Cc: Alexander Potapenko 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kasan: fix unaligned address is unhandled in kasan_remove_zero_shadow

2021-01-24T18:34:52+00:00

During testing kasan_populate_early_shadow and kasan_remove_zero_shadow,
if the shadow start and end address in kasan_remove_zero_shadow() is not
aligned to PMD_SIZE, the remain unaligned PTE won't be removed.

In the test case for kasan_remove_zero_shadow():

    shadow_start: 0xffffffb802000000, shadow end: 0xffffffbfbe000000

    3-level page table:
      PUD_SIZE: 0x40000000 PMD_SIZE: 0x200000 PAGE_SIZE: 4K

0xffffffbf80000000 ~ 0xffffffbfbdf80000 will not be removed because in
kasan_remove_pud_table(), kasan_pmd_table(*pud) is true but the next
address is 0xffffffbfbdf80000 which is not aligned to PUD_SIZE.

In the correct condition, this should fallback to the next level
kasan_remove_pmd_table() but the condition flow always continue to skip
the unaligned part.

Fix by correcting the condition when next and addr are neither aligned.

Link: https://lkml.kernel.org/r/20210103135621.83129-1-lecopzer@gmail.com
Fixes: 0207df4fa1a86 ("kernel/memremap, kasan: make ZONE_DEVICE with work with KASAN")
Signed-off-by: Lecopzer Chen 
Cc: Andrey Ryabinin 
Cc: Dan Williams 
Cc: Dmitry Vyukov 
Cc: Alexander Potapenko 
Cc: YJ Chiang 
Cc: Andrey Konovalov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: fix numa stats for thp migration

2021-01-24T17:20:52+00:00

Currently the kernel is not correctly updating the numa stats for
NR_FILE_PAGES and NR_SHMEM on THP migration.  Fix that.

For NR_FILE_DIRTY and NR_ZONE_WRITE_PENDING, although at the moment
there is no need to handle THP migration as kernel still does not have
write support for file THP but to be more future proof, this patch adds
the THP support for those stats as well.

Link: https://lkml.kernel.org/r/20210108155813.2914586-2-shakeelb@google.com
Fixes: e71769ae52609 ("mm: enable thp migration for shmem thp")
Signed-off-by: Shakeel Butt 
Acked-by: Yang Shi 
Reviewed-by: Roman Gushchin 
Cc: Johannes Weiner 
Cc: Michal Hocko 
Cc: Muchun Song 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds