| Message ID | 20221028091655.17741-2-sreekanth.reddy@broadcom.com (mailing list archive) |
|---|---|
| State | Deferred |
| Headers | show |
| Series | mpt3sas: Remove usage of dma_get_required_mask api | expand |
On Fri, Oct 28, 2022 at 02:46:55PM +0530, Sreekanth Reddy wrote: > Remove the usage of dma_get_required_mask() API. > Directly set the DMA mask to 63/64 if the system > is a 64bit machine. > > Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Looks good: Reviewed-by: Christoph Hellwig <hch@lst.de>
On Sun, Oct 30, 2022 at 04:52:51AM -0700, Christoph Hellwig wrote: > On Fri, Oct 28, 2022 at 02:46:55PM +0530, Sreekanth Reddy wrote: > > Remove the usage of dma_get_required_mask() API. > > Directly set the DMA mask to 63/64 if the system > > is a 64bit machine. > > > > Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> > > Looks good: > > Reviewed-by: Christoph Hellwig <hch@lst.de> Btw, it seems like mpi3mr will need similar treatment.
Martin, On Sun, 2022-10-30 at 04:52 -0700, Christoph Hellwig wrote: > On Fri, Oct 28, 2022 at 02:46:55PM +0530, Sreekanth Reddy wrote: > > Remove the usage of dma_get_required_mask() API. > > Directly set the DMA mask to 63/64 if the system > > is a 64bit machine. > > > > Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> > > Looks good: > > Reviewed-by: Christoph Hellwig <hch@lst.de> is anything blocking mainline inclusion of this patch? Regards Martin W.
Martin,
> is anything blocking mainline inclusion of this patch?
I applied 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.
Hi, On Mon, Jan 02, 2023 at 08:06:41AM -0500, Martin K. Petersen wrote: > > Martin, > > > is anything blocking mainline inclusion of this patch? > > I applied 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@mail.gmail.com/ . Regards, Salvatore
Hi, On Tue, Jan 24, 2023 at 10:37:23AM +0100, Salvatore Bonaccorso wrote: > Hi, > > On Mon, Jan 02, 2023 at 08:06:41AM -0500, Martin K. Petersen wrote: > > > > Martin, > > > > > is anything blocking mainline inclusion of this patch? > > > > I applied 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@mail.gmail.com/ > . 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). 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. Regards, Salvatore
Hi, this is your Linux kernel regression tracker. 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 appCiao, 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.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@mail.gmail.com/ >> . > > 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, 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. > 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.
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@mail.gmail.com/ >> >> 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.
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@mail.gmail.com/ > >> > >> 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
Thorsten, > 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: This had me confused, the above SHA is incorrect. It's: e0e0747de0ea ("scsi: mpt3sas: Fix return value check of dma_get_required_mask()") > 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? There are three recent commit in this area. e0e0747de0ea was accidentally reverted by Linus during a merge and reinstated as 1a2dcbdde82e. So unless I'm missing something, the appropriate thing would be to backport these three commits: 9df650963bf6 ("scsi: mpt3sas: Don't change DMA mask while reallocating pools") 1a2dcbdde82e ("scsi: mpt3sas: re-do lost mpt3sas DMA mask fix") 06e472acf964 ("scsi: mpt3sas: Remove usage of dma_get_required_mask() API")
On Mon, 2023-03-06 at 20:39 -0500, Martin K. Petersen wrote: > > There are three recent commit in this area. e0e0747de0ea was > accidentally reverted by Linus during a merge and reinstated as > 1a2dcbdde82e. So unless I'm missing something, the appropriate thing > would be to backport these three commits: > > 9df650963bf6 ("scsi: mpt3sas: Don't change DMA mask while > reallocating pools") > 1a2dcbdde82e ("scsi: mpt3sas: re-do lost mpt3sas DMA mask fix") > 06e472acf964 ("scsi: mpt3sas: Remove usage of dma_get_required_mask() > API") > I used the same sequence of backports for the SUSE kernel. Regards Martin
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c b/drivers/scsi/mpt3sas/mpt3sas_base.c index 4e981ccaac41..69061545d9d2 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_base.c +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c @@ -2992,8 +2992,7 @@ _base_config_dma_addressing(struct MPT3SAS_ADAPTER *ioc, struct pci_dev *pdev) struct sysinfo s; u64 coherent_dma_mask, dma_mask; - if (ioc->is_mcpu_endpoint || sizeof(dma_addr_t) == 4 || - dma_get_required_mask(&pdev->dev) <= DMA_BIT_MASK(32)) { + if (ioc->is_mcpu_endpoint || sizeof(dma_addr_t) == 4) { ioc->dma_mask = 32; coherent_dma_mask = dma_mask = DMA_BIT_MASK(32); /* Set 63 bit DMA mask for all SAS3 and SAS35 controllers */
Remove the usage of dma_get_required_mask() API. Directly set the DMA mask to 63/64 if the system is a 64bit machine. Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> --- drivers/scsi/mpt3sas/mpt3sas_base.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)