From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762457AbdEWJB0 (ORCPT ); Tue, 23 May 2017 05:01:26 -0400 Received: from mx2.suse.de ([195.135.220.15]:43345 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1762430AbdEWJBU (ORCPT ); Tue, 23 May 2017 05:01:20 -0400 Date: Tue, 23 May 2017 11:00:57 +0200 From: Petr Mladek To: Dmitry Torokhov Cc: "Luis R. Rodriguez" , shuah@kernel.org, jeyu@redhat.com, rusty@rustcorp.com.au, ebiederm@xmission.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, gregkh@linuxfoundation.org, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 6/6] kmod: use simplified rate limit printk Message-ID: <20170523090057.GB26699@pathway.suse.cz> References: <20170519032444.18416-1-mcgrof@kernel.org> <20170519032444.18416-7-mcgrof@kernel.org> <20170519222327.GH19281@dtor-ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170519222327.GH19281@dtor-ws> 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 On Fri 2017-05-19 15:23:27, Dmitry Torokhov wrote: > On Thu, May 18, 2017 at 08:24:44PM -0700, Luis R. Rodriguez wrote: > > Just use the simplified rate limit printk when the max modprobe > > limit is reached, while at it throw out a bone should the error > > be triggered. > > > > Reviewed-by: Petr Mladek > > Signed-off-by: Luis R. Rodriguez > > --- > > kernel/kmod.c | 10 ++-------- > > 1 file changed, 2 insertions(+), 8 deletions(-) > > > > diff --git a/kernel/kmod.c b/kernel/kmod.c > > index 7ea11dbc7564..56cd2a16e7ac 100644 > > --- a/kernel/kmod.c > > +++ b/kernel/kmod.c > > @@ -166,7 +166,6 @@ int __request_module(bool wait, const char *fmt, ...) > > va_list args; > > char module_name[MODULE_NAME_LEN]; > > int ret; > > - static int kmod_loop_msg; > > > > /* > > * We don't allow synchronous module loading from async. Module > > @@ -191,13 +190,8 @@ int __request_module(bool wait, const char *fmt, ...) > > > > ret = kmod_umh_threads_get(); > > if (ret) { > > - /* We may be blaming an innocent here, but unlikely */ > > - if (kmod_loop_msg < 5) { > > - printk(KERN_ERR > > - "request_module: runaway loop modprobe %s\n", > > - module_name); > > - kmod_loop_msg++; > > - } > > + pr_err_ratelimited("%s: module \"%s\" reached limit (%u) of concurrent modprobe calls\n", > > + __func__, module_name, max_modprobes); > > This is completely different behavior, isn't it? Instead of reporting > first 5 occurrences we now reporting every once in a while. Why is this > new behavior better? pr_err_ratelimited() shows the first 10 messages by default, see DEFAULT_RATELIMIT_BURST. In addition, it allows to see the messages again after some time (5 sec by default). Therefore you could see if the bad situation persists or if the limit was reached more times during the system lifetime. Best Regards, Petr