Messages in this thread | | | From | Mike Frysinger <> | Date | Sat, 13 Jun 2009 20:47:20 -0400 | Subject | Re: [PATCH] asm-generic: uaccess: fix up local access_ok() usage |
| |
On Sat, Jun 13, 2009 at 16:53, Arnd Bergmann wrote: > On Saturday 13 June 2009, Mike Frysinger wrote: >> There's no reason that I can see to use the short __access_ok() form >> directly when the access_ok() is clearer in intent and for more people, >> expands to the same C code (i.e. always specify the first field -- access >> type). Not all no-mmu systems lack memory protection, so the read/write >> could feasibly be checked. > > Ah, I didn't consider this. I checked all the architectures and could not > find a case where access_ok actually evaluates the the first argument, so > I chose the slightly terser variant. I also don't let you override > access_ok() at this moment, which means that you don't have a choice > to use the generic uaccess.h and still differentiate between read and > write accesses.
well, if you dont mind a bit of cruft, you can undef it ;) #include <asm-generic/uaccess.h> #undef access_ok
the Blackfin port does have hardware memory protection (MPU) and it does handle r/w/x bits, but we havent merged this into access_ok yet, just the vma lists
> What I really got wrong was the prototype for __access_ok(), as you > showed in your follow-up. I only tested this with the microblaze > patch that overrides __access_ok() with an architecture specific > version that gets this part right.
yeah, that looks good, but i'd still like the __access_ok -> access_ok
>> Also, the strnlen_user() function was missing a access_ok() check on the >> pointer given. We've had cases on Blackfin systems where test cases >> caused kernel crashes here because userspace passed up a NULL/-1 pointer >> and the kernel gladly attempted to run strlen() on it. > > Right, well spotted. I'll take this fix as a separate patch, ok?
np -mike -- 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/
| |