linux-kernel - Re: [PATCH] scsi: Delete scsi_{get,free}_host

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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 29 Jun 2021 09:15:37 +0100
From:   John Garry <john.garry@...wei.com>
To:     Hannes Reinecke <hare@...e.de>, <martin.petersen@...cle.com>,
        <jejb@...ux.ibm.com>
CC:     <bvanassche@....org>, <linux-scsi@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <hch@....de>, <ming.lei@...hat.com>
Subject: Re: [PATCH] scsi: Delete scsi_{get,free}_host_dev()

On 26/06/2021 12:55, Hannes Reinecke wrote:
> On 6/25/21 6:58 PM, John Garry wrote:
>> Functions scsi_{get,free}_host_dev() no longer have any in-tree users, so
>> delete them.
>>
>> Signed-off-by: John Garry <john.garry@...wei.com>
>> ---
>> An alt agenda of this patch is to get clarification on whether this API
>> should be used for Hannes' reserved commands series.
>>
>> Originally the recommendation was to use it, but now it seems to be to
>> not use it:
>> https://lore.kernel.org/linux-scsi/55918d68-7385-0153-0bd9-d822d3ce4c21@suse.de/ 
>>
>>
> Please don't.

ok, we can take that as a nacked-by for now.

> 
> Before we're doing something like this I would like to have 
> clarification from Christoph which way he prefers for reserved commands. 
> Personally I _do_ like the host dev approach for reserved commands as it 
> allows us to re-use existing infrastructure.

So when you deleted the gdth driver, the request there was to delete 
this API. And in the v8 series, again, the request was not to use it, 
and use the dedicated request queue instead - I do know that this 
conflicts with the much earlier suggestion not to do that, but that was 
when gdth existed.

As for reuse of existing infrastructure, using this API seems to add 
more code than it reuses.

So don't we just need to add a dedicated request_queue for host? I don't 
know the use in having the scsi_device. Having said all that, we don't 
seem to have a host request_queue sysfs entry with either solution, 
which would be good.

> 
> Christoph?
> 

Thanks,
John