incoming

incoming

[Andrew Morton]

5 fixes, based on 444fc5cde64330661bf59944c43844e7d4c2ccd8:


    Qian Cai <cai@lca.pw>:
      mm/z3fold: silence kmemleak false positives of slots

    Hugh Dickins <hughd@google.com>:
      mm,thp: stop leaking unreleased file pages

    Konstantin Khlebnikov <khlebnikov@yandex-team.ru>:
      mm: remove VM_BUG_ON(PageSlab()) from page_mapcount()

    Alexander Potapenko <glider@google.com>:
      fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info()

    Arnd Bergmann <arnd@arndb.de>:
      include/asm-generic/topology.h: guard cpumask_of_node() macro argument

 fs/binfmt_elf.c                |    2 +-
 include/asm-generic/topology.h |    2 +-
 include/linux/mm.h             |   19 +++++++++++++++----
 mm/khugepaged.c                |    1 +
 mm/z3fold.c                    |    3 +++
 5 files changed, 21 insertions(+), 6 deletions(-)

[patch 1/5] mm/z3fold: silence kmemleak false positives of slots

[Andrew Morton]

From: Qian Cai <cai@lca.pw>
Subject: mm/z3fold: silence kmemleak false positives of slots

Kmemleak reported many leaks while under memory pressue in,

slots = alloc_slots(pool, gfp);

which is referenced by "zhdr" in init_z3fold_page(),

zhdr->slots = slots;

However, "zhdr" could be gone without freeing slots as the later will be
freed separately when the last "handle" off of "handles" array is freed. It
will be within "slots" which is always aligned.

unreferenced object 0xc000000fdadc1040 (size 104):
  comm "oom04", pid 140476, jiffies 4295359280 (age 3454.970s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<00000000d1f0f5eb>] z3fold_zpool_malloc+0x7b0/0xe10
    alloc_slots at mm/z3fold.c:214
    (inlined by) init_z3fold_page at mm/z3fold.c:412
    (inlined by) z3fold_alloc at mm/z3fold.c:1161
    (inlined by) z3fold_zpool_malloc at mm/z3fold.c:1735
    [<0000000064a2e969>] zpool_malloc+0x34/0x50
    [<00000000af63e491>] zswap_frontswap_store+0x60c/0xda0
    zswap_frontswap_store at mm/zswap.c:1093
    [<00000000af5e07e0>] __frontswap_store+0x128/0x330
    [<00000000de2f582b>] swap_writepage+0x58/0x110
    [<000000000120885f>] pageout+0x16c/0xa40
    [<00000000444c1f68>] shrink_page_list+0x1ac8/0x25c0
    [<00000000d19e8610>] shrink_inactive_list+0x270/0x730
    [<00000000e17df726>] shrink_lruvec+0x444/0xf30
    [<000000005f02ab35>] shrink_node+0x2a4/0x9c0
    [<00000000014cabbd>] do_try_to_free_pages+0x158/0x640
    [<00000000dcfaba07>] try_to_free_pages+0x1bc/0x5f0
    [<00000000fa207ab8>] __alloc_pages_slowpath.constprop.60+0x4dc/0x15a0
    [<000000003669f1d2>] __alloc_pages_nodemask+0x520/0x650
    [<0000000011fa4168>] alloc_pages_vma+0xc0/0x420
    [<0000000098b376f2>] handle_mm_fault+0x1174/0x1bf0

Link: http://lkml.kernel.org/r/20200522220052.2225-1-cai@lca.pw
Signed-off-by: Qian Cai <cai@lca.pw>
Acked-by: Vitaly Wool <vitaly.wool@konsulko.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/z3fold.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/mm/z3fold.c~mm-z3fold-silence-kmemleak-false-positives-of-slots
+++ a/mm/z3fold.c
@@ -43,6 +43,7 @@
 #include <linux/spinlock.h>
 #include <linux/zpool.h>
 #include <linux/magic.h>
+#include <linux/kmemleak.h>
 
 /*
  * NCHUNKS_ORDER determines the internal allocation granularity, effectively
@@ -215,6 +216,8 @@ static inline struct z3fold_buddy_slots
 				 (gfp & ~(__GFP_HIGHMEM | __GFP_MOVABLE)));
 
 	if (slots) {
+		/* It will be freed separately in free_handle(). */
+		kmemleak_not_leak(slots);
 		memset(slots->slot, 0, sizeof(slots->slot));
 		slots->pool = (unsigned long)pool;
 		rwlock_init(&slots->lock);
