linux-kernel - Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl

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:   Fri, 14 Sep 2018 21:57:48 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Darren Hart <dvhart@...radead.org>
Cc:     Arnd Bergmann <arnd@...db.de>, linux-fsdevel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "David S. Miller" <davem@...emloft.net>,
        devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org,
        qat-linux@...el.com, linux-crypto@...r.kernel.org,
        linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        linaro-mm-sig@...ts.linaro.org, amd-gfx@...ts.freedesktop.org,
        linux-input@...r.kernel.org, linux-iio@...r.kernel.org,
        linux-rdma@...r.kernel.org, linux-nvdimm@...ts.01.org,
        linux-nvme@...ts.infradead.org, linux-pci@...r.kernel.org,
        platform-driver-x86@...r.kernel.org,
        linux-remoteproc@...r.kernel.org, sparclinux@...r.kernel.org,
        linux-scsi@...r.kernel.org, linux-usb@...r.kernel.org,
        linux-fbdev@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
        linux-btrfs@...r.kernel.org, ceph-devel@...r.kernel.org,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v2 05/17] compat_ioctl: move more drivers to
 generic_compat_ioctl_ptrarg

On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote:
 
> Acked-by: Darren Hart (VMware) <dvhart@...radead.org>
> 
> As for a longer term solution, would it be possible to init fops in such
> a way that the compat_ioctl call defaults to generic_compat_ioctl_ptrarg
> so we don't have to duplicate this boilerplate for every ioctl fops
> structure?

	Bad idea, that...  Because several years down the road somebody will add
an ioctl that takes an unsigned int for argument.  Without so much as looking
at your magical mystery macro being used to initialize file_operations.

	FWIW, I would name that helper in more blunt way - something like
compat_ioctl_only_compat_pointer_ioctls_here()...