svn commit: r250411 - in head/sys: conf kern sys

[Will Andrews]

On Sun, May 12, 2013 at 12:09 AM, Alfred Perlstein <bright at mu.org> wrote:

> Can we just admit to ourselves that tweaks to debugging macros/printing
> and WITNESS are our kernel developer's "bikeshed zone" and get over the
> fact that people's needs may diverge and changing non-default behavior in
> non-critical paths is not going to be the death of the kernel as we know it?
>
> I could certainly believe that this sort of thing needs long and thorough
> discussion if it wasn't the equivalent of style tweaks to manpages.
>
> Let's leave the long and lengthy discussions to things that matter such as
> standards compliance, ABI, API and really cool performance and stability
> stuff.


Except that this is *not* the equivalent of style tweaks.  I'm not sure how
you got that from Jeff's email.  False positive LORs results in people
ignoring all LORs, including real ones.  And that impacts stability.
 Especially if you are trying to implement performance improvements or fix
bugs; in that case, the LORs act as a safeguard against violating existing
object relationship assumptions.

Having worked on ZFS for a while, I can say that many (if not most) of the
LORs reported there that are false positives are because the locks
represent objects that are frequently and legitimately related to each
other in reverse orders, due to reuse of object types at different points
in the overall hierarchy.  So, I agree that the biggest issue is that
witness's model of comparing strings is insufficient for representing more
complex lock relationships.

In ZFS, in most cases, the locks are acquired after having already (in
debug builds) checked these relationships.  It seems appropriate,
therefore, that witness should be improved by adding the ability to bless
specific object relationships on a per-lock entry basis, so that we
continue to be notified about *legitimate* LORs, at every call site and
between every pair of object types.

It also seems best to add a new API for this purpose, so that it can be
used regardless of which lock type is being used, without having to modify
all existing lock calls.  This does mean that code in FreeBSD would need to
independently verify the object relationships, but doing so is, IMHO, a lot
easier to improve upon than folding this functionality into existing APIs
by adding more arguments.

--Will.