All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Joe Perches' <joe@perches.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>,
	John Ogness <john.ogness@linutronix.de>,
	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: RE: POC: Alternative solution: Re: [PATCH 0/4] printk: reimplement LOG_CONT handling
Date: Sat, 15 Aug 2020 09:25:16 +0000	[thread overview]
Message-ID: <2777285d9e224c509e10b8448844f19a@AcuMS.aculab.com> (raw)
In-Reply-To: <b87a02b75c715d9a9f381fe3869612bb826a7351.camel@perches.com>

From: Joe Perches
> Sent: 15 August 2020 00:52
...
> > This is why I think any discussion that says "people should buffer
> > their lines themselves and we should get rid if pr_cont()" is
> > fundamentally broken.
> >
> > Don't go down that hole. I won't take it. It's wrong.
> 
> I don't think it's wrong per se.
> 
> It's reasonable to avoid pr_cont when appropriate.
> 
> Trivial buffering, or adding and using YA vsprintf
> extension can avoid unnecessary message interleaving.
> 
> For instance, I just sent this patch to allow removal
> of print_vma_addr and its use of pr_cont.
> 
> https://lore.kernel.org/lkml/09f11651f0e913e159b955ac447cd8cadf36cb0d.camel@perches.com/

ISTM that is a bit complex for a printf format.
Even with the 'noinline_for_stack' it is going to
use a lot of stack - and error printfs are already likely
to be near the stack limit.
The recursion for %pV might also cause grief.

In that case formatting the data into an on-stack char[]
before the printf is probably the simplest solution.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: 'Joe Perches' <joe@perches.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>,
	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	John Ogness <john.ogness@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: RE: POC: Alternative solution: Re: [PATCH 0/4] printk: reimplement LOG_CONT handling
Date: Sat, 15 Aug 2020 09:25:16 +0000	[thread overview]
Message-ID: <2777285d9e224c509e10b8448844f19a@AcuMS.aculab.com> (raw)
In-Reply-To: <b87a02b75c715d9a9f381fe3869612bb826a7351.camel@perches.com>

From: Joe Perches
> Sent: 15 August 2020 00:52
...
> > This is why I think any discussion that says "people should buffer
> > their lines themselves and we should get rid if pr_cont()" is
> > fundamentally broken.
> >
> > Don't go down that hole. I won't take it. It's wrong.
> 
> I don't think it's wrong per se.
> 
> It's reasonable to avoid pr_cont when appropriate.
> 
> Trivial buffering, or adding and using YA vsprintf
> extension can avoid unnecessary message interleaving.
> 
> For instance, I just sent this patch to allow removal
> of print_vma_addr and its use of pr_cont.
> 
> https://lore.kernel.org/lkml/09f11651f0e913e159b955ac447cd8cadf36cb0d.camel@perches.com/

ISTM that is a bit complex for a printf format.
Even with the 'noinline_for_stack' it is going to
use a lot of stack - and error printfs are already likely
to be near the stack limit.
The recursion for %pV might also cause grief.

