On Wed, 30 Mar 2005, Muli Ben-Yehuda wrote: > On Wed, Mar 30, 2005 at 05:19:23PM +0200, guy keren wrote: > > > since when does 'D' state means a process is holding a lock? there are > > many situations in the kernel that processes are put to sleep while not > > holding any lock (at least as far as i saw - and i'm talking about 2.6 > > kernels) - unless the lock-taking was done much, much earlier. > > D means TASK_UNINTERRUPTIBLE. I believe the most common reason to be > in TASK_UNINTERRUPTIBLE state is to hold a semaphore, but there could > certainly be other cases.
"to hold" a semaphore, or "because we're already holding some other semaphore"? i fail to see why there's a need to be in TASK_UNINTERRUPTIBLE if you don't yet have the semaphore - use down_interruptible, and if you have a signal, fail te operation with EINTR. the problem is, some parts of the kernel _force_ you to use down instead of down_interruptible, as i found out the hard way... > > by the way, with 'holding a lock', do you also talk about 'having a page > > from the page cache marked as locked'? > > I don't think so, why? because it looks like block drivers _must_ use down and not down_interruptible to get hold of semaphores - they are not allowed to have a temporary failure for I/O requests, because the upper layer (page cache or whoever invoked the request) does not check for EINTR - it just fails the request with an I/O error. -- guy "For world domination - press 1, or dial 0, and please hold, for the creator." -- nob o. dy ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
