linux-kernel - Re: [PATCH 6/6] kmod: use simplified rate limit printk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170523090057.GB26699@pathway.suse.cz>
Date:   Tue, 23 May 2017 11:00:57 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     "Luis R. Rodriguez" <mcgrof@...nel.org>, shuah@...nel.org,
        jeyu@...hat.com, rusty@...tcorp.com.au, ebiederm@...ssion.com,
        acme@...hat.com, corbet@....net, martin.wilck@...e.com,
        mmarek@...e.com, hare@...e.com, rwright@....com, jeffm@...e.com,
        DSterba@...e.com, fdmanana@...e.com, neilb@...e.com,
        linux@...ck-us.net, rgoldwyn@...e.com, subashab@...eaurora.org,
        xypron.glpk@....de, keescook@...omium.org, atomlin@...hat.com,
        mbenes@...e.cz, paulmck@...ux.vnet.ibm.com,
        dan.j.williams@...el.com, jpoimboe@...hat.com, davem@...emloft.net,
        mingo@...hat.com, akpm@...ux-foundation.org,
        torvalds@...ux-foundation.org, gregkh@...uxfoundation.org,
        linux-kselftest@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/6] kmod: use simplified rate limit printk

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 <pmladek@...e.com>
> > Signed-off-by: Luis R. Rodriguez <mcgrof@...nel.org>
> > ---
> >  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