All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Minchan Kim <minchan@kernel.org>
Cc: Chao Yu <yuchao0@huawei.com>, 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>,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] mm: workingset: fix NULL ptr dereference
Date: Mon, 9 Apr 2018 08:20:32 -0700	[thread overview]
Message-ID: <20180409152032.GB11756@bombadil.infradead.org> (raw)
In-Reply-To: <20180409144958.GA211679@rodete-laptop-imager.corp.google.com>

On Mon, Apr 09, 2018 at 11:49:58PM +0900, Minchan Kim wrote:
> On Mon, Apr 09, 2018 at 08:25:06PM +0800, Chao Yu wrote:
> > On 2018/4/9 19:25, Minchan Kim wrote:
> > > On Mon, Apr 09, 2018 at 04:14:03AM -0700, Matthew Wilcox wrote:
> > >> On Mon, Apr 09, 2018 at 12:09:30PM +0900, Minchan Kim wrote:
> > >>> Look at fs/f2fs/inode.c
> > >>> mapping_set_gfp_mask(inode->i_mapping, GFP_F2FS_ZERO);
> > >>>
> > >>> __add_to_page_cache_locked
> > >>>   radix_tree_maybe_preload
> > >>>
> > >>> add_to_page_cache_lru
> > 
> > No, sometimes, we need to write meta data to new allocated block address,
> > then we will allocate a zeroed page in inner inode's address space, and
> > fill partial data in it, and leave other place with zero value which means
> > some fields are initial status.
> 
> Thanks for the explaining.
> 
> > There are two inner inodes (meta inode and node inode) setting __GFP_ZERO,
> > I have just checked them, for both of them, we can avoid using __GFP_ZERO,
> > and do initialization by ourselves to avoid unneeded/redundant zeroing
> > from mm.
> 
> Yub, it would be desirable for f2fs. Please go ahead for f2fs side.
> However, I think current problem is orthgonal. Now, the problem is
> radix_tree_node allocation is bind to page cache allocation.
> Why does FS cannot allocate page cache with __GFP_ZERO?
> I agree if the concern is only performance matter as Matthew mentioned.
> But it is beyond that because it shouldn't do due to limitation
> of workingset shadow entry implementation. I think such coupling is
> not a good idea.
> 
> I think right approach to abstract shadow entry in radix_tree is
> to mask off __GFP_ZERO in radix_tree's allocation APIs.

I don't think this is something the radix tree should know about.
SLAB should be checking for it (the patch I posted earlier in this
thread), but the right place to filter this out is in the caller of
radix_tree_maybe_preload -- it's already filtering out HIGHMEM pages,
and should filter out GFP_ZERO too.

diff --git a/mm/filemap.c b/mm/filemap.c
index c2147682f4c3..a87a523eea8e 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -785,7 +785,7 @@ int replace_page_cache_page(struct page *old, struct page *new, gfp_t gfp_mask)
 	VM_BUG_ON_PAGE(!PageLocked(new), new);
 	VM_BUG_ON_PAGE(new->mapping, new);
 
-	error = radix_tree_preload(gfp_mask & ~__GFP_HIGHMEM);
+	error = radix_tree_preload(gfp_mask & ~(__GFP_HIGHMEM | __GFP_ZERO));
 	if (!error) {
 		struct address_space *mapping = old->mapping;
 		void (*freepage)(struct page *);
@@ -841,7 +841,8 @@ static int __add_to_page_cache_locked(struct page *page,
 			return error;
 	}
 
-	error = radix_tree_maybe_preload(gfp_mask & ~__GFP_HIGHMEM);
+	error = radix_tree_maybe_preload(gfp_mask &
+			~(__GFP_HIGHMEM | __GFP_ZERO));
 	if (error) {
 		if (!huge)
 			mem_cgroup_cancel_charge(page, memcg, false);

  reply	other threads:[~2018-04-09 15:20 UTC|newest]

Thread overview: 46+ 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
2018-04-09  3:09   ` Minchan Kim
2018-04-09 11:14     ` Matthew Wilcox
2018-04-09 11:25       ` Minchan Kim
2018-04-09 11:25         ` Minchan Kim
2018-04-09 11:25         ` Minchan Kim
2018-04-09 12:25         ` Chao Yu
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 [this message]
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: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  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 13:28                   ` Minchan Kim
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=20180409152032.GB11756@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=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=minchan@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.