From: Petr Mladek <pmladek@suse.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: sergey.senozhatsky@gmail.com, jack@suse.com, tj@kernel.org,
kyle@kernel.org, davej@codemonkey.org.uk, calvinowens@fb.com,
akpm@linux-foundation.org, linux-mm@kvack.org, mhocko@kernel.org
Subject: Re: How to avoid printk() delay caused by cond_resched() ?
Date: Wed, 2 Mar 2016 16:21:32 +0100 [thread overview]
Message-ID: <20160302152132.GE22171@pathway.suse.cz> (raw)
In-Reply-To: <201603022311.CGC64089.HOOLJFVSMFQOtF@I-love.SAKURA.ne.jp>
On Wed 2016-03-02 23:11:30, Tetsuo Handa wrote:
> That's a good news. I was wishing that there were a dedicated kernel
> thread which does printk() operation. While at it, I ask for an API
> which waits for printk buffer to be flushed (something like below) so that
> a watchdog thread which might dump thousands of threads from sleepable
> context (like my dump) can avoid "** XXX printk messages dropped **"
> messages.
>
> ----------
> diff --git a/include/linux/console.h b/include/linux/console.h
> index ea731af..11e936c 100644
> --- a/include/linux/console.h
> +++ b/include/linux/console.h
> @@ -147,6 +147,7 @@ extern int unregister_console(struct console *);
> extern struct console *console_drivers;
> extern void console_lock(void);
> extern int console_trylock(void);
> +extern void wait_console_flushed(unsigned long timeout);
> extern void console_unlock(void);
> extern void console_conditional_schedule(void);
> extern void console_unblank(void);
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 9917f69..2eb60df 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -121,6 +121,15 @@ static int __down_trylock_console_sem(unsigned long ip)
> up(&console_sem);\
> } while (0)
>
> +static int __down_timeout_console_sem(unsigned long timeout, unsigned long ip)
> +{
> + if (down_timeout(&console_sem, timeout))
> + return 1;
> + mutex_acquire(&console_lock_dep_map, 0, 1, ip);
> + return 0;
> +}
> +#define down_timeout_console_sem(timeout) __down_timeout_console_sem((timeout), _RET_IP_)
> +
> /*
> * This is used for debugging the mess that is the VT code by
> * keeping track if we have the console semaphore held. It's
> @@ -2125,6 +2134,21 @@ int console_trylock(void)
> }
> EXPORT_SYMBOL(console_trylock);
>
> +void wait_console_flushed(unsigned long timeout)
> +{
> + might_sleep();
> +
> + if (down_timeout_console_sem(timeout))
> + return;
> + if (console_suspended) {
> + up_console_sem();
> + return;
> + }
> + console_locked = 1;
> + console_may_schedule = 1;
> + console_unlock();
> +}
This tries to take over the responsibility for printing to the
console. I would personally solve this by a wait queue.
console_unlock() might wakeup all waiters when empty. This
will work also when the console stuff is offloaded into
the workqueue.
But there still might be dropped messages if there is a flood
of them from another process. Note that even userspace could push
messages into the kernel ring buffer via /dev/kmsg. We need
to be careful against DOS attacks.
Best Regards,
Petr
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-03-02 15:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-02 12:01 How to avoid printk() delay caused by cond_resched() ? Tetsuo Handa
2016-03-02 13:38 ` Petr Mladek
2016-03-02 14:11 ` Tetsuo Handa
2016-03-02 15:21 ` Petr Mladek [this message]
2016-03-02 14:34 ` Sergey Senozhatsky
2016-03-02 14:56 ` Petr Mladek
2016-03-02 16:04 ` Jan Kara
2016-03-03 5:41 ` Sergey Senozhatsky
2016-03-02 14:04 ` Sergey Senozhatsky
2016-03-02 15:02 ` Tetsuo Handa
2016-03-02 15: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=20160302152132.GE22171@pathway.suse.cz \
--to=pmladek@suse.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-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--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.