[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.


More information about the linux-rpi-kernel mailing list