public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Yi Liu <yi.l.liu@intel.com>
Cc: kevin.tian@intel.com, iommu@lists.linux.dev, nicolinc@nvidia.com,
	joro@8bytes.org, baolu.lu@linux.intel.com,
	stable@vger.kernel.org
Subject: Re: [PATCH v2] iommufd: Fail replace if device has not been attached
Date: Fri, 7 Mar 2025 17:08:15 -0400	[thread overview]
Message-ID: <20250307210815.GW354511@nvidia.com> (raw)
In-Reply-To: <20250306034842.5950-1-yi.l.liu@intel.com>

On Wed, Mar 05, 2025 at 07:48:42PM -0800, Yi Liu wrote:
> The current implementation of iommufd_device_do_replace() implicitly
> assumes that the input device has already been attached. However, there
> is no explicit check to verify this assumption. If another device within
> the same group has been attached, the replace operation might succeed,
> but the input device itself may not have been attached yet.
> 
> As a result, the input device might not be tracked in the
> igroup->device_list, and its reserved IOVA might not be added. Despite
> this, the caller might incorrectly assume that the device has been
> successfully replaced, which could lead to unexpected behavior or errors.
> 
> To address this issue, add a check to ensure that the input device has
> been attached before proceeding with the replace operation. This check
> will help maintain the integrity of the device tracking system and prevent
> potential issues arising from incorrect assumptions about the device's
> attachment status.
> 
> Fixes: e88d4ec154a8 ("iommufd: Add iommufd_device_replace()")
> Cc: stable@vger.kernel.org
> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
> Signed-off-by: Yi Liu <yi.l.liu@intel.com>
> ---
> Change log:
> v2:
>   - Add r-b tag (Kevin)
>   - Minor tweaks. I swarpped the order of is_attach check with the
>     if (igroup->hwpt == NULL) check, hence no need to add WARN_ON.
> 
> v1: https://lore.kernel.org/linux-iommu/20250304120754.12450-1-yi.l.liu@intel.com/
> ---
>  drivers/iommu/iommufd/device.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)

Applied, I don't think I will do a -rc pull this cycle just for this
one patch, it does not seem critical but if you think otherwise let
me know

Jason

      reply	other threads:[~2025-03-07 21:08 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-06  3:48 [PATCH v2] iommufd: Fail replace if device has not been attached Yi Liu
2025-03-07 21:08 ` Jason Gunthorpe [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=20250307210815.GW354511@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=nicolinc@nvidia.com \
    --cc=stable@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox