Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759481AbcLPH6x (ORCPT ); Fri, 16 Dec 2016 02:58:53 -0500 Received: from mx2.suse.de ([195.135.220.15]:54309 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753126AbcLPH6e (ORCPT ); Fri, 16 Dec 2016 02:58:34 -0500 Date: Fri, 16 Dec 2016 08:57:26 +0100 From: "Luis R. Rodriguez" To: Petr Mladek Cc: "Luis R. Rodriguez" , shuah@kernel.org, jeyu@redhat.com, rusty@rustcorp.com.au, ebiederm@xmission.com, dmitry.torokhov@gmail.com, acme@redhat.com, corbet@lwn.net, martin.wilck@suse.com, mmarek@suse.com, hare@suse.com, rwright@hpe.com, jeffm@suse.com, DSterba@suse.com, fdmanana@suse.com, neilb@suse.com, linux@roeck-us.net, rgoldwyn@suse.com, subashab@codeaurora.org, xypron.glpk@gmx.de, keescook@chromium.org, atomlin@redhat.com, mbenes@suse.cz, paulmck@linux.vnet.ibm.com, dan.j.williams@intel.com, jpoimboe@redhat.com, davem@davemloft.net, mingo@redhat.com, akpm@linux-foundation.org, torvalds@linux-foundation.org, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC 09/10] kmod: add helpers for getting kmod count and limit Message-ID: <20161216075726.GD13946@wotan.suse.de> References: <20161208184801.1689-1-mcgrof@kernel.org> <20161208194920.2768-1-mcgrof@kernel.org> <20161215165619.GB18152@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161215165619.GB18152@pathway.suse.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2164 Lines: 48 On Thu, Dec 15, 2016 at 05:56:19PM +0100, Petr Mladek wrote: > On Thu 2016-12-08 11:49:20, Luis R. Rodriguez wrote: > > This adds helpers for getting access to the kmod count and limit from > > userspace. While at it, this also lets userspace fine tune the kmod > > limit after boot, it uses the shiny new proc_douintvec_minmax(). > > > > These knobs should help userspace more gracefully and deterministically > > handle module loading. > > > > Signed-off-by: Luis R. Rodriguez > > --- > > include/linux/kmod.h | 8 +++++ > > kernel/kmod.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++-- > > kernel/sysctl.c | 14 +++++++++ > > 3 files changed, 103 insertions(+), 2 deletions(-) > > I am not sure if it is worth it. As you say in the 3rd patch, > there was rather low limit for 16 years and nobody probably had > problems with it. Note, *probably* - ie, this could have gone unreported for a while, and to be frank how can we know for sure a pesky module just did not load due to this? In the case of get_fs_type() issue this can be fatal for a partition mount, not a good example to wait to look forward to before we take this serious. I added the sysctl value mostly for read purposes, the count is probably useless for any accounting to be done in userspace due to delays this reading and making this value useful in userspace can have, I can nuke that. The kmod-limit however seems very useful so that userspace knows how to properly thread *safely* modprobe calls more deterministically. Adding write support to let one bump the limit was just an easy convenience possible given the read support was being added, but its use should really only be useful for testing purposes post bootup given that the real value in the limit will be important at boot time prior to the sysctl parsing. The real know tweak which should be used in case of issues is the module parameter added earlier. So I could drop the kmod-count, and just make the kmod-limit read-only. Thoughts? > Anyway, it seems that such know should also get documented in > Documentation/sysctl/kernel.txt Will do if we keep them, thanks. Luis