On 5/9/13 3:13 PM, Attilio Rao wrote:
On Thu, May 9, 2013 at 10:56 PM, Marcel Moolenaar <mar...@xcllnt.net> wrote:
On May 9, 2013, at 9:46 AM, Attilio Rao <atti...@freebsd.org> wrote:
On Thu, May 9, 2013 at 6:28 PM, Marcel Moolenaar <mar...@freebsd.org> wrote:
Author: marcel
Date: Thu May 9 16:28:18 2013
New Revision: 250411
URL: http://svnweb.freebsd.org/changeset/base/250411
Log:
Add option WITNESS_NO_VNODE to suppress printing LORs between VNODE
locks. To support this, VNODE locks are created with the LK_IS_VNODE
flag. This flag is propagated down using the LO_IS_VNODE flag.
Note that WITNESS still records the LOR. Only the printing and the
optional entering into the kernel debugger is bypassed with the
WITNESS_NO_VNODE option.
This is the wrong way to deal with such problem and I avoided to do
something like that on purpose.
I disagree. We have known LOR messages between VNODE locks that
pollute the console and so far we haven't fixed the root cause
in some form or shape. Silencing this known case is good to
maximize the attention LORs need to be given while still have
witness involved to catch locking problems with vnodes that are
of a different nature.
The way to fix this is to implement LK_NOWITNESS on a per-lock basis
into lockmgr, propagate the same concept to the vn_lock() (which
should be basically done automatically) and finally identify the
false-positive case and commit for them explicitely LK_NOWITNESS on a
per-call basis, explaining in detail why the single case reported is a
false-positive.
This is worse. You want witness involved.
Please revert this patch asap.
This change does not inhibit people from fixing the problem at the
root cause, and in the mean time maximize witness' effectiveness.
Calling for a backout is unwarranted and unnecessarily aggressive.
I completely disagree with the whole content of your e-mail.
Thanks for disrupting a useful tool along with other commits which
happened in the past by other people about invariants effectiveness.
This should be taken offline. Marcel has some needs which without such
a change are hard to manage I encourage you to assist him and meeting
half-way on this as it will greatly help the project.
Please discuss this offline a bit so you can see where each are coming from.
If you would like to cc me about this I can help mediate and explain
this pragmatic approach to assertions.
Will you both be at BSDCan? That would be even better.
-Alfred
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
