[lkml]   [2018]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2 01/17] compat_ioctl: add generic_compat_ioctl_ptrarg()
On Thu, Sep 13, 2018 at 4:07 AM Al Viro <> wrote:
> On Wed, Sep 12, 2018 at 05:01:02PM +0200, Arnd Bergmann wrote:
> > Many drivers have ioctl() handlers that are completely compatible
> > between 32-bit and 64-bit architectures, except for the argument
> > that is passed down from user space and may have to be passed
> > through compat_ptr() in order to become a valid 64-bit pointer.
> >
> > Using ".compat_ptr=generic_compat_ioctl_ptrarg" in file operations
> > should let us simplify a lot of those drivers to avoid #ifdef
> > checks, and convert additional drivers that don't have proper
> > compat handling yet.
> Just keep in mind that this should *only* be used when all
> ioctls implemented in a given instance do take pointers.
> Because otherwise you are asking for trouble - e.g. if one of
> them takes an u32 used as a bitmap, this will run into trouble
> as soon as somebody uses bit 31. With no visible warnings.
> IOW, it shouldn't be used blindly and it should come with big
> fat warning.

I was hoping that the _ptrarg suffix gives enough warning here,
but maybe not. I was careful to only use it in cases that I
checked are safe, either using only pointer arguments, or
no arguments.

What we might do for further clarification (besides adding a
comment next to the declaration), would be to add a
complementary generic_compat_ioctl_intarg() that skips
the compat_ptr(). There are only a handful of drivers that
would use this though.


 \ /
  Last update: 2018-09-13 12:30    [W:0.146 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site