linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Minchan Kim <minchan@kernel.org>
Cc: Christopher Lameter <cl@linux.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>, Jan Kara <jack@suse.cz>,
	Chris Fries <cfries@google.com>
Subject: Re: [PATCH] mm: workingset: fix NULL ptr dereference
Date: Sun, 8 Apr 2018 19:49:25 -0700	[thread overview]
Message-ID: <20180409024925.GA21889@bombadil.infradead.org> (raw)
In-Reply-To: <20180409015815.235943-1-minchan@kernel.org>

On Mon, Apr 09, 2018 at 10:58:15AM +0900, Minchan Kim wrote:
> It assumes shadow entry of radix tree relies on the init state
> that node->private_list allocated should be list_empty state.
> Currently, it's initailized in SLAB constructor which means
> node of radix tree would be initialized only when *slub allocates
> new page*, not *new object*. So, if some FS or subsystem pass
> gfp_mask to __GFP_ZERO, slub allocator will do memset blindly.

Wait, what?  Who's declaring their radix tree with GFP_ZERO flags?
I don't see anyone using INIT_RADIX_TREE or RADIX_TREE or RADIX_TREE_INIT
with GFP_ZERO.

Although, even if nobody's doing that intentionally, if somebody has
a bitflip with the __GFP_ZERO bit, it's going to propagate widely.
I think something like this might be appropriate:

diff --git a/mm/slub.c b/mm/slub.c
index 9e1100f9298f..0f55f0a0dcaa 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2714,8 +2714,10 @@ static __always_inline void *slab_alloc_node(struct kmem_cache *s,
 		stat(s, ALLOC_FASTPATH);
 	}
 
-	if (unlikely(gfpflags & __GFP_ZERO) && object)
-		memset(object, 0, s->object_size);
+	if (unlikely(gfpflags & __GFP_ZERO) && object) {
+		if (!WARN_ON_ONCE(s->ctor))
+			memset(object, 0, s->object_size);
+	}
 
 	slab_post_alloc_hook(s, gfpflags, 1, &object);
 

Something you could try is checking that the list is empty when the node
is inserted into the radix tree.

diff --git a/lib/radix-tree.c b/lib/radix-tree.c
index 8e00138d593f..580f52d0c072 100644
--- a/lib/radix-tree.c
+++ b/lib/radix-tree.c
@@ -428,6 +428,7 @@ radix_tree_node_alloc(gfp_t gfp_mask, struct radix_tree_node *parent,
 		ret->exceptional = exceptional;
 		ret->parent = parent;
 		ret->root = root;
+		BUG_ON(!list_empty(&ret->private_list));
 	}
 	return ret;
 }

  reply	other threads:[~2018-04-09  2:49 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-09  1:58 [PATCH] mm: workingset: fix NULL ptr dereference Minchan Kim
2018-04-09  2:49 ` Matthew Wilcox [this message]
2018-04-09  3:09   ` Minchan Kim
2018-04-09 11:14     ` Matthew Wilcox
2018-04-09 11:25       ` Minchan Kim
2018-04-09 12:25         ` Chao Yu
2018-04-09 12:48           ` Michal Hocko
2018-04-09 13:41             ` Matthew Wilcox
2018-04-09 13:51               ` Christoph Hellwig
2018-04-09 13:52               ` Michal Hocko
2018-04-09 15:34                 ` David Sterba
2018-04-09 14:49           ` Minchan Kim
2018-04-09 15:20             ` Matthew Wilcox
2018-04-09 23:04               ` Minchan Kim
2018-04-10  1:12                 ` Matthew Wilcox
2018-04-10  2:33                   ` Minchan Kim
2018-04-10  2:39                     ` Minchan Kim
2018-04-10  2:41                     ` Matthew Wilcox
2018-04-10  2:59                       ` Minchan Kim
2018-04-10  8:50                         ` Jan Kara
2018-04-10 11:56                         ` Matthew Wilcox
2018-04-10 12:38                           ` Michal Hocko
2018-04-10 11:53                     ` [PATCH v2] " kbuild test robot
2018-04-10 13:11                     ` kbuild test robot
2018-04-09 18:38         ` [PATCH] " Jaegeuk Kim
2018-04-09 19:40           ` Matthew Wilcox
2018-04-10  8:26             ` Michal Hocko
2018-04-10 12:05               ` Matthew Wilcox
2018-04-10 12:33                 ` Michal Hocko
2018-04-10 12:39                 ` Johannes Weiner
2018-04-10 13:28                 ` Minchan Kim
2018-04-10 12:48   ` Johannes Weiner
2018-04-10  8:22 ` Michal Hocko
2018-04-10  8:55   ` Jan Kara
2018-04-10  9:32     ` Michal Hocko
2018-04-10 10:28       ` Jan Kara
2018-04-10 11:19         ` Minchan Kim
2018-04-10 12:07           ` Matthew Wilcox
2018-04-10 12:44 ` Johannes Weiner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180409024925.GA21889@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=cfries@google.com \
    --cc=cl@linux.com \
    --cc=hannes@cmpxchg.org \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).