From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 765993B6356 for ; Wed, 1 Jul 2026 15:54:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782921265; cv=none; b=MY4VFJ3R+icv+YHySjuSpxs+gpldtZ67DqDs4SQirEB7U+TYv5T7vgFCRN34KZsc3uUZru1J4mlirtpaPajO0H1OhVCGNJdc/kTEh2g/obmJdjDlm67bHAOtKk/cLw8wJJJVDUHihhrDfc1SXMKc7NRdetHmnR7VzsFi2LO+3oA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782921265; c=relaxed/simple; bh=Xiv8a+MHhH8J6rT1nMbNrm50OA23p3Gi0rYDhopodjQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=txl/PjM8ureswAzb4ZDESjrAKkdKUmXdomGT3P35z0qNRLtZI1NfbkrYj7PEebcQaJhABWIUw5agcYHj34N5MHpUVbi+s4o5Kq4BmSHQqOkzW445muVUur4GFFlvWaI1MqBw1NFxG2zuuN/xwMC5W1PsrVnXM1kaaeHsRTKcpmo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=A7iWcg2s; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=gTKQG8nd; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="A7iWcg2s"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="gTKQG8nd" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782921263; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ZQqt/bByGpZMVaTV47GrHV/MzFjAQYvcctbsvrjGHwc=; b=A7iWcg2s15SWrCLcvcL5iL1gvKcnPUTcPu81VdD+E641LEKd059mPI9Sd3CKaEN/VOI1Md Bq1/22pBQMlFb+LjwWshCSa6zvs6osx2wvl+a8KfS1/fkjdRbbF4BFIsIo18L56PB0/TMT 1XWyau9FvnN2vOPeYXGebjiEtcdfMvs= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-320-f-ymTyE4MkKP4xZCcT2_lA-1; Wed, 01 Jul 2026 11:54:22 -0400 X-MC-Unique: f-ymTyE4MkKP4xZCcT2_lA-1 X-Mimecast-MFC-AGG-ID: f-ymTyE4MkKP4xZCcT2_lA_1782921261 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-493bc2b376fso4737015e9.3 for ; Wed, 01 Jul 2026 08:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1782921261; x=1783526061; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ZQqt/bByGpZMVaTV47GrHV/MzFjAQYvcctbsvrjGHwc=; b=gTKQG8ndF4XALoXkbzeOsEQ4+SfGvgKBVqj2CSs9VHQsN+CewrgdrjnBZr7VJdr0VT MYGngikIn8lXx7IzwbOBXkxtxm04Ih2wBTHs/EnmgPVTCnbb1PaqNXaJcilvdqmQj3Q+ EBEh7BxIeEePk6vPgSmXtZeemL6T+Z8J7I1hdXs3vmLlBYTm8wHUZ2vv9wHbJNWOhQnm FDBBaL5J8WYpRcq3Hde3FkbbmcHmgVv2z7svpPcHkNrXdt7llg3GbvgQiz9xPorIdoT6 YKT5Vg3JvsZ3Bqex5joWyRvjNLisuIz2FfTzvE6AEz6f6ARy52XDsCwaLldMvihE1Bpn R9DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782921261; x=1783526061; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ZQqt/bByGpZMVaTV47GrHV/MzFjAQYvcctbsvrjGHwc=; b=hrpp3JniE2t1um2uGAJ6uzoYUcce5c1CWzAXFTczDM6DKcJcxsaPANl8LkyUOWQOwI aN373HKM+Xi2HXrUqTMfGHr1qczPmA+zs4+AJzk+/cGTu3wdDXGu23UAlSzAZcsyw7Ox YlgNtN1M/rN7QqcFXa4p6VHhRVhs/zQmoeX/tZE1ggXEYRXqP4X26fsiygcWu3RAlld/ 6uwrlT5dseD+u/2gYZOd3ozjvDguYqe2eqrwYX9P73n/3F2Q4YaLOxjO9MNBLobgqJVy NG9P7KTTjNE2odBJe4wHiz7NgD8Sq0v2ug2EzOxfB+3zDAhnVTcvFbMgsi3oyWD36IBI JQ6Q== X-Gm-Message-State: AOJu0YzbQUNd9hOj8co1M2RIScwMYTfQeyM4Br3UCtrCJmzS3xStcFjI yid4MzNq5502JrobBIHL2xWVyX9Xji+lfOxEebYr9wjjzmUf4IGASrPjS9Guj/2Qm+09KzEMhuT Kh+suYnAXICmIkh58gFuIFMeDnApgC5A2/YEqBVVNY+CWfkB/L3Crhk3T2K5xNWF+pg== X-Gm-Gg: AfdE7cmV4S4LVG/WRClM+21hsYjcyjsDro4bfmi8PhT/VX8K2fhDfOM8XhgA9qliUDH 9U2DB9YZNkxv2Hj1akJRd9/cYVQQ7l01Qi/VqKDyP3OPspgDmpDaoQZxbwZwlH8QAIlo7iSwidR fVumMFYERzyx89xfoEQFHaXtLthUrIDFiZOd1dDa1397VTB0lqL1Bu8wO1LGXWzLlkvmNUzDXd0 /xsSBFzfvnNyXAdOCW/gmGfPUecwwq4nrkSrrVQx5PGvu6E2Z1SB6VY89Tw66N5A/b4UVNUS1th RGW6vGMS6ZIVzCvPANWkeBAOgQlhz6roTWXmCS6bSAgf8KJi43l0zGPwjpob2Bmh9O9BCHaVNmw nx2n4UOf+dzQAp2hcXwlCZo/NtDegLBpj X-Received: by 2002:a05:600c:3588:b0:492:59fe:4a15 with SMTP id 5b1f17b1804b1-493c2b84695mr28231755e9.24.1782921260962; Wed, 01 Jul 2026 08:54:20 -0700 (PDT) X-Received: by 2002:a05:600c:3588:b0:492:59fe:4a15 with SMTP id 5b1f17b1804b1-493c2b84695mr28231295e9.24.1782921260379; Wed, 01 Jul 2026 08:54:20 -0700 (PDT) Received: from redhat.com (IGLD-80-230-85-71.inter.net.il. [80.230.85.71]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-493be4c89ccsm95218855e9.4.2026.07.01.08.54.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jul 2026 08:54:19 -0700 (PDT) Date: Wed, 1 Jul 2026 11:54:15 -0400 From: "Michael S. Tsirkin" To: "David Hildenbrand (Arm)" Cc: linux-kernel@vger.kernel.org, Miaohe Lin , Naoya Horiguchi , Andrew Morton , Oscar Salvador , Andi Kleen , Hidehiro Kawai , Rik van Riel , Vlastimil Babka , Lorenzo Stoakes , "Liam R. Howlett" , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Christoph Lameter , David Rientjes , Roman Gushchin , Harry Yoo , Hao Li , Kiryl Shutsemau , Byungchul Park , linux-mm@kvack.org, linux-cxl@vger.kernel.org Subject: Re: [PATCH 0/2] mm: memory-failure: fix HWPoison flag race with non-atomic page flag ops Message-ID: <20260701112946-mutt-send-email-mst@kernel.org> References: <54c8cbee-9b26-458c-93ba-5aa594f5d1e8@kernel.org> <20260629174225-mutt-send-email-mst@kernel.org> <20260630174852-mutt-send-email-mst@kernel.org> <2f884bfa-3cd5-4fba-8aa4-c2e68890ab64@kernel.org> <20260701041112-mutt-send-email-mst@kernel.org> <20260701043024-mutt-send-email-mst@kernel.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: On Wed, Jul 01, 2026 at 10:36:31AM +0200, David Hildenbrand (Arm) wrote: > On 7/1/26 10:33, Michael S. Tsirkin wrote: > > On Wed, Jul 01, 2026 at 10:26:26AM +0200, David Hildenbrand (Arm) wrote: > >> On 7/1/26 10:18, Michael S. Tsirkin wrote: > >>> > >>> So on this idea. It might not matter. What I had in mind is: > >>> 1. run the current logic > >>> 2. add page to a list of pages to check, then invoke e.g. call_rcu_tasks > >>> (or call_rcu_tasks_rude) maybe > >>> 3. in the callback, recheck and if poison cleared, go back to 1 > >>> 4. otherwise everyone will see the bit set, remove from list we are done > >>> > >>> it seems to not regress anything, and for the rare race, we set > >>> the bit eventually. > >>> > >> > >> So test-and-set (and friends) would also have to check the data structure that > >> remembers bit to set/clear (and possibly update the data structure). > >> > >> That does seem doable. Do you have a prototype? > > > > what do you think ;) post it? > > As RFC please :) [and if it's AI generated, obviously properly reviewed and > reworked by you] > -- > Cheers, > > David Not "generated" surely. But assisted, yes. Still hacking on it, but the difficulty with memory-failure is that fundamentally, it's not 100% robust. For example, we have a fifo fed by hardware and consumed by a workqueue: struct memory_failure_cpu *mf_cpu; unsigned long proc_flags; bool buffer_overflow; struct memory_failure_entry entry = { .pfn = pfn, .flags = flags, }; mf_cpu = &get_cpu_var(memory_failure_cpu); raw_spin_lock_irqsave(&mf_cpu->lock, proc_flags); buffer_overflow = !kfifo_put(&mf_cpu->fifo, entry); if (!buffer_overflow) schedule_work_on(smp_processor_id(), &mf_cpu->work); raw_spin_unlock_irqrestore(&mf_cpu->lock, proc_flags); put_cpu_var(memory_failure_cpu); if (buffer_overflow) pr_err("buffer overflow when queuing memory failure at %#lx\n", pfn); if there are lots of these and the scheduler is slow and it overflows, it's sayonara you have lost the flag, right? Oh and by the way, I just noticed that when buddy merges pages it does not check the poison bit. So it looks like there's a simple way to lose the poison bit - have it merge with a non poisoned page. I guess maybe we should fix this last one. -- MST