Received: by 10.213.65.68 with SMTP id h4csp2479747imn; Mon, 9 Apr 2018 04:18:32 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+BYWUq5KHcrkQ3uOgbnQqYd00o9E4mayAhIzULGhiDm9j+YlnMA9T5xL9QV8AlO4GUcxVw X-Received: by 10.99.64.131 with SMTP id n125mr24811617pga.303.1523272712685; Mon, 09 Apr 2018 04:18:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523272712; cv=none; d=google.com; s=arc-20160816; b=akRlq5DVaAPIAIT5G3ks4424P29y/9zh9yA7Oh6AkfrZcNArQsQLU8yqQVqKzg7cyk Q+UXiWtmY3jgllUrMZDos2MNdAEFaRJyaJHRWJmAdDotM++jHTiXSHcb0BSx7PCC770E LJ7AM7Cv3M2LwRC2fFtptSZWO8c4yJl59pe/f5hUXKZdscBF94Qq7cIWs8Pz8Gso2Y4l X14yWQLpMD0X87o92ZXOPlQy+uOHD8OiZmc8Soj8XEePRAmX+O/ehG/BcJ8iHwUQrO9H 8vHstbVdRIeyig3jhOMPTRZQfXXQ2F4aQKdvYiZqGFpQ8k+9jTIqY9aBHnkbMCVdwCUd YdYw== 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=jZXvHUn6eA4wsKARja41MfOwB7AjNNAYwCmmTwl9QQE=; b=fSJi0maqH1Bd+PE0C/a3c9lwgG3sEK1X7eldnFRbcvfXrsyvWuCi7ArBc6cVooKIIk bfYEUr8O6bfHeSzmRiHu7+KNPXfJNErB2MBGIbsb/dCZPzTcyUPVy1kznVv8JIjDHALd 0YvAoZUlyOXXdAkQgE5jNYo63ZGuJ13bhk1EOxzLAq9nEBgYcKvaA4R+N7KO7lb7g4IM S6mdDxzr0j22qN4EtQ87dTBgPlrhPKtqPnk6cjmbZSy2uIlmZTki5whIJ19HYsZ/5hNk xrX0xPYgpBnqe2uycuBUjMW7cJxIHQV4a8R1EQ3/mw7uDeSc/LIVkzqiqrYBLLdPS69E ODjg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=mbRUu3+F; 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 n1si85991pga.16.2018.04.09.04.17.55; Mon, 09 Apr 2018 04:18:32 -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=mbRUu3+F; 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 S1752394AbeDILOH (ORCPT + 99 others); Mon, 9 Apr 2018 07:14:07 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:41396 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751918AbeDILOG (ORCPT ); Mon, 9 Apr 2018 07:14:06 -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=jZXvHUn6eA4wsKARja41MfOwB7AjNNAYwCmmTwl9QQE=; b=mbRUu3+Fn6RDPWuIt3Lfqa8N7 Rx739d/WpHZXXGtKmnO7hdaQ5tWex8Z7lJ44hez/i1ptk9/9xuuuHILElNrbhBX2sgl4vd+kgZ7He 3ek0SuplS6BmRWQ56WtSe1/fYZlki2NaOPomnmDHrhF92UZmAlKdtHkvLCvAKr0hierLYsYaLwFOF 0qLsu3taL6hyn2WCw/mX4SM3o8rx0zYUM/fqmR41ki28w/4Nw6ub08GPqwWbg3egzPU9JbvDOVs7i 3Vg70tXJecqikKCLxbzqdm+9xLisTVW6MOIZ0qj3E8IQs7aE+RaVIZcUQN9QM17uO5001xHSRl/ZA OQBkymjdw==; Received: from willy by bombadil.infradead.org with local (Exim 4.90_1 #2 (Red Hat Linux)) id 1f5UkN-0004e8-Op; Mon, 09 Apr 2018 11:14:03 +0000 Date: Mon, 9 Apr 2018 04:14:03 -0700 From: Matthew Wilcox To: Minchan Kim Cc: Christopher Lameter , Andrew Morton , linux-mm , LKML , Johannes Weiner , Jan Kara , Chris Fries , Jaegeuk Kim , Chao Yu , linux-f2fs-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] mm: workingset: fix NULL ptr dereference Message-ID: <20180409111403.GA31652@bombadil.infradead.org> References: <20180409015815.235943-1-minchan@kernel.org> <20180409024925.GA21889@bombadil.infradead.org> <20180409030930.GA214930@rodete-desktop-imager.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180409030930.GA214930@rodete-desktop-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 12:09:30PM +0900, Minchan Kim wrote: > On Sun, Apr 08, 2018 at 07:49:25PM -0700, Matthew Wilcox wrote: > > 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. > > 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 > > What's the wrong with setting __GFP_ZERO with mapping->gfp_mask? Because it's a stupid thing to do. Pages are allocated and then filled from disk. Zeroing them before DMAing to them is just a waste of time.