From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6A9583AB466 for ; Thu, 30 Jul 2026 07:28:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785396501; cv=none; b=NOGa3X5sEk/jZOfpXJWiroF5shIbVwBKfepQu/vZi3gf0XMhUZUb3usjMhdcNbGdb1RMZ9qci6GRuec3s6U66vve9AvXDqljqboVnjF+lVo4m7NZnNQkDRlTBrN6eUcxy5VQeh1EroR1HyU3fWpjg7d+3bVt3xBul7fkISMEGno= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785396501; c=relaxed/simple; bh=I/g9ZvZSlL/yiNqcDcN14XRGLywEAGE7ODkqeqerkaY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fwVtrVhW2q2tMJhDvtnM56UrFbMf/8jlrwPmO8ogniazx8iMK5dNkR2oeCS7lJLTkZPLMzJVlv2a+ITtpm60szMHTcLsYuKD+b9i4lrKnmXMZbvVy3blhFHFDkik17bdNZkzqM3f5/lYSyZylM7kOYxhcX1kbczDcnIIPFoGMX8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JfpZcsTI; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JfpZcsTI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 184871F000E9; Thu, 30 Jul 2026 07:28:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785396498; bh=U+Tn6v+fwIrJojcp6KTc+RNYg06A/2SJBiLKpI3895M=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=JfpZcsTIi4Hst6B2IIzM18A8fKqpm49BKKL9gLMgWdsPlDnjn7wbKb1muCUmGrGiv mMyoSW9FQkCXNid8xKZQqGzFZORSD/nN+VeXAR1Rpm5ritRgWobY86FqWrvJgasIPi XszO0IBd0BWXSk1RjnXzQMwp5esqTrWO1aEDeUO0KtPtQFcCQ+P5E7LtaTz2T+Vhb9 5WWSBDEx/F6nGQZhYXvDcUo1bj04TESx1O2/Xs2sKq7tTJmDJTjdzEQI0/qsGYMuqH 60Dl10CCNSD1uxJrJyXgpZNFLeFzJZfMnooq+37x5XJJgGXwrD5UH7UfbH9K6V1q0d sVvpTRO0rQM4g== Date: Thu, 30 Jul 2026 08:27:59 +0100 From: "Lorenzo Stoakes (ARM)" To: Andrew Morton Cc: "David Hildenbrand (Arm)" , xueyuan.chen@vivo.com, linux-mm@kvack.org, Zi Yan , Baolin Wang , "Liam R. Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Kiryl Shutsemau , Bob Liu , linux-kernel@vger.kernel.org, Xueyuan Chen Subject: Re: [PATCH] mm/huge_memory: fix huge zero folio publication race Message-ID: References: <4ee89c27873fb4d9e598f8a5cfe71d700ecf894e.1785300563.git.xueyuan.chen@vivo.com> <37c40d62-51e2-45b4-9837-a4b96d1640b3@kernel.org> <20260729180241.2b8bcb2379b975b22c48d251@linux-foundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260729180241.2b8bcb2379b975b22c48d251@linux-foundation.org> On Wed, Jul 29, 2026 at 06:02:41PM -0700, Andrew Morton wrote: > On Wed, 29 Jul 2026 08:44:12 +0200 "David Hildenbrand (Arm)" wrote: > > > > --- a/mm/huge_memory.c > > > +++ b/mm/huge_memory.c > > > @@ -245,8 +245,11 @@ static bool get_huge_zero_folio(void) > > > } > > > WRITE_ONCE(huge_zero_pfn, folio_pfn(zero_folio)); > > > > > > - /* We take additional reference here. It will be put back by shrinker */ > > > - atomic_set(&huge_zero_refcount, 2); > > > + /* > > > + * Publish the folio and PFN before making them available to lockless > > > + * users. Pairs with a successful atomic_inc_not_zero() above. > > > + */ > > > + atomic_set_release(&huge_zero_refcount, 2); > > > preempt_enable(); > > > count_vm_event(THP_ZERO_PAGE_ALLOC); > > > return true; > > > > https://lore.kernel.org/r/20260728-fix-refcounted-huge-zero-v1-0-3f261f5447b4@kernel.org > > Does that actually fix the same thing? ??? This patch was sent after mine and tries to change code that doesn't exist? If you look at [0] you will see: + /* Paired with atomic_inc_not_zero(). +1 for shrinker pin. */ + atomic_set_release(&huge_zero_refcount, 2); Which is... doing what this does anyway? (I don't actually think this patch is correct anyway since the cmpxchg() is fully-ordered with a try loop and the issue with PFN vs folio publication still exists.) BUT it doesn't matter anyway. The race is fixed and I went into great detail in [0] and [1] explaining why and how. If somebody can poke holes in that then go ahead, otherwise I'm not sure why David's response didn't suffice here. > > Is so, Xueyuan's Fixes: is 97ae17497e99 ("thp: implement refcounting > for huge zero page"). Which to believe? > Again ??? 3b77e8c8cde5 is where the PFN actually started to matter, before that the huge zero page was compared directly. The patch proposed here says the PFN is the issue so it already had an incorrect fixes tag. Cheers, Lorenzo [0]:https://lore.kernel.org/all/20260728-fix-refcounted-huge-zero-v1-2-3f261f5447b4@kernel.org/ [1]:https://lore.kernel.org/all/ameC4IWCOVBGlXZu@lucifer/