Message ID | 20180522181512.39316-4-keescook@chromium.org |
---|---|
State | Not Applicable |
Delegated to: | David Miller |
Headers | show |
Series | block: Consolidate scsi sense buffer usage | expand |
On Tue, May 22, 2018 at 11:15:09AM -0700, Kees Cook wrote: > Both SCSI and ATAPI share the sense header. In preparation for using the > struct scsi_sense_hdr more widely, move this into a separate header and > move the helper function to scsi_ioctl.c which is linked with CONFIG_IDE > by way of CONFIG_BLK_SCSI_REQUEST. Please keep the code where it is and just depend on SCSI on the legacy ide driver. No need to do gymnastics just for a legacy case. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Christoph, > On Tue, May 22, 2018 at 11:15:09AM -0700, Kees Cook wrote: >> Both SCSI and ATAPI share the sense header. In preparation for using the >> struct scsi_sense_hdr more widely, move this into a separate header and >> move the helper function to scsi_ioctl.c which is linked with CONFIG_IDE >> by way of CONFIG_BLK_SCSI_REQUEST. > > Please keep the code where it is and just depend on SCSI on the legacy > ide driver. No need to do gymnastics just for a legacy case. Yup, I agree.
On Tue, May 22, 2018 at 11:50 AM, Martin K. Petersen <martin.petersen@oracle.com> wrote: > > Christoph, > >> On Tue, May 22, 2018 at 11:15:09AM -0700, Kees Cook wrote: >>> Both SCSI and ATAPI share the sense header. In preparation for using the >>> struct scsi_sense_hdr more widely, move this into a separate header and >>> move the helper function to scsi_ioctl.c which is linked with CONFIG_IDE >>> by way of CONFIG_BLK_SCSI_REQUEST. >> >> Please keep the code where it is and just depend on SCSI on the legacy >> ide driver. No need to do gymnastics just for a legacy case. > > Yup, I agree. Oh, er, this was mainly done at Jens's request. Jens, can you advise? -Kees
On 5/22/18 12:59 PM, Kees Cook wrote: > On Tue, May 22, 2018 at 11:50 AM, Martin K. Petersen > <martin.petersen@oracle.com> wrote: >> >> Christoph, >> >>> On Tue, May 22, 2018 at 11:15:09AM -0700, Kees Cook wrote: >>>> Both SCSI and ATAPI share the sense header. In preparation for using the >>>> struct scsi_sense_hdr more widely, move this into a separate header and >>>> move the helper function to scsi_ioctl.c which is linked with CONFIG_IDE >>>> by way of CONFIG_BLK_SCSI_REQUEST. >>> >>> Please keep the code where it is and just depend on SCSI on the legacy >>> ide driver. No need to do gymnastics just for a legacy case. >> >> Yup, I agree. > > Oh, er, this was mainly done at Jens's request. Jens, can you advise? I think Martin and Christoph are objecting to moving the code to block/scsi_ioctl.h. I don't care too much about where the code is, but think it would be nice to have the definitions in a separate header. But if they prefer just pulling in all of SCSI for it, well then I guess it's pointless to move the header bits. Seems very heavy handed to me, though.
On Tue, May 22, 2018 at 01:09:41PM -0600, Jens Axboe wrote: > I think Martin and Christoph are objecting to moving the code to > block/scsi_ioctl.h. I don't care too much about where the code is, but > think it would be nice to have the definitions in a separate header. But > if they prefer just pulling in all of SCSI for it, well then I guess > it's pointless to move the header bits. Seems very heavy handed to me, > though. It might be heavy handed for the 3 remaining users of drivers/ide, but as long as that stuff just keeps working I'd rather worry about everyone else, and keep the scsi code where it belongs. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 5/22/18 1:13 PM, Christoph Hellwig wrote: > On Tue, May 22, 2018 at 01:09:41PM -0600, Jens Axboe wrote: >> I think Martin and Christoph are objecting to moving the code to >> block/scsi_ioctl.h. I don't care too much about where the code is, but >> think it would be nice to have the definitions in a separate header. But >> if they prefer just pulling in all of SCSI for it, well then I guess >> it's pointless to move the header bits. Seems very heavy handed to me, >> though. > > It might be heavy handed for the 3 remaining users of drivers/ide, Brutal :-) > but as long as that stuff just keeps working I'd rather worry about > everyone else, and keep the scsi code where it belongs. Fine with me then, hopefully we can some day kill it off.
On Tue, May 22, 2018 at 12:16 PM, Jens Axboe <axboe@kernel.dk> wrote: > On 5/22/18 1:13 PM, Christoph Hellwig wrote: >> On Tue, May 22, 2018 at 01:09:41PM -0600, Jens Axboe wrote: >>> I think Martin and Christoph are objecting to moving the code to >>> block/scsi_ioctl.h. I don't care too much about where the code is, but >>> think it would be nice to have the definitions in a separate header. But >>> if they prefer just pulling in all of SCSI for it, well then I guess >>> it's pointless to move the header bits. Seems very heavy handed to me, >>> though. >> >> It might be heavy handed for the 3 remaining users of drivers/ide, > > Brutal :-) Heh. I noticed a similar sense buffer use in drivers/cdrom/cdrom.c too. Is this okay under the same considerations? diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig index ad9b687a236a..220ff321c102 100644 --- a/drivers/block/Kconfig +++ b/drivers/block/Kconfig @@ -79,7 +79,7 @@ config GDROM tristate "SEGA Dreamcast GD-ROM drive" depends on SH_DREAMCAST select CDROM - select BLK_SCSI_REQUEST # only for the generic cdrom code + select SCSI help A standard SEGA Dreamcast comes with a modified CD ROM drive called a "GD-ROM" by SEGA to signify it is capable of reading special disks @@ -345,7 +345,7 @@ config CDROM_PKTCDVD tristate "Packet writing on CD/DVD media (DEPRECATED)" depends on !UML select CDROM - select BLK_SCSI_REQUEST + select SCSI help Note: This driver is deprecated and will be removed from the kernel in the near future! diff --git a/drivers/block/paride/Kconfig b/drivers/block/paride/Kconfig index f8bd6ef3605a..7fdfcc5eaca5 100644 --- a/drivers/block/paride/Kconfig +++ b/drivers/block/paride/Kconfig @@ -27,7 +27,7 @@ config PARIDE_PCD tristate "Parallel port ATAPI CD-ROMs" depends on PARIDE select CDROM - select BLK_SCSI_REQUEST # only for the generic cdrom code + select SCSI ---help--- This option enables the high-level driver for ATAPI CD-ROM devices connected through a parallel port. If you chose to build PARIDE >> but as long as that stuff just keeps working I'd rather worry about >> everyone else, and keep the scsi code where it belongs. > > Fine with me then, hopefully we can some day kill it off. I'll send a v2. I found a few other things to fix up (including the cdrom.c one). Thanks! -Kees
On 05/22/2018 04:31 PM, Kees Cook wrote: > On Tue, May 22, 2018 at 12:16 PM, Jens Axboe <axboe@kernel.dk> wrote: >> On 5/22/18 1:13 PM, Christoph Hellwig wrote: >>> On Tue, May 22, 2018 at 01:09:41PM -0600, Jens Axboe wrote: >>>> I think Martin and Christoph are objecting to moving the code to >>>> block/scsi_ioctl.h. I don't care too much about where the code is, but >>>> think it would be nice to have the definitions in a separate header. But >>>> if they prefer just pulling in all of SCSI for it, well then I guess >>>> it's pointless to move the header bits. Seems very heavy handed to me, >>>> though. >>> >>> It might be heavy handed for the 3 remaining users of drivers/ide, >> >> Brutal :-) > > Heh. I noticed a similar sense buffer use in drivers/cdrom/cdrom.c > too. Is this okay under the same considerations? No. Do not select an entire subsystem. Use depends on it instead. > diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig > index ad9b687a236a..220ff321c102 100644 > --- a/drivers/block/Kconfig > +++ b/drivers/block/Kconfig > @@ -79,7 +79,7 @@ config GDROM > tristate "SEGA Dreamcast GD-ROM drive" > depends on SH_DREAMCAST > select CDROM > - select BLK_SCSI_REQUEST # only for the generic cdrom code > + select SCSI > help > A standard SEGA Dreamcast comes with a modified CD ROM drive called a > "GD-ROM" by SEGA to signify it is capable of reading special disks > @@ -345,7 +345,7 @@ config CDROM_PKTCDVD > tristate "Packet writing on CD/DVD media (DEPRECATED)" > depends on !UML > select CDROM > - select BLK_SCSI_REQUEST > + select SCSI > help > Note: This driver is deprecated and will be removed from the > kernel in the near future! > diff --git a/drivers/block/paride/Kconfig b/drivers/block/paride/Kconfig > index f8bd6ef3605a..7fdfcc5eaca5 100644 > --- a/drivers/block/paride/Kconfig > +++ b/drivers/block/paride/Kconfig > @@ -27,7 +27,7 @@ config PARIDE_PCD > tristate "Parallel port ATAPI CD-ROMs" > depends on PARIDE > select CDROM > - select BLK_SCSI_REQUEST # only for the generic cdrom code > + select SCSI > ---help--- > This option enables the high-level driver for ATAPI CD-ROM devices > connected through a parallel port. If you chose to build PARIDE > >>> but as long as that stuff just keeps working I'd rather worry about >>> everyone else, and keep the scsi code where it belongs. >> >> Fine with me then, hopefully we can some day kill it off. > > I'll send a v2. I found a few other things to fix up (including the > cdrom.c one).
On Tue, May 22, 2018 at 4:34 PM, Randy Dunlap <rdunlap@infradead.org> wrote: > On 05/22/2018 04:31 PM, Kees Cook wrote: >> On Tue, May 22, 2018 at 12:16 PM, Jens Axboe <axboe@kernel.dk> wrote: >>> On 5/22/18 1:13 PM, Christoph Hellwig wrote: >>>> On Tue, May 22, 2018 at 01:09:41PM -0600, Jens Axboe wrote: >>>>> I think Martin and Christoph are objecting to moving the code to >>>>> block/scsi_ioctl.h. I don't care too much about where the code is, but >>>>> think it would be nice to have the definitions in a separate header. But >>>>> if they prefer just pulling in all of SCSI for it, well then I guess >>>>> it's pointless to move the header bits. Seems very heavy handed to me, >>>>> though. >>>> >>>> It might be heavy handed for the 3 remaining users of drivers/ide, >>> >>> Brutal :-) >> >> Heh. I noticed a similar sense buffer use in drivers/cdrom/cdrom.c >> too. Is this okay under the same considerations? > > No. Do not select an entire subsystem. Use depends on it instead. I looked at that first, but it seems it's designed for that. For example, "config ATA" already has a "select SCSI". It does look fishy, though, since "config SCSI" has a "depends" which would be ignored by "select". Luckily, all these uses already do a "depends on BLOCK" (directly or indirectly). -Kees
On 05/22/2018 04:39 PM, Kees Cook wrote: > On Tue, May 22, 2018 at 4:34 PM, Randy Dunlap <rdunlap@infradead.org> wrote: >> On 05/22/2018 04:31 PM, Kees Cook wrote: >>> On Tue, May 22, 2018 at 12:16 PM, Jens Axboe <axboe@kernel.dk> wrote: >>>> On 5/22/18 1:13 PM, Christoph Hellwig wrote: >>>>> On Tue, May 22, 2018 at 01:09:41PM -0600, Jens Axboe wrote: >>>>>> I think Martin and Christoph are objecting to moving the code to >>>>>> block/scsi_ioctl.h. I don't care too much about where the code is, but >>>>>> think it would be nice to have the definitions in a separate header. But >>>>>> if they prefer just pulling in all of SCSI for it, well then I guess >>>>>> it's pointless to move the header bits. Seems very heavy handed to me, >>>>>> though. >>>>> >>>>> It might be heavy handed for the 3 remaining users of drivers/ide, >>>> >>>> Brutal :-) >>> >>> Heh. I noticed a similar sense buffer use in drivers/cdrom/cdrom.c >>> too. Is this okay under the same considerations? >> >> No. Do not select an entire subsystem. Use depends on it instead. > > I looked at that first, but it seems it's designed for that. For > example, "config ATA" already has a "select SCSI". > > It does look fishy, though, since "config SCSI" has a "depends" which > would be ignored by "select". Luckily, all these uses already do a > "depends on BLOCK" (directly or indirectly). Linus has railed against selecting subsystems. We shouldn't be adding more IMHO, although it is difficult to get rid of ones that we already have.
On May 22, 2018, at 5:31 PM, Kees Cook <keescook@chromium.org> wrote: > >> On Tue, May 22, 2018 at 12:16 PM, Jens Axboe <axboe@kernel.dk> wrote: >>> On 5/22/18 1:13 PM, Christoph Hellwig wrote: >>>> On Tue, May 22, 2018 at 01:09:41PM -0600, Jens Axboe wrote: >>>> I think Martin and Christoph are objecting to moving the code to >>>> block/scsi_ioctl.h. I don't care too much about where the code is, but >>>> think it would be nice to have the definitions in a separate header. But >>>> if they prefer just pulling in all of SCSI for it, well then I guess >>>> it's pointless to move the header bits. Seems very heavy handed to me, >>>> though. >>> >>> It might be heavy handed for the 3 remaining users of drivers/ide, >> >> Brutal :-) > > Heh. I noticed a similar sense buffer use in drivers/cdrom/cdrom.c > too. Is this okay under the same considerations? This is going from somewhat crazy to pretty nuts, imho. I guess in practical terms it doesn’t matter that much, since most folks would be using sr. I still think a split would be vastly superior. Just keep the scsi code in drivers/scsi/ and make it independently selectable. Jens -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, May 22, 2018 at 4:42 PM, Jens Axboe <axboe@kernel.dk> wrote: > On May 22, 2018, at 5:31 PM, Kees Cook <keescook@chromium.org> wrote: >> >>> On Tue, May 22, 2018 at 12:16 PM, Jens Axboe <axboe@kernel.dk> wrote: >>>> On 5/22/18 1:13 PM, Christoph Hellwig wrote: >>>>> On Tue, May 22, 2018 at 01:09:41PM -0600, Jens Axboe wrote: >>>>> I think Martin and Christoph are objecting to moving the code to >>>>> block/scsi_ioctl.h. I don't care too much about where the code is, but >>>>> think it would be nice to have the definitions in a separate header. But >>>>> if they prefer just pulling in all of SCSI for it, well then I guess >>>>> it's pointless to move the header bits. Seems very heavy handed to me, >>>>> though. >>>> >>>> It might be heavy handed for the 3 remaining users of drivers/ide, >>> >>> Brutal :-) >> >> Heh. I noticed a similar sense buffer use in drivers/cdrom/cdrom.c >> too. Is this okay under the same considerations? > > This is going from somewhat crazy to pretty nuts, imho. I guess in practical terms it doesn’t matter that much, since most folks would be using sr. I still think a split would be vastly superior. Just keep the scsi code in drivers/scsi/ and make it independently selectable. I had originally tied it to BLK_SCSI_REQUEST. Logically speaking, sense buffers are part of the request, and the CONFIG work is already done. This is roughly what I tried to do before, since scsi_ioctl.c is the only code pulled in for CONFIG_BLK_SCSI_REQUEST: $ git grep BLK_SCSI_REQUEST | grep Makefile block/Makefile:obj-$(CONFIG_BLK_SCSI_REQUEST) += scsi_ioctl.o Should I move to code to a new drivers/scsi/scsi_sense.c and add it to drivers/scsi/Makefile as: obj-$(CONFIG_BLK_SCSI_REQUEST) += scsi_sense.o Every place I want to use the code is already covered by CONFIG_BLK_SCSI_REQUEST, so it seems like I just need to know where to put the .c file. :P -Kees
On 5/22/18 5:49 PM, Kees Cook wrote: > On Tue, May 22, 2018 at 4:42 PM, Jens Axboe <axboe@kernel.dk> wrote: >> On May 22, 2018, at 5:31 PM, Kees Cook <keescook@chromium.org> wrote: >>> >>>> On Tue, May 22, 2018 at 12:16 PM, Jens Axboe <axboe@kernel.dk> wrote: >>>>> On 5/22/18 1:13 PM, Christoph Hellwig wrote: >>>>>> On Tue, May 22, 2018 at 01:09:41PM -0600, Jens Axboe wrote: >>>>>> I think Martin and Christoph are objecting to moving the code to >>>>>> block/scsi_ioctl.h. I don't care too much about where the code is, but >>>>>> think it would be nice to have the definitions in a separate header. But >>>>>> if they prefer just pulling in all of SCSI for it, well then I guess >>>>>> it's pointless to move the header bits. Seems very heavy handed to me, >>>>>> though. >>>>> >>>>> It might be heavy handed for the 3 remaining users of drivers/ide, >>>> >>>> Brutal :-) >>> >>> Heh. I noticed a similar sense buffer use in drivers/cdrom/cdrom.c >>> too. Is this okay under the same considerations? >> >> This is going from somewhat crazy to pretty nuts, imho. I guess in practical terms it doesn’t matter that much, since most folks would be using sr. I still think a split would be vastly superior. Just keep the scsi code in drivers/scsi/ and make it independently selectable. > > I had originally tied it to BLK_SCSI_REQUEST. Logically speaking, > sense buffers are part of the request, and the CONFIG work is already > done. This is roughly what I tried to do before, since scsi_ioctl.c is > the only code pulled in for CONFIG_BLK_SCSI_REQUEST: > > $ git grep BLK_SCSI_REQUEST | grep Makefile > block/Makefile:obj-$(CONFIG_BLK_SCSI_REQUEST) += scsi_ioctl.o > > Should I move to code to a new drivers/scsi/scsi_sense.c and add it to > drivers/scsi/Makefile as: > > obj-$(CONFIG_BLK_SCSI_REQUEST) += scsi_sense.o > > Every place I want to use the code is already covered by > CONFIG_BLK_SCSI_REQUEST, so it seems like I just need to know where to > put the .c file. :P I think this is so much saner than a SCSI select or dependency, so I'll have to disagree with Martin and Christoph. Just put it in drivers/scsi, if it's the location they care about.
On Wed, May 23, 2018 at 08:13:56AM -0600, Jens Axboe wrote: > > Should I move to code to a new drivers/scsi/scsi_sense.c and add it to > > drivers/scsi/Makefile as: > > > > obj-$(CONFIG_BLK_SCSI_REQUEST) += scsi_sense.o > > > > Every place I want to use the code is already covered by > > CONFIG_BLK_SCSI_REQUEST, so it seems like I just need to know where to > > put the .c file. :P > > I think this is so much saner than a SCSI select or dependency, so I'll > have to disagree with Martin and Christoph. Just put it in drivers/scsi, > if it's the location they care about. I actually plan to remove CONFIG_BLK_SCSI_REQUEST in a merge window or two. The only users are scsi and the ide layer, (virtio_blk support has already been accidentally disabled for a while), and getting rid of it allows to to shrink and simply the scsi data structures. But if you want this for now lets keep scsi_sense.c in drivers/scsi but depend on CONFIG_BLK_SCSI_REQUEST, that is easy enough to fix up. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 5/23/18 8:25 AM, Christoph Hellwig wrote: > On Wed, May 23, 2018 at 08:13:56AM -0600, Jens Axboe wrote: >>> Should I move to code to a new drivers/scsi/scsi_sense.c and add it to >>> drivers/scsi/Makefile as: >>> >>> obj-$(CONFIG_BLK_SCSI_REQUEST) += scsi_sense.o >>> >>> Every place I want to use the code is already covered by >>> CONFIG_BLK_SCSI_REQUEST, so it seems like I just need to know where to >>> put the .c file. :P >> >> I think this is so much saner than a SCSI select or dependency, so I'll >> have to disagree with Martin and Christoph. Just put it in drivers/scsi, >> if it's the location they care about. > > I actually plan to remove CONFIG_BLK_SCSI_REQUEST in a merge window > or two. The only users are scsi and the ide layer, (virtio_blk > support has already been accidentally disabled for a while), and getting > rid of it allows to to shrink and simply the scsi data structures. > > But if you want this for now lets keep scsi_sense.c in drivers/scsi > but depend on CONFIG_BLK_SCSI_REQUEST, that is easy enough to fix up. It could be a stand-alone dependency, doesn't have to be BLK_SCSI_REQUEST. BLA_SCSI_SENSE or something would do. I don't care too much about that, mostly getting rid of the entire stack dependency.
On Wed, May 23, 2018 at 7:31 AM, Jens Axboe <axboe@kernel.dk> wrote: > On 5/23/18 8:25 AM, Christoph Hellwig wrote: >> On Wed, May 23, 2018 at 08:13:56AM -0600, Jens Axboe wrote: >>>> Should I move to code to a new drivers/scsi/scsi_sense.c and add it to >>>> drivers/scsi/Makefile as: >>>> >>>> obj-$(CONFIG_BLK_SCSI_REQUEST) += scsi_sense.o >>>> >>>> Every place I want to use the code is already covered by >>>> CONFIG_BLK_SCSI_REQUEST, so it seems like I just need to know where to >>>> put the .c file. :P >>> >>> I think this is so much saner than a SCSI select or dependency, so I'll >>> have to disagree with Martin and Christoph. Just put it in drivers/scsi, >>> if it's the location they care about. >> >> I actually plan to remove CONFIG_BLK_SCSI_REQUEST in a merge window >> or two. The only users are scsi and the ide layer, (virtio_blk >> support has already been accidentally disabled for a while), and getting >> rid of it allows to to shrink and simply the scsi data structures. >> >> But if you want this for now lets keep scsi_sense.c in drivers/scsi >> but depend on CONFIG_BLK_SCSI_REQUEST, that is easy enough to fix up. > > It could be a stand-alone dependency, doesn't have to be BLK_SCSI_REQUEST. > BLA_SCSI_SENSE or something would do. I don't care too much about that, > mostly getting rid of the entire stack dependency. Aaand, I can't do this and leave it in drivers/scsi because of drivers/Makefile: obj-$(CONFIG_SCSI) += scsi/ So: this needs to live in block/ just like CONFIG_BLK_SCSI_REQUEST's scsi_ioctl.c. I will split it into CONFIG_BLK_SCSI_SENSE, but I'll still need to move the code from drivers/scsi/ to block/. Is this okay? -Kees
Kees, > obj-$(CONFIG_SCSI) += scsi/ > > So: this needs to live in block/ just like CONFIG_BLK_SCSI_REQUEST's > scsi_ioctl.c. I will split it into CONFIG_BLK_SCSI_SENSE, but I'll > still need to move the code from drivers/scsi/ to block/. Is this > okay? The reason this sucks is that scsi_normalize_sense() is an inherent core feature in the SCSI layer. Dealing with sense data for ioctls is just a fringe use case. I don't want to get too hung up on what goes where. But architecturally it really irks me to move a core piece of SCSI state machine functionality out of the subsystem to accommodate ioctl handling. I'm traveling today so I probably won't get a chance to look closely until tomorrow morning.
On 5/23/18 2:52 PM, Kees Cook wrote: > On Wed, May 23, 2018 at 7:31 AM, Jens Axboe <axboe@kernel.dk> wrote: >> On 5/23/18 8:25 AM, Christoph Hellwig wrote: >>> On Wed, May 23, 2018 at 08:13:56AM -0600, Jens Axboe wrote: >>>>> Should I move to code to a new drivers/scsi/scsi_sense.c and add it to >>>>> drivers/scsi/Makefile as: >>>>> >>>>> obj-$(CONFIG_BLK_SCSI_REQUEST) += scsi_sense.o >>>>> >>>>> Every place I want to use the code is already covered by >>>>> CONFIG_BLK_SCSI_REQUEST, so it seems like I just need to know where to >>>>> put the .c file. :P >>>> >>>> I think this is so much saner than a SCSI select or dependency, so I'll >>>> have to disagree with Martin and Christoph. Just put it in drivers/scsi, >>>> if it's the location they care about. >>> >>> I actually plan to remove CONFIG_BLK_SCSI_REQUEST in a merge window >>> or two. The only users are scsi and the ide layer, (virtio_blk >>> support has already been accidentally disabled for a while), and getting >>> rid of it allows to to shrink and simply the scsi data structures. >>> >>> But if you want this for now lets keep scsi_sense.c in drivers/scsi >>> but depend on CONFIG_BLK_SCSI_REQUEST, that is easy enough to fix up. >> >> It could be a stand-alone dependency, doesn't have to be BLK_SCSI_REQUEST. >> BLA_SCSI_SENSE or something would do. I don't care too much about that, >> mostly getting rid of the entire stack dependency. > > Aaand, I can't do this and leave it in drivers/scsi because of drivers/Makefile: > > obj-$(CONFIG_SCSI) += scsi/ > > So: this needs to live in block/ just like CONFIG_BLK_SCSI_REQUEST's > scsi_ioctl.c. I will split it into CONFIG_BLK_SCSI_SENSE, but I'll > still need to move the code from drivers/scsi/ to block/. Is this > okay? Ugh, so that would necessitate a change there too. As I said before, I don't really care where it lives. I know the SCSI folks seem bothered by moving it, but in reality, it's not like this stuff will likely ever really change. Of the two choices (select entire SCSI stack, or just move this little bit), I know what I would consider the saner option...
On Wed, May 23, 2018 at 2:06 PM, Martin K. Petersen <martin.petersen@oracle.com> wrote: > > Kees, > >> obj-$(CONFIG_SCSI) += scsi/ >> >> So: this needs to live in block/ just like CONFIG_BLK_SCSI_REQUEST's >> scsi_ioctl.c. I will split it into CONFIG_BLK_SCSI_SENSE, but I'll >> still need to move the code from drivers/scsi/ to block/. Is this >> okay? > > The reason this sucks is that scsi_normalize_sense() is an inherent core > feature in the SCSI layer. Dealing with sense data for ioctls is just a > fringe use case. True, though I'm finding other robustness issues in the CDROM code. They're probably all insane corner cases, but it seems like it'd be nice to just fix them: diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c index 3522d2cae1b6..7726c8618c30 100644 --- a/drivers/cdrom/cdrom.c +++ b/drivers/cdrom/cdrom.c @@ -2222,9 +2223,12 @@ static int cdrom_read_cdda_bpc(struct cdrom_device_info *cdi, __u8 __user *ubuf, blk_execute_rq(q, cdi->disk, rq, 0); if (scsi_req(rq)->result) { - struct request_sense *s = req->sense; + struct scsi_sense_hdr sshdr; + ret = -EIO; - cdi->last_sense = s->sense_key; + scsi_normalize_sense(req->sense, req->sense_len, + &sshdr); + cdi->last_sense = sshdr.sense_key; } if (blk_rq_unmap_user(bio)) This code wasn't checking req->sense_len, for example. It'll just get stale data at worst case, but it's still ugly, especially since we have a solution to do it right. > I don't want to get too hung up on what goes where. But architecturally > it really irks me to move a core piece of SCSI state machine > functionality out of the subsystem to accommodate ioctl handling. It looks like there is more in block/scsi_ioctl.c than just ioctl handling, which is why I put the function in there originally. Honestly, it's almost so small I could make it a static inline. :P > I'm traveling today so I probably won't get a chance to look closely > until tomorrow morning. No worries; thanks for looking at it! -Kees
On 05/23/2018 02:14 PM, Jens Axboe wrote: > On 5/23/18 2:52 PM, Kees Cook wrote: >> On Wed, May 23, 2018 at 7:31 AM, Jens Axboe <axboe@kernel.dk> wrote: >>> On 5/23/18 8:25 AM, Christoph Hellwig wrote: >>>> On Wed, May 23, 2018 at 08:13:56AM -0600, Jens Axboe wrote: >>>>>> Should I move to code to a new drivers/scsi/scsi_sense.c and add it to >>>>>> drivers/scsi/Makefile as: >>>>>> >>>>>> obj-$(CONFIG_BLK_SCSI_REQUEST) += scsi_sense.o >>>>>> >>>>>> Every place I want to use the code is already covered by >>>>>> CONFIG_BLK_SCSI_REQUEST, so it seems like I just need to know where to >>>>>> put the .c file. :P >>>>> >>>>> I think this is so much saner than a SCSI select or dependency, so I'll >>>>> have to disagree with Martin and Christoph. Just put it in drivers/scsi, >>>>> if it's the location they care about. >>>> >>>> I actually plan to remove CONFIG_BLK_SCSI_REQUEST in a merge window >>>> or two. The only users are scsi and the ide layer, (virtio_blk >>>> support has already been accidentally disabled for a while), and getting >>>> rid of it allows to to shrink and simply the scsi data structures. >>>> >>>> But if you want this for now lets keep scsi_sense.c in drivers/scsi >>>> but depend on CONFIG_BLK_SCSI_REQUEST, that is easy enough to fix up. >>> >>> It could be a stand-alone dependency, doesn't have to be BLK_SCSI_REQUEST. >>> BLA_SCSI_SENSE or something would do. I don't care too much about that, >>> mostly getting rid of the entire stack dependency. >> >> Aaand, I can't do this and leave it in drivers/scsi because of drivers/Makefile: >> >> obj-$(CONFIG_SCSI) += scsi/ >> >> So: this needs to live in block/ just like CONFIG_BLK_SCSI_REQUEST's >> scsi_ioctl.c. I will split it into CONFIG_BLK_SCSI_SENSE, but I'll >> still need to move the code from drivers/scsi/ to block/. Is this >> okay? > > Ugh, so that would necessitate a change there too. As I said before, > I don't really care where it lives. I know the SCSI folks seem bothered > by moving it, but in reality, it's not like this stuff will likely ever > really change. Of the two choices (select entire SCSI stack, or just move > this little bit), I know what I would consider the saner option... > or option 3: obj-y += scsi/ so that make descends into drivers/scsi/ and then builds whatever is needed, depending on individual kconfig options.
On 5/23/18 3:20 PM, Randy Dunlap wrote: > On 05/23/2018 02:14 PM, Jens Axboe wrote: >> On 5/23/18 2:52 PM, Kees Cook wrote: >>> On Wed, May 23, 2018 at 7:31 AM, Jens Axboe <axboe@kernel.dk> wrote: >>>> On 5/23/18 8:25 AM, Christoph Hellwig wrote: >>>>> On Wed, May 23, 2018 at 08:13:56AM -0600, Jens Axboe wrote: >>>>>>> Should I move to code to a new drivers/scsi/scsi_sense.c and add it to >>>>>>> drivers/scsi/Makefile as: >>>>>>> >>>>>>> obj-$(CONFIG_BLK_SCSI_REQUEST) += scsi_sense.o >>>>>>> >>>>>>> Every place I want to use the code is already covered by >>>>>>> CONFIG_BLK_SCSI_REQUEST, so it seems like I just need to know where to >>>>>>> put the .c file. :P >>>>>> >>>>>> I think this is so much saner than a SCSI select or dependency, so I'll >>>>>> have to disagree with Martin and Christoph. Just put it in drivers/scsi, >>>>>> if it's the location they care about. >>>>> >>>>> I actually plan to remove CONFIG_BLK_SCSI_REQUEST in a merge window >>>>> or two. The only users are scsi and the ide layer, (virtio_blk >>>>> support has already been accidentally disabled for a while), and getting >>>>> rid of it allows to to shrink and simply the scsi data structures. >>>>> >>>>> But if you want this for now lets keep scsi_sense.c in drivers/scsi >>>>> but depend on CONFIG_BLK_SCSI_REQUEST, that is easy enough to fix up. >>>> >>>> It could be a stand-alone dependency, doesn't have to be BLK_SCSI_REQUEST. >>>> BLA_SCSI_SENSE or something would do. I don't care too much about that, >>>> mostly getting rid of the entire stack dependency. >>> >>> Aaand, I can't do this and leave it in drivers/scsi because of drivers/Makefile: >>> >>> obj-$(CONFIG_SCSI) += scsi/ >>> >>> So: this needs to live in block/ just like CONFIG_BLK_SCSI_REQUEST's >>> scsi_ioctl.c. I will split it into CONFIG_BLK_SCSI_SENSE, but I'll >>> still need to move the code from drivers/scsi/ to block/. Is this >>> okay? >> >> Ugh, so that would necessitate a change there too. As I said before, >> I don't really care where it lives. I know the SCSI folks seem bothered >> by moving it, but in reality, it's not like this stuff will likely ever >> really change. Of the two choices (select entire SCSI stack, or just move >> this little bit), I know what I would consider the saner option... >> > > or option 3: > > obj-y += scsi/ > > so that make descends into drivers/scsi/ and then builds whatever is needed, > depending on individual kconfig options. Right, that was the initial option, the later two are the other options.
On 05/23/2018 02:22 PM, Jens Axboe wrote: > On 5/23/18 3:20 PM, Randy Dunlap wrote: >> On 05/23/2018 02:14 PM, Jens Axboe wrote: >>> On 5/23/18 2:52 PM, Kees Cook wrote: >>>> On Wed, May 23, 2018 at 7:31 AM, Jens Axboe <axboe@kernel.dk> wrote: >>>>> On 5/23/18 8:25 AM, Christoph Hellwig wrote: >>>>>> On Wed, May 23, 2018 at 08:13:56AM -0600, Jens Axboe wrote: >>>>>>>> Should I move to code to a new drivers/scsi/scsi_sense.c and add it to >>>>>>>> drivers/scsi/Makefile as: >>>>>>>> >>>>>>>> obj-$(CONFIG_BLK_SCSI_REQUEST) += scsi_sense.o >>>>>>>> >>>>>>>> Every place I want to use the code is already covered by >>>>>>>> CONFIG_BLK_SCSI_REQUEST, so it seems like I just need to know where to >>>>>>>> put the .c file. :P >>>>>>> >>>>>>> I think this is so much saner than a SCSI select or dependency, so I'll >>>>>>> have to disagree with Martin and Christoph. Just put it in drivers/scsi, >>>>>>> if it's the location they care about. >>>>>> >>>>>> I actually plan to remove CONFIG_BLK_SCSI_REQUEST in a merge window >>>>>> or two. The only users are scsi and the ide layer, (virtio_blk >>>>>> support has already been accidentally disabled for a while), and getting >>>>>> rid of it allows to to shrink and simply the scsi data structures. >>>>>> >>>>>> But if you want this for now lets keep scsi_sense.c in drivers/scsi >>>>>> but depend on CONFIG_BLK_SCSI_REQUEST, that is easy enough to fix up. >>>>> >>>>> It could be a stand-alone dependency, doesn't have to be BLK_SCSI_REQUEST. >>>>> BLA_SCSI_SENSE or something would do. I don't care too much about that, >>>>> mostly getting rid of the entire stack dependency. >>>> >>>> Aaand, I can't do this and leave it in drivers/scsi because of drivers/Makefile: >>>> >>>> obj-$(CONFIG_SCSI) += scsi/ >>>> >>>> So: this needs to live in block/ just like CONFIG_BLK_SCSI_REQUEST's >>>> scsi_ioctl.c. I will split it into CONFIG_BLK_SCSI_SENSE, but I'll >>>> still need to move the code from drivers/scsi/ to block/. Is this >>>> okay? >>> >>> Ugh, so that would necessitate a change there too. As I said before, >>> I don't really care where it lives. I know the SCSI folks seem bothered >>> by moving it, but in reality, it's not like this stuff will likely ever >>> really change. Of the two choices (select entire SCSI stack, or just move >>> this little bit), I know what I would consider the saner option... >>> >> >> or option 3: >> >> obj-y += scsi/ >> >> so that make descends into drivers/scsi/ and then builds whatever is needed, >> depending on individual kconfig options. > > Right, that was the initial option, the later two are the other options. > Sorry, I'm late to the party.
On Wed, May 23, 2018 at 02:17:14PM -0700, Kees Cook wrote: > > True, though I'm finding other robustness issues in the CDROM code. > They're probably all insane corner cases, but it seems like it'd be > nice to just fix them: > > diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c > index 3522d2cae1b6..7726c8618c30 100644 > --- a/drivers/cdrom/cdrom.c > +++ b/drivers/cdrom/cdrom.c > @@ -2222,9 +2223,12 @@ static int cdrom_read_cdda_bpc(struct > cdrom_device_info *cdi, __u8 __user *ubuf, > > blk_execute_rq(q, cdi->disk, rq, 0); > if (scsi_req(rq)->result) { > - struct request_sense *s = req->sense; > + struct scsi_sense_hdr sshdr; > + > ret = -EIO; > - cdi->last_sense = s->sense_key; > + scsi_normalize_sense(req->sense, req->sense_len, > + &sshdr); > + cdi->last_sense = sshdr.sense_key; > } > > if (blk_rq_unmap_user(bio)) The proper fix here is to rewrite this function to use the the ->generic_packet cdrom_device_ops method. Is is the only caller going straight to the scsi passthrough requests, which is a layering violation. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, May 23, 2018 at 03:14:19PM -0600, Jens Axboe wrote: > Ugh, so that would necessitate a change there too. As I said before, > I don't really care where it lives. I know the SCSI folks seem bothered > by moving it, but in reality, it's not like this stuff will likely ever > really change. Of the two choices (select entire SCSI stack, or just move > this little bit), I know what I would consider the saner option... Oh well. How about something like this respin of Kees' series? http://git.infradead.org/users/hch/block.git/shortlog/refs/heads/sense-cleanup -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 24, 2018 at 1:00 AM, Christoph Hellwig <hch@infradead.org> wrote: > On Wed, May 23, 2018 at 03:14:19PM -0600, Jens Axboe wrote: >> Ugh, so that would necessitate a change there too. As I said before, >> I don't really care where it lives. I know the SCSI folks seem bothered >> by moving it, but in reality, it's not like this stuff will likely ever >> really change. Of the two choices (select entire SCSI stack, or just move >> this little bit), I know what I would consider the saner option... > > Oh well. How about something like this respin of Kees' series? > > http://git.infradead.org/users/hch/block.git/shortlog/refs/heads/sense-cleanup Does the CONFIG_PCMCIA in drivers/scsi/Makefile now get exposed in weird config cases? Otherwise, yeah, looks good to me. Thanks! -Kees
On Thu, May 24, 2018 at 10:06:59AM -0700, Kees Cook wrote: > On Thu, May 24, 2018 at 1:00 AM, Christoph Hellwig <hch@infradead.org> wrote: > > On Wed, May 23, 2018 at 03:14:19PM -0600, Jens Axboe wrote: > >> Ugh, so that would necessitate a change there too. As I said before, > >> I don't really care where it lives. I know the SCSI folks seem bothered > >> by moving it, but in reality, it's not like this stuff will likely ever > >> really change. Of the two choices (select entire SCSI stack, or just move > >> this little bit), I know what I would consider the saner option... > > > > Oh well. How about something like this respin of Kees' series? > > > > http://git.infradead.org/users/hch/block.git/shortlog/refs/heads/sense-cleanup > > Does the CONFIG_PCMCIA in drivers/scsi/Makefile now get exposed in > weird config cases? That just includes drivers/scsi/pcmcia/Makefile, which only has three conditional modules in it, so it should be fine. > Otherwise, yeah, looks good to me. Thanks! Can you pick up my tweaks and ressend? -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 24, 2018 at 10:06:59AM -0700, Kees Cook wrote: > On Thu, May 24, 2018 at 1:00 AM, Christoph Hellwig <hch@infradead.org> wrote: > > On Wed, May 23, 2018 at 03:14:19PM -0600, Jens Axboe wrote: > >> Ugh, so that would necessitate a change there too. As I said before, > >> I don't really care where it lives. I know the SCSI folks seem bothered > >> by moving it, but in reality, it's not like this stuff will likely ever > >> really change. Of the two choices (select entire SCSI stack, or just move > >> this little bit), I know what I would consider the saner option... > > > > Oh well. How about something like this respin of Kees' series? > > > > http://git.infradead.org/users/hch/block.git/shortlog/refs/heads/sense-cleanup > > Does the CONFIG_PCMCIA in drivers/scsi/Makefile now get exposed in > weird config cases? > > Otherwise, yeah, looks good to me. Thanks! Btw, did you plan to resend the series with this and your changes applied? -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Christoph, On Sun, Jul 8, 2018 at 1:23 PM, Christoph Hellwig <hch@infradead.org> wrote: > On Thu, May 24, 2018 at 10:06:59AM -0700, Kees Cook wrote: >> On Thu, May 24, 2018 at 1:00 AM, Christoph Hellwig <hch@infradead.org> wrote: >> > On Wed, May 23, 2018 at 03:14:19PM -0600, Jens Axboe wrote: >> >> Ugh, so that would necessitate a change there too. As I said before, >> >> I don't really care where it lives. I know the SCSI folks seem bothered >> >> by moving it, but in reality, it's not like this stuff will likely ever >> >> really change. Of the two choices (select entire SCSI stack, or just move >> >> this little bit), I know what I would consider the saner option... >> > >> > Oh well. How about something like this respin of Kees' series? >> > >> > http://git.infradead.org/users/hch/block.git/shortlog/refs/heads/sense-cleanup >> >> Does the CONFIG_PCMCIA in drivers/scsi/Makefile now get exposed in >> weird config cases? >> >> Otherwise, yeah, looks good to me. Thanks! > > Btw, did you plan to resend the series with this and your changes > applied? Yeah, I've gotten distracted. I'll try to get to it in the next few days. Thanks for the reminder! -Kees
On Mon, Jul 09, 2018 at 08:56:50AM -0700, Kees Cook wrote: > > Btw, did you plan to resend the series with this and your changes > > applied? > > Yeah, I've gotten distracted. I'll try to get to it in the next few days. > > Thanks for the reminder! Another little reminder. I'd hate to miss it for 4.19. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jul 31, 2018 at 12:53 AM, Christoph Hellwig <hch@infradead.org> wrote: > On Mon, Jul 09, 2018 at 08:56:50AM -0700, Kees Cook wrote: >> > Btw, did you plan to resend the series with this and your changes >> > applied? >> >> Yeah, I've gotten distracted. I'll try to get to it in the next few days. >> >> Thanks for the reminder! > > Another little reminder. I'd hate to miss it for 4.19. Okay, finally sent. Thanks for the reminders. :) -Kees
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c index 60b471f8621b..87ff3cc7a364 100644 --- a/block/scsi_ioctl.c +++ b/block/scsi_ioctl.c @@ -728,6 +728,70 @@ void scsi_req_init(struct scsi_request *req) } EXPORT_SYMBOL(scsi_req_init); +/** + * scsi_normalize_sense - normalize main elements from either fixed or + * descriptor sense data format into a common format. + * + * @sense_buffer: byte array containing sense data returned by device + * @sb_len: number of valid bytes in sense_buffer + * @sshdr: pointer to instance of structure that common + * elements are written to. + * + * Notes: + * The "main elements" from sense data are: response_code, sense_key, + * asc, ascq and additional_length (only for descriptor format). + * + * Typically this function can be called after a device has + * responded to a SCSI command with the CHECK_CONDITION status. + * + * Return value: + * true if valid sense data information found, else false; + */ +bool scsi_normalize_sense(const u8 *sense_buffer, int sb_len, + struct scsi_sense_hdr *sshdr) +{ + memset(sshdr, 0, sizeof(struct scsi_sense_hdr)); + + if (!sense_buffer || !sb_len) + return false; + + sshdr->response_code = (sense_buffer[0] & 0x7f); + + if (!scsi_sense_valid(sshdr)) + return false; + + if (sshdr->response_code >= 0x72) { + /* + * descriptor format + */ + if (sb_len > 1) + sshdr->sense_key = (sense_buffer[1] & 0xf); + if (sb_len > 2) + sshdr->asc = sense_buffer[2]; + if (sb_len > 3) + sshdr->ascq = sense_buffer[3]; + if (sb_len > 7) + sshdr->additional_length = sense_buffer[7]; + } else { + /* + * fixed format + */ + if (sb_len > 2) + sshdr->sense_key = (sense_buffer[2] & 0xf); + if (sb_len > 7) { + sb_len = (sb_len < (sense_buffer[7] + 8)) ? + sb_len : (sense_buffer[7] + 8); + if (sb_len > 12) + sshdr->asc = sense_buffer[12]; + if (sb_len > 13) + sshdr->ascq = sense_buffer[13]; + } + } + + return true; +} +EXPORT_SYMBOL(scsi_normalize_sense); + static int __init blk_scsi_ioctl_init(void) { blk_set_cmd_filter_defaults(&blk_default_cmd_filter); diff --git a/drivers/scsi/scsi_common.c b/drivers/scsi/scsi_common.c index 90349498f686..8621a07cb967 100644 --- a/drivers/scsi/scsi_common.c +++ b/drivers/scsi/scsi_common.c @@ -116,70 +116,6 @@ void int_to_scsilun(u64 lun, struct scsi_lun *scsilun) } EXPORT_SYMBOL(int_to_scsilun); -/** - * scsi_normalize_sense - normalize main elements from either fixed or - * descriptor sense data format into a common format. - * - * @sense_buffer: byte array containing sense data returned by device - * @sb_len: number of valid bytes in sense_buffer - * @sshdr: pointer to instance of structure that common - * elements are written to. - * - * Notes: - * The "main elements" from sense data are: response_code, sense_key, - * asc, ascq and additional_length (only for descriptor format). - * - * Typically this function can be called after a device has - * responded to a SCSI command with the CHECK_CONDITION status. - * - * Return value: - * true if valid sense data information found, else false; - */ -bool scsi_normalize_sense(const u8 *sense_buffer, int sb_len, - struct scsi_sense_hdr *sshdr) -{ - memset(sshdr, 0, sizeof(struct scsi_sense_hdr)); - - if (!sense_buffer || !sb_len) - return false; - - sshdr->response_code = (sense_buffer[0] & 0x7f); - - if (!scsi_sense_valid(sshdr)) - return false; - - if (sshdr->response_code >= 0x72) { - /* - * descriptor format - */ - if (sb_len > 1) - sshdr->sense_key = (sense_buffer[1] & 0xf); - if (sb_len > 2) - sshdr->asc = sense_buffer[2]; - if (sb_len > 3) - sshdr->ascq = sense_buffer[3]; - if (sb_len > 7) - sshdr->additional_length = sense_buffer[7]; - } else { - /* - * fixed format - */ - if (sb_len > 2) - sshdr->sense_key = (sense_buffer[2] & 0xf); - if (sb_len > 7) { - sb_len = (sb_len < (sense_buffer[7] + 8)) ? - sb_len : (sense_buffer[7] + 8); - if (sb_len > 12) - sshdr->asc = sense_buffer[12]; - if (sb_len > 13) - sshdr->ascq = sense_buffer[13]; - } - } - - return true; -} -EXPORT_SYMBOL(scsi_normalize_sense); - /** * scsi_sense_desc_find - search for a given descriptor type in descriptor sense data format. * @sense_buffer: byte array of descriptor format sense data diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h index aaf1e971c6a3..3b9f42f6615c 100644 --- a/include/scsi/scsi_cmnd.h +++ b/include/scsi/scsi_cmnd.h @@ -120,7 +120,6 @@ struct scsi_cmnd { struct request *request; /* The command we are working on */ -#define SCSI_SENSE_BUFFERSIZE 96 unsigned char *sense_buffer; /* obtained by REQUEST SENSE when * CHECK CONDITION is received on original diff --git a/include/scsi/scsi_common.h b/include/scsi/scsi_common.h index 731ac09ed231..82d6209f2e10 100644 --- a/include/scsi/scsi_common.h +++ b/include/scsi/scsi_common.h @@ -8,6 +8,7 @@ #include <linux/types.h> #include <scsi/scsi_proto.h> +#include <scsi/scsi_sense.h> static inline unsigned scsi_varlen_cdb_length(const void *hdr) @@ -31,37 +32,6 @@ extern const char *scsi_device_type(unsigned type); extern void int_to_scsilun(u64, struct scsi_lun *); extern u64 scsilun_to_int(struct scsi_lun *); -/* - * This is a slightly modified SCSI sense "descriptor" format header. - * The addition is to allow the 0x70 and 0x71 response codes. The idea - * is to place the salient data from either "fixed" or "descriptor" sense - * format into one structure to ease application processing. - * - * The original sense buffer should be kept around for those cases - * in which more information is required (e.g. the LBA of a MEDIUM ERROR). - */ -struct scsi_sense_hdr { /* See SPC-3 section 4.5 */ - u8 response_code; /* permit: 0x0, 0x70, 0x71, 0x72, 0x73 */ - u8 sense_key; - u8 asc; - u8 ascq; - u8 byte4; - u8 byte5; - u8 byte6; - u8 additional_length; /* always 0 for fixed sense format */ -}; - -static inline bool scsi_sense_valid(const struct scsi_sense_hdr *sshdr) -{ - if (!sshdr) - return false; - - return (sshdr->response_code & 0x70) == 0x70; -} - -extern bool scsi_normalize_sense(const u8 *sense_buffer, int sb_len, - struct scsi_sense_hdr *sshdr); - extern void scsi_build_sense_buffer(int desc, u8 *buf, u8 key, u8 asc, u8 ascq); int scsi_set_sense_information(u8 *buf, int buf_len, u64 info); int scsi_set_sense_field_pointer(u8 *buf, int buf_len, u16 fp, u8 bp, bool cd); diff --git a/include/scsi/scsi_sense.h b/include/scsi/scsi_sense.h new file mode 100644 index 000000000000..be923c67b93e --- /dev/null +++ b/include/scsi/scsi_sense.h @@ -0,0 +1,44 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Structures and functions used by both SCSI and ATAPI sense code. + */ + +#ifndef _SCSI_SENSE_H_ +#define _SCSI_SENSE_H_ + +#include <linux/types.h> + +/* + * This is a slightly modified SCSI sense "descriptor" format header. + * The addition is to allow the 0x70 and 0x71 response codes. The idea + * is to place the salient data from either "fixed" or "descriptor" sense + * format into one structure to ease application processing. + * + * The original sense buffer should be kept around for those cases + * in which more information is required (e.g. the LBA of a MEDIUM ERROR). + */ +struct scsi_sense_hdr { /* See SPC-3 section 4.5 */ + u8 response_code; /* permit: 0x0, 0x70, 0x71, 0x72, 0x73 */ + u8 sense_key; + u8 asc; + u8 ascq; + u8 byte4; + u8 byte5; + u8 byte6; + u8 additional_length; /* always 0 for fixed sense format */ +}; + +static inline bool scsi_sense_valid(const struct scsi_sense_hdr *sshdr) +{ + if (!sshdr) + return false; + + return (sshdr->response_code & 0x70) == 0x70; +} + +#define SCSI_SENSE_BUFFERSIZE 96 + +extern bool scsi_normalize_sense(const u8 *sense_buffer, int sb_len, + struct scsi_sense_hdr *sshdr); + +#endif /* _SCSI_SENSE_H_ */
Both SCSI and ATAPI share the sense header. In preparation for using the struct scsi_sense_hdr more widely, move this into a separate header and move the helper function to scsi_ioctl.c which is linked with CONFIG_IDE by way of CONFIG_BLK_SCSI_REQUEST. Signed-off-by: Kees Cook <keescook@chromium.org> --- block/scsi_ioctl.c | 64 ++++++++++++++++++++++++++++++++++++++ drivers/scsi/scsi_common.c | 64 -------------------------------------- include/scsi/scsi_cmnd.h | 1 - include/scsi/scsi_common.h | 32 +------------------ include/scsi/scsi_sense.h | 44 ++++++++++++++++++++++++++ 5 files changed, 109 insertions(+), 96 deletions(-) create mode 100644 include/scsi/scsi_sense.h