On Wed, 11 Aug 2010 22:06:08 -0700 "H. Peter Anvin" <hpa@xxxxxxxxx> 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> -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
