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 A5A17C43331 for ; Thu, 2 Apr 2020 16:04:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 705CD20737 for ; Thu, 2 Apr 2020 16:04:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 705CD20737 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 138808E0009; Thu, 2 Apr 2020 12:04:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C4418E0007; Thu, 2 Apr 2020 12:04:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EA5988E0009; Thu, 2 Apr 2020 12:04:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0028.hostedemail.com [216.40.44.28]) by kanga.kvack.org (Postfix) with ESMTP id C998F8E0007 for ; Thu, 2 Apr 2020 12:04:46 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 941A2499612 for ; Thu, 2 Apr 2020 16:04:46 +0000 (UTC) X-FDA: 76663388172.07.cars45_46c24c6add43a X-HE-Tag: cars45_46c24c6add43a X-Filterd-Recvd-Size: 6781 Received: from mail-pj1-f67.google.com (mail-pj1-f67.google.com [209.85.216.67]) by imf50.hostedemail.com (Postfix) with ESMTP for ; Thu, 2 Apr 2020 16:04:46 +0000 (UTC) Received: by mail-pj1-f67.google.com with SMTP id kx8so1670930pjb.5 for ; Thu, 02 Apr 2020 09:04:46 -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=VAdtQeZG1W5hggzwlZjx1TjdJy3EIjRqPxs+2mgheWo=; b=SH757aKez9zEyprZnILL5ryo6WasgXo/B7xiM3alNByhCvwptjNmsw4T/Nh3O3vRrX alGOMHpdNv+SHOESpXTIQuWM1fhh0P0cZqw0QFlTRUVIpP+/NqLuxR//TsgREn1vZrGo B/EUN2x5qIcyKJ9Tj8u6pdvlDMDn1NAJvG70xA1trj7lOHan+dvL7V/D4inSETHsrpEV cOkV/Nn9ihGTEo5EPJFGJ82vcIytOxT54F2AylmAhlJjb47ulTP92V3C+Kx30+ZsUoDr OL3hKj2ayRyAduqVPOm8QgcjljxhDTu8TyVrARnDyEMdsHe6ozQvjkX4s6wrDhg1R7F6 JWzA== X-Gm-Message-State: AGi0PubC+9t96lmXZpyxdPwB2QOqjeFkoUhDJH9hCPuMbwxoAtJOTDZn f1LC3pIyt/w8TAsKiQszD6g= X-Google-Smtp-Source: APiQypLGf0t35D4GpzRZlLXnQ+AE2f8f9vge/ycWTZ41fuOR44A9Ncby4ouXoBP9j0rzBrPD0Ueoxg== X-Received: by 2002:a17:90a:bb88:: with SMTP id v8mr4688532pjr.54.1585843485016; Thu, 02 Apr 2020 09:04:45 -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 f9sm2907508pgj.2.2020.04.02.09.04.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Apr 2020 09:04:43 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id D687F40254; Thu, 2 Apr 2020 16:04:42 +0000 (UTC) Date: Thu, 2 Apr 2020 16:04:42 +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 Subject: Re: [PATCH 1/3] kernel/sysctl: support setting sysctl parameters from kernel command line Message-ID: <20200402160442.GA11244@42.do-not-panic.com> References: <20200330115535.3215-1-vbabka@suse.cz> <20200330115535.3215-2-vbabka@suse.cz> <20200330224422.GX11244@42.do-not-panic.com> <287ac6ae-a898-3e68-c7d8-4c1d17a40db9@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <287ac6ae-a898-3e68-c7d8-4c1d17a40db9@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 Wed, Apr 01, 2020 at 01:01:47PM +0200, Vlastimil Babka wrote: > On 3/31/20 12:44 AM, Luis Chamberlain wrote: > >> + } else if (wret != len) { > >> + pr_err("Wrote only %ld bytes of %d writing to proc file %s to set sysctl parameter '%s=%s'", > >> + wret, len, path, param, val); > >> + } > >> + > >> + err = filp_close(file, NULL); > >> + if (err) > >> + pr_err("Error %pe closing proc file to set sysctl parameter '%s=%s'", > >> + ERR_PTR(err), param, val); > >> +out: > >> + kfree(path); > >> + return 0; > >> +} > >> + > >> +void do_sysctl_args(void) > >> +{ > >> + char *command_line; > >> + struct vfsmount *proc_mnt = NULL; > >> + > >> + command_line = kstrdup(saved_command_line, GFP_KERNEL); > > > > can you use kstrndup() ? And then use kfree_const()? Yes, feel free to > > I don't follow, what am I missing? Do you mean this? > > size_t len = strlen(saved_command_line); > command_line = kstrndup(saved_command_line, len, GFP_KERNEL); > > What would be the advantage over plain kstrdup()? > As for kfree_const(), when would command_line be .rodata? I don't see using > kstrndup() resulting in that. The const nature of using kstrdup() comes with using const for your purpose. ie: const char *const_command_line = saved_command_line; The point of a kstrncpy() then is to ensure force a const throughout your use if you know you don't need modifications. > > move __kstrncpy() to a generic kstrncpy(). > > > >> + if (!command_line) > >> + panic("%s: Failed to allocate copy of command line\n", __func__); > >> + > >> + parse_args("Setting sysctl args", command_line, > >> + NULL, 0, -1, -1, &proc_mnt, process_sysctl_arg); > >> + > >> + if (proc_mnt) > >> + kern_unmount(proc_mnt); > >> + > >> + kfree(command_line); > >> +} > > > > Then, can we get this tested as part of lib/test_sysctl.c with its > > respective tools/testing/selftests/sysctl/sysctl.sh ? > > Hmm so I add some sysctl to the test "module" (in fact the 'config' file says it > should be build with 'y', which would be needed anyway) and expand the test > instructions so that the test kernel boot has to include it on the command line, > and then I verify it has been set? Or do you see a better way? We don't necessarily have a way to test the use boot params today. That reveals an are which we should eventually put some focus on in the future. In the meantime we have to deal with what we have. So let's think about this: You are adding a new cmdline sysctl boot param, and also a wrapper for those old boot bootparams to also work using both new sysctl path and old path. Testing just these both should suffice. How about this: For testing the new feature you are adding, can you extend the default boot params *always* if a new CONFIG_TEST_SYSCTL_CMDLINE is set? Then upon boot we can verify the proc handlers for these new boot params got kicked, and likewise some other proc handlers which also can be used from the cmdline are *not* set. For this later set, we already have a series of test syctls you can use. In fact, you can use the existing syctls for both cases already I believe, its just a matter of adding this new CONFIG_TEST_SYSCTL_CMDLINE which would extend the cmdline, and these tests would take place *first* on the script. That would test both cases with one kernel. You could then also add a bogus new sysctl which also expands to a silly raw boot param to test the wrapper you are providing. That would be the only new test syctl you would need to add. If you can think of a way to *break* your new functionality and ensure it doesn't break the kernel, even better. Luis