From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> To: Steven Rostedt <rostedt@goodmis.org> Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>, Tejun Heo <tj@kernel.org>, Petr Mladek <pmladek@suse.com>, Sergey Senozhatsky <sergey.senozhatsky@gmail.com>, akpm@linux-foundation.org, linux-mm@kvack.org, Cong Wang <xiyou.wangcong@gmail.com>, Dave Hansen <dave.hansen@intel.com>, Johannes Weiner <hannes@cmpxchg.org>, Mel Gorman <mgorman@suse.de>, Michal Hocko <mhocko@kernel.org>, Vlastimil Babka <vbabka@suse.cz>, Peter Zijlstra <peterz@infradead.org>, Linus Torvalds <torvalds@linux-foundation.org>, Jan Kara <jack@suse.cz>, Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>, rostedt@rostedt.homelinux.com, Byungchul Park <byungchul.park@lge.com>, Pavel Machek <pavel@ucw.cz>, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup Date: Sun, 21 Jan 2018 23:15:21 +0900 [thread overview] Message-ID: <20180121141521.GA429@tigerII.localdomain> (raw) In-Reply-To: <20180120104931.1942483e@gandalf.local.home> On (01/20/18 10:49), Steven Rostedt wrote: [..] > > printks from console_unlock()->call_console_drivers() are redirected > > to printk_safe buffer. we need irq_work on that CPU to flush its > > printk_safe buffer. > > So is the issue that we keep triggering this irq work then? Then this > solution does seem to be one that would work. Because after x amount of > recursive printks (printk called by printk) it would just stop printing > them, and end the irq work. > > Perhaps what Tejun is seeing is: > > printk() > net_console() > printk() --> redirected to irq work > > <irq work> > printk > net_console() > printk() --> redirected to another irq work > > and so on and so on. it's a bit trickier than that, I think. we have printk recursion from console drivers. it's redirected to printk_safe and we queue an IRQ work to flush the buffer printk console_unlock call_console_drivers net_console printk printk_save -> irq_work queue now console_unlock() enables local IRQs, we have the printk_safe flush. but printk_safe flush does not call into the console_unlock(), it uses printk_deferred() version of printk IRQ work prink_safe_flush printk_deferred -> irq_work queue so we schedule another IRQ work (deferred printk work), which eventually tries to lock console_sem IRQ work wake_up_klogd_work_func() if (console_trylock()) console_unlock() if it succeeds then it goes to console_unlock(), where console driver can cause another printk recursion. but, once again, it will be redirected to printk_safe buffer first. if it fails then we have either the original CPU to print out those irq_work messages, which is sort of bad, or another CPU which already acquired the console_sem and will print out. > This solution would need to be tweaked to add a timer to allow only so > many nested printks in a given time. Otherwise it too would be an issue: [..] > > how are we going to distinguish between lockdep splats, for instance, > > or WARNs from call_console_drivers() -> foo_write(), which are valuable, > > and kmalloc() print outs, which might be less valuable? are we going to > > The problem is that printk causing more printks is extremely dangerous, > and ANY printk that is caused by a printk is of equal value, whether it > is a console driver running out of memory or a lockdep splat. And > the chances of having two hit at the same time is extremely low. so.... fix the console drivers ;) just kidding. ok... the problem is that we flush printk_safe right when console_unlock() printing loop enables local IRQs via printk_safe_exit_irqrestore() [given that IRQs were enabled in the first place when the CPU went to console_unlock()]. this forces that CPU to loop in console_unlock() as long as we have printk-s coming from call_console_drivers(). but we probably can postpone printk_safe flush. basically, we can declare a new rule - we don't flush printk_safe buffer as long as console_sem is locked. because this is how that printing CPU stuck in the console_unlock() printing loop. printk_safe buffer is very important when it comes to storing a non-repetitive stuff, like a lockdep splat, which is a single shot event. but the more repetitive the message is, like millions of similar kmalloc() dump_stack()-s over and over again, the less value in it. we should have printk_safe buffer big enough for important info, like a lockdep splat, but millions of similar kmalloc() messages are pretty invaluable - one is already enough, we can drop the rest. and we should not flush new messages while there is a CPU looping in console_unlock(), because it already has messages to print, which were log_store()-ed the normal way. this is where the "postpone thing" jumps in. so how do we postpone printk_safe flush. we can't console_trylock()/console_unlock() in printk_safe flush code. but there is a `console_locked' flag and is_console_locked() function which tell us if the console_sem is locked. as long as we are in console_unlock() printing loop that flag is set, even if we enabled local IRQs and printk_safe flush work arrived. so now printk_safe flush does extra check and does not flush printk_safe buffer content as long as someone is currently printing or soon will start printing. but we need to take extra step and to re-queue flush on CPUs that did postpone it [console_unlock() can reschedule]. so now we flush only when printing CPU printed all pending logbuf messages, hit the "console_seq == log_next_seq" and up() console_sem. this sets a boundary -- no matter how many times during the current printing loop we called console drivers and how many times those drivers caused printk recursion, we will flush only SAFE_LOG_BUF_LEN chars. IOW, what we have now, looks like this: a) printk_safe is for important stuff, we don't guarantee that a flood of messages will be preserved. b) we extend the previously existing "will flush messages later on from a safer context" and now we also consider console_unlock() printing loop as unsafe context. so the unsafe context it's not only the one that can deadlock, but also the one that can lockup CPU in a printing loop because of recursive printk messages. so this printk console_unlock { for (;;) { call_console_drivers net_console printk printk_save -> irq_work queue IRQ work prink_safe_flush printk_deferred -> log_store() iret } up(); } // which can never break out, because we can always append new messages // from prink_safe_flush. becomes this printk console_unlock { for (;;) { call_console_drivers net_console printk printk_save -> irq_work queue } up(); IRQ work prink_safe_flush printk_deferred -> log_store() iret } something completely untested, sketchy and ugly. --- kernel/printk/internal.h | 2 ++ kernel/printk/printk.c | 1 + kernel/printk/printk_safe.c | 37 +++++++++++++++++++++++++++++++++++-- 3 files changed, 38 insertions(+), 2 deletions(-) diff --git a/kernel/printk/internal.h b/kernel/printk/internal.h index 2a7d04049af4..e85517818a49 100644 --- a/kernel/printk/internal.h +++ b/kernel/printk/internal.h @@ -30,6 +30,8 @@ __printf(1, 0) int vprintk_func(const char *fmt, va_list args); void __printk_safe_enter(void); void __printk_safe_exit(void); +void printk_safe_requeue_flushing(void); + #define printk_safe_enter_irqsave(flags) \ do { \ local_irq_save(flags); \ diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index 9cb943c90d98..7aca23e8d7b2 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -2428,6 +2428,7 @@ void console_unlock(void) raw_spin_lock(&logbuf_lock); retry = console_seq != log_next_seq; raw_spin_unlock(&logbuf_lock); + printk_safe_requeue_flushing(); printk_safe_exit_irqrestore(flags); if (retry && console_trylock()) diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c index 3e3c2004bb23..45d5b292d7e1 100644 --- a/kernel/printk/printk_safe.c +++ b/kernel/printk/printk_safe.c @@ -22,6 +22,7 @@ #include <linux/cpumask.h> #include <linux/irq_work.h> #include <linux/printk.h> +#include <linux/console.h> #include "internal.h" @@ -51,6 +52,7 @@ struct printk_safe_seq_buf { atomic_t message_lost; struct irq_work work; /* IRQ work that flushes the buffer */ unsigned char buffer[SAFE_LOG_BUF_LEN]; + bool need_requeue; }; static DEFINE_PER_CPU(struct printk_safe_seq_buf, safe_print_seq); @@ -196,6 +198,7 @@ static void __printk_safe_flush(struct irq_work *work) size_t len; int i; + s->need_requeue = false; /* * The lock has two functions. First, one reader has to flush all * available message to make the lockless synchronization with @@ -243,6 +246,36 @@ static void __printk_safe_flush(struct irq_work *work) raw_spin_unlock_irqrestore(&read_lock, flags); } +/* NMI buffers are always flushed */ +static void flush_nmi_buffer(struct irq_work *work) +{ + __printk_safe_flush(work); +} + +/* printk_safe buffers flushing, on the contrary, can be postponed */ +static void flush_printk_safe_buffer(struct irq_work *work) +{ + struct printk_safe_seq_buf *s = + container_of(work, struct printk_safe_seq_buf, work); + + if (is_console_locked()) { + s->need_requeue = true; + return; + } + + __printk_safe_flush(work); +} + +void printk_safe_requeue_flushing(void) +{ + int cpu; + + for_each_possible_cpu(cpu) { + if (per_cpu(safe_print_seq, cpu).need_requeue) + queue_flush_work(&per_cpu(safe_print_seq, cpu)); + } +} + /** * printk_safe_flush - flush all per-cpu nmi buffers. * @@ -387,11 +420,11 @@ void __init printk_safe_init(void) struct printk_safe_seq_buf *s; s = &per_cpu(safe_print_seq, cpu); - init_irq_work(&s->work, __printk_safe_flush); + init_irq_work(&s->work, flush_printk_safe_buffer); #ifdef CONFIG_PRINTK_NMI s = &per_cpu(nmi_print_seq, cpu); - init_irq_work(&s->work, __printk_safe_flush); + init_irq_work(&s->work, flush_nmi_buffer); #endif } --- > > lose all of them now? then we can do a much simpler thing - steal one > > bit from `printk_context' and use if for a new PRINTK_NOOP_CONTEXT, which > > will be set around call_console_drivers(). vprintk_func() would redirect > > printks to vprintk_noop(fmt, args), which will do nothing. > > Not sure what you mean here. Have some pseudo code to demonstrate with? sure, I meant that if we want to disable printk recursion from call_console_drivers(), then we can add another printk_safe section, say printk_noop_begin()/printk_noop_end(), which would set a PRINTK_NOOP bit of `printk_context', so when we have printk() under PRINTK_NOOP then vprintk_func() goes to a special vprintk_noop(fmt, args), which simply drops the message [does not store any in the per-cpu printk safe buffer, so we don't flush it and don't add new messages to the logbuf]. and we annotate call_console_drivers() as a pintk_noop function. but that a no-brainer and I'd prefer to have another solution. -ss
WARNING: multiple messages have this Message-ID (diff)
From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> To: Steven Rostedt <rostedt@goodmis.org> Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>, Tejun Heo <tj@kernel.org>, Petr Mladek <pmladek@suse.com>, Sergey Senozhatsky <sergey.senozhatsky@gmail.com>, akpm@linux-foundation.org, linux-mm@kvack.org, Cong Wang <xiyou.wangcong@gmail.com>, Dave Hansen <dave.hansen@intel.com>, Johannes Weiner <hannes@cmpxchg.org>, Mel Gorman <mgorman@suse.de>, Michal Hocko <mhocko@kernel.org>, Vlastimil Babka <vbabka@suse.cz>, Peter Zijlstra <peterz@infradead.org>, Linus Torvalds <torvalds@linux-foundation.org>, Jan Kara <jack@suse.cz>, Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>, rostedt@home.goodmis.org, Byungchul Park <byungchul.park@lge.com>, Pavel Machek <pavel@ucw.cz>, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup Date: Sun, 21 Jan 2018 23:15:21 +0900 [thread overview] Message-ID: <20180121141521.GA429@tigerII.localdomain> (raw) In-Reply-To: <20180120104931.1942483e@gandalf.local.home> On (01/20/18 10:49), Steven Rostedt wrote: [..] > > printks from console_unlock()->call_console_drivers() are redirected > > to printk_safe buffer. we need irq_work on that CPU to flush its > > printk_safe buffer. > > So is the issue that we keep triggering this irq work then? Then this > solution does seem to be one that would work. Because after x amount of > recursive printks (printk called by printk) it would just stop printing > them, and end the irq work. > > Perhaps what Tejun is seeing is: > > printk() > net_console() > printk() --> redirected to irq work > > <irq work> > printk > net_console() > printk() --> redirected to another irq work > > and so on and so on. it's a bit trickier than that, I think. we have printk recursion from console drivers. it's redirected to printk_safe and we queue an IRQ work to flush the buffer printk console_unlock call_console_drivers net_console printk printk_save -> irq_work queue now console_unlock() enables local IRQs, we have the printk_safe flush. but printk_safe flush does not call into the console_unlock(), it uses printk_deferred() version of printk IRQ work prink_safe_flush printk_deferred -> irq_work queue so we schedule another IRQ work (deferred printk work), which eventually tries to lock console_sem IRQ work wake_up_klogd_work_func() if (console_trylock()) console_unlock() if it succeeds then it goes to console_unlock(), where console driver can cause another printk recursion. but, once again, it will be redirected to printk_safe buffer first. if it fails then we have either the original CPU to print out those irq_work messages, which is sort of bad, or another CPU which already acquired the console_sem and will print out. > This solution would need to be tweaked to add a timer to allow only so > many nested printks in a given time. Otherwise it too would be an issue: [..] > > how are we going to distinguish between lockdep splats, for instance, > > or WARNs from call_console_drivers() -> foo_write(), which are valuable, > > and kmalloc() print outs, which might be less valuable? are we going to > > The problem is that printk causing more printks is extremely dangerous, > and ANY printk that is caused by a printk is of equal value, whether it > is a console driver running out of memory or a lockdep splat. And > the chances of having two hit at the same time is extremely low. so.... fix the console drivers ;) just kidding. ok... the problem is that we flush printk_safe right when console_unlock() printing loop enables local IRQs via printk_safe_exit_irqrestore() [given that IRQs were enabled in the first place when the CPU went to console_unlock()]. this forces that CPU to loop in console_unlock() as long as we have printk-s coming from call_console_drivers(). but we probably can postpone printk_safe flush. basically, we can declare a new rule - we don't flush printk_safe buffer as long as console_sem is locked. because this is how that printing CPU stuck in the console_unlock() printing loop. printk_safe buffer is very important when it comes to storing a non-repetitive stuff, like a lockdep splat, which is a single shot event. but the more repetitive the message is, like millions of similar kmalloc() dump_stack()-s over and over again, the less value in it. we should have printk_safe buffer big enough for important info, like a lockdep splat, but millions of similar kmalloc() messages are pretty invaluable - one is already enough, we can drop the rest. and we should not flush new messages while there is a CPU looping in console_unlock(), because it already has messages to print, which were log_store()-ed the normal way. this is where the "postpone thing" jumps in. so how do we postpone printk_safe flush. we can't console_trylock()/console_unlock() in printk_safe flush code. but there is a `console_locked' flag and is_console_locked() function which tell us if the console_sem is locked. as long as we are in console_unlock() printing loop that flag is set, even if we enabled local IRQs and printk_safe flush work arrived. so now printk_safe flush does extra check and does not flush printk_safe buffer content as long as someone is currently printing or soon will start printing. but we need to take extra step and to re-queue flush on CPUs that did postpone it [console_unlock() can reschedule]. so now we flush only when printing CPU printed all pending logbuf messages, hit the "console_seq == log_next_seq" and up() console_sem. this sets a boundary -- no matter how many times during the current printing loop we called console drivers and how many times those drivers caused printk recursion, we will flush only SAFE_LOG_BUF_LEN chars. IOW, what we have now, looks like this: a) printk_safe is for important stuff, we don't guarantee that a flood of messages will be preserved. b) we extend the previously existing "will flush messages later on from a safer context" and now we also consider console_unlock() printing loop as unsafe context. so the unsafe context it's not only the one that can deadlock, but also the one that can lockup CPU in a printing loop because of recursive printk messages. so this printk console_unlock { for (;;) { call_console_drivers net_console printk printk_save -> irq_work queue IRQ work prink_safe_flush printk_deferred -> log_store() iret } up(); } // which can never break out, because we can always append new messages // from prink_safe_flush. becomes this printk console_unlock { for (;;) { call_console_drivers net_console printk printk_save -> irq_work queue } up(); IRQ work prink_safe_flush printk_deferred -> log_store() iret } something completely untested, sketchy and ugly. --- kernel/printk/internal.h | 2 ++ kernel/printk/printk.c | 1 + kernel/printk/printk_safe.c | 37 +++++++++++++++++++++++++++++++++++-- 3 files changed, 38 insertions(+), 2 deletions(-) diff --git a/kernel/printk/internal.h b/kernel/printk/internal.h index 2a7d04049af4..e85517818a49 100644 --- a/kernel/printk/internal.h +++ b/kernel/printk/internal.h @@ -30,6 +30,8 @@ __printf(1, 0) int vprintk_func(const char *fmt, va_list args); void __printk_safe_enter(void); void __printk_safe_exit(void); +void printk_safe_requeue_flushing(void); + #define printk_safe_enter_irqsave(flags) \ do { \ local_irq_save(flags); \ diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index 9cb943c90d98..7aca23e8d7b2 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -2428,6 +2428,7 @@ void console_unlock(void) raw_spin_lock(&logbuf_lock); retry = console_seq != log_next_seq; raw_spin_unlock(&logbuf_lock); + printk_safe_requeue_flushing(); printk_safe_exit_irqrestore(flags); if (retry && console_trylock()) diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c index 3e3c2004bb23..45d5b292d7e1 100644 --- a/kernel/printk/printk_safe.c +++ b/kernel/printk/printk_safe.c @@ -22,6 +22,7 @@ #include <linux/cpumask.h> #include <linux/irq_work.h> #include <linux/printk.h> +#include <linux/console.h> #include "internal.h" @@ -51,6 +52,7 @@ struct printk_safe_seq_buf { atomic_t message_lost; struct irq_work work; /* IRQ work that flushes the buffer */ unsigned char buffer[SAFE_LOG_BUF_LEN]; + bool need_requeue; }; static DEFINE_PER_CPU(struct printk_safe_seq_buf, safe_print_seq); @@ -196,6 +198,7 @@ static void __printk_safe_flush(struct irq_work *work) size_t len; int i; + s->need_requeue = false; /* * The lock has two functions. First, one reader has to flush all * available message to make the lockless synchronization with @@ -243,6 +246,36 @@ static void __printk_safe_flush(struct irq_work *work) raw_spin_unlock_irqrestore(&read_lock, flags); } +/* NMI buffers are always flushed */ +static void flush_nmi_buffer(struct irq_work *work) +{ + __printk_safe_flush(work); +} + +/* printk_safe buffers flushing, on the contrary, can be postponed */ +static void flush_printk_safe_buffer(struct irq_work *work) +{ + struct printk_safe_seq_buf *s = + container_of(work, struct printk_safe_seq_buf, work); + + if (is_console_locked()) { + s->need_requeue = true; + return; + } + + __printk_safe_flush(work); +} + +void printk_safe_requeue_flushing(void) +{ + int cpu; + + for_each_possible_cpu(cpu) { + if (per_cpu(safe_print_seq, cpu).need_requeue) + queue_flush_work(&per_cpu(safe_print_seq, cpu)); + } +} + /** * printk_safe_flush - flush all per-cpu nmi buffers. * @@ -387,11 +420,11 @@ void __init printk_safe_init(void) struct printk_safe_seq_buf *s; s = &per_cpu(safe_print_seq, cpu); - init_irq_work(&s->work, __printk_safe_flush); + init_irq_work(&s->work, flush_printk_safe_buffer); #ifdef CONFIG_PRINTK_NMI s = &per_cpu(nmi_print_seq, cpu); - init_irq_work(&s->work, __printk_safe_flush); + init_irq_work(&s->work, flush_nmi_buffer); #endif } --- > > lose all of them now? then we can do a much simpler thing - steal one > > bit from `printk_context' and use if for a new PRINTK_NOOP_CONTEXT, which > > will be set around call_console_drivers(). vprintk_func() would redirect > > printks to vprintk_noop(fmt, args), which will do nothing. > > Not sure what you mean here. Have some pseudo code to demonstrate with? sure, I meant that if we want to disable printk recursion from call_console_drivers(), then we can add another printk_safe section, say printk_noop_begin()/printk_noop_end(), which would set a PRINTK_NOOP bit of `printk_context', so when we have printk() under PRINTK_NOOP then vprintk_func() goes to a special vprintk_noop(fmt, args), which simply drops the message [does not store any in the per-cpu printk safe buffer, so we don't flush it and don't add new messages to the logbuf]. and we annotate call_console_drivers() as a pintk_noop function. but that a no-brainer and I'd prefer to have another solution. -ss -- 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:[~2018-01-21 14:15 UTC|newest] Thread overview: 280+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-01-10 13:24 [PATCH v5 0/2] printk: Console owner and waiter logic cleanup Petr Mladek 2018-01-10 13:24 ` Petr Mladek 2018-01-10 13:24 ` [PATCH v5 1/2] printk: Add console owner and waiter logic to load balance console writes Petr Mladek 2018-01-10 13:24 ` Petr Mladek 2018-01-10 16:50 ` Steven Rostedt 2018-01-10 16:50 ` Steven Rostedt 2018-01-12 16:54 ` Steven Rostedt 2018-01-12 16:54 ` Steven Rostedt 2018-01-12 17:11 ` Steven Rostedt 2018-01-12 17:11 ` Steven Rostedt 2018-01-17 19:13 ` Rasmus Villemoes 2018-01-17 19:13 ` Rasmus Villemoes 2018-01-17 19:33 ` Steven Rostedt 2018-01-17 19:33 ` Steven Rostedt 2018-01-19 9:51 ` Sergey Senozhatsky 2018-01-19 9:51 ` Sergey Senozhatsky 2018-01-18 22:03 ` Pavel Machek 2018-01-18 22:03 ` Pavel Machek 2018-01-19 0:20 ` Steven Rostedt 2018-01-19 0:20 ` Steven Rostedt 2018-01-17 2:19 ` Byungchul Park 2018-01-17 2:19 ` Byungchul Park 2018-01-17 4:54 ` Byungchul Park 2018-01-17 4:54 ` Byungchul Park 2018-01-17 7:34 ` Byungchul Park 2018-01-17 7:34 ` Byungchul Park 2018-01-17 12:04 ` Petr Mladek 2018-01-17 12:04 ` Petr Mladek 2018-01-18 1:53 ` Byungchul Park 2018-01-18 1:53 ` Byungchul Park 2018-01-18 1:57 ` Byungchul Park 2018-01-18 1:57 ` Byungchul Park 2018-01-18 2:19 ` Steven Rostedt 2018-01-18 2:19 ` Steven Rostedt 2018-01-18 4:01 ` Byungchul Park 2018-01-18 4:01 ` Byungchul Park 2018-01-18 15:21 ` Steven Rostedt 2018-01-18 15:21 ` Steven Rostedt 2018-01-19 2:37 ` Byungchul Park 2018-01-19 2:37 ` Byungchul Park 2018-01-19 3:27 ` Steven Rostedt 2018-01-19 3:27 ` Steven Rostedt 2018-01-22 2:31 ` Byungchul Park 2018-01-22 2:31 ` Byungchul Park 2018-01-10 13:24 ` [PATCH v5 2/2] printk: Hide console waiter logic into helpers Petr Mladek 2018-01-10 13:24 ` Petr Mladek 2018-01-10 17:52 ` Steven Rostedt 2018-01-10 17:52 ` Steven Rostedt 2018-01-11 12:03 ` Petr Mladek 2018-01-11 12:03 ` Petr Mladek 2018-01-12 15:37 ` Steven Rostedt 2018-01-12 15:37 ` Steven Rostedt 2018-01-12 16:08 ` Petr Mladek 2018-01-12 16:08 ` Petr Mladek 2018-01-12 16:36 ` Steven Rostedt 2018-01-12 16:36 ` Steven Rostedt 2018-01-15 16:08 ` Petr Mladek 2018-01-15 16:08 ` Petr Mladek 2018-01-16 5:05 ` Sergey Senozhatsky 2018-01-16 5:05 ` Sergey Senozhatsky 2018-01-10 14:05 ` [PATCH v5 0/2] printk: Console owner and waiter logic cleanup Tejun Heo 2018-01-10 14:05 ` Tejun Heo 2018-01-10 16:29 ` Petr Mladek 2018-01-10 16:29 ` Petr Mladek 2018-01-10 17:02 ` Tejun Heo 2018-01-10 17:02 ` Tejun Heo 2018-01-10 18:21 ` Peter Zijlstra 2018-01-10 18:21 ` Peter Zijlstra 2018-01-10 18:30 ` Tejun Heo 2018-01-10 18:30 ` Tejun Heo 2018-01-10 18:41 ` Peter Zijlstra 2018-01-10 18:41 ` Peter Zijlstra 2018-01-10 19:05 ` Tejun Heo 2018-01-10 19:05 ` Tejun Heo 2018-01-11 5:15 ` Sergey Senozhatsky 2018-01-11 5:15 ` Sergey Senozhatsky 2018-01-10 18:22 ` Steven Rostedt 2018-01-10 18:22 ` Steven Rostedt 2018-01-10 18:36 ` Tejun Heo 2018-01-10 18:36 ` Tejun Heo 2018-01-10 18:40 ` Mathieu Desnoyers 2018-01-10 18:40 ` Mathieu Desnoyers 2018-01-11 7:36 ` Sergey Senozhatsky 2018-01-11 7:36 ` Sergey Senozhatsky 2018-01-11 11:24 ` Petr Mladek 2018-01-11 11:24 ` Petr Mladek 2018-01-11 13:19 ` Sergey Senozhatsky 2018-01-11 13:19 ` Sergey Senozhatsky 2018-01-24 9:36 ` Peter Zijlstra 2018-01-24 9:36 ` Peter Zijlstra 2018-01-24 18:46 ` Tejun Heo 2018-01-24 18:46 ` Tejun Heo 2018-05-09 8:58 ` Sergey Senozhatsky 2018-05-09 8:58 ` Sergey Senozhatsky 2018-01-10 18:54 ` Steven Rostedt 2018-01-10 18:54 ` Steven Rostedt 2018-01-11 5:10 ` Sergey Senozhatsky 2018-01-11 5:10 ` Sergey Senozhatsky 2018-01-10 18:05 ` Steven Rostedt 2018-01-10 18:05 ` Steven Rostedt 2018-01-10 18:12 ` Tejun Heo 2018-01-10 18:12 ` Tejun Heo 2018-01-10 18:14 ` Tejun Heo 2018-01-10 18:14 ` Tejun Heo 2018-01-10 18:45 ` Steven Rostedt 2018-01-10 18:45 ` Steven Rostedt 2018-01-10 18:41 ` Steven Rostedt 2018-01-10 18:41 ` Steven Rostedt 2018-01-10 18:57 ` Tejun Heo 2018-01-10 18:57 ` Tejun Heo 2018-01-10 19:17 ` Steven Rostedt 2018-01-10 19:17 ` Steven Rostedt 2018-01-10 19:34 ` Tejun Heo 2018-01-10 19:34 ` Tejun Heo 2018-01-10 19:44 ` Steven Rostedt 2018-01-10 19:44 ` Steven Rostedt 2018-01-10 22:44 ` Tejun Heo 2018-01-10 22:44 ` Tejun Heo 2018-01-11 5:35 ` Sergey Senozhatsky 2018-01-11 5:35 ` Sergey Senozhatsky 2018-01-11 4:58 ` Sergey Senozhatsky 2018-01-11 4:58 ` Sergey Senozhatsky 2018-01-11 9:34 ` Petr Mladek 2018-01-11 9:34 ` Petr Mladek 2018-01-11 10:38 ` Sergey Senozhatsky 2018-01-11 10:38 ` Sergey Senozhatsky 2018-01-11 11:50 ` Petr Mladek 2018-01-11 11:50 ` Petr Mladek 2018-01-11 16:29 ` Steven Rostedt 2018-01-11 16:29 ` Steven Rostedt 2018-01-12 1:30 ` Steven Rostedt 2018-01-12 1:30 ` Steven Rostedt 2018-01-12 2:55 ` Steven Rostedt 2018-01-12 2:55 ` Steven Rostedt 2018-01-12 4:20 ` Steven Rostedt 2018-01-12 4:20 ` Steven Rostedt 2018-01-16 19:44 ` Tejun Heo 2018-01-16 19:44 ` Tejun Heo 2018-01-17 9:12 ` Petr Mladek 2018-01-17 9:12 ` Petr Mladek 2018-01-17 15:15 ` Tejun Heo 2018-01-17 15:15 ` Tejun Heo 2018-01-17 17:12 ` Steven Rostedt 2018-01-17 17:12 ` Steven Rostedt 2018-01-17 18:42 ` Steven Rostedt 2018-01-17 18:42 ` Steven Rostedt 2018-01-19 18:20 ` Steven Rostedt 2018-01-19 18:20 ` Steven Rostedt 2018-01-20 7:14 ` Sergey Senozhatsky 2018-01-20 7:14 ` Sergey Senozhatsky 2018-01-20 15:49 ` Steven Rostedt 2018-01-20 15:49 ` Steven Rostedt 2018-01-21 14:15 ` Sergey Senozhatsky [this message] 2018-01-21 14:15 ` Sergey Senozhatsky 2018-01-21 21:04 ` Steven Rostedt 2018-01-21 21:04 ` Steven Rostedt 2018-01-22 8:56 ` Sergey Senozhatsky 2018-01-22 8:56 ` Sergey Senozhatsky 2018-01-22 10:28 ` Sergey Senozhatsky 2018-01-22 10:28 ` Sergey Senozhatsky 2018-01-22 10:36 ` Sergey Senozhatsky 2018-01-22 10:36 ` Sergey Senozhatsky 2018-01-23 6:40 ` Sergey Senozhatsky 2018-01-23 6:40 ` Sergey Senozhatsky 2018-01-23 7:05 ` Sergey Senozhatsky 2018-01-23 7:05 ` Sergey Senozhatsky 2018-01-23 7:31 ` Sergey Senozhatsky 2018-01-23 7:31 ` Sergey Senozhatsky 2018-01-23 14:56 ` Steven Rostedt 2018-01-23 14:56 ` Steven Rostedt 2018-01-23 15:21 ` Sergey Senozhatsky 2018-01-23 15:21 ` Sergey Senozhatsky 2018-01-23 15:41 ` Steven Rostedt 2018-01-23 15:41 ` Steven Rostedt 2018-01-23 15:43 ` Tejun Heo 2018-01-23 15:43 ` Tejun Heo 2018-01-23 16:12 ` Sergey Senozhatsky 2018-01-23 16:12 ` Sergey Senozhatsky 2018-01-23 16:13 ` Steven Rostedt 2018-01-23 16:13 ` Steven Rostedt 2018-01-23 17:21 ` Tejun Heo 2018-01-23 17:21 ` Tejun Heo 2018-04-23 5:35 ` Sergey Senozhatsky 2018-04-23 5:35 ` Sergey Senozhatsky 2018-01-23 16:01 ` Sergey Senozhatsky 2018-01-23 16:01 ` Sergey Senozhatsky 2018-01-23 16:24 ` Steven Rostedt 2018-01-23 16:24 ` Steven Rostedt 2018-01-24 2:11 ` Sergey Senozhatsky 2018-01-24 2:11 ` Sergey Senozhatsky 2018-01-24 2:52 ` Steven Rostedt 2018-01-24 2:52 ` Steven Rostedt 2018-01-24 4:44 ` Sergey Senozhatsky 2018-01-24 4:44 ` Sergey Senozhatsky 2018-01-23 17:22 ` Tejun Heo 2018-01-23 17:22 ` Tejun Heo 2018-01-20 12:19 ` Tejun Heo 2018-01-20 12:19 ` Tejun Heo 2018-01-20 14:51 ` Steven Rostedt 2018-01-20 14:51 ` Steven Rostedt 2018-01-17 20:05 ` Tejun Heo 2018-01-17 20:05 ` Tejun Heo 2018-01-18 5:43 ` Sergey Senozhatsky 2018-01-18 5:43 ` Sergey Senozhatsky 2018-01-18 11:51 ` Petr Mladek 2018-01-18 11:51 ` Petr Mladek 2018-01-18 5:42 ` Sergey Senozhatsky 2018-01-18 5:42 ` Sergey Senozhatsky 2018-01-12 3:12 ` Sergey Senozhatsky 2018-01-12 3:12 ` Sergey Senozhatsky 2018-01-12 2:56 ` Sergey Senozhatsky 2018-01-12 2:56 ` Sergey Senozhatsky 2018-01-12 3:21 ` Steven Rostedt 2018-01-12 3:21 ` Steven Rostedt 2018-01-12 10:05 ` Sergey Senozhatsky 2018-01-12 10:05 ` Sergey Senozhatsky 2018-01-12 12:21 ` Steven Rostedt 2018-01-12 12:21 ` Steven Rostedt 2018-01-12 12:55 ` Petr Mladek 2018-01-12 12:55 ` Petr Mladek 2018-01-13 7:31 ` Sergey Senozhatsky 2018-01-13 7:31 ` Sergey Senozhatsky 2018-01-15 8:51 ` Petr Mladek 2018-01-15 8:51 ` Petr Mladek 2018-01-15 9:48 ` Sergey Senozhatsky 2018-01-15 9:48 ` Sergey Senozhatsky 2018-01-16 5:16 ` Sergey Senozhatsky 2018-01-16 5:16 ` Sergey Senozhatsky 2018-01-16 9:08 ` Petr Mladek 2018-01-16 9:08 ` Petr Mladek 2018-01-15 12:08 ` Steven Rostedt 2018-01-15 12:08 ` Steven Rostedt 2018-01-16 4:51 ` Sergey Senozhatsky 2018-01-16 4:51 ` Sergey Senozhatsky 2018-01-13 7:28 ` Sergey Senozhatsky 2018-01-13 7:28 ` Sergey Senozhatsky 2018-01-15 10:17 ` Petr Mladek 2018-01-15 10:17 ` Petr Mladek 2018-01-15 11:50 ` Petr Mladek 2018-01-15 11:50 ` Petr Mladek 2018-01-16 6:10 ` Sergey Senozhatsky 2018-01-16 6:10 ` Sergey Senozhatsky 2018-01-16 9:36 ` Petr Mladek 2018-01-16 9:36 ` Petr Mladek 2018-01-16 10:10 ` Sergey Senozhatsky 2018-01-16 10:10 ` Sergey Senozhatsky 2018-01-16 16:06 ` Steven Rostedt 2018-01-16 16:06 ` Steven Rostedt 2018-01-16 5:23 ` Sergey Senozhatsky 2018-01-16 5:23 ` Sergey Senozhatsky 2018-01-15 12:06 ` Steven Rostedt 2018-01-15 12:06 ` Steven Rostedt 2018-01-15 14:45 ` Petr Mladek 2018-01-15 14:45 ` Petr Mladek 2018-01-16 2:23 ` Sergey Senozhatsky 2018-01-16 2:23 ` Sergey Senozhatsky 2018-01-16 4:47 ` Sergey Senozhatsky 2018-01-16 4:47 ` Sergey Senozhatsky 2018-01-16 10:19 ` Petr Mladek 2018-01-16 10:19 ` Petr Mladek 2018-01-17 2:24 ` Sergey Senozhatsky 2018-01-17 2:24 ` Sergey Senozhatsky 2018-01-16 15:45 ` Steven Rostedt 2018-01-16 15:45 ` Steven Rostedt 2018-01-17 2:18 ` Sergey Senozhatsky 2018-01-17 2:18 ` Sergey Senozhatsky 2018-01-17 13:04 ` Petr Mladek 2018-01-17 13:04 ` Petr Mladek 2018-01-17 15:24 ` Steven Rostedt 2018-01-17 15:24 ` Steven Rostedt 2018-01-18 4:31 ` Sergey Senozhatsky 2018-01-18 4:31 ` Sergey Senozhatsky 2018-01-18 15:22 ` Steven Rostedt 2018-01-18 15:22 ` Steven Rostedt 2018-01-16 10:13 ` Petr Mladek 2018-01-16 10:13 ` Petr Mladek 2018-01-17 6:29 ` Sergey Senozhatsky 2018-01-17 6:29 ` Sergey Senozhatsky 2018-01-16 1:46 ` Sergey Senozhatsky 2018-01-16 1:46 ` 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=20180121141521.GA429@tigerII.localdomain \ --to=sergey.senozhatsky@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=byungchul.park@lge.com \ --cc=dave.hansen@intel.com \ --cc=hannes@cmpxchg.org \ --cc=jack@suse.cz \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mathieu.desnoyers@efficios.com \ --cc=mgorman@suse.de \ --cc=mhocko@kernel.org \ --cc=pavel@ucw.cz \ --cc=penguin-kernel@I-love.SAKURA.ne.jp \ --cc=peterz@infradead.org \ --cc=pmladek@suse.com \ --cc=rostedt@goodmis.org \ --cc=rostedt@rostedt.homelinux.com \ --cc=sergey.senozhatsky.work@gmail.com \ --cc=tj@kernel.org \ --cc=torvalds@linux-foundation.org \ --cc=vbabka@suse.cz \ --cc=xiyou.wangcong@gmail.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: linkBe 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.