Hi,
That patch is wrong for earlier kernel. There will be a memory leak on
page tables.
The reason is syscall page was not backup by VMA, clear_page_tables will
only clear up to TASK_SIZE, so there will be a leak on syscall page.
But in 2.6.11 kernel, clear_page_range will clear more page tables than
that.
I have tested my patch on 2.6.11 kernel.
Do a chroot bash to 32 bit system, then a 32 bit ltp test. No issue was
found.
However I found the patch is not compatible with recent 2.6.12-rc3
kernel.
In rc3 kernel, syscall page is backup with VMA, thus the special case
code to deal with syscall page was removed from arch/x86_64/mm/fault.c.
So I changed the patch to rebase it on 2.6.12-rc3,
This patch has been tested on 2.6.12-rc3
by chroot to a 32 bit system,
then follow an 32 bit ltp test.
Signed-off-by: Suresh Siddha <suresh.b.siddha@xxxxxxxxx>
Signed-off-by: Zou Nan hai <Nanhai.zou@xxxxxxxxx>
> -----Original Message-----
> From: Alexander Nyberg [mailto:[email protected]]
> Sent: Saturday, April 23, 2005 5:10 PM
> To: Zou, Nanhai
> Cc: Andi Kleen; [email protected]; [email protected];
Siddha,
> Suresh B
> Subject: RE: [discuss] [Patch] X86_64 TASK_SIZE cleanup - more
comments
>
> > PPC64 IA64 and S390 use variable size TASK_SIZE for 32 bit and 64
bit
> > program.
> > I feel it is hard to maintain if we try to audit TASK_SIZE use
> > everywhere, because most of them are in generic code.
> >
> > And maintaining those audit code in separate place is also a
problem.
> > E.g. in current 32 bit emulation code
> > TASK_SIZE is defined as 0xfffffff in elf loading, but defined as
> > 0xffffe000 in mmaping.
> >
> > How did that earlier patch break applications?
>
> http://www.ussg.iu.edu/hypermail/linux/kernel/0408.2/1605.html
>
> I never investigated specifically what broke down