svn commit: r348737 - head/sys/kern

[John Baldwin]

On 6/6/19 11:21 AM, Ian Lepore wrote:
> On Thu, 2019-06-06 at 12:04 -0600, Alan Somers wrote:
>> On Thu, Jun 6, 2019 at 12:01 PM John Baldwin <jhb at freebsd.org> wrote:
>>>
>>> On 6/6/19 10:39 AM, Alan Somers wrote:
>>>> On Thu, Jun 6, 2019 at 11:35 AM Rodney W. Grimes
>>>> <freebsd at gndrsh.dnsmgr.net> wrote:
>>>>>
>>>>>> Author: asomers
>>>>>> Date: Thu Jun  6 15:04:50 2019
>>>>>> New Revision: 348737
>>>>>> URL: https://svnweb.freebsd.org/changeset/base/348737
>>>>>>
>>>>>> Log:
>>>>>>   Add a testing facility to manually reclaim a vnode
>>>>>>
>>>>>>   Add the debug.try_reclaim_vnode sysctl. When a pathname is
>>>>>> written to it, it
>>>>>>   will be reclaimed, as long as it isn't already or doomed.
>>>>>> The purpose is to
>>>>>>   gain test coverage for vnode reclamation, which is
>>>>>> otherwise hard to
>>>>>>   achieve.
>>>>>>
>>>>>>   Add the debug.ftry_reclaim_vnode sysctl.  It does the same
>>>>>> thing, except
>>>>>>   that its argument is a file descriptor instead of a
>>>>>> pathname.
>>>>>
>>>>> Should not this all be wrapped in some #ifdef or other
>>>>> protection,
>>>>> is it really a good idea to have this on every single box
>>>>> running
>>>>> FreeBSD?
>>>>
>>>> I initially thought so too, but kib thought that it could be
>>>> useful
>>>> for debugging problems in the field.  The potential downside is
>>>> limited, because only root can write to the sysctls, and the
>>>> worse-case damage is similar to a "umount -f".
>>>
>>> A compromise might be to stick this in a kernel module instead of
>>> in the
>>> base kernel.  You could still kldload it in the field for debugging
>>> but
>>> not necessarily have it directly available out of the box.
>>>
>>> --
>>> John Baldwin
>>
>> If we already had such a module, it would make sense to put these
>> sysctls in there.  But I don't want to create an entire module for
>> just a few dozen LOC.  Nor do I want to mediate a bike shed.  So
>> let's
>> vote.  kib already registered a vote for making them available all of
>> the time.  rgrimes voted to guard them by INVARIANTS.  Anybody else
>> who cares can reply to this thread.  I'll count the votes in 24
>> hours.
>> -Alan
>>
> 
> If our new policy is to remove sysctls that aren't used often "because
> something bad might happen" (without any requirement for the complainer
> to elaborate on just what might happen or why it's so much worse than
> the damage a root user could do with any other sysctl), I think several
> people could be employed full time doing that removal work.  Or we
> could all just get on with doing some real work.

What I find a bit different about this case is when it's a debugging
knob.  For that sort of thing, kernel modules are a pretty decent way
to inject new functionality into the system that is rarely needed.  A
while back I had a problem with resume on a laptop seemingly not
unsticking all of the processes that had been paused via stop_all and had
a hacky kernel module with a magic sysctl that would try to unstick things.
That worked better as a module that I only loaded if needed.  Similar for
a hacky kernel module at a previous job (killsmi.ko) that would write to
the appropriate ICH register to disable all SMIs when loaded, etc.

-- 
John Baldwin