httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: fcntl hanging without anyone holding the lock?
Date Mon, 26 Apr 1999 18:22:19 GMT
On Thu, 22 Apr 1999, Manoj Kasichainula wrote:

> On Tue, Apr 20, 1999 at 10:15:40PM -0700, Dean Gaudet wrote:
> > The fcntl() stuff is shared by the CLONE_FS option to clone() -- are you
> > sure the linuxthread manager thread isn't still hanging around with the
> > shared struct?
> The manager thread is definitely hanging around in this case, as its
> supposed to. But it's not holding the lock (at least as far as lsof
> knows). Is this what you mean?

strace a simple linuxthread program and find the clone() call which
creates the manager thread.  Look to see if CLONE_FILES is set in that
clone call (it should be set in all clone calls which create user-visible
threads, I'm guessing it's also set in the manager thread).  If that's the
case, the fd table is shared.  The locking information is part of the fd
table.  So the manager thread probably shares the lock (and lsof is
probably misleading you). 

> > Your best bet right now is to hack up the test/test-mutex (or whatever
> > it's called) and reproduce the problem... make a small test case and mail
> > it to linux-kernel.  This sounds like a kernel bug.
> I'm working on this. Just wrapping the fcntl with
> pthread_mutex_[un]locks didn't trigger the problem. But, this bug
> isn't triggered when the child processes are gracefully shutdown (i.e.
> lsof will report a *thread* as having a lock rather than each thread
> in the process. My gut feeling is that we're hitting the same problem
> as pthread process locks, and that a thread with the lock that dies
> doesn't release its lock. I don't know why this would be triggered by
> the pthread calls wrapping fcntl, though.

Yeah, the kernel structure for the locks includes the pid -- which with
linuxthreads is essentially the same as the tid.  And the structure/locks
aren't cleared until the process exits.  Reading the "single unix" 
reference this seems to be correct.  (Undesirable, but correct.)

Although there appears to be a DoS attack possible with pid reuse. 

I haven't tested any of this, I just eyeballed the kernel source. 


View raw message