From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Petr Mladek <pmladek@suse.com>, Jan Kara <jack@suse.com>,
Tejun Heo <tj@kernel.org>, Kyle McMartin <kyle@kernel.org>,
Dave Jones <davej@codemonkey.org.uk>,
Calvin Owens <calvinowens@fb.com>,
linux-kernel@vger.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [RFC][PATCH v3 0/4] let printk()/console_trylock() callers to cond_resched()
Date: Wed, 3 Feb 2016 12:49:30 +0900 [thread overview]
Message-ID: <20160203034930.GA718@swordfish> (raw)
In-Reply-To: <1453536913-9545-1-git-send-email-sergey.senozhatsky@gmail.com>
Hello,
On (01/23/16 17:15), Sergey Senozhatsky wrote:
> [was: cond_resched() some of console_trylock callers]
>
> Hello,
>
> console_unlock() allows to cond_resched() if its caller has
> set `console_may_schedule' to 1 (this functionality present
> since commit 'printk: do cond_resched() between lines while
> outputting to consoles').
gentlemen, did you get a chance to look into this?
-ss
> The rules are:
> -- console_lock() always sets `console_may_schedule' to 1
> -- console_trylock() always sets `console_may_schedule' to 0
>
> printk() calls console_unlock() with preemption desabled, which
> basically can lead to RCU stalls, watchdog soft lockups, etc. if
> something is simultaneously calling printk() frequent enough (IOW,
> console_sem owner always has new data to send to console divers
> and can't leave console_unlock() for a long time).
>
> printk()->console_trylock() callers do not necessarily execute in
> atomic contexts, and some of them can cond_resched() in
> console_unlock(). console_trylock() can set `console_may_schedule'
> to 1 (allow cond_resched() later in consoe_unlock()) when it's safe.
>
> 0001 addresses a theoretical loss of printk messages.
> 0002 is an optional optimization patch
> 0003 drops console_trylock_for_printk
> 0004 lets some of printk()/console_trylock() callers to cond_resched()
> in console_unlock()
>
> v2-v3 (thanks to Petr Mladek for reviews):
> -- do not call can_use_console() on every iteration in console_unlock() (Petr Mladek)
> -- move "This stops the holder of console_sem.." comment (noted by Petr Mladek)
> -- take extra care of !PREEMPT_COUNT kernels (Petr Mladek)
> -- call_console_drivers() still must check cpu_online && CON_ANYTIME (Petr Mladek)
> -- removed console_trylock_for_printk() (noted by Petr Mladek)
>
> v1-v2:
> -- make have_callable_console() available for !PRINTK configs (lkp@intel.com)
> -- take care of RCU preempt kernels in console_trylock()
>
>
> Sergey Senozhatsky (4):
> printk: move can_use_console out of console_trylock_for_printk
> printk: do not console_cont_flush() on every jump to again
> printk: remove console_trylock_for_printk
> printk: set may_schedule for some of console_trylock callers
>
> kernel/printk/printk.c | 121 ++++++++++++++++++++++---------------------------
> 1 file changed, 55 insertions(+), 66 deletions(-)
>
> --
> 2.7.0
>
prev parent reply other threads:[~2016-02-03 3:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-23 8:15 [RFC][PATCH v3 0/4] let printk()/console_trylock() callers to cond_resched() Sergey Senozhatsky
2016-01-23 8:15 ` [RFC][PATCH v3 1/4] printk: move can_use_console out of console_trylock_for_printk Sergey Senozhatsky
2016-02-10 16:48 ` Petr Mladek
2016-02-11 7:57 ` Sergey Senozhatsky
2016-01-23 8:15 ` [RFC][PATCH v3 2/4] printk: do not console_cont_flush() on every jump to again Sergey Senozhatsky
2016-02-10 16:58 ` Petr Mladek
2016-02-11 8:03 ` Sergey Senozhatsky
2016-01-23 8:15 ` [RFC][PATCH v3 3/4] printk: remove console_trylock_for_printk Sergey Senozhatsky
2016-02-11 12:33 ` Petr Mladek
2016-01-23 8:15 ` [RFC][PATCH v3 4/4] printk: set may_schedule for some of console_trylock callers Sergey Senozhatsky
2016-02-11 14:41 ` Petr Mladek
2016-02-11 15:02 ` Sergey Senozhatsky
2016-02-11 16:10 ` Petr Mladek
2016-02-12 5:11 ` Sergey Senozhatsky
2016-02-03 3:49 ` Sergey Senozhatsky [this message]
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=20160203034930.GA718@swordfish \
--to=sergey.senozhatsky.work@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=calvinowens@fb.com \
--cc=davej@codemonkey.org.uk \
--cc=jack@suse.com \
--cc=kyle@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=tj@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.