linux-kernel - Re: [PATCH 11/11] compat_ioctl: move tape handling into drivers

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: <CAK8P3a0evhaJGL_XdUjQhJDGyAh01UjLFkKx-Cq21htXmFsY2A@mail.gmail.com>
Date:   Tue, 11 Sep 2018 17:36:46 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     David Miller <davem@...emloft.net>,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        Heiko Carstens <heiko.carstens@...ibm.com>, osst@...de.org,
        "James E.J. Bottomley" <jejb@...ux.vnet.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Kai.Makisara@...umbus.fi,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        IDE-ML <linux-ide@...r.kernel.org>,
        linux-s390 <linux-s390@...r.kernel.org>,
        osst-users@...ts.sourceforge.net,
        linux-scsi <linux-scsi@...r.kernel.org>,
        Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH 11/11] compat_ioctl: move tape handling into drivers

On Sun, Sep 9, 2018 at 6:38 AM Al Viro <viro@...iv.linux.org.uk> wrote:
>
> On Sat, Sep 08, 2018 at 04:28:17PM +0200, Arnd Bergmann wrote:
> > MTIOCPOS and MTIOCGET are incompatible between 32-bit and 64-bit user
> > space, and traditionally have been translated in fs/compat_ioctl.c.
> >
> > To get rid of that translation handler, move a corresponding
> > implementation into each of the four drivers implementing those commands.
> >
> > The interesting part of that is now in a new linux/mtio.h header that
> > wraps the existing uapi/linux/mtio.h header and provides an abstraction
> > to let drivers handle both cases easily.
>
> Ugh...  Frankly, this bool compat passed all way down looks wrong.
> I can live with that; the question is whether block folks will be
> OK with that thing...

I have tried to come up with an alternative, but couldn't really find anything
that is less ugly. Since nobody else complained, I'll resend this version
along with the other patches.

       Arnd