On Thu, Sep 13, 2018 at 4:07 AM Al Viro <v...@zeniv.linux.org.uk> 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.

       Arnd

Reply via email to