2008/1/30, Attilio Rao <attilio@freebsd.org>:
quoted text
> 2008/1/30, Yar Tikhiy <yar@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

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.

Attilio

-- 
Peace can only be achieved by understanding - A. Einstein
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"