Messages in this thread | ![/](/images/icornerl.gif) | | Date | Sat, 7 Jun 2003 09:25:43 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: __user annotations |
| |
On Sat, 7 Jun 2003, Ingo Oeser wrote: > > That's a big pity. How do I workaround this? I would like to > help resolving this issues, if you are interested.
The solution to these things is to _always_ have a separate type for the user thing than for the kernel thing.
In practice, a lot of code has ended up doing that _anyway_, since the kernel usually wants to have a few extra fields for its internal use. The classic unix example of this, of course, is "struct stat" vs "struct inode".
But if your structures are 100% the same, then you can just share them. There's nothing wrong with having
struct ioctl_arg { int value; int another_value; .. };
and then in your ioctl routines you have
int my_ioctl_routine(struct ioctl_arg __user *ptr) { struct ioctl_arg arg;
if (copy_from_user(&arg, ptr, sizeof(*ptr)) return -EFAULT; ... }
and that's fine.
You can even have user pointers _inside_ the structure: because "sparse" really understands C types at a very fundamental level (like a compiler would, not like some simpler source scanner), you can have
struct ioctl_arg { int value; void __user *buf; };
and do
int my_ioctl_routine(struct ioctl_arg __user *ptr) { struct ioctl_arg arg; char buffer[10];
if (copy_from_user(&arg, ptr, sizeof(*ptr)) return -EFAULT;
and sparse will be aware of the fact that "arg.buf" is a user pointer, and it will properly warn if you pass it to a function that expects a kernel pointer (or assign it to a normal non-user pointer thing).
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |