On Wednesday 14 December 2005 04:05, Sven K=F6hler wrote:
> > e2fsprogs-1.38/misc/fsck.c:check_all() repeatedly invokes fsck_device(),
> > which invokes execute(), which does a perfectly normal fork()/exec().
> > No threads here. Nor is there use of aio_*(), which might use threads
> > (well, POSIX allows it).
> Sorry, and what's the conclusion?
> fork() calles set_thread_area()?
Interesting... yep, it could.
Ok, picture down:
a) in NPTL, getpid() caches the result of the syscall in the TLS - so each =
process at startup (i.e. after exec!) calls set_thread_area(). But that's=20
b) I know that in clone()*, and I presume that in fork(), the pid cache mus=
be invalidated / updated. So while fork() maybe doesn't use set_thread_area=
(and it could, seeing that no TLS setup has been done, and retrying) it wan=
to puzzle with the TLS content.
* We know that as glibc once didn't and UML was the one user of clone() +=20
getpid(), and we discovered the hard way that glibc forgot that. Workaround=
with a real getpid().
At bug report time we got an angry Ulrich saying "it's already fixed in lat=
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
Yahoo! Messenger: chiamate gratuite in tutto il mondo