LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>, Petr Mladek <pmladek@suse.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
Peter Zijlstra <peterz@infradead.org>, Jan Kara <jack@suse.cz>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Tejun Heo <tj@kernel.org>,
linux-kernel@vger.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [PATCH] printk: Ratelimit messages printed by console drivers
Date: Mon, 16 Apr 2018 10:47:29 +0900 [thread overview]
Message-ID: <20180416014729.GB1034@jagdpanzerIV> (raw)
In-Reply-To: <20180414023516.GA17806@tigerII.localdomain>
On (04/14/18 11:35), Sergey Senozhatsky wrote:
> On (04/13/18 10:12), Steven Rostedt wrote:
> >
> > > The interval is set to one hour. It is rather arbitrary selected time.
> > > It is supposed to be a compromise between never print these messages,
> > > do not lockup the machine, do not fill the entire buffer too quickly,
> > > and get information if something changes over time.
> >
> >
> > I think an hour is incredibly long. We only allow 100 lines per hour for
> > printks happening inside another printk?
> >
> > I think 5 minutes (at most) would probably be plenty. One minute may be
> > good enough.
>
> Besides 100 lines is absolutely not enough for any real lockdep splat.
> My call would be - up to 1000 lines in a 1 minute interval.
Well, if we want to basically turn printk_safe() into printk_safe_ratelimited().
I'm not so sure about it.
Besides the patch also rate limits printk_nmi->logbuf - the logbuf
PRINTK_NMI_DEFERRED_CONTEXT_MASK bypass, which is way too important
to rate limit it - for no reason.
Dunno, can we keep printk_safe() the way it is and introduce a new
printk_safe_ratelimited() specifically for call_console_drivers()?
Lockdep splat is a one time event, if we lose half of it - we, most
like, lose the entire report. And call_console_drivers() is not the
one and only source of warnings/errors/etc. So if we turn printk_safe
into printk_safe_ratelimited() [not sure we want to do it] for all
then I want restrictions to be as low as possible, IOW to log_store()
as many lines as possible.
Chatty console drivers is not exactly the case which printk_safe() was
meant to fix. I'm pretty sure I put call_console_drivers() under printk_safe
just because we call console_drivers with local IRQs disabled anyway and I
was too lazy to do something like this
---
@@ -2377,6 +2377,7 @@ void console_unlock(void)
console_idx = log_next(console_idx);
console_seq++;
raw_spin_unlock(&logbuf_lock);
+ __printk_safe_exit();
/*
* While actively printing out messages, if another printk()
@@ -2390,6 +2391,7 @@ void console_unlock(void)
call_console_drivers(ext_text, ext_len, text, len);
start_critical_timings();
+ __printk_safe_enter();
if (console_lock_spinning_disable_and_check()) {
printk_safe_exit_irqrestore(flags);
return;
---
But, in general, I don't think there are real reasons for us to call
console drivers from printk_safe section: call_console_drivers()->printk()
will not deadlock, because vprintk_emit()->console_trylock_spinning() will
always fail.
-ss
next prev parent reply other threads:[~2018-04-16 1:47 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-13 12:47 Petr Mladek
2018-04-13 14:12 ` Steven Rostedt
2018-04-14 2:35 ` Sergey Senozhatsky
2018-04-16 1:47 ` Sergey Senozhatsky [this message]
2018-04-16 4:25 ` Sergey Senozhatsky
2018-04-19 12:53 ` Petr Mladek
2018-04-20 2:15 ` Sergey Senozhatsky
2018-04-20 9:12 ` Petr Mladek
2018-04-20 12:04 ` Steven Rostedt
2018-04-20 14:01 ` Petr Mladek
2018-04-20 14:17 ` Steven Rostedt
2018-04-20 14:19 ` Steven Rostedt
2018-04-20 14:57 ` Petr Mladek
2018-04-20 15:13 ` Steven Rostedt
2018-04-23 10:32 ` Petr Mladek
2018-04-23 11:36 ` Steven Rostedt
2018-04-23 12:45 ` Petr Mladek
2018-04-25 5:31 ` Sergey Senozhatsky
2018-04-26 9:42 ` Petr Mladek
2018-04-27 10:22 ` Sergey Senozhatsky
2018-05-09 12:00 ` Petr Mladek
2018-05-09 12:59 ` Steven Rostedt
2019-02-26 10:24 ` Tetsuo Handa
2019-02-28 4:45 ` Sergey Senozhatsky
2018-04-23 5:21 ` Sergey Senozhatsky
2018-04-23 12:26 ` Petr Mladek
2018-04-23 13:00 ` Sergey Senozhatsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180416014729.GB1034@jagdpanzerIV \
--to=sergey.senozhatsky.work@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=tj@kernel.org \
--subject='Re: [PATCH] printk: Ratelimit messages printed by console drivers' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).