From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 87EEBFA373F for ; Mon, 24 Oct 2022 19:21:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231419AbiJXTVO (ORCPT ); Mon, 24 Oct 2022 15:21:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45666 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231477AbiJXTUn (ORCPT ); Mon, 24 Oct 2022 15:20:43 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 399C84F182; Mon, 24 Oct 2022 10:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.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; bh=q/e1Qu4FtWDfZNOOIMgHCz0SgGdfdg4tA5OsEGOoE3c=; b=FrQ93RbAeyAsBBB/x8a2KWyRjb Pnwug+kpeEh3janb7pZacOSL53hYEgpXbZBGelbSUgmxB6EsqOHrLbauSQgOGjPeiGDOLMHKfUJTj eXpvysgzSc9vtKgKY03QtgbNRpfMaitvj4ixAcvj0BMhQ9JkqWTiLpIagTjlxxgDg50PO3qC355SM fEuSIZ9jjmDOeB1xrMW6o/bw+6Dso7BGdtfhvqVd/nraTKcfK+ODa4sLS+YJQSAJR0BMfRQxkgSjr jJ3aUQxfS0YpMJ1jUdZ+uqZEBiBC+UuqDaNIXUqwFiEV+ocKj8ZQsHcKJ2irFxXvLGzFyiGKEmF+f g9PhdxZw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1omz25-00FWrf-Vj; Mon, 24 Oct 2022 15:06:30 +0000 Date: Mon, 24 Oct 2022 16:06:29 +0100 From: Matthew Wilcox To: Vlastimil Babka Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>, Hugh Dickins , David Laight , Joel Fernandes , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, rcu@vger.kernel.org Subject: Re: amusing SLUB compaction bug when CC_OPTIMIZE_FOR_SIZE Message-ID: References: <35502bdd-1a78-dea1-6ac3-6ff1bcc073fa@suse.cz> <7dddca4c-bc36-2cf0-de1c-a770bef9e1b7@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7dddca4c-bc36-2cf0-de1c-a770bef9e1b7@suse.cz> Precedence: bulk List-ID: X-Mailing-List: rcu@vger.kernel.org On Mon, Oct 24, 2022 at 04:35:04PM +0200, Vlastimil Babka wrote: > I would like to have a working safe version in -next, even if we are able > simplify it later thanks to frozen refcounts. I've made a formal patch of > yours, but I'm still convinced the slab check needs to be more paranoid so > it can't observe a false positive __folio_test_movable() while missing the > folio_test_slab(), hence I added the barriers as in my previous attempt [1]. > Does that work for you and can I add your S-o-b? Thanks for picking this back up. > +++ b/mm/slab.c > @@ -1370,6 +1370,8 @@ static struct slab *kmem_getpages(struct kmem_cache *cachep, gfp_t flags, > > account_slab(slab, cachep->gfporder, cachep, flags); > __folio_set_slab(folio); > + /* Make the flag visible before any changes to folio->mapping */ > + smp_wmb(); So what's the point of using __folio_set_slab() only to call smp_wmb() afterwards? If we call folio_set_slab() instead, don't all the other barriers go away? (This is a genuine question; I am bad at this kind of reasoning). Obviously it would still need a comment.