[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200924012132.GA577@jagdpanzerIV.localdomain>
Date: Thu, 24 Sep 2020 10:21:32 +0900
From: Sergey Senozhatsky <sergey.senozhatsky@...il.com>
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>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH printk 3/5] printk: use buffer pool for sprint buffers
On (20/09/22 17:44), John Ogness wrote:
[..]
> int vprintk_store(int facility, int level,
> const struct dev_printk_info *dev_info,
> const char *fmt, va_list args)
> {
> - static char textbuf[LOG_LINE_MAX];
> - char *text = textbuf;
> size_t text_len;
> enum log_flags lflags = 0;
> + unsigned long irqflags;
> + int sprint_id;
> + char *text;
> + int ret;
> +
> + text = get_sprint_buf(&sprint_id, &irqflags);
> + if (WARN_ON_ONCE(!text))
> + return 0;
So we failed to get the buffer. How likely that this recursive
WARN_ON_ONCE()->printk()->get_sprint_buf() will be able to get one?
I would rather expect that we will entirely lose WARN_ON_ONCE().
-ss
Powered by blists - more mailing lists