Received: by 10.213.65.68 with SMTP id h4csp3849279imn; Tue, 10 Apr 2018 05:44:42 -0700 (PDT) X-Google-Smtp-Source: AIpwx48uZH0YPYTlS6tRj0lc3gfbOCajDufVbqLCGCb+xafB4/SghWaWjDDRiDl+Cf/kqSQuYoB8 X-Received: by 2002:a17:902:7b8e:: with SMTP id w14-v6mr306251pll.52.1523364282810; Tue, 10 Apr 2018 05:44:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523364282; cv=none; d=google.com; s=arc-20160816; b=nL1IlM3ArmlM44vWZC6HrO/eEIIwZRQVdwWAF0fQ6UgZ8yY2W+GesWmUfsWIkWVqIL rfTbQv3RMNMyrikspVThVLR8KMjH02I1A17Ywvfm6t3B684qVF8LL9s4fafu4OAH78q2 u17wjbgjw4hWbOhStya4mz0LEDL6+9yplLDc5aUF7LM9ummFVbLSYFSKpa8+vLE0v+vn ZcMkEkauNAcvGcnMg2gDQ1ytGaC6P/NsU1NEUTd1b/oPb1ogiv9oAx9GP64j+W5zs7oD GN724PibXQz//OlZbsOKqBVeOtsf5OPF7aM+udeGDz2DMpvgwVqr8xrwqys2rHu+lazF xulg== 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=fjv2aB394aEXLfQPkqU0uYYA55nwxmBynPPzvZjI9n4=; b=rzelICJWEdji0S3lQ9lwZpaOfhvoqe0VrMvTA7g/0mTaMFPOQKQ0QQ56B0h+Vpq092 mSMQsx9eAfP/qc7qSoy2+DeLkYQCBH9tiJ2rpa8kAvAcBl4qLTuqnzGEtnF+IlLQxQUJ DQLiI/pKe9chsOQQol0qgSHNbbyRXuCU54hmQ9DCE/gewNlE0/horQao0UIDQG5BHCQ5 RH2dbipvfhydgtwdBqOKZZq+FGFaLOeB8813WzKehh5Lup7BR2hU5foWCDKhll3lQV7R acxAuuH6yEoG13Fb4+pHOR3t9Znoc2/D07YQ6EIhtnKy+Z8+OTDpxqTSvMXNUg5w7VZd RtCw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@cmpxchg.org header.s=x header.b=DVAaATkt; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=cmpxchg.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u6-v6si2712394plz.562.2018.04.10.05.44.05; Tue, 10 Apr 2018 05:44: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=@cmpxchg.org header.s=x header.b=DVAaATkt; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=cmpxchg.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753166AbeDJMi3 (ORCPT + 99 others); Tue, 10 Apr 2018 08:38:29 -0400 Received: from gum.cmpxchg.org ([85.214.110.215]:50876 "EHLO gum.cmpxchg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752584AbeDJMi1 (ORCPT ); Tue, 10 Apr 2018 08:38:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cmpxchg.org ; s=x; 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=fjv2aB394aEXLfQPkqU0uYYA55nwxmBynPPzvZjI9n4=; b=DVAaATkt60EGrKbGFnsED54lmY rJ51NLaZdxbhMKiaCeLhNT2pG8pHHIpBYU6qWUIOs/bsuz0T8n7hdZkxea79w0/I8UqIUhAxngPIP OtdKZa9WEs3FtH+F0CyrEwkAQDyPZkAOxjXKqYlPOy+MImcdlujjh6gP7Pyj+N4Aw9ic=; Date: Tue, 10 Apr 2018 08:39:46 -0400 From: Johannes Weiner To: Matthew Wilcox Cc: Michal Hocko , Jaegeuk Kim , Minchan Kim , Christopher Lameter , Andrew Morton , linux-mm , LKML , Jan Kara , Chris Fries , Chao Yu , linux-f2fs-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] mm: workingset: fix NULL ptr dereference Message-ID: <20180410123946.GA6334@cmpxchg.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> <20180409183827.GD17558@jaegeuk-macbookpro.roam.corp.google.com> <20180409194044.GA15295@bombadil.infradead.org> <20180410082643.GX21835@dhcp22.suse.cz> <20180410120528.GB22118@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180410120528.GB22118@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 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. Fully agreed. I'm surprised there is so much pushback to what Willy is saying here, this stuff has been established for years. > > 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); That looks reasonable to me.