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/
This archive was generated by hypermail 2b29 : Sat Jun 07 2003 - 22:00:33 EST