On Thu, May 12, 2022 at 09:56:46AM -0400, Theodore Ts'o wrote:
> On Thu, May 12, 2022 at 08:18:24PM +0900, Byungchul Park wrote:
> > I have a question about this one. Yes, it would never been stuck thanks
> > to timeout. However, IIUC, timeouts are not supposed to expire in normal
> > cases. So I
Hello,
On Thu, May 12, 2022 at 08:18:24PM +0900, Byungchul Park wrote:
> > 1. wait_for_completion_killable_timeout() doesn't need someone to wake it up
> >to make forward progress because it will unstick itself after timeout
> >expires.
>
> I have a question about this one. Yes, it would
On Thu, May 12, 2022 at 08:18:24PM +0900, Byungchul Park wrote:
> I have a question about this one. Yes, it would never been stuck thanks
> to timeout. However, IIUC, timeouts are not supposed to expire in normal
> cases. So I thought a timeout expiration means not a normal case so need
> to
Tejun wrote:
> Hello,
Hello,
> I'm not sure I'm reading it correctly but it looks like "process B" column
I think you're interpreting the report correctly.
> is superflous given that it's waiting on the same lock to do the same thing
> that A is already doing (besides, you can't really halt
Hello,
Just took a look out of curiosity.
On Thu, May 12, 2022 at 02:25:57PM +0900, Byungchul Park wrote:
> PROCESS A PROCESS B WORKER C
>
> __do_sys_reboot()
> __do_sys_reboot()
> mutex_lock(_transition_mutex)
> ... mutex_lock(_transition_mutex) <- stuck
>
+cc mcg...@kernel.org (firmware)
+cc h...@sgi.com (syscall reboot)
Hi Luis, Robin and folks,
I'm developing a tool for lockup detection, DETP(Dependency Tracker).
I got a DEPT report from Hyeonggon - Thanks, Hyeonggon!
It doesn't mean the code *definitely* has a deadlock. However, it looks
