Re: [PATCH 1/1] mpt3sas: Remove usage of dma_get_required_mask api

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thorsten, thanks for you time!

On Fri, Mar 03, 2023 at 10:39:32AM +0100, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 27.02.23 15:07, Thorsten Leemhuis wrote:
> > On 22.02.23 17:44, Salvatore Bonaccorso wrote:
> >> On Tue, Jan 24, 2023 at 10:37:23AM +0100, Salvatore Bonaccorso wrote:
> >>> On Mon, Jan 02, 2023 at 08:06:41AM -0500, Martin K. Petersen wrote:
> >>>>> is anything blocking mainline inclusion of this patch?
> >>>> I app
> 
> [removing a footer from the quoting here, that accidentally was added
> here in my previous mail; sorry!]
> 
> >>>> lied these to 6.2/scsi-fixes last week. The patches have been
> >>>> sitting in a topic branch for a bit due to the three-way conflict
> >>>> between fixes, queue, and upstream.
> >>>
> >>> It landed in 6.2-rc4 recently in fact. Thank you!
> >>>
> >>> Would it be posssible to backport the fix as well back to the stable
> >>> series affected? 
> >>>
> >>> In Debian we have the reports as per https://bugs.debian.org/1022126
> >>> where the issue was introduced back in 5.10.y. Context in
> >>> https://lore.kernel.org/linux-scsi/CAK=zhgr=MYn=-mrz3gKUFoXG_+EQ796bHEWSdK88o1Aqamby7g@xxxxxxxxxxxxxx/
> >>
> >> Friendly ping on this, can this change be backported as well to the
> >> relevant stable series? It would apply already cleanly to 6.1.y, but
> >> due to 9df650963bf6 ("scsi: mpt3sas: Don't change DMA mask while
> >> reallocating pools") it might need some additional review for the
> >> older stable series (in particular of interest due to the above for
> >> 5.10.y).
> > 
> > This afaics is a reasonable request for 6.1, as this seems to be
> > (Salvatore, please correct me if I'm wrong) a regression caused by
> > 0e0747de0ea3 ("scsi: mpt3sas: Fix return value check of
> > dma_get_required_mask()"), which was merged for 6.0-rc7. Hence allow me
> > to ask:
> > 
> > Sreekanth and Martin, is there a reason why this request (and the
> > earlier one a month ago) was apparently met with silence? Or was
> > progress made in between and I just missed it?
> 
> Salvatore, seems my inquiry didn't help. I'd suggest you ask the stable
> maintainers yourself to pick this up for 6.1.y. See "Option 2" in
> 
> 
> https://docs.kernel.org/process/stable-kernel-rules.html

Yes as a start this will help to get it in 6.1 where it should apply
cleanly, thank you. I will do that next.

> 
> > Salvatore, for 5.10 things are a bit more complicated, as someone would
> > need to do the work. Sometimes that work is done by the driver
> > developers and maintainers as well, but strictly speaking it's the duty
> > of those that backported the change to 5.10.y. Didn't check who did that
> > this case (the stable team?); but well, maybe let's sort this out for
> > 6.1.y first.
> 
> Option 3 mentioned on above page might work for you here.

That might be an option yes. And the fix really neeeds to go back to
5.10.y at least as people are experiencing regressions from it (see
the Debian bugs). Help and confirmation from the affected people would
be welcome, but did not happened so far.

Thorsten, thanks for your work on the regression trackings!

Regards,
Salvatore



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux