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]

Date:   Tue, 21 Apr 2020 12:32:56 +0200
From:   Cornelia Huck <cohuck@...hat.com>
To:     Christian Borntraeger <borntraeger@...ibm.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 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?