public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: joro@8bytes.org, will@kernel.org, iommu@lists.linux.dev,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	rafael@kernel.org, lenb@kernel.org, lpieralisi@kernel.org,
	andre.draszik@linaro.org, quic_zhenhuah@quicinc.com
Subject: Re: [PATCH] iommu: Avoid more races around device probe
Date: Thu, 16 Nov 2023 13:05:58 -0400	[thread overview]
Message-ID: <ZVZL9kZuVsb9VPnM@nvidia.com> (raw)
In-Reply-To: <16f433658661d7cadfea51e7c65da95826112a2b.1700071477.git.robin.murphy@arm.com>

On Wed, Nov 15, 2023 at 06:25:44PM +0000, Robin Murphy wrote:
> It turns out there are more subtle races beyond just the main part of
> __iommu_probe_device() itself running in parallel - the dev_iommu_free()
> on the way out of an unsuccessful probe can still manage to trip up
> concurrent accesses to a device's fwspec. Thus, extend the scope of
> iommu_probe_device_lock() to also serialise fwspec creation and initial
> retrieval.
> 
> Reported-by: Zhenhua Huang <quic_zhenhuah@quicinc.com>
> Link: https://lore.kernel.org/linux-iommu/e2e20e1c-6450-4ac5-9804-b0000acdf7de@quicinc.com/
> Fixes: 01657bc14a39 ("iommu: Avoid races around device probe")
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> 
> This is my idea of a viable fix, since it does not need a 700-line
> diffstat to make the code do what it was already *trying* to do anyway.
> This stuff should fundamentally not be hanging off driver probe in the
> first place, so I'd rather get on with removing the underlying
> brokenness than waste time and effort polishing it any further.

I'm fine with this as some hacky backport, but I don't want to see
this cross-layer leakage left in the next merge window.

ie we should still do my other series on top of and reverting this.

I've poked at moving parts of it under probe and I think we can do
substantial amounts in about two more series and a tidy a bunch of
other stuff too.

Jason

  reply	other threads:[~2023-11-16 17:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-15 18:25 [PATCH] iommu: Avoid more races around device probe Robin Murphy
2023-11-16 17:05 ` Jason Gunthorpe [this message]
2023-11-22 14:44   ` Greg KH
2023-11-22 19:22     ` Jason Gunthorpe
2023-11-27  9:57   ` Joerg Roedel
2023-11-20 11:26 ` André Draszik
2023-11-24 15:35 ` 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=ZVZL9kZuVsb9VPnM@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=andre.draszik@linaro.org \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=quic_zhenhuah@quicinc.com \
    --cc=rafael@kernel.org \
    --cc=robin.murphy@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox