Date: Wed, 19 Jun 2019 20:06:13 -0600 From: Alan Somers <asomers@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: Ian Lepore <ian@freebsd.org>, "Rodney W. Grimes" <rgrimes@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r348737 - head/sys/kern Message-ID: <CAOtMX2gyqgHjRk8Pz6q4ppTN9jx4HUM6GVaKXdnEBiuA6-VwuA@mail.gmail.com> In-Reply-To: <cf2709c0-bc87-f158-5979-a80830695583@FreeBSD.org> References: <201906061504.x56F4odw034764@repo.freebsd.org> <201906061735.x56HZGIJ058845@gndrsh.dnsmgr.net> <CAOtMX2iQ=Q9tR2MviXQDRqs_UNW6gQq=BGiDpNwXbpWjG%2BH7CQ@mail.gmail.com> <c6d9a869-d678-212b-0bc6-d0046f892e76@FreeBSD.org> <CAOtMX2jvfnXx35DoV3JBGeVcm%2BDtbd4HWmqFBSNNEbGO4eBa9Q@mail.gmail.com> <62763406801d603b0dda6ff4754bf7e9b714a8e0.camel@freebsd.org> <cf2709c0-bc87-f158-5979-a80830695583@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 6, 2019 at 2:02 PM John Baldwin <jhb@freebsd.org> wrote: > > 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@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@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 It's been two weeks, and the vote tally is: * Unconditional: 3 * Module: 2 * Don't care/Get on with bigger problems: 2 Unconditional wins the vote. Though if rgrimes goes to the trouble of writing the module, I'll review it. -Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2gyqgHjRk8Pz6q4ppTN9jx4HUM6GVaKXdnEBiuA6-VwuA>