> Hmm, the only thing I touched in svc.c is a jiffy wrap issue. I don't
Ah you mean the patch I done at schedule_timeout() implementation time!!
Yes, it could have caused the bug:
/* Go to sleep waiting for GRANT callback. Some servers seem
* to lose callbacks, however, so we're going to poll from
* time to time just to make sure.
*
* For now, the retry frequency is pretty high; normally
* a 1 minute timeout would do. See the comment before
* nlmclnt_lock for an explanation.
*/
/*
* FIXME, can we be not interruptible and so be allowed to use
* a timeout here? -arca
*/
/* current->timeout = jiffies + 30 * HZ; */
sleep_on(&block.b_wait);
Unfortunately I don't know what the code does. I don't know if we could be
allowed to use sleep_on_interruptible() and to care signals at that time.
In such case you could replace the two lines of code with:
interruptible_sleep_on_timeout(&block.b_wait, 30 * HZ);
Doing that you are sure to avoid the deadlock, but you risk to exit from
the sleep_on() too early if a signal will be sent to the process that is
sleeping...
In the case interruptible_sleep_on() is not allowed we could
implement a sleep_on_timeout() just to avoid code duplication
putting a timer in lockd by hand, because now schedule_timeout()
handle the UNINTERRUPTIBLE state fine.
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/