Received: by 10.213.65.68 with SMTP id h4csp4201010imn; Tue, 10 Apr 2018 10:49:43 -0700 (PDT) X-Google-Smtp-Source: AIpwx49hQooka/Gms0c5Zirl7PyOeTzvFDwSoUfD20tppQ0oVTkm7JfjejortrU/v5qGePPHQrWB X-Received: by 2002:a17:902:24a5:: with SMTP id w34-v6mr1426821pla.328.1523382583023; Tue, 10 Apr 2018 10:49:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523382582; cv=none; d=google.com; s=arc-20160816; b=E8d0Gm06aRdFxv3QDXXRN3bkLf7DzNkx7v8YDWkxYDQoFZhQSniWoOS7yFyteCz2jX lPmtlH7WsiBwesEkfzWKDkaHcie8W+21pQeAETii3Muaeop10806I8vIroXSknbJxYoJ THJpA+5blJA8Qi/nXM1hXBTDYg5cVAwpy8cz3RgDqZm+fM1TP7oLZobm2AqurVb1Xkrm 5HuT8Gh7w9HmASEG/ePr2jR6hf9U5kqvQ7S5PRnMT4ZHbvs1mmE1EqvwoBp/57jkCmQl LPIp7EIdgDydLOH5oxj2hwEhXRsLklKtq3REB01qGL5bDK0+U+gEOAs7NvMun1bObjA+ iIIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=nDFUwvBoBJtjx30z1nm+sKhCoroapBZMkQpR07KYLeU=; b=kg9xuw8i0Z79/wIOo9ccMst6uAIaZvCjV+aFSmHTXobpxOALA551kTdgoIfPJD/N5P /zoCHt2I4B8ANdy45YrSkO8k9xw5vWCiIYcdwB4sIm+o/t33j+YR6kZ5a1/WpQwKbjMU ABc80Tv/v+Rfl5kiqUUhKRND7XOf3CoXnud0OiBrmTFSfnIqYgmbiU+1F4A/CiFTCL/W BHIZd9tMUZO2LLGIlqq6sNvkfYQ5YnkAYt5J0cIMfJfyf+Sw3yVZfLZ+rQokWSq5v3GF 3cv59osauDS4oAMnFACQOf68Qy2TQFPu18YQdv2c9G+s4YDAZpCVqhc/i8gAzw38JAJx pmUw== 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 u20si2373023pfm.70.2018.04.10.10.49.05; Tue, 10 Apr 2018 10:49: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; 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 S1751886AbeDJRqC (ORCPT + 99 others); Tue, 10 Apr 2018 13:46:02 -0400 Received: from resqmta-ch2-06v.sys.comcast.net ([69.252.207.38]:37818 "EHLO resqmta-ch2-06v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751504AbeDJRqA (ORCPT ); Tue, 10 Apr 2018 13:46:00 -0400 Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id 5xKSfyHFhlpHk5xLDf2Jb3; Tue, 10 Apr 2018 17:45:59 +0000 Received: from gentwo.org ([98.222.162.64]) by resomta-ch2-12v.sys.comcast.net with SMTP id 5xLAfi6bmKKpS5xLBfVAPl; Tue, 10 Apr 2018 17:45:59 +0000 Received: by gentwo.org (Postfix, from userid 1001) id 59F2D1160B41; Tue, 10 Apr 2018 12:45:56 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 5782B11600FD; Tue, 10 Apr 2018 12:45:56 -0500 (CDT) Date: Tue, 10 Apr 2018 12:45:56 -0500 (CDT) From: Christopher Lameter X-X-Sender: cl@nuc-kabylake To: Matthew Wilcox cc: Eric Dumazet , linux-mm@kvack.org, Matthew Wilcox , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , linux-kernel@vger.kernel.org, Jan Kara , Jeff Layton , Mel Gorman , stable@vger.kernel.org Subject: Re: [PATCH 1/2] slab: __GFP_ZERO is incompatible with a constructor In-Reply-To: <20180410173841.GD3614@bombadil.infradead.org> Message-ID: References: <20180410125351.15837-1-willy@infradead.org> <20180410165054.GC3614@bombadil.infradead.org> <20180410173841.GD3614@bombadil.infradead.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-CMAE-Envelope: MS4wfP/bjkeDFg7P81g6/kNz/8v2v7EpXbc1ECdczd+gAPnfYJbQk2shovJQ0F6PSebJX6RrJjGvsbgp8NNQBuZKxhzKnilWK5ykLjXw4a9UQxOLWlbxvjV2 gyUV9XqErrk1TIwaGeqRLdWUZMcGuFnThzBzgNKC01v/7viPWKhvM/vJadmdBeTkoYvptUmq+/VCx6X2cJhj3yCfaWPqXdmJsBKX4F7od3bkgQThpoLFT7Q8 zU03uGGEqKWizTXUKqI+RKbBbHNgwN4sTnn+jTdGJ+UfwwrLrx0kjtO75kcVgy8JeNIKOpQrW9v8ls6XgbjRl2zFJ0ownLIdumDVIGyj29hxtFIFH8xFS+Hw xEVEC4V4KR8joO4xY3smaS1hk11pIchOihXUaBoR7aAZ/0JAD6bbgAowJli3HYOqbjf9IAnNCu7XOrG4El2ntXpv4OzOvjLoPPL1xZUke3bQ2xDyEu4K1881 lYOGnySg1M7DaMB6/AD9/Cz7O6NBFzJb2/dT0ls5kPCNkDJ994NZLghfBB0tYdNn3xDdddirpe9bXmPjHQhdajKGPM4B+FNkachxXg== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 10 Apr 2018, Matthew Wilcox wrote: > > How do you envision dealing with the SLAB_TYPESAFE_BY_RCU slab caches? > > Those must have a defined state of the objects at all times and a constructor is > > required for that. And their use of RCU is required for numerous lockless > > lookup algorithms in the kernhel. > > Not at all times. Only once they've been used. Re-constructing them > once they've been used might break the rcu typesafety, I suppose ... > would need to examine the callers. Objects can be freed and reused and still be accessed from code that thinks the object is the old and not the new object....