From owner-svn-src-all@freebsd.org Thu Jun 20 02:06:28 2019 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 958F015D09BC; Thu, 20 Jun 2019 02:06:28 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf1-f67.google.com (mail-lf1-f67.google.com [209.85.167.67]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 640138C9C0; Thu, 20 Jun 2019 02:06:27 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf1-f67.google.com with SMTP id y198so1182489lfa.1; Wed, 19 Jun 2019 19:06:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YtHJy+/mpKzzsjTU/qJOvRH6rk+xFPykHezowXt5+l8=; b=cm9ncuD4pci1azcGOL3ktPRvHbZam1Z/T3Ai9Pk7y4t2AEafxSfSNVXU54QKcrU1eJ Ze43OrK0h/4xA46tNSsPN5pJvnNE3HECse4OmPxQqO+Y3aDESBleABpn+GQ2YVce7vIE yyBGh1ZB8GgmKu3M0/x25/Zrs72duJFivImJYxduZOBXOmau2t1eFoCQlDhqLmU2ehqe eFQ+kxaxOjcyfXc1Pj2db0weEHlwmQyISAY8pYuNh3USUXobsCAqjC5Q5KqnDl6UcQAL w1yiSA7mYv9DEAzsR+jhTGj4ECEhU6SA6rqXrtq08gKm9gRU1VtmTmoCSCZ1i5U27iqT 1o2w== X-Gm-Message-State: APjAAAVy0djYEyn2o5Lyf6wQMkPFOq0E48H1C7P2eInqObEWORiuR03T mNjSBR4tbMSxHK6RyeOSt4uI8K4tpHuThrDof660yT0W X-Google-Smtp-Source: APXvYqx8Eb4htL5wIovPsty0hh+/RCgWxTqQWXjKbXr60PrN4Yo+RiSBBAImG8uXq3Q17VyAmmYu3XZFvBGp0o5ktrI= X-Received: by 2002:ac2:5324:: with SMTP id f4mr23057562lfh.156.1560996384953; Wed, 19 Jun 2019 19:06:24 -0700 (PDT) MIME-Version: 1.0 References: <201906061504.x56F4odw034764@repo.freebsd.org> <201906061735.x56HZGIJ058845@gndrsh.dnsmgr.net> <62763406801d603b0dda6ff4754bf7e9b714a8e0.camel@freebsd.org> In-Reply-To: From: Alan Somers Date: Wed, 19 Jun 2019 20:06:13 -0600 Message-ID: Subject: Re: svn commit: r348737 - head/sys/kern To: John Baldwin Cc: Ian Lepore , "Rodney W. Grimes" , src-committers , svn-src-all , svn-src-head Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 640138C9C0 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.167.67 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-3.88 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_FIVE(0.00)[6]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-1.16)[ipnet: 209.85.128.0/17(-3.43), asn: 15169(-2.31), country: US(-0.06)]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.71)[-0.710,0]; RCVD_IN_DNSWL_NONE(0.00)[67.167.85.209.list.dnswl.org : 127.0.5.0]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[67.167.85.209.rep.mailspike.net : 127.0.0.17]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 02:06:28 -0000 On Thu, Jun 6, 2019 at 2:02 PM John Baldwin 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 wrote: > >>> > >>> On 6/6/19 10:39 AM, Alan Somers wrote: > >>>> On Thu, Jun 6, 2019 at 11:35 AM Rodney W. Grimes > >>>> 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