Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1645160 > unrolled thread
| Started by | "Luis R. Rodriguez" <mcgrof@kernel.org> |
|---|---|
| First post | 2017-05-19 05:30 +0200 |
| Last post | 2017-05-23 11:10 +0200 |
| Articles | 3 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
[PATCH 6/6] kmod: use simplified rate limit printk "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-05-19 05:30 +0200
Re: [PATCH 6/6] kmod: use simplified rate limit printk Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-05-20 00:30 +0200
Re: [PATCH 6/6] kmod: use simplified rate limit printk Petr Mladek <pmladek@suse.com> - 2017-05-23 11:10 +0200
| From | "Luis R. Rodriguez" <mcgrof@kernel.org> |
|---|---|
| Date | 2017-05-19 05:30 +0200 |
| Subject | [PATCH 6/6] kmod: use simplified rate limit printk |
| Message-ID | <tIGM1-4u0-7@gated-at.bofh.it> |
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@suse.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.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);
return ret;
}
--
2.11.0
[toc] | [next] | [standalone]
| From | Dmitry Torokhov <dmitry.torokhov@gmail.com> |
|---|---|
| Date | 2017-05-20 00:30 +0200 |
| Message-ID | <tIYzg-hU-17@gated-at.bofh.it> |
| In reply to | #1645160 |
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@suse.com>
> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.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?
--
Dmitry
[toc] | [prev] | [next] | [standalone]
| From | Petr Mladek <pmladek@suse.com> |
|---|---|
| Date | 2017-05-23 11:10 +0200 |
| Message-ID | <tKdZg-15V-21@gated-at.bofh.it> |
| In reply to | #1645988 |
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@suse.com>
> > Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.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
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web