kqueue LOR

[Kostik Belousov]

On Sat, Sep 08, 2007 at 12:58:24AM -0700, Maxim Sobolev wrote:
> Kostik Belousov wrote:
> >On Fri, Sep 07, 2007 at 11:49:50AM -0700, Maxim Sobolev wrote:
> >>Hi,
> >>
> >>On my 6.2 system I am seeing LOR discussed almost 1 year ago here:
> >>
> >>http://lists.freebsd.org/pipermail/freebsd-stable/2006-November/031048.html
> >>http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031197.html
> >>
> >>lock order reversal:
> >> 1st 0xc52cb500 kqueue (kqueue) @ kern/kern_event.c:1547
> >> 2nd 0xc4e4d80c struct mount mtx (struct mount mtx) @ 
> >>ufs/ufs/ufs_vnops.c:138
> >>
> >>Do you have any plans to commit the suggested fix?
> >I suspect that the LOR is bogus. I was never able to get the information
> >where the reverse lock order happen. What I asked of the most reporters is
> >to apply sys/kern/subr_witness.c rev. 1.222 to RELENG_6 and provide me
> >with the LOR report, if any.
> 
> What do you mean "bogus"? It happens reliably on my system.
Bogus means that reported LOR, most likely, do not cause actual deadlock.

> 
> >Note that doing that on RELENG_6_2 makes no sense, most likely you will
> >get LORs with cdev mutex, fixed in RELENG_6.
> 
> I don't quite understand that.

RELENG_6_2 had known LOR that already was fixed in RELENG_6, between
cdev mutex and and sleep mtxpool, namely LOR #197. After user have
applyed rev. 1.222 of subr_witness, I usuallygot the reports of that
LOR, if any, but not the LOR I needed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20070908/84dc135c/attachment.pgp