Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

[Sergey Senozhatsky]

On (01/10/18 13:05), Steven Rostedt wrote:
[..]
> My solution takes printk from its current unbounded state, and makes it
> fixed bounded. Which means printk() is now a O(1) algorithm.
						^^^
						O(logbuf)

and   O(logbuf) > watchdog_thresh   is totally possible. and there
is nothing super unlucky in having O(logbuf). limiting printk is the
right way to go, sure. but you limit it to the wrong thing. limiting
it to logbuf is not enough, especially given that logbuf size is
configurable via kernel param - it's a moving target. if one wants
printk to stop disappointing the watchdog then printk must learn to
respect watchdog's threshold.


https://marc.info/?l=linux-kernel&m=151444381104068


hence a small fix up

---

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 8882a4bf2a9e..4efa7542d84d 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2341,6 +2341,14 @@ void console_unlock(void)
 
 		printk_safe_enter_irqsave(flags);
 		raw_spin_lock(&logbuf_lock);
+
+		if (log_next_seq - console_seq > 666) {
+			console_seq = log_next_seq;
+			raw_spin_unlock(&logbuf_lock);
+			printk_safe_exit_irqrestore(flags);
+			panic("you mad bro? this can softlockup your system! let me fix that for you");
+		}
+
 		if (seen_seq != log_next_seq) {
 			wake_klogd = true;
 			seen_seq = log_next_seq;

---

> The solution is simple, everyone at KS agreed with it, there should be
> no controversy here.

frankly speaking, that's not what I recall ;)


[..]
> My printk solution is solid, with no risk of regressions of current
> printk usages.

except that handing off a console_sem to atomic task when there
is   O(logbuf) > watchdog_thresh   is a regression, basically...
it is what it is.


> If anything, I'll pull theses patches myself, and push them to Linus
> directly

lovely.

	-ss