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@gmail.com>,
	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] printk: fix buffer overflow potential for print_text()
Date: Tue, 19 Jan 2021 13:22:02 +0100	[thread overview]
Message-ID: <YAbO6tQelFISgovf@alley> (raw)
In-Reply-To: <87bldl5exc.fsf@jogness.linutronix.de>

On Tue 2021-01-19 12:50:47, John Ogness wrote:
> On 2021-01-19, Sergey Senozhatsky <sergey.senozhatsky@gmail.com> wrote:
> >>> John, how did you spot these problems?
> >> 
> >> I am preparing my series to remove the logbuf_lock, which also
> >> refactors and consolidates code from syslog_print_all() and
> >> kmsg_dump_get_buffer(). While testing/verifying my series, I noticed
> >> the these oddities in the semantics and decided I should research
> >> where they came from and if they were actually necessary.
> >
> > Any chance you can put those tests somewhere public so that we can
> > run them regularly?

Great idea.

> I have a collection of hacked-together tools that I use to test most of
> the various interfaces of printk. I would need to clean them up if they
> should be used for any kind of automated regression testing.

Sounds good. We could even help with the clean up. This kind of code
always need it when it was not written for public use from scratch.

> And where should I make such things available? I could put them in a
> repo in the Linutronix github account (like I did for the ringbuffer
> stress testing tool). (??)

Sounds good as well.

Best Regards,
Petr

  reply	other threads:[~2021-01-19 12:35 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-14 17:04 [PATCH] printk: fix buffer overflow potential for print_text() John Ogness
2021-01-15 12:04 ` Petr Mladek
2021-01-15 12:07   ` Petr Mladek
2021-01-19  0:44     ` Sergey Senozhatsky
2021-01-19  8:54       ` John Ogness
2021-01-19 10:29         ` Sergey Senozhatsky
2021-01-19 11:44           ` John Ogness
2021-01-19 12:22             ` Petr Mladek [this message]
2021-01-19 11:20       ` Petr Mladek
2021-01-15 14:16 ` John Ogness
2021-01-15 16:04   ` Petr Mladek
2021-01-22 21:21 ` Sven Schnelle
2021-01-22 23:42   ` John Ogness
2021-01-23 21:18     ` Sven Schnelle
2021-01-23 21:41       ` Sven Schnelle
2021-01-24  8:13         ` John Ogness
2021-01-24  8:59           ` Sven Schnelle
2021-02-26 17:19 ` Alexander Gordeev
2021-02-26 17:39   ` John Ogness

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=YAbO6tQelFISgovf@alley \
    --to=pmladek@suse.com \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=sergey.senozhatsky@gmail.com \
    --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.