lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 7 Feb 2024 10:56:56 -0400
From: Jason Gunthorpe <jgg@...pe.ca>
To: Nikhil V <quic_nprakash@...cinc.com>
Cc: Will Deacon <will@...nel.org>, Joerg Roedel <joro@...tes.org>,
	Robin Murphy <robin.murphy@....com>,
	Charan Teja Kalla <quic_charante@...cinc.com>,
	iommu@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] iommu: Avoid races around default domain allocations

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.

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