linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Michal Hocko <mhocko@kernel.org>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	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>, Chao Yu <yuchao0@huawei.com>,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] mm: workingset: fix NULL ptr dereference
Date: Tue, 10 Apr 2018 22:28:22 +0900	[thread overview]
Message-ID: <20180410132822.GA32026@rodete-laptop-imager.corp.google.com> (raw)
In-Reply-To: <20180410120528.GB22118@bombadil.infradead.org>

On Tue, Apr 10, 2018 at 05:05:28AM -0700, Matthew Wilcox wrote:
> On Tue, Apr 10, 2018 at 10:26:43AM +0200, Michal Hocko wrote:
> > On Mon 09-04-18 12:40:44, Matthew Wilcox wrote:
> > > The problem is that the mapping gfp flags are used not only for allocating
> > > pages, but also for allocating the page cache data structures that hold
> > > the pages.  F2FS is the only filesystem that set the __GFP_ZERO bit,
> > > so it's the first time anyone's noticed that the page cache passes the
> > > __GFP_ZERO bit through to the radix tree allocation routines, which
> > > causes the radix tree nodes to be zeroed instead of constructed.
> > > 
> > > I think the right solution to this is:
> > 
> > This just hides the underlying problem that the node is not fully and
> > properly initialized. Relying on the previous released state is just too
> > subtle.
> 
> That's the fundamental design of slab-with-constructors.  The user provides
> a constructor, so all newly allocagted objects are initialised to a known
> state, then the user will restore the object to that state when it frees
> the object to slab.
> 
> > Are you going to blacklist all potential gfp flags that come
> > from the mapping? This is just unmaintainable! If anything this should
> > be an explicit & with the allowed set of allowed flags.
> 
> Oh, I agree that using the set of flags used to allocate the page
> in order to allocate the radix tree nodes is a pretty horrible idea.
> 
> Your suggestion, then, is:
> 
> -	error = radix_tree_preload(gfp_mask & ~__GFP_HIGHMEM);
> +	error = radix_tree_preload(gfp_mask & GFP_RECLAIM_MASK);
> 
> correct?
> 

Looks much better.

Finally, it seems everyone agree on this. However, I won't include
warning part of slab allocator because I think it's improve stuff
not bug fix so it could be separted.
If anyone really want to include it in this stable patch,
please discuss with slub maintainers before.

Thanks for the reivew, Matthew, Michal, Jan and Johannes.

  parent reply	other threads:[~2018-04-10 13:28 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-09  1:58 Minchan Kim
2018-04-09  2:49 ` Matthew Wilcox
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 [this message]
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=20180410132822.GA32026@rodete-laptop-imager.corp.google.com \
    --to=minchan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=cfries@google.com \
    --cc=cl@linux.com \
    --cc=hannes@cmpxchg.org \
    --cc=jack@suse.cz \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=willy@infradead.org \
    --cc=yuchao0@huawei.com \
    /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