Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 15 Apr 2020 06:08:07 +0000
From:   Luis Chamberlain <mcgrof@kernel.org>
To:     Vlastimil Babka <vbabka@suse.cz>
Cc:     Kees Cook <keescook@chromium.org>,
        Iurii Zaikin <yzaikin@google.com>,
        linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
        linux-mm@kvack.org, Ivan Teterevkov <ivan.teterevkov@nutanix.com>,
        Michal Hocko <mhocko@kernel.org>,
        David Rientjes <rientjes@google.com>,
        Matthew Wilcox <willy@infradead.org>,
        "Eric W . Biederman" <ebiederm@xmission.com>,
        "Guilherme G . Piccoli" <gpiccoli@canonical.com>,
        Alexey Dobriyan <adobriyan@gmail.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Christian Brauner <christian.brauner@ubuntu.com>,
        Masami Hiramatsu <mhiramat@kernel.org>
Subject: Re: [PATCH 1/3] kernel/sysctl: support setting sysctl parameters
 from kernel command line
Message-ID: <20200415060807.GR11244@42.do-not-panic.com>
References: <20200330224422.GX11244@42.do-not-panic.com>
 <287ac6ae-a898-3e68-c7d8-4c1d17a40db9@suse.cz>
 <20200402160442.GA11244@42.do-not-panic.com>
 <202004021017.3A23B759@keescook>
 <20200402205932.GM11244@42.do-not-panic.com>
 <202004031654.C4389A04EF@keescook>
 <20200406140836.GA11244@42.do-not-panic.com>
 <202004060856.6BC17C5C99@keescook>
 <20200406170822.GE11244@42.do-not-panic.com>
 <7585f0b0-c5d2-b527-aac7-eeafdd15ffad@suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7585f0b0-c5d2-b527-aac7-eeafdd15ffad@suse.cz>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Apr 14, 2020 at 01:25:07PM +0200, Vlastimil Babka wrote:
> On 4/6/20 7:08 PM, Luis Chamberlain wrote:
> > On Mon, Apr 06, 2020 at 08:58:50AM -0700, Kees Cook wrote:
> >> On Mon, Apr 06, 2020 at 02:08:36PM +0000, Luis Chamberlain wrote:
> >> > > Yes. Doing an internal extension isn't testing the actual code.
> >> > 
> >> > But it would.
> >> > 
> >> > [...]
> >> > > I don't think anything is needed for this series. It can be boot tested
> >> > > manually.
> >> > 
> >> > Why test it manually when it could be tested automatically with a new kconfig?
> >> 
> >> So, my impression is that adding code to the internals to test the
> >> internals isn't a valid test (or at least makes it fragile) because the
> >> test would depend on the changes to the internals (or at least depend on
> >> non-default non-production CONFIGs).
> > 
> > The *internal* aspect here is an extension to boot params under a
> > kconfig which would simply append to it, as if the user would have
> 
> So there's no such kconfig yet to apply boot parameters specified by configure,
> right? That would itself be a new feature.

I cannot say, there is no easy grammatical expression for this. For
kernel testing, no, I am not aware of one.

> Or could we use bootconfig? (CC Masami)

Neat, yeah, that seems like a set of helpers of which could help for
sure.

> >> Regardless of testing, I think this series is ready for -mm.
> > 
> > I'm happy for it to go in provided we at least devise a follow up plan
> > for testing. Otherwise -- like other things, it won't get done.
> 
> OK I'll send a v2 and we can discuss the test driver details. I don't want to
> neglect testing, but also not block the new functionality,

So long as the testing part gets done, I'm happy :)

> in case it means
> testing means adding another new functionality.

Yeah, I can see how some new code may need to be added for that, its a
good point.

But think about this for a second, if we *didn't* have such code added,
how could it have easily been tested before? The question is rhetorical,
as I'm alluding to that a lot of old code wasn't designed for easy unit
testing either, and I'd invite one to consider the value of the change
in philosophy on first code design when one *does* take that into
consideration. There are certain best practices that I'd wager are
probably good for us to evaluate for the long term of kernel evolution,
and I think that always advocating designing testing around new
functionality would be one.

Once and if you do add your testing, and if such testing is expanded to
test parsing the cmdline further, and to purposely break it, who knows
what other bugs bugs we'll find.

But maybe Masami already uncovered all the fun bugs.

  Luis