From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759456AbcLPIFK (ORCPT ); Fri, 16 Dec 2016 03:05:10 -0500 Received: from mx2.suse.de ([195.135.220.15]:55277 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753951AbcLPIFD (ORCPT ); Fri, 16 Dec 2016 03:05:03 -0500 Date: Fri, 16 Dec 2016 09:05:00 +0100 From: "Luis R. Rodriguez" To: Petr Mladek Cc: "Luis R. Rodriguez" , Kees Cook , shuah@kernel.org, Jessica Yu , Rusty Russell , "Eric W. Biederman" , Dmitry Torokhov , Arnaldo Carvalho de Melo , Jonathan Corbet , martin.wilck@suse.com, Michal Marek , hare@suse.com, rwright@hpe.com, Jeff Mahoney , DSterba@suse.com, fdmanana@suse.com, neilb@suse.com, Guenter Roeck , rgoldwyn@suse.com, subashab@codeaurora.org, Heinrich Schuchardt , Aaron Tomlin , mbenes@suse.cz, "Paul E. McKenney" , Dan Williams , Josh Poimboeuf , "David S. Miller" , Ingo Molnar , Andrew Morton , Linus Torvalds , linux-kselftest@vger.kernel.org, "linux-doc@vger.kernel.org" , LKML Subject: Re: [RFC 04/10] kmod: provide wrappers for kmod_concurrent inc/dec Message-ID: <20161216080500.GE13946@wotan.suse.de> References: <20161208184801.1689-1-mcgrof@kernel.org> <20161208194824.2532-1-mcgrof@kernel.org> <20161208210859.GZ1402@wotan.suse.de> <20161215124625.GA14324@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161215124625.GA14324@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 On Thu, Dec 15, 2016 at 01:46:25PM +0100, Petr Mladek wrote: > On Thu 2016-12-08 22:08:59, Luis R. Rodriguez wrote: > > On Thu, Dec 08, 2016 at 12:29:42PM -0800, Kees Cook wrote: > > > On Thu, Dec 8, 2016 at 11:48 AM, Luis R. Rodriguez wrote: > > > > kmod_concurrent is used as an atomic counter for enabling > > > > the allowed limit of modprobe calls, provide wrappers for it > > > > to enable this to be expanded on more easily. This will be done > > > > later. > > > > > > > > Signed-off-by: Luis R. Rodriguez > > > > --- > > > > kernel/kmod.c | 27 +++++++++++++++++++++------ > > > > 1 file changed, 21 insertions(+), 6 deletions(-) > > > > > > > > diff --git a/kernel/kmod.c b/kernel/kmod.c > > > > index cb6f7ca7b8a5..049d7eabda38 100644 > > > > --- a/kernel/kmod.c > > > > +++ b/kernel/kmod.c > > > > @@ -108,6 +111,20 @@ static int call_modprobe(char *module_name, int wait) > > > > return -ENOMEM; > > > > } > > > > > > > > +static int kmod_umh_threads_get(void) > > > > +{ > > > > + atomic_inc(&kmod_concurrent); > > This approach might actually cause false failures. If we > are on the limit and more processes do this increment > in parallel, it makes the number bigger that it should be. This approach is *exactly* what the existing code does :P I just provided wrappers. I agree with the old approach though, reason is it acts as a lock in for the bump. What seems rather stupid though is to just reject with an error on limit without first taking a breather. I've now added a little clutch so that we first take some fresh air when close to the limit, this reduces the chances of going fatal. With a clutch in place we can still go over the limit, its just we'd have a few threads waiting until previous calls clear out. If there is enough calls waiting eventually we'll fail. Note though that __request_module() can wait, but here is an option to not wait so such a clutch can only wait if we're allowed to. > > > > + if (atomic_read(&kmod_concurrent) < max_modprobes) > > > > + return 0; > > > > + atomic_dec(&kmod_concurrent); > > > > + return -ENOMEM; > > > > +} > > > > + > > > > +static void kmod_umh_threads_put(void) > > > > +{ > > > > + atomic_dec(&kmod_concurrent); > > > > +} > > > > > > Can you use a kref here instead? We're trying to kill raw use of > > > atomic_t for reference counting... > > > > That's a much broader functional change than I was looking for, but I am up for > > it. Can you describe the benefit of using kref you expect or why this is an > > ongoing crusade? Since its a larger functional change how about doing this > > change later, and we can test impact with the tress test driver. In theory if > > there are benefits can't we add a test case to prove the gains? > > Kees probably refers to the kref improvements that Peter Zijlstra > is working on, see > https://lkml.kernel.org/r/20161114174446.832175072@infradead.org > > The advantage is that the new refcount API handles over and > underflow. > > Another advantage is that it increments/decrements the value > only when it is safe. It uses cmpxchg to make sure that > the checks are valid. Great thanks, will look into that. Luis