All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH next v2 0/2] printk: fix reading beyond buffer
Date: Wed, 30 Sep 2020 15:30:55 +0200	[thread overview]
Message-ID: <20200930133055.GG29288@alley> (raw)
In-Reply-To: <20200930090134.8723-1-john.ogness@linutronix.de>

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-5f4973d2bfdc@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

      parent reply	other threads:[~2020-09-30 13:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-30  9:01 [PATCH next v2 0/2] printk: fix reading beyond buffer John Ogness
2020-09-30  9:01 ` [PATCH next v2 1/2] printk: avoid and/or handle record truncation John Ogness
2020-09-30  9:43   ` Sergey Senozhatsky
2020-09-30 10:24     ` John Ogness
2020-09-30 11:28       ` Petr Mladek
2020-09-30 11:42         ` John Ogness
2020-09-30 11:53           ` Petr Mladek
2020-09-30 23:25             ` Sergey Senozhatsky
2020-09-30 13:29   ` Petr Mladek
2020-09-30 15:25   ` Joe Perches
2020-10-01  7:26     ` Petr Mladek
2020-10-01  7:39       ` Joe Perches
2020-10-01  7:54         ` Petr Mladek
2020-09-30  9:01 ` [PATCH next v2 2/2] printk: reduce setup_text_buf size to LOG_LINE_MAX John Ogness
2020-09-30 13:30 ` Petr Mladek [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200930133055.GG29288@alley \
    --to=pmladek@suse.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.