linux-kernel - Re: stop using ioctl_by_bdev in the s390 DASD driver

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]

Message-Id: <427b0095-6a38-5632-8e46-422c7a4a552a@de.ibm.com>
Date:   Tue, 21 Apr 2020 12:43:03 +0200
From:   Christian Borntraeger <borntraeger@...ibm.com>
To:     Cornelia Huck <cohuck@...hat.com>
Cc:     Christoph Hellwig <hch@....de>,
        Stefan Haberland <sth@...ux.ibm.com>,
        Jan Hoeppner <hoeppner@...ux.ibm.com>,
        Jens Axboe <axboe@...nel.dk>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>, linux-s390@...r.kernel.org,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: stop using ioctl_by_bdev in the s390 DASD driver



On 21.04.20 12:32, Cornelia Huck wrote:
> On Tue, 21 Apr 2020 11:58:31 +0200
> Christian Borntraeger <borntraeger@...ibm.com> wrote:
> 
>> On 21.04.20 08:12, Christoph Hellwig wrote:
>>> Hi Jens and DASD maintainers,
>>>
>>> can you take a look at this series, which stops the DASD driver from
>>> issuing ioctls from kernel space, in preparation of removing
>>> ioctl_by_bdev.  I don't really like the new s390-only method, but short
>>> of forcing the dasd driver to be built into the kernel I can't think of
>>> anything better.  But maybe the s390 maintainers are fine with forcing
>>> the DASD driver to be built in, in which case we could go down that
>>> route?  
>>
>> Hmm the defconfig results in dasd built-in anyway. But distros really like
>> to keep it modular.
>>
>> Hmm, we do have
>>
>> obj-$(CONFIG_DASD) += dasd_mod.o
>> obj-$(CONFIG_DASD_DIAG) += dasd_diag_mod.o
>> obj-$(CONFIG_DASD_ECKD) += dasd_eckd_mod.o
>> obj-$(CONFIG_DASD_FBA)  += dasd_fba_mod.o
>>
>> Would it work to make CONFIG_DASD built-in only and keep the other 3 as modules?
>> Not sure about the implications. 
>>
> 
> I don't think non-eckd dasd drivers are really useful outside of z/VM
> guests, so keeping at least the disciplines modular would be good.
> 
> Also, what about special purpose environments like the zfcp dumper?
> Would be good to be able to keep these small.
> 
> How big is the dasd code in the end?


  File: drivers/s390/block/dasd_diag_mod.ko
  Size: 519976    	Blocks: 1016       IO Block: 4096   regular file
--
  File: drivers/s390/block/dasd_eckd_mod.ko
  Size: 2125976   	Blocks: 4160       IO Block: 4096   regular file
--
  File: drivers/s390/block/dasd_fba_mod.ko
  Size: 524256    	Blocks: 1024       IO Block: 4096   regular file
--
  File: drivers/s390/block/dasd_mod.ko
  Size: 3273464   	Blocks: 6400       IO Block: 4096   regular file


So 3 MB seems quite a lot for special purpose Linuxes like the zfcp dumper.