From: Petr Mladek <pmladek@suse.com>
To: Jan Kara <jack@suse.cz>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
Andrew Morton <akpm@linux-foundation.org>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Jan Kara <jack@suse.com>, Tejun Heo <tj@kernel.org>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Byungchul Park <byungchul.park@lge.com>,
vlevenetz@mm-sol.com,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH v10 1/2] printk: Make printk() completely async
Date: Tue, 23 Aug 2016 15:48:47 +0200 [thread overview]
Message-ID: <20160823134847.GF4866@pathway.suse.cz> (raw)
In-Reply-To: <20160819190007.GA8275@quack2.suse.cz>
On Fri 2016-08-19 21:00:07, Jan Kara wrote:
> On Fri 19-08-16 11:54:55, Petr Mladek wrote:
> > On Fri 2016-08-19 15:32:36, Sergey Senozhatsky wrote:
> > > On (08/18/16 12:56), Petr Mladek wrote:
> > > > The advantage of the printk_func trick is that it is transparent.
> > > > You do not need to modify any existing functions used by WARN()/BUG()
> > > > macros.
> > >
> > > good point.
> > >
> > > so something like below, perhaps. I'm less sure about
> > > deferred BUG()/BUG_ON():
> > >
> > > #define DEFERRED_BUG() do { \
> > > printk_deferred_enter(); \
> > > BUG(); \
> > > printk_deferred_exit(); \
> > > } while (0) \
> > >
> > > #define DEFERRED_BUG_ON(condition) do { \
> > > printk_deferred_enter(); \
> > > BUG_ON(condition); \
> > > printk_deferred_exit(); \
> > > } while (0)
> > >
> > > depending on .config BUG() may never return back -- passing control
> > > to do_exit(), so printk_deferred_exit() won't be executed. thus we
> > > probably need to have a per-cpu variable that would indicate that
> > > we are in deferred_bug. hm... but do we really need deferred BUG()
> > > in the first place?
> >
> > Good question. I am not aware of any BUG_ON() that would be called from
> > wake_up_process() but it is hard to check everything.
> >
> > A conservative approach would be to force synchronous printk from
> > BUG_ON().
>
> Just a quick thought: Cannot we just do printk_deferred_enter() when we are
> about to call into the scheduler from printk code and printk_deferred_exit()
> when leaving it? That would look like the least error-prone way how
> handling this kind of recursion...
>
> OTOH there's also the other possible direction for the recursion when we
> are in the scheduler, holding some scheduler locks, decide to WARN which
> enters printk, that ends up calling wake_up_process() which deadlocks
> on scheduler locks... I don't see how to handle this type of recursion
> inside the printk code itself easily and so far the answer was - use
> printk_deferred() in the scheduler and don't use WARN...
>
> Hum, maybe we could add lockdep annotation to a WARN_ON and BUG_ON macros so
> that it would grab and release console_sem (even if the condition is false).
> That way we'd get lockdep splats for all the possible WARN_ON and BUG_ON
> calls that could deadlock.
The idea is interesting but I think that we do not want the fake
grab/release of the console_sem.
We use console_trylock() in vprintk_emit(). Please note the "try"
variant. So it is safe to call a nested printk() from the console code.
IMHO, we want to avoid calling console from the scheduler code because:
1. console is slow and we do not want to block the scheduler.
2. console_unlock() calls wake_up_process() and we do not want
a deadlock by the scheduler locks.
Therefore I think that we want to detect something specific
from the scheduler that is also reachable from WARN()/printk().
Best Regards,
Petr
PS: My brain rotated several times this day around these problems.
I hope that my opinion still makes some sense :-)
next prev parent reply other threads:[~2016-08-23 13:49 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-04 16:57 [PATCH v10 0/2] printk: Make printk() completely async Sergey Senozhatsky
2016-04-04 16:57 ` [PATCH v10 1/2] " Sergey Senozhatsky
2016-04-04 22:51 ` Andrew Morton
2016-04-05 5:17 ` Sergey Senozhatsky
2016-04-05 7:39 ` Sergey Senozhatsky
2016-04-06 0:19 ` Sergey Senozhatsky
2016-04-06 8:27 ` Jan Kara
2016-04-07 9:48 ` Sergey Senozhatsky
2016-04-07 12:08 ` Sergey Senozhatsky
2016-04-07 13:15 ` Jan Kara
2016-08-10 21:17 ` Viresh Kumar
2016-08-12 9:44 ` Petr Mladek
2016-08-15 14:26 ` Vladislav Levenetz
2016-08-16 9:04 ` Petr Mladek
2016-08-18 2:27 ` Sergey Senozhatsky
2016-08-18 9:33 ` Petr Mladek
2016-08-18 9:51 ` Sergey Senozhatsky
2016-08-18 10:56 ` Petr Mladek
2016-08-19 6:32 ` Sergey Senozhatsky
2016-08-19 9:54 ` Petr Mladek
2016-08-19 19:00 ` Jan Kara
2016-08-20 5:24 ` Sergey Senozhatsky
2016-08-22 4:15 ` Sergey Senozhatsky
2016-08-23 12:19 ` Petr Mladek
2016-08-24 1:33 ` Sergey Senozhatsky
2016-08-25 21:10 ` Petr Mladek
2016-08-26 1:56 ` Sergey Senozhatsky
2016-08-26 8:20 ` Sergey Senozhatsky
2016-08-30 9:29 ` Petr Mladek
2016-08-31 2:31 ` Sergey Senozhatsky
2016-08-31 9:38 ` Petr Mladek
2016-08-31 12:52 ` Sergey Senozhatsky
2016-09-01 8:58 ` Petr Mladek
2016-09-02 7:58 ` Sergey Senozhatsky
2016-09-02 15:15 ` Petr Mladek
2016-09-06 7:16 ` Sergey Senozhatsky
2016-08-23 13:03 ` Petr Mladek
2016-08-23 13:48 ` Petr Mladek [this message]
2016-04-04 16:57 ` [PATCH v10 2/2] printk: Make wake_up_klogd_work_func() async Sergey Senozhatsky
2016-08-23 3:32 [PATCH v10 1/2] printk: Make printk() completely async Andreas Mohr
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=20160823134847.GF4866@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=akpm@linux-foundation.org \
--cc=byungchul.park@lge.com \
--cc=gregkh@linuxfoundation.org \
--cc=jack@suse.com \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=tj@kernel.org \
--cc=viresh.kumar@linaro.org \
--cc=vlevenetz@mm-sol.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).