Re: TASK_SIZE is variable.

David S. Miller
2005-01-25T23:52:39Z

On Tue, 25 Jan 2005 22:26:52 +0000
David Woodhouse <dwmw2@infradead.org> wrote:

> Bad things can happen if a 32-bit process is the last user of a 64-bit
> mm.

I guess this is OK.

I think the easiest way to fix this for good is to simply
kill off TASK_SIZE and that way each and every use will be
audited. We can replace TASK_SIZE with something the describes
what is really wanted:

1) Max address potentially mapped in "mm". Although I heavily
dislike the MM_VM_SIZE(mm) scheme because address space size
is determined by the process emul type, and thus is a thread
not a mm property

In fact, look at how nobody seems to even use the "mm" argument
to this macro. Further, look at the comment above the ppc64
definition:

/* We can't actually tell the TASK_SIZE given just the mm, but default
* to the 64-bit case to make sure that enough gets cleaned up. */

Yeah, we can't tell the TASK_SIZE from the "mm", no shit.

2) Limits imposed at mmap()/munmap()/mremap() time for virtual
address arguments.

Thinking about this some more, it may in fact be better to make
these platforms go to using a constant TASK_SIZE, kill this
bogus'ly argumented MM_VM_SIZE(mm) thing, and use something new
for mmap()/mremap()/munmap() et al. argument checking which
is based upon some thread property.