svn commit: r275751 - in head: share/man/man9 sys/kern sys/sys

[Mateusz Guzik]

On Sat, Dec 13, 2014 at 10:10:18PM -0500, Benjamin Kaduk wrote:
> On Sat, 13 Dec 2014, Mateusz Guzik wrote:
> 
> > I think the actual question was when would you call _init_flags and not
> > want _NEW and it would have a potential to detect double init.
> 
> That is a fine question to ask, but it is not the one I was trying to ask.
> 
> I can answer yours, though: it detects when buggy code is using
> uninitialized memory for a structure that needs initialization.
> 

It detects when provided memory happens to not be zeroed, which may or
may not violate a requirement for the structure which contains given lock.

I'm guessing the rationale is to simply not have to call malloc with
M_ZERO just to satisfy invariants.

But then who and where would not want to use this _NEW flag?

> If I remember correctly, the need for
> https://github.com/openafs/openafs/commit/64da7c133a66a15233c2cdc5d9a8f71d17d80d77
> was detected by this feature of WITNESS.
> 

This sounds valid, but does not answer my concern, see above.

> > I think a better approach would be to have a hash with addresses of all
> > locks in use. Then _init/_destroy would add/remove it respectively and
> > we would not be dependent on the state of the lock (e.g. struct could be
> > zeroed by unrelated code and then double init is not detected).
> >
> > Chains locked separately of course.
> >
> > I didn't try that, should be totally fine for invariants.
> 
> That is an interesting proposal, which might be better than the current
> state of affairs.  (I am not signing up to implement it, though.)
> 

Turns out even production code contains some witness-related structs, so
growing it just to accomodate for this feature may not be as easy.

Someone(tm) will have to check what's the point (I doubt production
modules run on debug kernels, at least not reliably).

-- 
Mateusz Guzik <mjguzik gmail.com>