Re: [PATCH] scsi: eata: drop VLA in reorder()
On Sun, Mar 11, 2018 at 8:08 PM, Tobin C. Harding <tobin@apporbit.com> wrote:
I think we are going to see a recurring theme here. MAX_MAILBOXES==64 so this patch adds 1536 bytes to the stack on a 64 bit machine or 768 bytes on a 32 bit machine.
Yeah, that's a bit excessive. It probably works, but one or two of those allocations will make the kernel stack really tight, so in general I really would suggest using kmalloc() instead, or figuring out some way to simply shrink the data structures. That said, I wonder if the solution to this particular driver is "delete it". Because the hardware is truly ancient and nobody sane would use it any more. The last patch that seemed to come from an actual _user_ finding a problem was in 2008 (commit 20c09df7eb9c: "[SCSI] eata: fix the data buffer accessors conversion regression"). And even then it apparently took a year for people to have noticed the breakage. But because the person who reported that problem is still around, I'll just add him to the cc, just in case. Arthur Marsh, you have the dubious honor and distinction of being the only person to have apparently used that driver in the last ten years. Do you still have hardware using that? Because maybe it's really time to retire that driver. Linus
Linus Torvalds wrote on 13/03/18 05:15:
On Sun, Mar 11, 2018 at 8:08 PM, Tobin C. Harding <tobin@apporbit.com> wrote:
I think we are going to see a recurring theme here. MAX_MAILBOXES==64 so this patch adds 1536 bytes to the stack on a 64 bit machine or 768 bytes on a 32 bit machine.
Yeah, that's a bit excessive. It probably works, but one or two of those allocations will make the kernel stack really tight, so in general I really would suggest using kmalloc() instead, or figuring out some way to simply shrink the data structures.
That said, I wonder if the solution to this particular driver is "delete it". Because the hardware is truly ancient and nobody sane would use it any more.
The last patch that seemed to come from an actual _user_ finding a problem was in 2008 (commit 20c09df7eb9c: "[SCSI] eata: fix the data buffer accessors conversion regression"). And even then it apparently took a year for people to have noticed the breakage.
But because the person who reported that problem is still around, I'll just add him to the cc, just in case.
Arthur Marsh, you have the dubious honor and distinction of being the only person to have apparently used that driver in the last ten years. Do you still have hardware using that? Because maybe it's really time to retire that driver.
Linus
Hi Linus and maintainers, thanks for the courtesy email and all the help with the driver. I am unable to make use of the driver any more due to failed hardware. The DPT2044W SCSI controller and the IBM disk from May 1998 last officially ran on 7 August 2017. I was had previously been able to get the data off it and disconnected the controller and disk following recurring problems with booting. Aug 7 16:40:24 localhost kernel: [ 105.098705] sd 0:0:6:0: [sda] Synchronizing SCSI cache Aug 7 16:40:24 localhost kernel: [ 105.233166] EATA0: IRQ 11 mapped to IO-APIC IRQ 18. Aug 7 16:40:24 localhost kernel: [ 105.233475] EATA/DMA 2.0x: Copyright (C) 1994-2003 Dario Ballabio. Aug 7 16:40:24 localhost kernel: [ 105.233485] EATA config options -> tm:1, lc:y, mq:16, rs:y, et:n, ip:n, ep:n, pp:y. Aug 7 16:40:24 localhost kernel: [ 105.233492] EATA0: 2.0C, PCI 0x9010, IRQ 18, BMST, SG 122, MB 64. Aug 7 16:40:24 localhost kernel: [ 105.233499] EATA0: wide SCSI support enabled, max_id 16, max_lun 8. Aug 7 16:40:24 localhost kernel: [ 105.233505] EATA0: SCSI channel 0 enabled, host target ID 7. Aug 7 16:40:24 localhost kernel: [ 105.233521] scsi host0: EATA/DMA 2.0x rev. 8.10.00 Arthur Marsh.
Linus,
That said, I wonder if the solution to this particular driver is "delete it". Because the hardware is truly ancient and nobody sane would use it any more.
I'm not aware of anybody actively using these anymore. They are mid-nineties vintage with an M68K processor onboard. I ran a couple of these when they were new but haven't had a working board in probably a decade. No objections to Salvatore's patch but I have a slight affinity for retiring unused code over patching it. So unless there are objections... -- Martin K. Petersen Oracle Linux Engineering
On Mon, Mar 12, 2018 at 10:35:36PM -0400, Martin K. Petersen wrote:
No objections to Salvatore's patch but I have a slight affinity for retiring unused code over patching it. So unless there are objections...
Lets kill it. And the not DMA capable eata_pio driver with it for good riddance.
-- Martin K. Petersen Oracle Linux Engineering
---end quoted text---
2018-03-13 10:05 GMT+01:00 Christoph Hellwig <hch@infradead.org>:
On Mon, Mar 12, 2018 at 10:35:36PM -0400, Martin K. Petersen wrote:
No objections to Salvatore's patch but I have a slight affinity for retiring unused code over patching it. So unless there are objections...
Lets kill it. And the not DMA capable eata_pio driver with it for good riddance.
Good, I'll send a patch to remove eata & friends. Thank you for your time, Salvatore
participants (5)
-
Arthur Marsh -
Christoph Hellwig -
Linus Torvalds -
Martin K. Petersen -
Salvatore Mesoraca