Re: TASK_SIZE is variable.

Paul Mackerras
2005-01-29T23:28:50Z

Andrew Morton writes:

> Guys, could I get a bit of clarity on how we want to proceed with all of
> this?
>
> I have the below two patches queued. Speak now or forever stfu!

In both cases (free_pgtables and exit_mmap) we want to do something to
the whole of an address space which may not be ours. With these
patches we use MM_VM_SIZE(mm) to tell us how big the address space is
rather than TASK_SIZE, which is a good start. However, the default
MM_VM_SIZE is still (based on) TASK_SIZE, and each 64-bit arch that
has TASK_SIZE as a per-task property then has to override it (except
that parisc doesn't seem to). Also, having the mm as an argument to
MM_VM_SIZE is currently useless because there is nothing in the mm
that is helpful.

Thus the two patches you included will fix the problems, at the
expense of having to scan the whole pgd at exit time, even though we
really only need to look at the first 2 entries on ppc64 for the
very common case where the mm was used by a 32-bit process.

IMHO it would be cleaner and more efficient to have a way to tell how
much of an address space has actually been used, just from the mm,
without having to know what task(s) used the mm and whether they were
32-bit or 64-bit tasks. That is what my mm->max_addr patch was aiming
at. Having mm->max_addr should also work correctly across all
architectures, even the ones that have mappings above the 4GB point
for 32-bit processes, as long as they create vma's for those mappings.

Thus I would like to see the mm->max_addr patch go in. If
architectures still want to control MM_VM_SIZE, we could have the
default definition of MM_VM_SIZE(mm) be mm->max_addr + 1 (or
alternatively make mm->max_addr be the address space size rather than
the max address - I made it the max address because I was concerned
that there might be 32-bit architectures that allowed mappings up to
and including 0xffffffff).

I am happy to make a combined patch if people agree on the approach.

Paul.