[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YFba1Fje6+TeIiGW@google.com>
Date: Sun, 21 Mar 2021 14:34:12 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: John Ogness <john.ogness@...utronix.de>
Cc: Petr Mladek <pmladek@...e.com>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH next v1 1/3] printk: track/limit recursion
On (21/03/17 00:33), John Ogness wrote:
[..]
> static inline void printk_delay(void)
> @@ -2040,11 +2105,13 @@ int vprintk_store(int facility, int level,
> struct prb_reserved_entry e;
> enum log_flags lflags = 0;
> struct printk_record r;
> + unsigned long irqflags;
> u16 trunc_msg_len = 0;
> char prefix_buf[8];
> u16 reserve_size;
> va_list args2;
> u16 text_len;
> + int ret = 0;
> u64 ts_nsec;
>
> /*
> @@ -2055,6 +2122,9 @@ int vprintk_store(int facility, int level,
> */
> ts_nsec = local_clock();
>
> + if (!printk_enter_irqsave(&irqflags))
> + return 0;
I guess it can be interesting to somehow signal us that we had printk()
recursion overflow, and how many messages we lost.
3 levels of recursion seem like reasonable limit, but I maybe wouldn't
mind one extra level. And maybe we could add some sort of message prefix
for high levels of recursion nesting (levels 3+), so that things should
not be normal will be on the radars and, possibly, will be reported.
-ss
Powered by blists - more mailing lists