On Wed 2020-09-30 11:07:32, 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. > > 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
The patchset is committed in printk/linux.git, branch printk-rework. Best Regards, Petr
