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, _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
[PATCH next 0/2] printk: fix reading beyond buffer
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. However, the various readers used buffers that were about 1KB in size. The ringbuffer would only fill the reader's 1KB buffer, but the meta data stated that the message was actually much larger. The reader code was not checking this and assumed its buffer contained the full message. I have solved this problem by adding the necessary check to the functions where the situation can occur and also adding an argument when extending records so that a maximum size is specified. This will prevent the records from growing beyond the size that we know our readers are using. I did not add the check where it is certain that the reader's buffer is large enough to contain the largest possible message. The 2nd patch in this series reduces the size of the initial setup buffer. I noticed it was too big while verifying all the sizes for this series. John Ogness [0] https://lkml.kernel.org/r/f1651593-3579-5820-6863-5f4973d2b...@samsung.com John Ogness (2): printk: avoid and/or handle record truncation printk: reduce setup_text_buf size to LOG_LINE_MAX kernel/printk/printk.c| 9 +++-- kernel/printk/printk_ringbuffer.c | 12 ++-- kernel/printk/printk_ringbuffer.h | 2 +- 3 files changed, 18 insertions(+), 5 deletions(-) -- 2.20.1
