From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
To: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
Steven Rostedt <rostedt@goodmis.org>,
Peter Zijlstra <peterz@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jslaby@suse.cz>,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] printk: Correctly handle preemption in console_unlock()
Date: Tue, 17 Jan 2017 00:19:41 +0900 [thread overview]
Message-ID: <20170116151941.GC23242@tigerII.localdomain> (raw)
In-Reply-To: <20170116141455.GT14894@pathway.suse.cz>
On (01/16/17 15:14), Petr Mladek wrote:
[..]
> > SYNC printk mode is also handled in deferred printk callback and
> > does console_trylock()/console_unlock().
>
> I am confused by the sentence.
>
> If it is a synchronous mode then console_trylock()/console_unlock() must
> be called directly from printk()/vprintk_emit().
>
> If you move this to a deferred callback, it is not longer synchronous.
yes, everything is about to move to the deferred printk() handler.
it has been discussed during the LPC/KS session. Linus proposed it,
to be exact. and I was quite sure that everyone in the room,
including you, agreed. we either do everything asking scheduled for
help (wake_up()), which is async printk. or do the print out from
deferred printk() handler /** 1) in case of panic() there is a
console_flush_on_panic() call. 2) once the system stores at least
one EMERG loglevel message, we don't wake_up() printk_kthread from
deferred printk handler. **/
but, well, probably this is not related to this thread.
> it is not longer synchronous.
well, a silly and boring note is that there is nothing that guarantees
or provides 'synchronous' printk(). console_sem simply can be locked
and printk() will just log_store(), while the actual printing will
happen sometime later (if ever) from whatever context that held the
console_sem. can be IRQ or anything else.
*may be* we need a new 'terminology' here. 'sync printk' does
not reflect the actual behavior and can give false expectations.
just a note.
> > > Then you would need to revert the entire commit 6b97a20d3a7909daa06625
> > > ("printk: set may_schedule for some of console_trylock() callers")
> > > to disable preemption also in preemptive kernel.
> >
> > we check can_use_console() in console_unlock(), with console_sem acquired.
> > it's not like the CPU will suddenly go offline from under us.
>
> I am not sure how this is related to the above. It talked about
> the "no resched" behavior.
>
> If you want to avoid preemtion in preemtible kernel, you need to
> disable preemtion.
>
> If you want to avoid preemtion in non-preemtible kernel, it is
> enough to do _not_ call cond_resched()/schedule().
[..]
> Your mail
> https://lkml.kernel.org/r/20170114062825.GB699@tigerII.localdomain
> suggested to avoid calling cond_resched(). This reverted the
> original behavior only for non-preemtible kernel.
> If we wanted to restore the original behavior also for preemtible
> kernel, we would need to disable preemtion around console_trylock/
> console_unlock() calls again.
ah, ok. the code there is not even a patch. so yes, could be
incomplete/wrong "revert".
[..]
> > well, we can add that *_orig/etc, but is it really worth it?
> > console_trylock() won't be used that often. not in printk at
> > least.
>
> IMHO, it is worth it because both patches go into the right direction.
well, ok. if you insist :)
-ss
next prev parent reply other threads:[~2017-01-16 15:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-13 13:15 [PATCH] printk: Correctly handle preemption in console_unlock() Petr Mladek
2017-01-13 16:05 ` Steven Rostedt
2017-01-16 11:00 ` Petr Mladek
2017-01-18 5:45 ` Sergey Senozhatsky
2017-01-18 7:21 ` Sergey Senozhatsky
2017-01-25 12:34 ` Petr Mladek
2017-01-14 6:28 ` Sergey Senozhatsky
2017-01-16 11:38 ` Petr Mladek
2017-01-16 11:58 ` Sergey Senozhatsky
2017-01-16 12:48 ` Petr Mladek
2017-01-16 13:26 ` Sergey Senozhatsky
2017-01-16 13:43 ` Sergey Senozhatsky
2017-01-16 14:14 ` Petr Mladek
2017-01-16 15:19 ` Sergey Senozhatsky [this message]
2017-01-16 15:43 ` Sergey Senozhatsky
2017-01-16 16:35 ` Petr Mladek
2017-01-16 13:41 ` Tetsuo Handa
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=20170116151941.GC23242@tigerII.localdomain \
--to=sergey.senozhatsky@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.cz \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
/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).