On Wed, 11 Aug 2010 22:06:08 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:

quoted text
> On 08/11/2010 09:30 PM, Andrew Morton wrote:
> > 
> > It occurs so rarely that it's probably not worth bothering about, IMO.
> > 
> 
> I think the real question is if we want people to convert:
> 
> 	if (copy_from_user(foo, bar, sizeof *foo))
> 		return -EFAULT;
> 
> ... into ...
> 
> 	if (get_user(*foo, bar))
> 		return -EFAULT;
> 
> ... or ...
> 
> 	rv = get_user(*foo, bar);
> 	if (rv)
> 		return rv;
> 
> ... where *foo is a structure type.  It does have the advantage that a
> single API does everything, simple or not, but has the disadvantage that
> the partial-access semantics are now less explicit.
> 

Well, anyone who does get_user() on a struct while expecting it to be
atomic gets to own both pieces.  I think the problem here is
specifically u64/s64.  These work on 64-bit but don't work on 32-bit.

Is the atomicity really a problem?  If userspace updates the 64-bit
number while the kernel is copying it, the kernel gets a garbage
number.  But so what?  Userspace can feed the kernel garbage numbers in
lots of ways, and the kernel must be able to cope with it
appropriately.


<I suspect you can do get_user() on a 4-byte or 8-byte struct right now
and it'll work>
--
unsubscribe notice
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/