kern/172166: Deadlock in the networking code, possible due to a bug in the SCHED_ULE

[Andriy Gapon]

The following reply was made to PR kern/172166; it has been noted by GNATS.

From: Andriy Gapon <avg at FreeBSD.org>
To: Eugene Grosbein <egrosbein at rdtc.ru>
Cc: bug-followup at FreeBSD.org, Alexander Motin <mav at FreeBSD.org>
Subject: Re: kern/172166: Deadlock in the networking code, possible due to
 a bug in the SCHED_ULE
Date: Thu, 04 Oct 2012 13:23:55 +0300

 on 04/10/2012 09:12 Eugene Grosbein said the following:
 > 03.10.2012 21:56, Andriy Gapon ÐÉÛÅÔ:
 >> on 02/10/2012 09:58 Alexander Motin said the following:
 >>> About rw_lock priority propagation locking(9) tells:
 >>> The rw_lock locks have priority propagation like mutexes, but priority can be
 >>> propagated only to an exclusive holder.  This limitation comes from the fact that
 >>> shared owners are anonymous.
 >>
 >> Yeah... and as we see it has a potential to result in priority inversion.
 >>
 >>> What's about idle stealing threshold, it was fixed in HEAD at r239194, but wasn't
 >>> merged yet. It should be trivial to merge it.
 >>
 >> And I've also misread the code, confused 6 CPUs case with 8 CPUs case.
 >>
 
 BTW, I've just noticed that the syslogd thread had td_pinned == 1 and I can't
 explain why...  But that probably explains why it was not stolen.
 
 > 
 > Can I have any advice/workaround/bugfix on how to reconfigure my routers
 > to prevent them from locking this way?
 
 As I said, the primary problem here is the ipmi thread going insane.
 You can try to remove ipmi driver, if you can afford that.
 Or you can try to hack on it, so that
 (1) it voluntary yields even when it thinks that it always has work to do
 (2) there is some diagnostic on what keeps it running
 
 You may also try to set the thread's priority to PUSER (using sched_prio), but I
 am not sure what bad side-effects may happen because of that.
 
 No magic bullet here, sorry.
 
 -- 
 Andriy Gapon