From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3D351C2BB85 for ; Wed, 15 Apr 2020 06:08:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0AD7C20737 for ; Wed, 15 Apr 2020 06:08:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0AD7C20737 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 979E48E0006; Wed, 15 Apr 2020 02:08:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 902968E0001; Wed, 15 Apr 2020 02:08:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7C9ED8E0006; Wed, 15 Apr 2020 02:08:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0142.hostedemail.com [216.40.44.142]) by kanga.kvack.org (Postfix) with ESMTP id 5EEC18E0001 for ; Wed, 15 Apr 2020 02:08:12 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 170334857 for ; Wed, 15 Apr 2020 06:08:12 +0000 (UTC) X-FDA: 76709059224.21.light38_81c171fd80d14 X-HE-Tag: light38_81c171fd80d14 X-Filterd-Recvd-Size: 6190 Received: from mail-pl1-f193.google.com (mail-pl1-f193.google.com [209.85.214.193]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Wed, 15 Apr 2020 06:08:11 +0000 (UTC) Received: by mail-pl1-f193.google.com with SMTP id y12so877324pll.2 for ; Tue, 14 Apr 2020 23:08:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ZUFRFKP5XHm+tVn1iBb6i8NUmk+hMwix7vSoVxV5lZQ=; b=VeqMs4sxHMnjqkliT1+slaZhoIayPzul3FEda1OGtdkNKs+7gepQstJc/QEBcjyG75 z2JTjdjujiK9/B+ZEN08rlN0FtHdmhftaHxplxUCO517etnQ044gUbw1vKF0917PE+mc X12Bsm32Y4sKHXuW2Mrt3zkYLreevr8Mj5AZ8bKL46vXZ58f58XGNCzZqANjIEEizDQs 83rYuE1HHGt0v0FAojouu/CoI2mQa/CRdmj7TklZwqo54vLflnnRJ5Mvvr/Wzf39HhWi E5R3NV2QbZTgMz1Udi1m1mfZbEtrrLncaSF1LUsDsd4xoGeJIRiItHS24YI95U0gmhwO teUQ== X-Gm-Message-State: AGi0PuYnzKKxjzaYkVZS8Wf2bvxCLZdwPpdX89QkqwUPPgx7xsbpJdIv xp+XaGDBSTYC5LyAx+MJGxE= X-Google-Smtp-Source: APiQypITe0Jo2LSazeCPOlLHzXhdbcDlQkPI1hUI+ssy+AUoQcqqY+hqTknibeyRkw3bWyzsVGcAig== X-Received: by 2002:a17:90a:aa0e:: with SMTP id k14mr4382466pjq.74.1586930890545; Tue, 14 Apr 2020 23:08:10 -0700 (PDT) Received: from 42.do-not-panic.com (42.do-not-panic.com. [157.230.128.187]) by smtp.gmail.com with ESMTPSA id q131sm7947640pfq.115.2020.04.14.23.08.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Apr 2020 23:08:08 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id DA59D40277; Wed, 15 Apr 2020 06:08:07 +0000 (UTC) Date: Wed, 15 Apr 2020 06:08:07 +0000 From: Luis Chamberlain To: Vlastimil Babka Cc: Kees Cook , Iurii Zaikin , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-mm@kvack.org, Ivan Teterevkov , Michal Hocko , David Rientjes , Matthew Wilcox , "Eric W . Biederman" , "Guilherme G . Piccoli" , Alexey Dobriyan , Thomas Gleixner , Greg Kroah-Hartman , Christian Brauner , Masami Hiramatsu 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) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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