From: Nicolin Chen <nicolinc@nvidia.com>
To: Yi Liu <yi.l.liu@intel.com>
Cc: <joro@8bytes.org>, Lu Baolu <baolu.lu@linux.intel.com>,
Kevin Tian <kevin.tian@intel.com>, Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Jean-Philippe Brucker <jpb@kernel.org>,
"Jason Gunthorpe" <jgg@nvidia.com>, <iommu@lists.linux.dev>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 5/5] iommu: Reject a same-domain replace in the attach handle APIs
Date: Tue, 3 Nov 2026 09:37:20 -0800 [thread overview]
Message-ID: <auob0IV+h0aiW8u2@nvidia.com> (raw)
In-Reply-To: <68570abd-f619-4d9d-a7af-d2acf1f9aad3@intel.com>
On Tue, Nov 03, 2026 at 07:59:52PM +0800, Yi Liu wrote:
> On 11/2/26 15:04, Nicolin Chen wrote:
> > @@ -3716,6 +3716,10 @@ EXPORT_SYMBOL_GPL(iommu_attach_device_pasid);
> > * Caller should always provide a new handle to avoid race with the paths
> > * that have lockless reference to handle if it intends to pass a valid handle.
> > *
> > + * The @domain must not be the domain currently attached to the @pasid. Such a
> > + * same-domain replace would skip the driver callback flushing pending faults.
> > + * Then, those faults could use the old handle after the caller frees it.
> > + *
>
>
> Not a native speaker, but this reads a bit ambiguous to me:
>
> I parsed the last sentence as describing intended/acceptable behavior
> rather than the hazard being guarded against - "Then, ... could use"
> reads like a neutral continuation rather than a warning. Might be worth
> making the use-after-free explicit, e.g.:
>
> A same-domain replace would skip the driver callback that flushes
> pending faults - this is a use-after-free hazard: a fault still holding
> the old handle could dereference it after the caller frees it.
OK. I will respin a v3.
Nicolin
prev parent reply other threads:[~2026-11-03 17:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-02 7:04 [PATCH v2 0/5] iommu: Fix attach handle publication ordering Nicolin Chen
2026-11-02 7:04 ` [PATCH v2 1/5] iommu: Unpublish the attach handle before the group detach callback Nicolin Chen
2026-11-02 7:04 ` [PATCH v2 2/5] iommu: Unpublish the attach handle before the PASID " Nicolin Chen
2026-11-02 7:04 ` [PATCH v2 3/5] iommu: Unpublish the old attach handle before the group replace callback Nicolin Chen
2026-11-02 7:04 ` [PATCH v2 4/5] iommu: Unpublish the old attach handle before the PASID " Nicolin Chen
2026-11-02 7:04 ` [PATCH v2 5/5] iommu: Reject a same-domain replace in the attach handle APIs Nicolin Chen
2026-11-03 11:59 ` Yi Liu
2026-11-03 17:37 ` Nicolin Chen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=auob0IV+h0aiW8u2@nvidia.com \
--to=nicolinc@nvidia.com \
--cc=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=jpb@kernel.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
--cc=yi.l.liu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.