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.
pgpbplIHuZo3G.pgp
Description: PGP signature