In that case formatting the data into an on-stack char[]
before the printf is probably the simplest solution.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  parent reply	other threads:[~2020-08-16  1:29 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-17 23:48 [PATCH 0/4] printk: reimplement LOG_CONT handling John Ogness
2020-07-17 23:48 ` John Ogness
2020-07-17 23:48 ` [PATCH 1/4] printk: ringbuffer: support dataless records John Ogness
2020-07-17 23:48   ` John Ogness
2020-07-20 14:49   ` John Ogness
2020-07-20 14:49     ` John Ogness
2020-07-17 23:48 ` [PATCH 2/4] printk: store instead of processing cont parts John Ogness
2020-07-17 23:48   ` John Ogness
2020-07-19 14:35   ` Sergey Senozhatsky
2020-07-19 14:35     ` Sergey Senozhatsky
2020-07-19 18:27     ` Linus Torvalds
2020-07-19 18:27       ` Linus Torvalds
2020-07-20  1:50       ` Sergey Senozhatsky
2020-07-20  1:50         ` Sergey Senozhatsky
2020-07-20 18:30         ` Linus Torvalds
2020-07-20 18:30           ` Linus Torvalds
2020-07-21  3:53           ` Joe Perches
2020-07-21  3:53             ` Joe Perches
2020-07-21 14:42           ` Sergey Senozhatsky
2020-07-21 14:42             ` Sergey Senozhatsky
2020-07-21 14:57             ` John Ogness
2020-07-21 14:57               ` John Ogness
2020-07-29  2:03               ` Sergey Senozhatsky
2020-07-29  2:03                 ` Sergey Senozhatsky
2020-07-21 15:40             ` Linus Torvalds
2020-07-21 15:40               ` Linus Torvalds
2020-07-28  2:22               ` Sergey Senozhatsky
2020-07-28  2:22                 ` Sergey Senozhatsky
2020-07-17 23:48 ` [PATCH 3/4] printk: process cont records during reading John Ogness
2020-07-17 23:48   ` John Ogness
2020-07-17 23:48 ` [PATCH 4/4] ipconfig: cleanup printk usage John Ogness
2020-07-17 23:48   ` John Ogness
2020-07-18  0:00 ` [PATCH 0/4] printk: reimplement LOG_CONT handling Linus Torvalds
2020-07-18  0:00   ` Linus Torvalds
2020-07-18 14:42   ` John Ogness
2020-07-18 14:42     ` John Ogness
2020-07-18 17:42     ` Linus Torvalds
2020-07-18 17:42       ` Linus Torvalds
2020-08-11 16:05     ` Petr Mladek
2020-08-11 16:05       ` Petr Mladek
2020-08-12 16:39       ` POC: Alternative solution: " Petr Mladek
2020-08-12 16:39         ` Petr Mladek
2020-08-13  0:24         ` John Ogness
2020-08-13  0:24           ` John Ogness
2020-08-13  5:18           ` Sergey Senozhatsky
2020-08-13  5:18             ` Sergey Senozhatsky
2020-08-13  7:44             ` John Ogness
2020-08-13  7:44               ` John Ogness
2020-08-13  8:41               ` Petr Mladek
2020-08-13  8:41                 ` Petr Mladek
2020-08-13 10:29                 ` John Ogness
2020-08-13 10:29                   ` John Ogness
2020-08-13 11:30                   ` Petr Mladek
2020-08-13 11:30                     ` Petr Mladek
2020-08-14  3:34                   ` Sergey Senozhatsky
2020-08-14  3:34                     ` Sergey Senozhatsky
2020-08-14  8:16                     ` John Ogness
2020-08-14  8:16                       ` John Ogness
2020-08-14  9:12                       ` Petr Mladek
2020-08-14  9:12                         ` Petr Mladek
2020-08-13 11:54                 ` Sergey Senozhatsky
2020-08-13 11:54                   ` Sergey Senozhatsky
2020-08-14  9:04                   ` Petr Mladek
2020-08-14  9:04                     ` Petr Mladek
2020-08-14 22:46                   ` Linus Torvalds
2020-08-14 22:46                     ` Linus Torvalds
2020-08-14 23:52                     ` Joe Perches
2020-08-14 23:52                       ` Joe Perches
2020-08-15  2:33                       ` Linus Torvalds
2020-08-15  2:33                         ` Linus Torvalds
2020-08-15  3:08                         ` Joe Perches
2020-08-15  3:08                           ` Joe Perches
2020-08-15  9:25                       ` David Laight [this message]
2020-08-15  9:25                         ` David Laight
2020-08-15  5:41                     ` Sergey Senozhatsky
2020-08-15  5:41                       ` Sergey Senozhatsky
2020-08-13  7:51             ` Petr Mladek
2020-08-13  7:51               ` Petr Mladek
2020-08-13  7:31           ` Petr Mladek
2020-08-13  7:31             ` 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=2777285d9e224c509e10b8448844f19a@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=joe@perches.com \
    --cc=john.ogness@linutronix.de \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.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.