threads and libc/stdlib/malloc

[Robin Getz]

Hi.

In Oct of 2002 (based on a 2.4.19 kernel), Miles Bader added support for 
pthreads in the malloc code for uClinux (noMMU), and needed (at the time) to 
work around some issues in broken kernel munmap.

Discussion is at:
http://osdir.com/ml/lib.uclibc.general/2002-10/msg00100.html

Commit is at:
http://uclibc.org/cgi-bin/viewcvs.cgi?rev=5634&view=rev

Commit message is:
* Add support for uClinux's broken munmap, contingent on
  __UCLIBC_UCLINUX_BROKEN_MUNMAP__ (which is currently not defined anywhere).
  This makes other cases a tiny bit less efficient too.

Question:

Jie noticed when digging into an issue, that there is a race condition in 
malloc/free for multi-threading applications.

When Miles added things, to work around the 2.4 kernel's munmap brokeness in 
noMMU mode, libc/stdlib/malloc in uClibc uses a linked list of structure mmb 
to deal with the problem in user space. The issue is the linked list is not 
thread safe...

Can someone with the history describe the "broken" munmap, and we can 
determine if it still exists on recent kernels (which have much better 
mmap/munmap support due to David Howells' efforts).

Jie has a patch for the existing uClibc's malloc (libc/stdlib/malloc) for the 
issues that he found, but I was wondering if the best thing would be to 
remove the UCLINUX_BROKEN_MUNMAP__ (because it isn't anymore), or if the 
userspace workarounds are still needed on a 2.6.x kernel?

Thanks
-Robin