[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <16c9a13fb945065cd1fc9f0b9ece1862e42867e0.camel@perches.com>
Date: Fri, 25 Sep 2020 20:28:00 -0700
From: Joe Perches <joe@...ches.com>
To: John Ogness <john.ogness@...utronix.de>,
Petr Mladek <pmladek@...e.com>
Cc: 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>,
Marek Szyprowski <m.szyprowski@...sung.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH next 0/2] printk: fix reading beyond buffer
On Sat, 2020-09-26 at 04:01 +0206, John Ogness wrote:
> Hello,
>
> Marek Szyprowski reported [0] a problem with a particular printk
> usage. This particular usage performs thousands of LOG_CONT calls.
> The printk.c implementation was only limiting the growing record by
> the maximum size available in the ringbuffer, thus creating a record
> that was several kilobytes in size. This in and of itself is not
> a problem.
Perhaps another mechanism would be to change the code to
add a backspace before the rotor and have the printk
ringbuffer actually backspace on \h when position > 0
Something like:
---
diff --git a/init/do_mounts_rd.c b/init/do_mounts_rd.c
index ac021ae6e6fa..8a36443b4866 100644
--- a/init/do_mounts_rd.c
+++ b/init/do_mounts_rd.c
@@ -257,7 +258,7 @@ int __init rd_load_image(char *from)
kernel_write(out_file, buf, BLOCK_SIZE, &out_pos);
#if !defined(CONFIG_S390)
if (!(i % 16)) {
- pr_cont("%c\b", rotator[rotate & 0x3]);
+ pr_cont("\h%c\b", rotator[rotate & 0x3]);
rotate++;
}
#endif
Powered by blists - more mailing lists