Hi,
I'm seeing this on today's Linus tree:
[ 24.048278] tty_init_dev: 24 callbacks suppressed
[ 45.630349] tty_init_dev: 3 callbacks suppressed
It is either from that WARN_RATELIMIT thing or the printk_ratelimited
further below in tty_init_dev but I don't know for sure because the
actual text message from both printk's doesn't come out in dmesg - only
that something got suppressed.
And it quiets down later, after the machine has finished booting. Still,
this doesn't tell me anything about any issue. So what's up?
Thanks.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
On 2012.10.04 at 11:20 +0200, Borislav Petkov wrote:
> Hi,
>
> I'm seeing this on today's Linus tree:
>
> [ 24.048278] tty_init_dev: 24 callbacks suppressed
> [ 45.630349] tty_init_dev: 3 callbacks suppressed
>
> It is either from that WARN_RATELIMIT thing or the printk_ratelimited
> further below in tty_init_dev but I don't know for sure because the
> actual text message from both printk's doesn't come out in dmesg - only
> that something got suppressed.
>
> And it quiets down later, after the machine has finished booting. Still,
> this doesn't tell me anything about any issue. So what's up?
I'm seeing the same thing.
This can be fixed by a slightly modified version of:
https://patchwork.kernel.org/patch/1339221/
diff --git a/include/linux/ratelimit.h b/include/linux/ratelimit.h
index e11ccb4..2d02461 100644
--- a/include/linux/ratelimit.h
+++ b/include/linux/ratelimit.h
@@ -46,20 +46,17 @@ extern int ___ratelimit(struct ratelimit_state *rs, const char *func);
#define WARN_ON_RATELIMIT(condition, state) \
WARN_ON((condition) && __ratelimit(state))
-#define __WARN_RATELIMIT(condition, state, format...) \
-({ \
- int rtn = 0; \
- if (unlikely(__ratelimit(state))) \
- rtn = WARN(condition, format); \
- rtn; \
-})
-
-#define WARN_RATELIMIT(condition, format...) \
+#define WARN_RATELIMIT(condition, state, fmt, ...) \
({ \
static DEFINE_RATELIMIT_STATE(_rs, \
DEFAULT_RATELIMIT_INTERVAL, \
DEFAULT_RATELIMIT_BURST); \
- __WARN_RATELIMIT(condition, &_rs, format); \
+ int rtn = !!(condition); \
+ \
+ if (unlikely(rtn && __ratelimit(state))) \
+ WARN(rtn, fmt, ##__VA_ARGS__); \
+ \
+ rtn; \
})
#else
@@ -67,15 +64,9 @@ extern int ___ratelimit(struct ratelimit_state *rs, const char *func);
#define WARN_ON_RATELIMIT(condition, state) \
WARN_ON(condition)
-#define __WARN_RATELIMIT(condition, state, format...) \
-({ \
- int rtn = WARN(condition, format); \
- rtn; \
-})
-
-#define WARN_RATELIMIT(condition, format...) \
+#define WARN_RATELIMIT(condition, fmt, ...) \
({ \
- int rtn = WARN(condition, format); \
+ int rtn = WARN(condition, fmt, ##__VA_ARGS__); \
rtn; \
})
--
Markus
On 2012.10.04 at 13:23 +0200, Markus Trippelsdorf wrote:
> On 2012.10.04 at 11:20 +0200, Borislav Petkov wrote:
> > Hi,
> >
> > I'm seeing this on today's Linus tree:
> >
> > [ 24.048278] tty_init_dev: 24 callbacks suppressed
> > [ 45.630349] tty_init_dev: 3 callbacks suppressed
> >
> > It is either from that WARN_RATELIMIT thing or the printk_ratelimited
> > further below in tty_init_dev but I don't know for sure because the
> > actual text message from both printk's doesn't come out in dmesg - only
> > that something got suppressed.
> >
> > And it quiets down later, after the machine has finished booting. Still,
> > this doesn't tell me anything about any issue. So what's up?
>
> I'm seeing the same thing.
> This can be fixed by a slightly modified version of:
> https://patchwork.kernel.org/patch/1339221/
My first patch was wrong. This one should be correct:
diff --git a/include/linux/ratelimit.h b/include/linux/ratelimit.h
index e11ccb4..d8de255 100644
--- a/include/linux/ratelimit.h
+++ b/include/linux/ratelimit.h
@@ -46,20 +46,17 @@ extern int ___ratelimit(struct ratelimit_state *rs, const char *func);
#define WARN_ON_RATELIMIT(condition, state) \
WARN_ON((condition) && __ratelimit(state))
-#define __WARN_RATELIMIT(condition, state, format...) \
-({ \
- int rtn = 0; \
- if (unlikely(__ratelimit(state))) \
- rtn = WARN(condition, format); \
- rtn; \
-})
-
-#define WARN_RATELIMIT(condition, format...) \
+#define WARN_RATELIMIT(condition, fmt, ...) \
({ \
static DEFINE_RATELIMIT_STATE(_rs, \
DEFAULT_RATELIMIT_INTERVAL, \
DEFAULT_RATELIMIT_BURST); \
- __WARN_RATELIMIT(condition, &_rs, format); \
+ int rtn = !!(condition); \
+ \
+ if (unlikely(rtn && __ratelimit(&_rs))) \
+ WARN(rtn, fmt, ##__VA_ARGS__); \
+ \
+ rtn; \
})
#else
@@ -67,15 +64,9 @@ extern int ___ratelimit(struct ratelimit_state *rs, const char *func);
#define WARN_ON_RATELIMIT(condition, state) \
WARN_ON(condition)
-#define __WARN_RATELIMIT(condition, state, format...) \
-({ \
- int rtn = WARN(condition, format); \
- rtn; \
-})
-
-#define WARN_RATELIMIT(condition, format...) \
+#define WARN_RATELIMIT(condition, fmt, ...) \
({ \
- int rtn = WARN(condition, format); \
+ int rtn = WARN(condition, fmt, ##__VA_ARGS__); \
rtn; \
})
--
Markus
On Thu, Oct 04, 2012 at 01:51:57PM +0200, Markus Trippelsdorf wrote:
> diff --git a/include/linux/ratelimit.h b/include/linux/ratelimit.h
> index e11ccb4..d8de255 100644
> --- a/include/linux/ratelimit.h
> +++ b/include/linux/ratelimit.h
> @@ -46,20 +46,17 @@ extern int ___ratelimit(struct ratelimit_state *rs, const char *func);
> #define WARN_ON_RATELIMIT(condition, state) \
> WARN_ON((condition) && __ratelimit(state))
>
> -#define __WARN_RATELIMIT(condition, state, format...) \
> -({ \
> - int rtn = 0; \
> - if (unlikely(__ratelimit(state))) \
> - rtn = WARN(condition, format); \
> - rtn; \
> -})
> -
> -#define WARN_RATELIMIT(condition, format...) \
> +#define WARN_RATELIMIT(condition, fmt, ...) \
> ({ \
> static DEFINE_RATELIMIT_STATE(_rs, \
> DEFAULT_RATELIMIT_INTERVAL, \
> DEFAULT_RATELIMIT_BURST); \
> - __WARN_RATELIMIT(condition, &_rs, format); \
> + int rtn = !!(condition); \
> + \
> + if (unlikely(rtn && __ratelimit(&_rs))) \
> + WARN(rtn, fmt, ##__VA_ARGS__); \
> + \
> + rtn; \
> })
Aha, I see it. We need to look at the condition before the __ratelimit,
otherwise we WARN unnecessarily, good catch.
> #else
> @@ -67,15 +64,9 @@ extern int ___ratelimit(struct ratelimit_state *rs, const char *func);
> #define WARN_ON_RATELIMIT(condition, state) \
> WARN_ON(condition)
>
> -#define __WARN_RATELIMIT(condition, state, format...) \
> -({ \
> - int rtn = WARN(condition, format); \
> - rtn; \
> -})
> -
> -#define WARN_RATELIMIT(condition, format...) \
> +#define WARN_RATELIMIT(condition, fmt, ...) \
... except this change is unrelated and unneeded - there's enough room
in 80 cols to leave it as "format" instead of shortening it.
Other than that:
Acked-and-tested-by: Borislav Petkov <[email protected]>
Thanks.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
On 2012.10.04 at 14:40 +0200, Borislav Petkov wrote:
> On Thu, Oct 04, 2012 at 01:51:57PM +0200, Markus Trippelsdorf wrote:
> > diff --git a/include/linux/ratelimit.h b/include/linux/ratelimit.h
> > index e11ccb4..d8de255 100644
> > --- a/include/linux/ratelimit.h
> > +++ b/include/linux/ratelimit.h
> > @@ -46,20 +46,17 @@ extern int ___ratelimit(struct ratelimit_state *rs, const char *func);
> > #define WARN_ON_RATELIMIT(condition, state) \
> > WARN_ON((condition) && __ratelimit(state))
> >
> > -#define __WARN_RATELIMIT(condition, state, format...) \
> > -({ \
> > - int rtn = 0; \
> > - if (unlikely(__ratelimit(state))) \
> > - rtn = WARN(condition, format); \
> > - rtn; \
> > -})
> > -
> > -#define WARN_RATELIMIT(condition, format...) \
> > +#define WARN_RATELIMIT(condition, fmt, ...) \
> > ({ \
> > static DEFINE_RATELIMIT_STATE(_rs, \
> > DEFAULT_RATELIMIT_INTERVAL, \
> > DEFAULT_RATELIMIT_BURST); \
> > - __WARN_RATELIMIT(condition, &_rs, format); \
> > + int rtn = !!(condition); \
> > + \
> > + if (unlikely(rtn && __ratelimit(&_rs))) \
> > + WARN(rtn, fmt, ##__VA_ARGS__); \
> > + \
> > + rtn; \
> > })
>
> Aha, I see it. We need to look at the condition before the __ratelimit,
> otherwise we WARN unnecessarily, good catch.
>
> > #else
> > @@ -67,15 +64,9 @@ extern int ___ratelimit(struct ratelimit_state *rs, const char *func);
> > #define WARN_ON_RATELIMIT(condition, state) \
> > WARN_ON(condition)
> >
> > -#define __WARN_RATELIMIT(condition, state, format...) \
> > -({ \
> > - int rtn = WARN(condition, format); \
> > - rtn; \
> > -})
> > -
> > -#define WARN_RATELIMIT(condition, format...) \
> > +#define WARN_RATELIMIT(condition, fmt, ...) \
>
> ... except this change is unrelated and unneeded - there's enough room
> in 80 cols to leave it as "format" instead of shortening it.
>
> Other than that:
>
> Acked-and-tested-by: Borislav Petkov <[email protected]>
I'll let Jiri handle this :). It's his patch anyway.
--
Markus
CCing Joe.
On 10/04/2012 03:11 PM, Markus Trippelsdorf wrote:
> On 2012.10.04 at 14:40 +0200, Borislav Petkov wrote:
>> On Thu, Oct 04, 2012 at 01:51:57PM +0200, Markus Trippelsdorf wrote:
>>> diff --git a/include/linux/ratelimit.h b/include/linux/ratelimit.h
>>> index e11ccb4..d8de255 100644
>>> --- a/include/linux/ratelimit.h
>>> +++ b/include/linux/ratelimit.h
>>> @@ -46,20 +46,17 @@ extern int ___ratelimit(struct ratelimit_state *rs, const char *func);
>>> #define WARN_ON_RATELIMIT(condition, state) \
>>> WARN_ON((condition) && __ratelimit(state))
>>>
>>> -#define __WARN_RATELIMIT(condition, state, format...) \
>>> -({ \
>>> - int rtn = 0; \
>>> - if (unlikely(__ratelimit(state))) \
>>> - rtn = WARN(condition, format); \
>>> - rtn; \
>>> -})
>>> -
>>> -#define WARN_RATELIMIT(condition, format...) \
>>> +#define WARN_RATELIMIT(condition, fmt, ...) \
>>> ({ \
>>> static DEFINE_RATELIMIT_STATE(_rs, \
>>> DEFAULT_RATELIMIT_INTERVAL, \
>>> DEFAULT_RATELIMIT_BURST); \
>>> - __WARN_RATELIMIT(condition, &_rs, format); \
>>> + int rtn = !!(condition); \
>>> + \
>>> + if (unlikely(rtn && __ratelimit(&_rs))) \
>>> + WARN(rtn, fmt, ##__VA_ARGS__); \
>>> + \
>>> + rtn; \
>>> })
>>
>> Aha, I see it. We need to look at the condition before the __ratelimit,
>> otherwise we WARN unnecessarily, good catch.
>>
>>> #else
>>> @@ -67,15 +64,9 @@ extern int ___ratelimit(struct ratelimit_state *rs, const char *func);
>>> #define WARN_ON_RATELIMIT(condition, state) \
>>> WARN_ON(condition)
>>>
>>> -#define __WARN_RATELIMIT(condition, state, format...) \
>>> -({ \
>>> - int rtn = WARN(condition, format); \
>>> - rtn; \
>>> -})
>>> -
>>> -#define WARN_RATELIMIT(condition, format...) \
>>> +#define WARN_RATELIMIT(condition, fmt, ...) \
>>
>> ... except this change is unrelated and unneeded - there's enough room
>> in 80 cols to leave it as "format" instead of shortening it.
>>
>> Other than that:
>>
>> Acked-and-tested-by: Borislav Petkov <[email protected]>
>
> I'll let Jiri handle this :). It's his patch anyway.
Actually this is Joe's version of the patch. Joe, people started hitting
the bug [1]. Could you resend your patch?
[1] https://patchwork.kernel.org/patch/1339221/
BTW what scares me that nobody noticed that bug until this is in the
Linus's tree. Do people use -next at all or am I the only one user? (I
didn't hit it as I have the patch in my local queue.)
thanks,
--
js
suse labs
> Actually this is Joe's version of the patch. Joe, people started hitting
> the bug [1]. Could you resend your patch?
>
> [1] https://patchwork.kernel.org/patch/1339221/
>
> BTW what scares me that nobody noticed that bug until this is in the
> Linus's tree. Do people use -next at all or am I the only one user? (I
> didn't hit it as I have the patch in my local queue.)
I run -next for various things. I'd noticed that funny but you'd started
investigating it before I got to investigating.
Alan
On Fri, Oct 05, 2012 at 01:17:02PM +0200, Jiri Slaby wrote:
> BTW what scares me that nobody noticed that bug until this is in the
> Linus's tree. Do people use -next at all or am I the only one user? (I
> didn't hit it as I have the patch in my local queue.)
Noticing this before -rc1 and fixing it around that time is still fine
in my book. So can *someone* *please* send a patch already so that we
can forget about this.
Thanks.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
On the current git tree one sees messages such as:
tty_init_dev: 24 callbacks suppressed
tty_init_dev: 3 callbacks suppressed
To fix this we need to look at condition before calling __ratelimit in
the WARN_RATELIMIT macro. While at it remove the superfluous
__WARN_RATELIMIT macros.
Original patch is from Joe Perches and Jiri Slaby.
Signed-off-by: Markus Trippelsdorf <[email protected]>
Acked-and-tested-by: Borislav Petkov <[email protected]>
---
include/linux/ratelimit.h | 27 +++++++++------------------
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/include/linux/ratelimit.h b/include/linux/ratelimit.h
index e11ccb4..0a260d8 100644
--- a/include/linux/ratelimit.h
+++ b/include/linux/ratelimit.h
@@ -46,20 +46,17 @@ extern int ___ratelimit(struct ratelimit_state *rs, const char *func);
#define WARN_ON_RATELIMIT(condition, state) \
WARN_ON((condition) && __ratelimit(state))
-#define __WARN_RATELIMIT(condition, state, format...) \
-({ \
- int rtn = 0; \
- if (unlikely(__ratelimit(state))) \
- rtn = WARN(condition, format); \
- rtn; \
-})
-
-#define WARN_RATELIMIT(condition, format...) \
+#define WARN_RATELIMIT(condition, format, ...) \
({ \
static DEFINE_RATELIMIT_STATE(_rs, \
DEFAULT_RATELIMIT_INTERVAL, \
DEFAULT_RATELIMIT_BURST); \
- __WARN_RATELIMIT(condition, &_rs, format); \
+ int rtn = !!(condition); \
+ \
+ if (unlikely(rtn && __ratelimit(&_rs))) \
+ WARN(rtn, format, ##__VA_ARGS__); \
+ \
+ rtn; \
})
#else
@@ -67,15 +64,9 @@ extern int ___ratelimit(struct ratelimit_state *rs, const char *func);
#define WARN_ON_RATELIMIT(condition, state) \
WARN_ON(condition)
-#define __WARN_RATELIMIT(condition, state, format...) \
-({ \
- int rtn = WARN(condition, format); \
- rtn; \
-})
-
-#define WARN_RATELIMIT(condition, format...) \
+#define WARN_RATELIMIT(condition, format, ...) \
({ \
- int rtn = WARN(condition, format); \
+ int rtn = WARN(condition, format, ##__VA_ARGS__); \
rtn; \
})
--
Markus
On Fri, Oct 05, 2012 at 02:57:17PM +0200, Markus Trippelsdorf wrote:
> On the current git tree one sees messages such as:
> tty_init_dev: 24 callbacks suppressed
> tty_init_dev: 3 callbacks suppressed
>
> To fix this we need to look at condition before calling __ratelimit in
> the WARN_RATELIMIT macro. While at it remove the superfluous
> __WARN_RATELIMIT macros.
>
> Original patch is from Joe Perches and Jiri Slaby.
>
> Signed-off-by: Markus Trippelsdorf <[email protected]>
> Acked-and-tested-by: Borislav Petkov <[email protected]>
> ---
> include/linux/ratelimit.h | 27 +++++++++------------------
> 1 file changed, 9 insertions(+), 18 deletions(-)
I don't have a problem with this patch, but I don't understand why it's
now showing up. There haven't been any changes in the ratelimit.h area
recently that I can see, so why is this change needed now? What is in
the tty layer that is causing this, just the fact that it's actually
being used now?
thanks,
greg k-h
On 2012.10.05 at 07:26 -0700, Greg Kroah-Hartman wrote:
> On Fri, Oct 05, 2012 at 02:57:17PM +0200, Markus Trippelsdorf wrote:
> > On the current git tree one sees messages such as:
> > tty_init_dev: 24 callbacks suppressed
> > tty_init_dev: 3 callbacks suppressed
> >
> > To fix this we need to look at condition before calling __ratelimit in
> > the WARN_RATELIMIT macro. While at it remove the superfluous
> > __WARN_RATELIMIT macros.
> >
> > Original patch is from Joe Perches and Jiri Slaby.
> >
> > Signed-off-by: Markus Trippelsdorf <[email protected]>
> > Acked-and-tested-by: Borislav Petkov <[email protected]>
> > ---
> > include/linux/ratelimit.h | 27 +++++++++------------------
> > 1 file changed, 9 insertions(+), 18 deletions(-)
>
> I don't have a problem with this patch, but I don't understand why it's
> now showing up. There haven't been any changes in the ratelimit.h area
> recently that I can see, so why is this change needed now? What is in
> the tty layer that is causing this, just the fact that it's actually
> being used now?
See Jiri's recent commit:
commit 5d4121c04b3577e37e389b3553d442f44bb346d7
Author: Jiri Slaby <[email protected]>
Date: Fri Aug 17 14:27:52 2012 +0200
TTY: check if tty->port is assigned
And if not, complain loudly. None in-kernel module should trigger
that, but let us find out for sure. On the other hand, all the
out-of-tree modules will hit that. Give them some time (maybe one
release) to catch up.
Signed-off-by: Jiri Slaby <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 28c3e86..41e42f1 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -1415,6 +1415,10 @@ struct tty_struct *tty_init_dev(struct tty_driver *driver, int idx)
if (!tty->port)
tty->port = driver->ports[idx];
+ WARN_RATELIMIT(!tty->port,
+ "%s: %s driver does not set tty->port. This will crash the kernel later. Fix the driver!\n",
+ __func__, tty->driver->name);
+
/*
* Structures all installed ... call the ldisc open routines.
* If we fail here just call release_tty to clean up. No need
--
Markus
On Fri, Oct 05, 2012 at 07:26:39AM -0700, Greg Kroah-Hartman wrote:
> I don't have a problem with this patch, but I don't understand why
> it's now showing up. There haven't been any changes in the ratelimit.h
> area recently that I can see, so why is this change needed now? What
> is in the tty layer that is causing this, just the fact that it's
> actually being used now?
>From my quick semi-skilled git history browsing, I'd say it's
5d4121c04b357 which added the WARN_RATELIMIT to tty_init_dev during the
current merge window.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
On Fri, 2012-10-05 at 13:17 +0200, Jiri Slaby wrote:
> CCing Joe.
[]
> > I'll let Jiri handle this :). It's his patch anyway.
>
> Actually this is Joe's version of the patch. Joe, people started hitting
> the bug [1]. Could you resend your patch?
> [1] https://patchwork.kernel.org/patch/1339221/
Markus already did that.
I think it'd be fine if someone picked it up.
> BTW what scares me that nobody noticed that bug until this is in the
> Linus's tree. Do people use -next at all or am I the only one user? (I
> didn't hit it as I have the patch in my local queue.)
I think you're the only actual user.
Does anyone else really use it as more than a tree
integration compilation testbed?
On Fri, Oct 05, 2012 at 05:29:48PM +0200, Borislav Petkov wrote:
> On Fri, Oct 05, 2012 at 07:26:39AM -0700, Greg Kroah-Hartman wrote:
> > I don't have a problem with this patch, but I don't understand why
> > it's now showing up. There haven't been any changes in the ratelimit.h
> > area recently that I can see, so why is this change needed now? What
> > is in the tty layer that is causing this, just the fact that it's
> > actually being used now?
>
> >From my quick semi-skilled git history browsing, I'd say it's
> 5d4121c04b357 which added the WARN_RATELIMIT to tty_init_dev during the
> current merge window.
So WARN_RATELIMIT was never working properly? If so, how far back does
it go in kernel releases that this should be fixed?
thanks,
greg k-h
On 2012.10.05 at 08:37 -0700, Greg Kroah-Hartman wrote:
> On Fri, Oct 05, 2012 at 05:29:48PM +0200, Borislav Petkov wrote:
> > On Fri, Oct 05, 2012 at 07:26:39AM -0700, Greg Kroah-Hartman wrote:
> > > I don't have a problem with this patch, but I don't understand why
> > > it's now showing up. There haven't been any changes in the ratelimit.h
> > > area recently that I can see, so why is this change needed now? What
> > > is in the tty layer that is causing this, just the fact that it's
> > > actually being used now?
> >
> > >From my quick semi-skilled git history browsing, I'd say it's
> > 5d4121c04b357 which added the WARN_RATELIMIT to tty_init_dev during the
> > current merge window.
>
> So WARN_RATELIMIT was never working properly? If so, how far back does
> it go in kernel releases that this should be fixed?
The only user until this merge window was net/core/filter.c. The
WARN_RATELIMIT is used there since v3.0.
--
Markus
On Fri, Oct 05, 2012 at 08:37:06AM -0700, Greg Kroah-Hartman wrote:
> So WARN_RATELIMIT was never working properly? If so, how far back does
> it go in kernel releases that this should be fixed?
Since b3eec79b0776e which added it in May 2011. But the only one other
user is net/core/filter.c.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
On 2012.10.05 at 17:43 +0200, Borislav Petkov wrote:
> On Fri, Oct 05, 2012 at 08:37:06AM -0700, Greg Kroah-Hartman wrote:
> > So WARN_RATELIMIT was never working properly? If so, how far back does
> > it go in kernel releases that this should be fixed?
>
> Since b3eec79b0776e which added it in May 2011. But the only one othe r
> user is net/core/filter.c.
But it doesn't matter, because the WARN_RATELIMIT in net/core/filter.c
is guarded by a switch statement and uses WARN_RATELIMIT(1,...). So it
could never trigger the bug.
--
Markus
On Fri, Oct 05, 2012 at 05:48:47PM +0200, Markus Trippelsdorf wrote:
> On 2012.10.05 at 17:43 +0200, Borislav Petkov wrote:
> > On Fri, Oct 05, 2012 at 08:37:06AM -0700, Greg Kroah-Hartman wrote:
> > > So WARN_RATELIMIT was never working properly? If so, how far back does
> > > it go in kernel releases that this should be fixed?
> >
> > Since b3eec79b0776e which added it in May 2011. But the only one othe r
> > user is net/core/filter.c.
>
> But it doesn't matter, because the WARN_RATELIMIT in net/core/filter.c
> is guarded by a switch statement and uses WARN_RATELIMIT(1,...). So it
> could never trigger the bug.
Yes, but you should say "it covers the bug with a brown paper bag
because the condition is always true."
:-)
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
On Fri, Oct 05, 2012 at 05:48:47PM +0200, Markus Trippelsdorf wrote:
> On 2012.10.05 at 17:43 +0200, Borislav Petkov wrote:
> > On Fri, Oct 05, 2012 at 08:37:06AM -0700, Greg Kroah-Hartman wrote:
> > > So WARN_RATELIMIT was never working properly? If so, how far back does
> > > it go in kernel releases that this should be fixed?
> >
> > Since b3eec79b0776e which added it in May 2011. But the only one othe r
> > user is net/core/filter.c.
>
> But it doesn't matter, because the WARN_RATELIMIT in net/core/filter.c
> is guarded by a switch statement and uses WARN_RATELIMIT(1,...). So it
> could never trigger the bug.
Ok, thanks for digging that all up, I'll just merge this in for 3.7.
greg k-h
On 10/05/2012 02:57 PM, Markus Trippelsdorf wrote:
> On the current git tree one sees messages such as:
> tty_init_dev: 24 callbacks suppressed
> tty_init_dev: 3 callbacks suppressed
>
> To fix this we need to look at condition before calling __ratelimit in
> the WARN_RATELIMIT macro. While at it remove the superfluous
> __WARN_RATELIMIT macros.
>
> Original patch is from Joe Perches and Jiri Slaby.
>
> Signed-off-by: Markus Trippelsdorf <[email protected]>
> Acked-and-tested-by: Borislav Petkov <[email protected]>
Acked-by: Jiri Slaby <[email protected]>
Thanks.
--
js
suse labs