RE: [discuss] [Patch] X86_64 TASK_SIZE cleanup - more comments
From: Zou, Nanhai
Date: Wed Apr 27 2005 - 11:24:48 EST
That patch is wrong for earlier kernel. There will be a memory leak on
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
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
However I found the patch is not compatible with recent 2.6.12-rc3
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:alexn@xxxxxxxxx]
> Sent: Saturday, April 23, 2005 5:10 PM
> To: Zou, Nanhai
> Cc: Andi Kleen; discuss@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> Suresh B
> Subject: RE: [discuss] [Patch] X86_64 TASK_SIZE cleanup - more
> > PPC64 IA64 and S390 use variable size TASK_SIZE for 32 bit and 64
> > 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
> > 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?
> I never investigated specifically what broke down