From: Petr Mladek <pmladek@suse.com>
To: David Laight <David.Laight@aculab.com>
Cc: John Ogness <john.ogness@linutronix.de>,
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>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH printk 3/5] printk: use buffer pool for sprint buffers
Date: Wed, 23 Sep 2020 18:41:44 +0200 [thread overview]
Message-ID: <20200923164144.GF6442@alley> (raw)
In-Reply-To: <f4c854b05b394a5f9548715698fd5f59@AcuMS.aculab.com>
On Wed 2020-09-23 15:21:41, David Laight wrote:
> From: Petr Mladek
> > Sent: 23 September 2020 16:11
> >
> > On Tue 2020-09-22 17:44:14, John Ogness wrote:
> > > vprintk_store() is using a single static buffer as a temporary
> > > sprint buffer for the message text. This will not work once
> > > @logbuf_lock is removed. Replace the single static buffer with a
> > > pool of buffers.
> >
> > The buffer is used because we do not know the length of the
> > formatted message to reserve the right space in the ring buffer
> > in advance.
> >
> > There was the idea to call vsprintf(NULL, fmt, args) to count
> > the length in advance.
> >
> > AFAIK, there is one catch. We need to use va_copy() around
> > the 1st call because va_format can be proceed only once.
> > See, va_format() in lib/vsprintf.c as an example.
> >
> > Is there any other problem, please?
>
> Potentially the data can change after the vsprintf(NULL, ...)
> call so that the buffer isn't guaranteed to be the right length.
Yup. Well, in the worst case, we would shrink the text when the length
increased in the meantime. The content of such a message is racy
anyway.
> Never mind the extra cost of doing all the work twice.
IMHO, neither of this is worth the extra complexity with a pool
of buffers.
I would prefer to increase the complexity only when there are real life
problems.
Best Regards,
Petr
next prev parent reply other threads:[~2020-09-23 16:41 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-22 15:38 [PATCH printk 0/5] printk: remove logbuf_lock John Ogness
2020-09-22 15:38 ` [PATCH printk 1/5] printk: get new seq before enabling interrupts John Ogness
2020-09-23 14:17 ` Petr Mladek
2020-09-23 14:36 ` John Ogness
2020-09-22 15:38 ` [PATCH printk 2/5] printk: kmsg_dump_rewind_nolock: start from first record John Ogness
2020-09-23 14:52 ` Petr Mladek
2020-09-23 15:39 ` John Ogness
2020-09-22 15:38 ` [PATCH printk 3/5] printk: use buffer pool for sprint buffers John Ogness
2020-09-23 15:11 ` Petr Mladek
2020-09-23 15:21 ` David Laight
2020-09-23 16:41 ` Petr Mladek [this message]
2020-09-24 5:40 ` Sergey Senozhatsky
2020-09-24 8:45 ` Petr Mladek
2020-09-24 8:53 ` Sergey Senozhatsky
2020-09-24 9:49 ` Rasmus Villemoes
2020-09-25 8:15 ` Petr Mladek
2020-09-24 9:54 ` Rasmus Villemoes
2020-09-24 12:32 ` Rasmus Villemoes
2020-09-25 8:28 ` Petr Mladek
2020-09-30 8:06 ` Rasmus Villemoes
2020-09-30 8:51 ` Petr Mladek
2020-09-30 8:57 ` John Ogness
2020-09-30 13:35 ` Steven Rostedt
2020-09-30 14:32 ` David Laight
2020-10-01 7:15 ` Rasmus Villemoes
2020-10-01 7:58 ` Petr Mladek
2020-09-24 1:21 ` Sergey Senozhatsky
2020-09-24 6:17 ` Sergey Senozhatsky
2020-09-24 8:54 ` Petr Mladek
2020-09-24 9:06 ` Sergey Senozhatsky
2020-09-25 8:13 ` Petr Mladek
2020-09-22 15:38 ` [PATCH printk 4/5] printk: remove logbuf_lock, add syslog_lock John Ogness
2020-09-23 16:30 ` Petr Mladek
2020-09-24 8:45 ` Sergey Senozhatsky
2020-09-24 9:21 ` John Ogness
2020-09-22 15:38 ` [PATCH printk 5/5] printk: remove nmi safe buffers John Ogness
2020-09-23 16:36 ` Petr Mladek
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=20200923164144.GF6442@alley \
--to=pmladek@suse.com \
--cc=David.Laight@aculab.com \
--cc=gregkh@linuxfoundation.org \
--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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®