From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1037205AbdE0BON (ORCPT ); Fri, 26 May 2017 21:14:13 -0400 Received: from mx2.suse.de ([195.135.220.15]:44111 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S944902AbdEZU1f (ORCPT ); Fri, 26 May 2017 16:27:35 -0400 Date: Fri, 26 May 2017 22:27:31 +0200 From: "Luis R. Rodriguez" To: Dmitry Torokhov , Tom Gundersen Cc: "Luis R. Rodriguez" , akpm@linux-foundation.org, jeyu@redhat.com, shuah@kernel.org, rusty@rustcorp.com.au, ebiederm@xmission.com, acme@redhat.com, corbet@lwn.net, 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, alan@linux.intel.com, tytso@mit.edu, gregkh@linuxfoundation.org, torvalds@linux-foundation.org, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 4/5] kmod: add helpers for getting kmod limit Message-ID: <20170526202731.GY8951@wotan.suse.de> References: <20170519032444.18416-1-mcgrof@kernel.org> <20170526001630.19203-1-mcgrof@kernel.org> <20170526001630.19203-5-mcgrof@kernel.org> <20170526005651.GE29859@dtor-ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170526005651.GE29859@dtor-ws> 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, May 25, 2017 at 05:56:51PM -0700, Dmitry Torokhov wrote: > On Thu, May 25, 2017 at 05:16:29PM -0700, Luis R. Rodriguez wrote: > > This adds helpers for getting access to the kmod limit from > > userspace. This knob should help userspace more gracefully and > > deterministically handle module loading. > > I think more details is needed before we add a new ABI to the kernel. > Why can't userspace submit as much as it wants and the kernel decide how > much it will service at once? I suppose I should clarify on the commit log then, that without this heuristic of #ifdef get_kmod_umh_limit -- *iff* userspace today is allowing more than 50 threads it can mean userspace is allowing a modprobe to fail. Check the results of test 0008 and 0009 on dmesg, you can end up with really unexpected results. This knob enables userspace to gracefully send in as many requests as allowed. I guess this could just be a kernel revision check... given that once throttling go in it can be as crazy as it wants. Also I suppose one could argue that *since* this has not been a real issue *yet* (we assume), the old userspace of sending as many requests as it needs is fine. Will drop this! Luis