All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolin Chen <nicolinc@nvidia.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: <iommu@lists.linux.dev>, Joerg Roedel <joro@8bytes.org>,
	Kevin Tian <kevin.tian@intel.com>,
	<linux-kselftest@vger.kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Shuah Khan <shuah@kernel.org>, Will Deacon <will@kernel.org>,
	Lu Baolu <baolu.lu@linux.intel.com>, <patches@lists.linux.dev>,
	<syzbot+80620e2d0d0a33b09f93@syzkaller.appspotmail.com>
Subject: Re: [PATCH 1/3] iommufd: Fix race during abort for file descriptors
Date: Wed, 17 Sep 2025 22:07:38 -0700	[thread overview]
Message-ID: <aMuTmuBKd9aU7ngO@Asurada-Nvidia> (raw)
In-Reply-To: <1-v1-02cd136829df+31-iommufd_syz_fput_jgg@nvidia.com>

On Wed, Sep 17, 2025 at 05:01:47PM -0300, Jason Gunthorpe wrote:
> Fix this by putting the core code in charge of the file lifetime, and call
> __fput_sync() during abort to ensure that release() is called before
> kfree. __fput_sync() is a bit too tricky to open code in all the object
> implementations

Mind elaborating this "too tricky"? I thought that we're supposed
to use __fput_sync(), instead of fput(), in the alloc function in
the first place?

> Cc: stable@vger.kernel.org
> Fixes: 07838f7fd529 ("iommufd: Add iommufd fault object")
> Reported-by: syzbot+80620e2d0d0a33b09f93@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/r/68c8583d.050a0220.2ff435.03a2.GAE@google.com
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>

The patch looks good to me though:

Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>

> @@ -131,10 +132,30 @@ void iommufd_object_abort(struct iommufd_ctx *ictx, struct iommufd_object *obj)
>  void iommufd_object_abort_and_destroy(struct iommufd_ctx *ictx,
>  				      struct iommufd_object *obj)
>  {
> -	if (iommufd_object_ops[obj->type].abort)
> -		iommufd_object_ops[obj->type].abort(obj);
> +	const struct iommufd_object_ops *ops = &iommufd_object_ops[obj->type];
> +
> +	if (ops->file_offset) {
> +		struct file **filep = ((void *)obj) + ops->file_offset;
> +
> +		/*
> +		 * files should hold a users refcount while the file is open and
> +		 * put it back in their release. They should hold a pointer to
> +		 * obj in their private data. Normal fput() is deferred to a

Nit: there is only one file_offset per obj, so it should be "file"
and "it/its"?

> +		 * workqueue and can get out of order with the following
> +		 * kfree(obj). Using the sync version ensures the release
> +		 * happens immediately. During abort we require the file
> +		 * refcount is one at this point - meaning the object alloc
> +		 * function cannot do anything to allow another thread to take a
> +		 * refcount prior to a guaranteed success.
> +		 */

Thanks
Nicolin

  reply	other threads:[~2025-09-18  5:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-17 20:01 [PATCH 0/3] Fix a race with fput during eventq abort Jason Gunthorpe
2025-09-17 20:01 ` [PATCH 1/3] iommufd: Fix race during abort for file descriptors Jason Gunthorpe
2025-09-18  5:07   ` Nicolin Chen [this message]
2025-09-18 14:43     ` Jason Gunthorpe
2025-09-18 12:37   ` Nirmoy Das
2025-09-19  8:16   ` Tian, Kevin
2025-09-17 20:01 ` [PATCH 2/3] iommufd: WARN if an object is aborted with an elevated refcount Jason Gunthorpe
2025-09-18  6:10   ` Nicolin Chen
2025-09-18 14:47     ` Jason Gunthorpe
2025-09-18 20:49       ` Nicolin Chen
2025-09-18 20:50   ` Nicolin Chen
2025-09-19  8:16   ` Tian, Kevin
2025-09-17 20:01 ` [PATCH 3/3] iommufd/selftest: Update the fail_nth limit Jason Gunthorpe
2025-09-18  5:28   ` Nicolin Chen
2025-09-19  8:17   ` Tian, Kevin
2025-09-18 20:52 ` [PATCH 0/3] Fix a race with fput during eventq abort Nicolin Chen
2025-09-19 13:43 ` Jason Gunthorpe

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=aMuTmuBKd9aU7ngO@Asurada-Nvidia \
    --to=nicolinc@nvidia.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=robin.murphy@arm.com \
    --cc=shuah@kernel.org \
    --cc=syzbot+80620e2d0d0a33b09f93@syzkaller.appspotmail.com \
    --cc=will@kernel.org \
    /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.