[uClinux-dev] TASK_SIZE

Fabrice Gautier Fabrice_Gautier at sdesigns.com
Tue Nov 20 22:14:22 EST 2001


I found the following defenition for TASK_SIZE: (in the arm-linux ML)

" The maximum size of a user process in bytes. Since user space always
starts at zero, this is the maximum address that a user process can
access+1. The user space stack grows down from this address. Any virtual
address below TASK_SIZE is deemed to be user process area, and therefore
managed dynamically on a process by process basis by the kernel. I'll call
this the user segment. Anything above TASK_SIZE is common to all processes.
I'll call this the kernel segment. (In other words, you can't put IO
mappings below TASK_SIZE, and hence PAGE_OFFSET). "

There is an assumption in this definition that is not true for uClinux:
"Since user space always starts at zero, this is the maximum address that a
user process can access+1"

My impression is that uClinux user space start at a different adress for
each process.

In my case (Atmel) the RAM start at 0x02000000 (I've customized that), and
TASK_SIZE is set 0x01a00000.

In the kernel do_getname use TASK_SIZE to check if the pointer to the
filename is valid. So this abviously fail. The port for EB01 in the cvs has
dram mapped at 0x01000000 so i guess this is what nobody noticed that
before. 2.0 doesn't seem to check pointer against TASK_SIZE. 

The symptom of all this (for me) is that the kernel can't open the initial

So the question is how should we correct the problem?

1/ - Set TASK_SIZE to maximum memory adress
2/ - Correct the kernel to correctly check the pointer?
3/ - ...

Solution 1 sure would workaround the problem, and one can argue that anyway
the user space is the full memeory space and that the user program can
access any memory from user space anyway. However I think this made the
checking user space pointer even more important...



Fabrice Gautier
Software Engineer, Sigma Designs
Fabrice_Gautier at sdesigns.com

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/

More information about the uClinux-dev mailing list