Hi Andi,
What is your comment on this patch?
Here is another example bug this patch will fix.
The following piece of code will get a success mmap even if compiled
with -m32.
int *p;
p = mmap((void *)(0xFFFFE000UL), 0x10000UL, PROT_READ|PROT_WRITE,
MAP_FIXED|MAP_PRIVATE|MAP_ANON, 0, 0);
I believe there are other kind of corner case bugs around mm and fs.
e.g in mremap and munmap.
Those bugs will be fixed by this patch.
Zou Nan hai
> -----Original Message-----
> From: Zou, Nanhai
> Sent: Tuesday, April 19, 2005 12:37 AM
> To: 'Andi Kleen'
> Cc: [email protected]; [email protected]; Siddha, Suresh B
> Subject: RE: [discuss] [Patch] X86_64 TASK_SIZE cleanup
>
>
> When a 32bit program is mapping a lot of hugepage vm_areas,
> hugetlb_get_unmapped_area may search beyond 4G, then the program will
get a
> SIGFAULT instead of an errno of ENOMEM.
> This patch will fix that.
> I believe there are other inconsistent cases in generic code like mm
and fs.
>
> Zou Nan hai
>
> > -----Original Message-----
> > From: Andi Kleen [mailto:[email protected]]
> > Sent: Monday, April 18, 2005 5:06 PM
> > To: Zou, Nanhai
> > Cc: [email protected]; Andi Kleen; [email protected];
Siddha,
> > Suresh B
> > Subject: Re: [discuss] [Patch] X86_64 TASK_SIZE cleanup
> >
> > On Sat, Apr 16, 2005 at 09:34:25AM +0800, Zou, Nanhai wrote:
> > >
> > > Hi,
> > > This patch will clean up the X86_64 compatibility mode
TASK_SIZE
> > > define thus fix some bugs found in X86_64 compatibility mode
program.
> >
> > Fix what bugs exactly? Please a detailed description.
> >
> > -Andi
On Thu, Apr 21, 2005 at 01:17:40AM +0800, Zou, Nanhai wrote:
> Hi Andi,
> What is your comment on this patch?
There is at least one wrong change in there, you have a check
for test_thread_flag(TIF_IA32) && (flags & MAP_32BIT)
and that is wrong because MAP_32BIT is used from 64bit code
-Andi
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