RE: Debugging kernel semaphore contention and priority inversion

Davda, Bhavesh P (Bhavesh)
2005-08-18T03:43:37Z

> From: Keith Mannthey [mailto:kmannth@gmail.com]
> Sent: Wednesday, August 17, 2005 5:33 PM
>
> On 8/17/05, Davda, Bhavesh P (Bhavesh) <bhavesh@avaya.com> wrote:
> > Is there a way to know which task has a particular (struct
> semaphore
> > *) down()ed, leading to another task's down() blocking on it?
>
> I would add a field to struct semaphore that tracks the
> current process.
> In your various up and downs have that field tracks the
> "current" process.

Yeah, I thought about that. Unfortunately, it doesn't meet my need for
not Heisenberg'ing the system. I can't instrument the struct semaphore
{} in a running system.

>
> Do you know what semaphore it is?

Yes. It is an inode->i_sem semaphore for a file being written to by the
high-priority SCHED_FIFO task.

>
> This way you dump the semaphore you can see what task it is
> holding it. Have the module dump the semaphore and you can
> id the task
>
> > It would be helpful to get a kernel stacktrace for the culprit too.
>
> Have you tried sysrq t? See the Documentation/sysrq.txt file.

This is a headless system.

>
> How stuck is the system?
>
> Keith

Very. Only pingable, but can't login via telnet/ssh/anything. Reason is
the same reason the low priority mystery task is unable to run and
release the held semaphore.

Thanks

- Bhavesh

Bhavesh P. Davda | Distinguished Member of Technical Staff | Avaya |
1300 West 120th Avenue | B3-B03 | Westminster, CO 80234 | U.S.A. |
Voice/Fax: 303.538.4438 | bhavesh@avaya.com