On Wednesday 14 December 2005 04:05, Sven Köhler 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 new process at startup (i.e. after exec!) calls set_thread_area(). But that's normal. b) I know that in clone()*, and I presume that in fork(), the pid cache must 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 wants to puzzle with the TLS content. * We know that as glibc once didn't and UML was the one user of clone() + getpid(), and we discovered the hard way that glibc forgot that. Workarounded with a real getpid(). At bug report time we got an angry Ulrich saying "it's already fixed in latest version", luckily. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Messenger: chiamate gratuite in tutto il mondo http://it.messenger.yahoo.com ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
