[PATCH] staging: vc04_services: rework ioctl code path
Arnd Bergmann
arnd at arndb.de
Wed Nov 9 14:51:38 PST 2016
On Wednesday, November 9, 2016 2:41:42 PM CET Michael Zoran wrote:
> > > Arnd
> >
> > That I have absolutely no problem changing. I'll go ahead and change
> > it and resubmit the patch.
> > >
>
> Actually, I'm looking at this a bit more and I'm noticing some
> interesting things.
>
> If something like compat_ptr is used, why can the ioctl.h header be
> included twice with different #defines to generate both the 32 bit and
> 64 bit cases.
I can't see how that would work, as you have to change the macro
names as well.
> Also, I'm think more about the kernel pointer idea. One complication
> I'm thinking is of the case of IN/OUT data. How does it unwind the
> operation on a failure of the final copy back to userland?
>
> On thing I'm just brainstorming about is what can't it "lock" the
> page(s) for the userland pointer in ram until the end of the ioctl so
> that the copy back from the kernel can't ever or can't very easily
> fail?
The normal approach is to return without copying back if something
fails before the copy_to_user(), but return -EFAULT if the copy
itself fails for a _IOWR or _IOR command.
Arnd
More information about the linux-rpi-kernel
mailing list