From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout02.his.huawei.com (canpmsgout02.his.huawei.com [113.46.200.217]) (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 CCC512BDC05 for ; Thu, 11 Jun 2026 03:35:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.217 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781148947; cv=none; b=bmAt+pDbiGIVcIniPbJb7alLgS7LmXtQgTWRX48ivFJhGV/UrjFM1b7eSX6q61i/bqD87MOCsHyD/UYTR0/BHr2t33sHI1oXWFGuy6NtPGgKhIEpg1AAMyfqZAjDB6YzhH2OXmXBYaGE6TFhbzDvBaz5Ei9EmGJONmAy+UoVbrU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781148947; c=relaxed/simple; bh=nvRc8GedXD+t6Lf4HNZNiOJLlaUXpTfFEuCgpsamMxc=; h=Subject:To:CC:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=kctB0vs+WN6eGdXnFwfppuEg6ZI2KuRdJ5tzgu3/BteayczEgEsgvNCkekkQF+EyvYGjr1TUo61TmMl+6WaUeJnaCEVKP5/3FAXRJUDcHvSmj17sbjyY2aMNFZxSp9xROS8J5pedYVeMdCXh1XoojEUv9+gP6jMvIHHJIR/gCqs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=s2c+zISf; arc=none smtp.client-ip=113.46.200.217 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="s2c+zISf" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=udMeqyjo/ojhmjQo8mZa5UnxqjBW6Epo1JZrcj9cKSA=; b=s2c+zISfurUf+7wHGhsy/XXdBPiaMlR76c5w9vuixp2j4ufSD7YkhbbMqmcA6nYSWqiVEZgCX 7cilsr4IvqF9dZLLKRrzXrHlOVa1pb7agG1XD3kT0IpQg+CmRSPXLMOYDY1ipE5+t6CjtiVeV1e 6pOdEuOY+qXKfiy7xjmEpLE= Received: from mail.maildlp.com (unknown [172.19.162.197]) by canpmsgout02.his.huawei.com (SkyGuard) with ESMTPS id 4gbSkk71zszcb1Y; Thu, 11 Jun 2026 11:27:26 +0800 (CST) Received: from dggemv705-chm.china.huawei.com (unknown [10.3.19.32]) by mail.maildlp.com (Postfix) with ESMTPS id 4BF6140577; Thu, 11 Jun 2026 11:35:40 +0800 (CST) Received: from kwepemq500010.china.huawei.com (7.202.194.235) by dggemv705-chm.china.huawei.com (10.3.19.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 11 Jun 2026 11:35:40 +0800 Received: from [10.173.124.160] (10.173.124.160) by kwepemq500010.china.huawei.com (7.202.194.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 11 Jun 2026 11:35:37 +0800 Subject: Re: [PATCH splitout] mm: memory-failure: serialize TestSetPageHWPoison with zone->lock To: "Michael S. Tsirkin" CC: Zi Yan , "David Hildenbrand (Arm)" , Andrew Morton , , Jason Wang , Xuan Zhuo , =?UTF-8?Q?Eugenio_P=c3=a9rez?= , Muchun Song , Oscar Salvador , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Hugh Dickins , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Christoph Lameter , David Rientjes , Roman Gushchin , Harry Yoo , Axel Rasmussen , Yuanchu Xie , Wei Xu , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , , , Andrea Arcangeli , Naoya Horiguchi References: <20260609111020.e88f51a7b6ebc37360d66fdc@linux-foundation.org> <8c1f468e-b50a-487a-a267-8d1ea5a61c87@kernel.org> <38C84F23-E881-4DB2-86BA-93F39D44AE1B@nvidia.com> <20260609162437-mutt-send-email-mst@kernel.org> <4BA276D9-9EB9-4E2A-8A05-657ACACFF227@nvidia.com> <20260609165829-mutt-send-email-mst@kernel.org> <20260610171646-mutt-send-email-mst@kernel.org> From: Miaohe Lin Message-ID: <14537566-94d9-eac5-2636-35f925a9d159@huawei.com> Date: Thu, 11 Jun 2026 11:35:36 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: <20260610171646-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To kwepemq500010.china.huawei.com (7.202.194.235) On 2026/6/11 5:18, Michael S. Tsirkin wrote: > On Wed, Jun 10, 2026 at 03:24:30PM +0800, Miaohe Lin wrote: >> On 2026/6/10 5:00, Michael S. Tsirkin wrote: >>> On Tue, Jun 09, 2026 at 04:54:01PM -0400, Zi Yan wrote: >>>> On 9 Jun 2026, at 16:34, Michael S. Tsirkin wrote: >>>> >>>>> On Tue, Jun 09, 2026 at 02:52:47PM -0400, Zi Yan wrote: >>>>>> On 9 Jun 2026, at 14:39, Zi Yan wrote: >>>>>> >>>>>>> On 9 Jun 2026, at 14:38, David Hildenbrand (Arm) wrote: >>>>>>> >>>>>>>> On 6/9/26 20:10, Andrew Morton wrote: >>>>>>>>> On Tue, 9 Jun 2026 06:12:49 -0400 "Michael S. Tsirkin" wrote: >>>>>>>>> >>>>>>>>>> TestSetPageHWPoison() is called without zone->lock, so its atomic >>>>>>>>>> update to page->flags can race with non-atomic flag operations >>>>>>>>>> that run under zone->lock in the buddy allocator. >>>>>>>>>> >>>>>>>>>> In particular, __free_pages_prepare() does: >>>>>>>>>> >>>>>>>>>> page->flags.f &= ~PAGE_FLAGS_CHECK_AT_PREP; >>>>>>>>>> >>>>>>>>>> This non-atomic read-modify-write, while correctly excluding >>>>>>>>>> __PG_HWPOISON from the mask, can still lose a concurrent >>>>>>>>>> TestSetPageHWPoison if the read happens before the poison bit >>>>>>>>>> is set and the write happens after. Will only get worse if/when >>>>>>>>>> we add more non-atomic flag operations. >>>>>>>>>> >>>>>>>>>> Fix by acquiring zone->lock around TestSetPageHWPoison and >>>>>>>>>> around ClearPageHWPoison in the retry path. This >>>>>>>>>> serializes with all buddy flag manipulation. The cost is >>>>>>>>>> negligible: one lock/unlock in an extremely rare path >>>>>>>>>> (hardware memory errors). >>>>>>>>>> >>>>>>>>>> Note: SetPageHWPoison and TestClearPageHWPoison calls elsewhere >>>>>>>>>> in this file operate on pages already removed from the buddy >>>>>>>>>> allocator or on non-buddy pages (DAX, hugetlb), so they do not >>>>>>>>>> need zone->lock protection. >>>>>>>>> >>>>>>>>> Sashiko is saying this doesn't do anything "Because >>>>>>>>> __free_pages_prepare() executes entirely locklessly". Did it goof? >>>>>>>>> >>>>>>>>> https://sashiko.dev/#/patchset/df06b66fe4ff8e925ee0714955abc2183a727b90.1780998980.git.mst@redhat.com >>>>>>>> >>>>>>>> Battle of the bots: it's right. >>>>>>> >>>>>>> Yep, __free_pages_prepare() changes the page flag without holding >>>>>>> zone->lock. >>>>>> >>>>>> __free_pages_prepare() works on frozen pages and assumes no one else >>>>>> touches the input page. To avoid this race, memory_failure() might >>>>>> want to try_get_page() before TestClearPageHWPoison(), but I am not >>>>>> sure if that works along with memory failure flow. >>>>>> >>>>>> Best Regards, >>>>>> Yan, Zi >>>>> >>>>> >>>>> >>>>> Actually memory failure already plays with this down the road no? >>>>> >>>>> So maybe it's enough to just SetPageHWPoison afterwards again? >>>>> >>>>> >>>>> diff --git a/mm/memory-failure.c b/mm/memory-failure.c >>>>> index ee42d4361309..4758fea94a96 100644 >>>>> --- a/mm/memory-failure.c >>>>> +++ b/mm/memory-failure.c >>>>> @@ -2415,6 +2415,7 @@ int memory_failure(unsigned long pfn, int flags) >>>>> if (!res) { >>>>> if (is_free_buddy_page(p)) { >>>>> if (take_page_off_buddy(p)) { >>>>> + SetPageHWPoison(p); >>>>> page_ref_inc(p); >>>>> res = MF_RECOVERED; >>>>> } else { >>>>> >>>>> >>>>> and maybe in a bunch of other places in there? >>>> >>>> You mean for fear of losing HWPoison flag in the earlier TestSetPageHWPoison(), >>>> just set it again here? >>> >>> Yea. >>> >>>> Why not do it after get_hwpoison_page(), since that >>>> is the expected page flag? >>> >>> It's still in the buddy at that point right? I'm worried buddy might >>> poke at flags. >> >> Since __free_pages_prepare() executes entirely locklessly, the only way to ensure >> HWPoison flag won't be lost might be only set hwpoison flag iff we can make sure >> pages are not on the way to buddy... >> >> Thanks. >> . > > > To clarify do you not agree repeating SetPageHWPoison is enough for > this? And if not, do you have suggestions on how to fix this race? Do you mean repeating SetPageHWPoison on every branch? Is it possible to make __free_pages_prepare changes page->flags atomically or this race is specified to memory_failure? Thanks. .