panic: System call lstat returning with 1 locks held

Attilio Rao attilio at
Wed Jan 30 07:12:03 PST 2008

2008/1/30, Attilio Rao <attilio at>:
> 2008/1/30, Yar Tikhiy <yar at>:
> > 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:
> 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

What I forgot to mention in this log is that the patch also fixes what
seems a bug to me in the case a thread holds an exclusive lock and
tries to acquire the same lock in a shared way. What happens in
current CVS code is that the lock cames downgraded, but it seems to be
handled badly so this patch should fix the behaviour.


Peace can only be achieved by understanding - A. Einstein

More information about the freebsd-current mailing list