[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9be8a4d6-41d6-4e44-af98-bd2d6eae6f71@intel.com>
Date: Tue, 30 Sep 2025 10:38:30 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Xiaoyao Li <xiaoyao.li@...el.com>,
Rick Edgecombe <rick.p.edgecombe@...el.com>, kas@...nel.org, bp@...en8.de,
chao.gao@...el.com, dave.hansen@...ux.intel.com, isaku.yamahata@...el.com,
kai.huang@...el.com, kvm@...r.kernel.org, linux-coco@...ts.linux.dev,
linux-kernel@...r.kernel.org, mingo@...hat.com, pbonzini@...hat.com,
seanjc@...gle.com, tglx@...utronix.de, x86@...nel.org, yan.y.zhao@...el.com,
vannapurve@...gle.com
Cc: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Subject: Re: [PATCH v3 07/16] x86/virt/tdx: Add tdx_alloc/free_page() helpers
On 9/30/25 07:03, Xiaoyao Li wrote:
> My understanding/expectation is that, when refcount is not zero it needs
> to increment the refcount instead of simply return. And ...
That's a good point.
This doesn't properly handle the case where the PAMT exists and the
refcount is already incremented.
We need something like this with a fast path for a non-zero refcount
that doesn't take the lock:
// When the refcount is nonzero, the PAMT is allocated already.
// Bump it up and return.
if (atomic_inc_not_zero(pamt_refcount))
return;
// No PAMT is present. Take the lock to ensure there is no race
// to allocate it and proceed to allocate one.
... existing code here
Without this, all of the atomic manipulation is within the lock and the
atomic_t could just be a plain int.
Powered by blists - more mailing lists