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

[Alfred Perlstein]

On 5/9/13 3:13 PM, Attilio Rao wrote:
> On Thu, May 9, 2013 at 10:56 PM, Marcel Moolenaar <marcel at xcllnt.net> wrote:
>> On May 9, 2013, at 9:46 AM, Attilio Rao <attilio at freebsd.org> wrote:
>>
>>> On Thu, May 9, 2013 at 6:28 PM, Marcel Moolenaar <marcel at 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