From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: tj@kernel.org
Cc: akpm@linux-foundation.org, calvinowens@fb.com,
davej@codemonkey.org.uk, jack@suse.com, kyle@kernel.org,
stable@vger.kernel.org, mm-commits@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: + printk-do-cond_resched-between-lines-while-outputting-to-consoles.patch added to -mm tree
Date: Thu, 3 Dec 2015 10:11:29 +0900 [thread overview]
Message-ID: <20151203011129.GA510@swordfish> (raw)
In-Reply-To: <565f855a./bN6NB3bZKjpF4Wa%akpm@linux-foundation.org>
Hello,
On (12/02/15 15:57), akpm@linux-foundation.org wrote:
[..]
> @console_may_schedule tracks whether console_sem was acquired through lock
> or trylock. If the former, we're inside a sleepable context and
> console_conditional_schedule() performs cond_resched(). This allows
> console drivers which use console_lock for synchronization to yield while
> performing time-consuming operations such as scrolling.
>
> However, the actual console outputting is performed while holding irq-safe
> logbuf_lock, so console_unlock() clears @console_may_schedule before
> starting outputting lines. Also, only a few drivers call
> console_conditional_schedule() to begin with. This means that when a lot
> of lines need to be output by console_unlock(), for example on a console
> registration, the task doing console_unlock() may not yield for a long
> time on a non-preemptible kernel.
>
> If this happens with a slow console devices, for example a serial console,
> the outputting task may occupy the cpu for a very long time. Long enough
> to trigger softlockup and/or RCU stall warnings, which in turn pile more
> messages, sometimes enough to trigger the next cycle of warnings
> incapacitating the system.
>
> Fix it by making console_unlock() insert cond_resched() between lines if
> @console_may_schedule.
CPU2 still can cause lots of troubles. consider
CPU0 CPU1 CPU2
printk
... printk_deferred
printk wake_up_klogd
wake_up_klogd_work_func
console_trylock
console_unlock
printk_deferred() may be issued by scheduler, for example.
-ss
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Reported-by: Calvin Owens <calvinowens@fb.com>
> Acked-by: Jan Kara <jack@suse.com>
> Cc: Dave Jones <davej@codemonkey.org.uk>
> Cc: Kyle McMartin <kyle@kernel.org>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> kernel/printk/printk.c | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff -puN kernel/printk/printk.c~printk-do-cond_resched-between-lines-while-outputting-to-consoles kernel/printk/printk.c
> --- a/kernel/printk/printk.c~printk-do-cond_resched-between-lines-while-outputting-to-consoles
> +++ a/kernel/printk/printk.c
> @@ -2234,13 +2234,24 @@ void console_unlock(void)
> static u64 seen_seq;
> unsigned long flags;
> bool wake_klogd = false;
> - bool retry;
> + bool do_cond_resched, retry;
>
> if (console_suspended) {
> up_console_sem();
> return;
> }
>
> + /*
> + * Console drivers are called under logbuf_lock, so
> + * @console_may_schedule should be cleared before; however, we may
> + * end up dumping a lot of lines, for example, if called from
> + * console registration path, and should invoke cond_resched()
> + * between lines if allowable. Not doing so can cause a very long
> + * scheduling stall on a slow console leading to RCU stall and
> + * softlockup warnings which exacerbate the issue with more
> + * messages practically incapacitating the system.
> + */
> + do_cond_resched = console_may_schedule;
> console_may_schedule = 0;
>
> /* flush buffered message fragment immediately to console */
> @@ -2312,6 +2323,9 @@ skip:
> call_console_drivers(level, ext_text, ext_len, text, len);
> start_critical_timings();
> local_irq_restore(flags);
> +
> + if (do_cond_resched)
> + cond_resched();
> }
> console_locked = 0;
>
> _
>
> Patches currently in -mm which might be from tj@kernel.org are
>
> printk-do-cond_resched-between-lines-while-outputting-to-consoles.patch
>
> --
> To unsubscribe from this list: send the line "unsubscribe mm-commits" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next parent reply other threads:[~2015-12-03 1:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <565f855a./bN6NB3bZKjpF4Wa%akpm@linux-foundation.org>
2015-12-03 1:11 ` Sergey Senozhatsky [this message]
2015-12-03 2:39 ` + printk-do-cond_resched-between-lines-while-outputting-to-consoles.patch added to -mm tree Sergey Senozhatsky
2015-12-03 9:57 ` Jan Kara
2015-12-04 0:29 ` 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=20151203011129.GA510@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=mm-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox