Re: panic: System call lstat returning with 1 locks held

2008/1/30, Yar Tikhiy <yar_at_comp.chem.msu.su>:
> On Tue, Jan 29, 2008 at 11:11:13PM +0100, Attilio Rao wrote:
> >
> > I'm committing my WITNESS patch now to perforce so that other people
> > can hopefully stress-test it before to be committed.
>
> Do you think that that patch is applicable in my case?  I.e., shall
> I use it to get more debug info on my panics?
>
> If so, where is the patched file in the depot?

Sorry but I had to delay the operation so far.
In the end, a suitable patch is located here:
http://www.freebsd.org/~attilio/witness_lockmgr.diff

I tried it and it alredy reported 4 LORs just when booting the kernel :)
So I would expect reasonably LOR cascades with this patch.

If you all 3 (Scot, Yar and Doug) could try and test it I would
appreciate a lot.

Thanks,
Attilio

PS: This is the commit log to perforce:
Add WITNESS support to lockmgr.
       A couple of notes:
       - Two options have been added in order to serve WITNESS:
               * LK_NOWITNESS which disables the support for the specified
                 lock
               * LK_NODUP which disallows the usual DUPOK behaviour
                 assumed as the default with lockmgr
       - In the case of lockmgr_disown() the lock is simply dropped.
         This means that a printout won't show the lock held even if it
         is basically held by LK_KERNPROC
       - In the case of upgrade we can have 3 different cases:
               * The shared lock is unheld but consequent acquisition
                 fails; in this case the lock is reported dropped
               * We are the first upgrader so there is an effective
                 WITNESS_UPGRADE
               * We are not the first upgrader so after the shared unlocking
                 we need to acquire the lock in exclusive mode; this will be
                 reported with 2 different WITNESS steps.
       - In the case of LK_DRAIN the lock will be only checked about the
         order but it won't be marked as acquired. This happens because a
         drained lock is directly destroyed and not really released, so
         witness_destroy() would badly panic in this case