Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756134AbcLOMqf (ORCPT ); Thu, 15 Dec 2016 07:46:35 -0500 Received: from mx2.suse.de ([195.135.220.15]:58154 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752673AbcLOMqd (ORCPT ); Thu, 15 Dec 2016 07:46:33 -0500 Date: Thu, 15 Dec 2016 13:46:25 +0100 From: Petr Mladek To: "Luis R. Rodriguez" Cc: 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: <20161215124625.GA14324@pathway.suse.cz> References: <20161208184801.1689-1-mcgrof@kernel.org> <20161208194824.2532-1-mcgrof@kernel.org> <20161208210859.GZ1402@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161208210859.GZ1402@wotan.suse.de> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2322 Lines: 62 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. > > > + 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. Best Regards, Petr