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 > 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. >> Thanks already! If the change for older series needs some additional >> testing we might ask the affected users from the Debian bug 1022126 to >> test on 5.10.y as well. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page.
