Linux IOMMU Development
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Jason Gunthorpe <jgg@ziepe.ca>, Nikhil V <quic_nprakash@quicinc.com>
Cc: Will Deacon <will@kernel.org>, Joerg Roedel <joro@8bytes.org>,
	Charan Teja Kalla <quic_charante@quicinc.com>,
	iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] iommu: Avoid races around default domain allocations
Date: Thu, 8 Feb 2024 00:04:44 +0000	[thread overview]
Message-ID: <37ab8689-5e0d-4166-bad6-84d3c51446ca@arm.com> (raw)
In-Reply-To: <20240207145656.GJ31743@ziepe.ca>

On 2024-02-07 2:56 pm, Jason Gunthorpe wrote:
> On Wed, Feb 07, 2024 at 07:56:25PM +0530, Nikhil V wrote:
>>
>>
>> On 2/1/2024 9:53 PM, Jason Gunthorpe wrote:
>>> On Mon, Jan 29, 2024 at 01:29:12PM +0530, Nikhil V wrote:
>>>
>>>> Gentle ping to have your valuable feedback. This fix is helping us
>>>> downstream without which we see a bunch of kernel crashes.
>>>
>>> What are you expecting here? This was fixed in Linus's tree some time
>>> ago now
>>>
>>> Are you asking for the stable team to put something weird in 6.1? I
>>> don't think they generally do that?
>>>
>>> Jason
>>
>>
>> Hi @Jason,
>>
>> Considering that the issue is reported on 6.1, which is an __LTS kernel__,
>> any suggestion to fix this issue cleanly would help us a lot. Right thing
>> here would have been propagating the changes from 6.6 (like for any
>> stability issue), but considering the intrusiveness of them, is it even
>> possible?
>>
>> Just to be open about reproducibility of the issue, a bunch of them are
>> reported, both internally and by customers.
> 
> I think you need to talk to the stable maintainers not the iommu
> upstream folks. I don't well know their policy.
> 
> Frankly, I'd suggest just proposing the necessary (and tested)
> upstream patches to 6.1, however large they are, and see what Greg and
> Sasha say. This is the usual working model they have, as I understand
> it.

To be blunt, hell no. Stable is far enough from its namesake already; 
the ongoing bordering-on-ridiculous brokenness of your mainline changes 
where each "fix" keeps affecting something else is a massive NAK to 
backporting any of it, let alone 43+ patches to achieve a 2-line fix.

Nikhil, if this is truly sufficient to resolve the issues you see 
(AFAICS things end up serialised by the group mutex so probably should 
be robust enough), then I'm OK with you proposing it as a dedicated 
stable-only fix, as an "equivalent" patch per Option 3 of 
stable-kernel-rules.rst - I reckon your commit message is already pretty 
good with regards to the final point there, but I'll be happy to help 
argue the case if necessary. Just one point - is it genuinely not 
relevant to 5.15 and earlier or is it just the case that 6.1 is the 
oldest thing you're actively testing? (Apologies, I've already forgotten 
where things were that far back).

That said, I also don't think there would be any harm in applying this 
to mainline as a belt-and-braces thing either, if it helps makes a 
backport easier and Joerg doesn't mind. There's already a bunch of stuff 
I'll be cleaning up once the underlying issue behind all of this is 
properly fixed, so adding a couple more lines of code to that list is no 
big deal as far as I'm concerned.

Thanks,
Robin.

  reply	other threads:[~2024-02-08  0:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-18 10:11 [PATCH 1/1] iommu: Avoid races around default domain allocations Nikhil V
2024-01-29  7:59 ` Nikhil V
2024-02-01 16:23   ` Jason Gunthorpe
2024-02-07 14:26     ` Nikhil V
2024-02-07 14:56       ` Jason Gunthorpe
2024-02-08  0:04         ` Robin Murphy [this message]
2024-02-08  1:13           ` Jason Gunthorpe
2024-02-08  1:37             ` Robin Murphy
2024-02-08 15:17               ` Nikhil V
2024-02-08 16:09                 ` 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=37ab8689-5e0d-4166-bad6-84d3c51446ca@arm.com \
    --to=robin.murphy@arm.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_charante@quicinc.com \
    --cc=quic_nprakash@quicinc.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