linux-kernel - Re: [PATCH 3/6] block: Create scsi

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 23 May 2018 15:14:19 -0600
From:   Jens Axboe <axboe@...nel.dk>
To:     Kees Cook <keescook@...omium.org>
Cc:     Christoph Hellwig <hch@...radead.org>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        Tejun Heo <tj@...nel.org>, Borislav Petkov <bp@...en8.de>,
        "David S. Miller" <davem@...emloft.net>,
        "Manoj N. Kumar" <manoj@...ux.vnet.ibm.com>,
        "Matthew R. Ochs" <mrochs@...ux.vnet.ibm.com>,
        Uma Krishnan <ukrishn@...ux.vnet.ibm.com>,
        linux-block <linux-block@...r.kernel.org>,
        linux-ide@...r.kernel.org, linux-scsi@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/6] block: Create scsi_sense.h for SCSI and ATAPI

On 5/23/18 2:52 PM, Kees Cook wrote:
> On Wed, May 23, 2018 at 7:31 AM, Jens Axboe <axboe@...nel.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...

-- 
Jens Axboe