Re: + drivers-acpi-apei-erst-dbgc-get_useru64-doesnt-work-on-i386.patch added to -mm tree

[Andrew Morton <akpm@linux-foundation.org>]

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

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