This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: LinuxThreads' stacks can collide with malloc


> > The stacks are unmapped at thread exit time, so if a stack region is
> > later occupied by e.g. malloc, and still later another thread is
> > started, it may corrupt the heap due to the use of MAP_FIXED to
> > re-claim the stack region.
> 
> You mean the kernel allows to mmap() with MAP_FIXED in a place below
> the sbrk?  This sounds like a kernel bug.

No, when the address space gets nearly full malloc() can allocate
chunks using mmap() (w/o MAP_FIXED) so high that they collide with the
fixed regions used by LinuxThreads for the stacks.

But anyway, MAP_FIXED definitely works below sbrk, too.  When you use
MAP_FIXED, you really must know what you're doing.  The real problem
IMHO is that it's impossible in Unix to probe whether an address range
is available for mapping with MAP_FIXED.  That would require an
additional MAP_ONLY_IF_FREE flag or something.

> > I noticed that FLOATING_STACKS can only be enabled on i686.  Wouldn't
> > the ldt tricks work on i586, too?
> 
> It does.  Most people only build i386 and i686 versions.  I wanted to
> have a way to get the version without LDT use and one with.

OK.

> In
> addition, I've never looked at the performance of the ldt use on
> anything but i686.  I think these usages were improved in modern CPUs
> since M$ is using this method, too.  On older versions it's dog slow.

Right, I'll do a performance check and let you know.

> We can of course change it to use this also for i586 but I want some
> evidence that this is really wanted.

I for one would really appreciate any change that lets us avoid
MAP_FIXED.

Regards,
Wolfram.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]