From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756504AbdESDZ1 (ORCPT ); Thu, 18 May 2017 23:25:27 -0400 Received: from mail.kernel.org ([198.145.29.99]:47744 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756427AbdESDZY (ORCPT ); Thu, 18 May 2017 23:25:24 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0B55D239EA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=mcgrof@kernel.org From: "Luis R. Rodriguez" To: shuah@kernel.org, jeyu@redhat.com, rusty@rustcorp.com.au, ebiederm@xmission.com, dmitry.torokhov@gmail.com, acme@redhat.com, corbet@lwn.net Cc: martin.wilck@suse.com, mmarek@suse.com, pmladek@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, gregkh@linuxfoundation.org, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, "Luis R. Rodriguez" Subject: [PATCH 5/6] kmod: preempt on kmod_umh_threads_get() Date: Thu, 18 May 2017 20:24:43 -0700 Message-Id: <20170519032444.18416-6-mcgrof@kernel.org> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20170519032444.18416-1-mcgrof@kernel.org> References: <20170519032444.18416-1-mcgrof@kernel.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In theory it is possible multiple concurrent threads will try to kmod_umh_threads_get() and as such atomic_inc(&kmod_concurrent) at the same time, therefore enabling a small time during which we've bumped kmod_concurrent but have not really enabled work. By using preemption we mitigate this a bit. Preemption is not needed when we kmod_umh_threads_put(). Signed-off-by: Luis R. Rodriguez --- kernel/kmod.c | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/kernel/kmod.c b/kernel/kmod.c index 563600fc9bb1..7ea11dbc7564 100644 --- a/kernel/kmod.c +++ b/kernel/kmod.c @@ -113,15 +113,35 @@ static int call_modprobe(char *module_name, int wait) static int kmod_umh_threads_get(void) { + int ret = 0; + + /* + * Disabling preemption makes sure that we are not rescheduled here + * + * Also preemption helps kmod_concurrent is not increased by mistake + * for too long given in theory two concurrent threads could race on + * atomic_inc() before we atomic_read() -- we know that's possible + * and but we don't care, this is not used for object accounting and + * is just a subjective threshold. The alternative is a lock. + */ + preempt_disable(); atomic_inc(&kmod_concurrent); if (atomic_read(&kmod_concurrent) <= max_modprobes) - return 0; + goto out; + atomic_dec(&kmod_concurrent); - return -EBUSY; + ret = -EBUSY; +out: + preempt_enable(); + return ret; } static void kmod_umh_threads_put(void) { + /* + * Preemption is not needed given once work is done we can + * pace ourselves on our way out. + */ atomic_dec(&kmod_concurrent); } -- 2.11.0