Thread (15 messages) 15 messages, 10 authors, 2018-10-06

Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg

From: Jason Gunthorpe <jgg@ziepe.ca>
Date: 2018-09-18 17:59:52
Also in: amd-gfx, ceph-devel, dri-devel, linux-btrfs, linux-crypto, linux-fbdev, linux-fsdevel, linux-input, linux-media, linux-pci, linux-rdma, linux-remoteproc, linux-scsi, linux-usb, linux-wireless, lkml, netdev, nvdimm, platform-driver-x86, sparclinux

On Tue, Sep 18, 2018 at 10:51:08AM -0700, Darren Hart wrote:
On Fri, Sep 14, 2018 at 09:57:48PM +0100, Al Viro wrote:
quoted
On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote:
 
quoted
Acked-by: Darren Hart (VMware) <dvhart@infradead.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.
Fair, being explicit in the declaration as it is currently may be
preferable then.
It would be much cleaner and safer if you could arrange things to add
something like this to struct file_operations:

  long (*ptr_ioctl) (struct file *, unsigned int, void __user *);

Where the core code automatically converts the unsigned long to the
void __user * as appropriate.

Then it just works right always and the compiler will help address
Al's concern down the road.

Cheers,
Jason
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help