Received: by 10.213.65.68 with SMTP id h4csp2747730imn; Mon, 9 Apr 2018 08:24:42 -0700 (PDT) X-Google-Smtp-Source: AIpwx485iOsWbW23OBQD/DYHYIBGlED3F8kZ5RPy2t5Ke/39VuGu9cyyLYdKLrxSzSlcXPwIhrNi X-Received: by 2002:a17:902:3f83:: with SMTP id a3-v6mr39541444pld.279.1523287482515; Mon, 09 Apr 2018 08:24:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523287482; cv=none; d=google.com; s=arc-20160816; b=aHGRT068x3VvWgnAhXBwHVa8rHZnL2b3qe2iKMFLmp1ADoCo1f1WnMIpcWgtddP3m+ qat+Ey9XOfSfG2PpSCZ7Y/eTLovd0FGHQXsok7MAK10z/WAJJ/AeDdBiqhlsxD1FgEVW HlSKvOWfyicgxdmL7jqwLQIe226aMK1Aydb3n+AYS9EpHtIM5/iGjIo6JjDJh4rTuOJ7 /Vv1+kIUQC0AqI4IEGmKMLfWOTHblyBWVufJ6E275WV7IkkOC3xjxvdBIsn93YwFhE40 DK9/HOFn8YBN0q5Ou3hgugWkqVLJ9RsyPCeVTnTfECIv69Ie1k/7d3yxjRiICfDBkrn9 yaIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=i6ZW5XqUQ/B7Q9pfQCsmOZRDeY/4Tbfh0MsluPEERqg=; b=eP4BRhbkVNPfc19tr7g/lZBkETBkkvktuX0tV4iWPQiNf/Tmst/6SNYedmvVr+/Efe 8G38RTmeTxnN+sDpOO6XG4On0hp7swJnLqGR60eQvYYZAkv0OThPJhMNyjpqVwu3631T hTtvpTN+QLYdYqaTf+kQqdTybZA3AoHUstDjBNtop0GWiZG6kKRR3MPGUt3lZaFdUjKm wGSPWLN8KdQYgGqENOfnD7sqKIHBm/j2+cs0sfCM3I25qzwHlvICWHmUKFt5SCDp+F2s 5wHO23/6/002znBQgZLnypbVGl5GNOIwiDaWZaC5JtT9kUx2ccafJpZbmDu97VnPelKz cTow== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=U4uj6h23; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c2si354015pgq.675.2018.04.09.08.24.04; Mon, 09 Apr 2018 08:24:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=U4uj6h23; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753037AbeDIPUi (ORCPT + 99 others); Mon, 9 Apr 2018 11:20:38 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:46418 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751633AbeDIPUg (ORCPT ); Mon, 9 Apr 2018 11:20:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=i6ZW5XqUQ/B7Q9pfQCsmOZRDeY/4Tbfh0MsluPEERqg=; b=U4uj6h23PgPg0rXYV2ob0UjzM Qavrba/yIaCK+UwqMyLNkud7KLWShFfff45gKChNgITLupYCxm2t6wTPXXW4Q41bz7lzLSz9bktAz D2LaYhL+dGfHiXLHjOc3M2RhCOTnmbNnYbF9tN5AYZpP1JtXQdA9r1V9JrIRaPmNQmjD64o/co7b0 I/wliskJnDUy775eaxMWtZ/RqJULPm7eVQsgAl7b4APENg3thXafhxPPe9v4TXruVzTWviv8nMXqh H5py36h5YtEWNyRmQ1GpWvxv1I9gaSxbMrRHhZsGLN9oH5YucmG2/PoEny42Y8Ewgf0tl/8AUDyB8 j32vdBlTA==; Received: from willy by bombadil.infradead.org with local (Exim 4.90_1 #2 (Red Hat Linux)) id 1f5Yau-0002M5-A9; Mon, 09 Apr 2018 15:20:32 +0000 Date: Mon, 9 Apr 2018 08:20:32 -0700 From: Matthew Wilcox To: Minchan Kim Cc: Chao Yu , Jaegeuk Kim , Christopher Lameter , Andrew Morton , linux-mm , LKML , Johannes Weiner , Jan Kara , Chris Fries , linux-f2fs-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] mm: workingset: fix NULL ptr dereference Message-ID: <20180409152032.GB11756@bombadil.infradead.org> References: <20180409015815.235943-1-minchan@kernel.org> <20180409024925.GA21889@bombadil.infradead.org> <20180409030930.GA214930@rodete-desktop-imager.corp.google.com> <20180409111403.GA31652@bombadil.infradead.org> <20180409112514.GA195937@rodete-laptop-imager.corp.google.com> <7706245c-2661-f28b-f7f9-8f11e1ae932b@huawei.com> <20180409144958.GA211679@rodete-laptop-imager.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180409144958.GA211679@rodete-laptop-imager.corp.google.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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);