_

[patch 2/5] mm,thp: stop leaking unreleased file pages

[Andrew Morton]

From: Hugh Dickins <hughd@google.com>
Subject: mm,thp: stop leaking unreleased file pages

When collapse_file() calls try_to_release_page(), it has already isolated
the page: so if releasing buffers happens to fail (as it sometimes does),
remember to putback_lru_page(): otherwise that page is left unreclaimable
and unfreeable, and the file extent uncollapsible.

Link: http://lkml.kernel.org/r/alpine.LSU.2.11.2005231837500.1766@eggly.anvils
Fixes: 99cb0dbd47a1 ("mm,thp: add read-only THP support for (non-shmem) FS")
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: Song Liu <songliubraving@fb.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: <stable@vger.kernel.org>	[5.4+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/khugepaged.c |    1 +
 1 file changed, 1 insertion(+)

--- a/mm/khugepaged.c~mmthp-stop-leaking-unreleased-file-pages
+++ a/mm/khugepaged.c
@@ -1692,6 +1692,7 @@ static void collapse_file(struct mm_stru
 		if (page_has_private(page) &&
 		    !try_to_release_page(page, GFP_KERNEL)) {
 			result = SCAN_PAGE_HAS_PRIVATE;
+			putback_lru_page(page);
 			goto out_unlock;
 		}
 
_

[patch 3/5] mm: remove VM_BUG_ON(PageSlab()) from page_mapcount()

[Andrew Morton]

From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Subject: mm: remove VM_BUG_ON(PageSlab()) from page_mapcount()

Replace superfluous VM_BUG_ON() with comment about correct usage.

Technically reverts commit 1d148e218a0d0566b1c06f2f45f1436d53b049b2
("mm: add VM_BUG_ON_PAGE() to page_mapcount()"), but context have changed.

Function isolate_migratepages_block() runs some checks out of lru_lock
when choose pages for migration.  After checking PageLRU() it checks extra
page references by comparing page_count() and page_mapcount().  Between
these two checks page could be removed from lru, freed and taken by slab.

As a result this race triggers VM_BUG_ON(PageSlab()) in page_mapcount().
Race window is tiny. For certain workload this happens around once a year.

 page:ffffea0105ca9380 count:1 mapcount:0 mapping:ffff88ff7712c180 index:0x0 compound_mapcount: 0
 flags: 0x500000000008100(slab|head)
 raw: 0500000000008100 dead000000000100 dead000000000200 ffff88ff7712c180
 raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000
 page dumped because: VM_BUG_ON_PAGE(PageSlab(page))
 ------------[ cut here ]------------
 kernel BUG at ./include/linux/mm.h:628!
 invalid opcode: 0000 [#1] SMP NOPTI
 CPU: 77 PID: 504 Comm: kcompactd1 Tainted: G        W         4.19.109-27 #1
 Hardware name: Yandex T175-N41-Y3N/MY81-EX0-Y3N, BIOS R05 06/20/2019
 RIP: 0010:isolate_migratepages_block+0x986/0x9b0

Code in isolate_migratepages_block() was added in commit 119d6d59dcc0
("mm, compaction: avoid isolating pinned pages") before adding VM_BUG_ON
into page_mapcount().

This race has been predicted in 2015 by Vlastimil Babka (see link below).

[akpm@linux-foundation.org: comment tweaks, per Hugh]
Link: http://lkml.kernel.org/r/159032779896.957378.7852761411265662220.stgit@buzz
Link: https://lore.kernel.org/lkml/557710E1.6060103@suse.cz/
Link: https://lore.kernel.org/linux-mm/158937872515.474360.5066096871639561424.stgit@buzz/T/ (v1)
Fixes: 1d148e218a0d ("mm: add VM_BUG_ON_PAGE() to page_mapcount()")
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Acked-by: Hugh Dickins <hughd@google.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: David Rientjes <rientjes@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 include/linux/mm.h |   15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

--- a/include/linux/mm.h~mm-remove-vm_bug_onpageslab-from-page_mapcount
+++ a/include/linux/mm.h
@@ -782,6 +782,11 @@ static inline void *kvcalloc(size_t n, s
 
 extern void kvfree(const void *addr);
 
+/*
+ * Mapcount of compound page as a whole, does not include mapped sub-pages.
+ *
+ * Must be called only for compound pages or any their tail sub-pages.
+ */
 static inline int compound_mapcount(struct page *page)
 {
 	VM_BUG_ON_PAGE(!PageCompound(page), page);
@@ -801,10 +806,16 @@ static inline void page_mapcount_reset(s
 
 int __page_mapcount(struct page *page);
 
+/*
+ * Mapcount of 0-order page; when compound sub-page, includes
+ * compound_mapcount().
+ *
+ * Result is undefined for pages which cannot be mapped into userspace.
+ * For example SLAB or special types of pages. See function page_has_type().
+ * They use this place in struct page differently.
+ */
 static inline int page_mapcount(struct page *page)
 {
-	VM_BUG_ON_PAGE(PageSlab(page), page);
-
 	if (unlikely(PageCompound(page)))
 		return __page_mapcount(page);
 	return atomic_read(&page->_mapcount) + 1;
_

[patch 4/5] fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info()

[Andrew Morton]

From: Alexander Potapenko <glider@google.com>
Subject: fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info()

KMSAN reported uninitialized data being written to disk when dumping core.
As a result, several kilobytes of kmalloc memory may be written to the
core file and then read by a non-privileged user.

Link: http://lkml.kernel.org/r/20200419100848.63472-1-glider@google.com
Link: https://github.com/google/kmsan/issues/76
Signed-off-by: Alexander Potapenko <glider@google.com>
Reported-by: sam <sunhaoyl@outlook.com>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 fs/binfmt_elf.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/binfmt_elf.c~fs-binfmt_elfc-allocate-initialized-memory-in-fill_thread_core_info
+++ a/fs/binfmt_elf.c
@@ -1733,7 +1733,7 @@ static int fill_thread_core_info(struct
 		    (!regset->active || regset->active(t->task, regset) > 0)) {
 			int ret;
 			size_t size = regset_size(t->task, regset);
-			void *data = kmalloc(size, GFP_KERNEL);
+			void *data = kzalloc(size, GFP_KERNEL);
 			if (unlikely(!data))
 				return 0;
 			ret = regset->get(t->task, regset,
_

[patch 5/5] include/asm-generic/topology.h: guard cpumask_of_node() macro argument

[Andrew Morton]

From: Arnd Bergmann <arnd@arndb.de>
Subject: include/asm-generic/topology.h: guard cpumask_of_node() macro argument

drivers/hwmon/amd_energy.c:195:15: error: invalid operands to binary expression ('void' and 'int')
                                        (channel - data->nr_cpus));
                                        ~~~~~~~~~^~~~~~~~~~~~~~~~~
include/asm-generic/topology.h:51:42: note: expanded from macro 'cpumask_of_node'
    #define cpumask_of_node(node)       ((void)node, cpu_online_mask)
                                               ^~~~
include/linux/cpumask.h:618:72: note: expanded from macro 'cpumask_first_and'
 #define cpumask_first_and(src1p, src2p) cpumask_next_and(-1, (src1p), (src2p))
                                                                       ^~~~~

Link: http://lkml.kernel.org/r/20200527134623.930247-1-arnd@arndb.de
Fixes: f0b848ce6fe9 ("cpumask: Introduce cpumask_of_{node,pcibus} to replace {node,pcibus}_to_cpumask")
Fixes: 8abee9566b7e ("hwmon: Add amd_energy driver to report energy counters")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 include/asm-generic/topology.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/asm-generic/topology.h~cpumask-guard-cpumask_of_node-macro-argument
+++ a/include/asm-generic/topology.h
@@ -48,7 +48,7 @@
   #ifdef CONFIG_NEED_MULTIPLE_NODES
     #define cpumask_of_node(node)	((node) == 0 ? cpu_online_mask : cpu_none_mask)
   #else
-    #define cpumask_of_node(node)	((void)node, cpu_online_mask)
+    #define cpumask_of_node(node)	((void)(node), cpu_online_mask)
   #endif
 #endif
 #ifndef pcibus_to_node
_

Re: incoming

[Linus Torvalds]

Hmm..

On Wed, May 27, 2020 at 10:20 PM Andrew Morton
<akpm@linux-foundation.org> wrote:
>
>  fs/binfmt_elf.c                |    2 +-
>  include/asm-generic/topology.h |    2 +-
>  include/linux/mm.h             |   19 +++++++++++++++----
>  mm/khugepaged.c                |    1 +
>  mm/z3fold.c                    |    3 +++
>  5 files changed, 21 insertions(+), 6 deletions(-)

I wonder how you generate that diffstat.

The change to <linux/mm.h> simply doesn't match what you sent me.  The
patch you sent me that changed mm.h had this:

 include/linux/mm.h |   15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

(note 15 lines changed: it's +13 and -2) but now suddenly in your
overall diffstat you have that

  include/linux/mm.h             |   19 +++++++++++++++----

with +15/-4.

So your diffstat simply doesn't match what you are sending. What's going on?

               Linus

Re: incoming

[Andrew Morton]

On Thu, 28 May 2020 13:10:18 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:

> Hmm..
> 
> On Wed, May 27, 2020 at 10:20 PM Andrew Morton
> <akpm@linux-foundation.org> wrote:
> >
> >  fs/binfmt_elf.c                |    2 +-
> >  include/asm-generic/topology.h |    2 +-
> >  include/linux/mm.h             |   19 +++++++++++++++----
> >  mm/khugepaged.c                |    1 +
> >  mm/z3fold.c                    |    3 +++
> >  5 files changed, 21 insertions(+), 6 deletions(-)
> 
> I wonder how you generate that diffstat.
> 
> The change to <linux/mm.h> simply doesn't match what you sent me.  The
> patch you sent me that changed mm.h had this:
> 
>  include/linux/mm.h |   15 +++++++++++++--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> (note 15 lines changed: it's +13 and -2) but now suddenly in your
> overall diffstat you have that
> 
>   include/linux/mm.h             |   19 +++++++++++++++----
> 
> with +15/-4.
> 
> So your diffstat simply doesn't match what you are sending. What's going on?
> 

Bah.  I got lazy (didn't want to interrupt an ongoing build) so I
generated the diffstat prior to folding two patches into a single one. 
Evidently diffstat isn't as smart as I had assumed!

Re: incoming

[Linus Torvalds]

On Fri, May 29, 2020 at 1:31 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> Bah.  I got lazy (didn't want to interrupt an ongoing build) so I
> generated the diffstat prior to folding two patches into a single one.
> Evidently diffstat isn't as smart as I had assumed!

Ahh. Yes - given two patches, diffstat just adds up the line number
counts for the individual diffs, it doesn't count some kind of
"combined diff result" line counts.

               Linus

Re: incoming

[Andrew Morton]

On Fri, 29 May 2020 13:38:35 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Fri, May 29, 2020 at 1:31 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > Bah.  I got lazy (didn't want to interrupt an ongoing build) so I
> > generated the diffstat prior to folding two patches into a single one.
> > Evidently diffstat isn't as smart as I had assumed!
> 
> Ahh. Yes - given two patches, diffstat just adds up the line number
> counts for the individual diffs, it doesn't count some kind of
> "combined diff result" line counts.

Stupid diffstat.  Means that basically all my diffstats are very wrong.
Thanks for spotting it.

I can fix that...

Re: incoming

[Linus Torvalds]

On Fri, May 29, 2020 at 2:12 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> Stupid diffstat.  Means that basically all my diffstats are very wrong.

I'm actually used to diffstats not matching 100%/

Usually it's not due to this issue - a "git diff --stat" *will* give
the stat from the actual combined diff result - but with git diffstats
the issue is that I might have gotten a patch from another source.

So the diffstat I see after-the-merge is possibly different from the
pre-merge diffstat simply due to merge issues.

So then I usually take a look at "ok, why did that diffstat differ"
and go "Ahh".

In your case, when I looked at the diffstat, I couldn't for the life
of me see how you would have gotten the diffstat you did, since I only
saw a single patch with no merge issues.

> Thanks for spotting it.
>
> I can fix that...

I can also just live with it, knowing what your workflow is. The
diffstat matching exactly just isn't that important - in fact,
different versions of "diff" can give slightly different output anyway
depending on diff algorithms even when they are looking at the exact
same before/after state. There's not necessarily always only one way
to generate a valid diff.

So to me, the diffstat is more of a guide than a hard thing, and I
want to see the rough outline,

In fact, one reason I want to see it in pull requests is actually just
that I want to get a feel for what changes even before I do the pull
or merge, so it's not just a "match against what I get" thing.

                      Linus