Received: by 10.213.65.68 with SMTP id h4csp2646462imn; Mon, 9 Apr 2018 06:56:23 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+ZgeO56KrDa0CCKJmz54GOfkgjZFIoe2tvQy1HHUV8bfvqNgoy+a35+rGl1KtIoFocbTB6 X-Received: by 10.99.66.197 with SMTP id p188mr15195164pga.28.1523282183743; Mon, 09 Apr 2018 06:56:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523282183; cv=none; d=google.com; s=arc-20160816; b=IhYhMT4mM9HRX0eO09eqpg149pNmKWNMX4vAdeknqK7bKrlfSY9zT8zQ+duojQlY8Z 182N3ZrTzjyuBRF3/96n3cxebDZeMj1ckLyIBe3nd+0JKX5N58Wje8ij1JvYRz2yauFW fVQYoBupPFOSoiK9lVK749sQ8yz8v2ah7je2XVdXNG5aJbXo3gUI11WZWbgO4mtWWkCU KHjvKMbbU+muRo26H87jFEdq2I2qW9JGkfGkCGlfKoi/W3uo3PajriEBhQ7WF10Y9RPJ aYS0sOa9ZxcpqevigZUEPeKxmMNYGaUN2uoYjfk66VFUEBMseLX7NrUemrzoVXarRWtM Pc1w== 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:arc-authentication-results; bh=KVD/ZVBHLTwb3wwhaUD0luGfo203LkmHadHWKrYsnrQ=; b=kDw7srW/ZTeWYi3e+bn7obIXiEMxDQBLKusfv3X8+cZI2bSRM7TXzWpmPoGeUZpoCa dUplJ6zl0tc0TXLuO2EStMUFeR6IqkksNbWlMCblGF1XmmIUPmK34fA3iQuaUB/Y2alP zDGIDirN/QRJWKQ+sNzrpli6Wlll5IPvE7KvBCNu48jdEgq0JrDjb5xFiVVs8loikZvX 3Z0MYOj94lQR0JbKVn8lqEp0y5M4IOEum3l3sd9ePps0T4xXy3LA7AGozJCYRISzXNxG fJvProkUpNmwG/R25KhZYX4z6usrOQT9ABm8pWn/Bdb4CGbJOB3w3o+HlkZcUjx3qULZ CHxw== ARC-Authentication-Results: i=1; mx.google.com; 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 b8si265860pgs.429.2018.04.09.06.55.46; Mon, 09 Apr 2018 06:56:23 -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; 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 S1752107AbeDINwU (ORCPT + 99 others); Mon, 9 Apr 2018 09:52:20 -0400 Received: from mx2.suse.de ([195.135.220.15]:46619 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751539AbeDINwT (ORCPT ); Mon, 9 Apr 2018 09:52:19 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id C6348AE60; Mon, 9 Apr 2018 13:52:17 +0000 (UTC) Date: Mon, 9 Apr 2018 15:52:15 +0200 From: Michal Hocko To: Matthew Wilcox Cc: Chao Yu , Minchan Kim , 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: <20180409135215.GH21835@dhcp22.suse.cz> 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> <20180409124852.GE21835@dhcp22.suse.cz> <20180409134114.GA30963@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180409134114.GA30963@bombadil.infradead.org> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 09-04-18 06:41:14, Matthew Wilcox wrote: > On Mon, Apr 09, 2018 at 02:48:52PM +0200, Michal Hocko wrote: > > On Mon 09-04-18 20:25:06, Chao Yu wrote: > > [...] > > > diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c > > > index c85cccc2e800..cc63f8c448f0 100644 > > > --- a/fs/f2fs/inode.c > > > +++ b/fs/f2fs/inode.c > > > @@ -339,10 +339,10 @@ struct inode *f2fs_iget(struct super_block *sb, unsigned long ino) > > > make_now: > > > if (ino == F2FS_NODE_INO(sbi)) { > > > inode->i_mapping->a_ops = &f2fs_node_aops; > > > - mapping_set_gfp_mask(inode->i_mapping, GFP_F2FS_ZERO); > > > + mapping_set_gfp_mask(inode->i_mapping, GFP_NOFS); > > > > An unrelated question. Why do you make all allocations for the mapping > > NOFS automatically? What kind of reclaim recursion problems are you > > trying to prevent? > > It's worth noting that this is endemic in filesystems. Yes, and I have strong suspicion that this is a mindless copy&pasting... Well, xfs had a good reason for it in the past - mostly to handle deep call stacks on complicated storage setups in the past when we used to trigger IO from the direct reclaim. I am not sure whether there are other reasons to keep the status quo except for finding somebody brave enough to post the patch, do all the due testing. > $ git grep mapping_set_gfp_mask.*FS > drivers/block/loop.c: mapping_set_gfp_mask(mapping, lo->old_gfp_mask & ~(__GFP_IO|__GFP_FS)); > fs/btrfs/disk-io.c: mapping_set_gfp_mask(fs_info->btree_inode->i_mapping, GFP_NOFS); > fs/f2fs/inode.c: mapping_set_gfp_mask(inode->i_mapping, GFP_F2FS_ZERO); > fs/f2fs/inode.c: mapping_set_gfp_mask(inode->i_mapping, GFP_F2FS_ZERO); > fs/gfs2/glock.c: mapping_set_gfp_mask(mapping, GFP_NOFS); > fs/gfs2/ops_fstype.c: mapping_set_gfp_mask(mapping, GFP_NOFS); > fs/jfs/jfs_imap.c: mapping_set_gfp_mask(ip->i_mapping, GFP_NOFS); > fs/jfs/super.c: mapping_set_gfp_mask(inode->i_mapping, GFP_NOFS); > fs/nilfs2/gcinode.c: mapping_set_gfp_mask(inode->i_mapping, GFP_NOFS); > fs/nilfs2/page.c: mapping_set_gfp_mask(mapping, GFP_NOFS); > fs/reiserfs/xattr.c: mapping_set_gfp_mask(mapping, GFP_NOFS); > fs/xfs/xfs_iops.c: mapping_set_gfp_mask(inode->i_mapping, (gfp_mask & ~(__GFP_FS))); -- Michal Hocko SUSE Labs