Hi Andi,
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?
Thanks
Zou Nan hai
> -----Original Message-----
> From: Andi Kleen [mailto:[email protected]]
> Sent: Thursday, April 21, 2005 7:54 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
>
>
> Another comment:
>
> In general I am not too happy about the variable size TASK_SIZE.
> There was a patch for this earlier, but it broke 32bit emulation
> completely. And I think it needs auditing of all uses of TASK_SIZE,
> because I suspect there are more bugs lurking in it.
>
> The way hugetlb etc. mmap were supposed to be handled was to
> let the mmap succeed and then check in the mmap wrapper
> if any address is > 4GB and free it. Probably that code
> has some problems or got broken (I think it worked at least
> in 2.4, but there might have been regressions later)
>
> -Andi
> 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