Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: access_ok macor | Date | Wed, 15 Jul 2009 15:27:07 +0200 |
| |
On Wednesday 15 July 2009, Ralf Baechle wrote:
> > I think in step 4. AFIACT, the kernel must do a number of checks on accesses > > to random pointers. > > Yes; but the checks that unaligned.c does on MIPS are no different from > any other get_user(), that is it ensures that the entire 8/16/32/64-bit > access is in userspace. That's done using access_ok().
Well, access_ok() plus the fixup code for unmapped or write-protected user pages, I guess. But I agree, there are no checks beyond what get/put_user does. In particular, the access_ok() check should only be needed for faults from user space, while any fault coming from kernel space is either some kernel code accessing its own data (as you mention below) or a __get_user/__put_user that has already checked access permissions.
In my example, I got the case from kernel space wrong, it should not check access_ok() if !user_space(regs), or it needs to do set_fs(KERNEL_DS) first, like the mips code does.
> We've moved on. Handling miss-alignment is no longer a very relavent part > of the syscall interface. So I think for the definition of the Linux > ABI this should just be left as implementation defined behaviour but > whatever an architecture does, it should be done consistently for all > system interfaces.
Ok, thanks, for explanation.
I guess for the microblaze unaligned handler, both cases mean that it needs to do a fixup table lookup for the original fault and it needs to handle fixups on its own emulation code. The only difference between disallowing unaligned accesses in the ABI and allowing them is which of the two ways (check fixup table, emulate instruction) it tries first.
Arnd <><
| |