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] |
Hello, > I was pointed at a problem with the way we are using mmap() within > libpthread. It seems that the Linux kernel will kill an existing mapping > silently if you try to mmap(MAP_FIXED) on a range overlaying an existing > mapping for a task. According to SUSv2 this seems to be within spec > (http://www.opengroup.org/public/pubs/online/7908799/xsh/mmap.html): Yes, this is perfectly OK, I'm pretty sure most if not all Unices do this. > However linuxthreads/manager.c seems to rely on mmap() returning > MAP_FAILED in case you have a conflict, for instance this part: .. > Hence the question is what to do here, should one try to fix > linuxthreads to check for a conflict before trying a mapping or lobby > for the kernel to be changed? I'm currently looking into this. It has been pointed out on bug-glibc that Linux obeys the hint given by specifying an addr argument without MAP_FIXED as long as the area is unmapped, which is very useful here. So I'm working on a patch that makes use of this fact. Regards, Wolfram.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |