On Tue, Oct 12, 2010 at 02:01:56PM -0700, David Daney wrote: > The TASK_SIZE macro should reflect the size of a user process virtual > address space. Previously for 64-bit kernels, this was not the case. > The immediate cause of pain was in > hugetlbfs/inode.c:hugetlb_get_unmapped_area() where 32-bit processes > trying to mmap a huge page would be served a page with an address > outside of the 32-bit address range. But there are other uses of > TASK_SIZE in the kernel as well that would like an accurate value. > > The new definition is nice because it now makes TASK_SIZE and > TASK_SIZE_OF() yield the same value for any given process. > > For 32-bit kernels there should be no change, although I did factor > out some code in asm/processor.h that became identical for the 32-bit and > 64-bit cases. > > Another, perhaps non-obvious, change is that in 64-bit kernels, the > get_fs() value (A.K.A current_thread_info()->addr_limit) will now vary > depending on the address space size of the process. This is a change, > as previously even 32-bit processes would have an addr_limit > appropriate for a 64-bit process. This will change the behavior of > access_ok(), but I think the new behavior is desirable. > > Before the patch it may have been possible for a user space process to > pass a pointer to the kernel that would pass the access_ok() check, > but be outside of the 32-bit address space. That was intensional. The sole purpose of the access_ok check is to prevent users from passing kernel addresses to syscalls. Beyond that we absolutely don't care. The creation of mappings above 0x7fff8000 is prevented in the syscalls themselves but even if that's mechanism should have a hole that is not a problem for uaccess.h - the protection of the kernel will hold. Ralf
