Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753915AbbH0PJV (ORCPT ); Thu, 27 Aug 2015 11:09:21 -0400 Received: from mail-wi0-f169.google.com ([209.85.212.169]:35101 "EHLO mail-wi0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753116AbbH0PJT (ORCPT ); Thu, 27 Aug 2015 11:09:19 -0400 Date: Thu, 27 Aug 2015 17:09:17 +0200 From: Michal Hocko To: "Paul E. McKenney" Cc: Hugh Dickins , Vlastimil Babka , "Kirill A. Shutemov" , Andrew Morton , "Kirill A. Shutemov" , Andrea Arcangeli , Dave Hansen , Johannes Weiner , David Rientjes , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Christoph Lameter Subject: Re: [PATCHv3 4/5] mm: make compound_head() robust Message-ID: <20150827150917.GF27052@dhcp22.suse.cz> References: <1439976106-137226-5-git-send-email-kirill.shutemov@linux.intel.com> <20150820163643.dd87de0c1a73cb63866b2914@linux-foundation.org> <20150821121028.GB12016@node.dhcp.inet.fi> <55DC550D.5060501@suse.cz> <20150825183354.GC4881@node.dhcp.inet.fi> <20150825201113.GK11078@linux.vnet.ibm.com> <55DCD434.9000704@suse.cz> <20150825211954.GN11078@linux.vnet.ibm.com> <20150826212916.GG11078@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150826212916.GG11078@linux.vnet.ibm.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1450 Lines: 34 On Wed 26-08-15 14:29:16, Paul E. McKenney wrote: > On Wed, Aug 26, 2015 at 11:18:45AM -0700, Hugh Dickins wrote: [...] > > But if you do one day implement that, wouldn't sl?b.c have to use > > call_rcu_with_added_meaning() instead of call_rcu(), to be in danger > > of getting that bit set? (No rcu_head is placed in a PageTail page.) > > Good point, call_rcu_lazy(), but yes. > > > So although it might be a little strange not to use a variant intended > > for freeing memory when indeed that's what it's doing, it would not be > > the end of the world for SLAB_DESTROY_BY_RCU to carry on using straight > > call_rcu(), in defence of the struct page safety Kirill is proposing. > > As long as you are OK with the bottom bit being zero throughout the RCU > processing, yes. I am really not sure I udnerstand. What will prevent call_rcu(&page->rcu_head, free_page_rcu) done in a random driver? Cannot the RCU simply claim bit1? I can see 1146edcbef37 ("rcu: Loosen __call_rcu()'s rcu_head alignment constraint") but AFAIU all it would take to fix this would be to require struct rcu_head to be aligned to 32b no? Btw. Do we need the same think for page::mapping and KSM? -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/