Kexec Archive on 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>,
	Peter Zijlstra <peterz@infradead.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	kexec@lists.infradead.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: POC: Alternative solution: Re: [PATCH 0/4] printk: reimplement LOG_CONT handling
Date: Fri, 14 Aug 2020 11:12:41 +0200	[thread overview]
Message-ID: <20200814091240.GL6215@alley> (raw)
In-Reply-To: <87k0y1k5gc.fsf@jogness.linutronix.de>

On Fri 2020-08-14 10:22:35, John Ogness wrote:
> On 2020-08-14, Sergey Senozhatsky <sergey.senozhatsky@gmail.com> wrote:
> > One thing that we need to handle here, I believe, is that the context
> > which crashes the kernel should flush its cont buffer, because the
> > information there is relevant to the crash:
> >
> > 	pr_cont_alloc_info(&c);
> > 	pr_cont(&c, "1");
> > 	pr_cont(&c, "2");
> > 	>>
> > 	   oops
> > 	      panic()
> > 	<<
> > 	pr_cont_flush(&c);
> >
> > We better flush that context's pr_cont buffer during panic().
> 
> I am not convinced of the general usefulness of partial messages, but as
> long as we have an API that includes registration, usage, and
> deregistration of some sort of handle, then we leave the window open for
> such implementations.

Registering some handle is an interesting idea. But it rules out
buffers on the stack. And we should avoid dynamic allocation.
printk() must be reliable also when there is not enough memory.

Please, keep it simple and do not add dependencies on new subsystems.
Using external code in printk() is always a call for problems.
The called code must be lockless and must not call printk().

Best Regards,
Petr

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

  reply	other threads:[~2020-08-14  9:12 UTC|newest]

Thread overview: 40+ 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 ` [PATCH 1/4] printk: ringbuffer: support dataless records 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-19 14:35   ` Sergey Senozhatsky
2020-07-19 18:27     ` Linus Torvalds
2020-07-20  1:50       ` Sergey Senozhatsky
2020-07-20 18:30         ` Linus Torvalds
2020-07-21  3:53           ` Joe Perches
2020-07-21 14:42           ` Sergey Senozhatsky
2020-07-21 14:57             ` John Ogness
2020-07-29  2:03               ` Sergey Senozhatsky
2020-07-21 15:40             ` Linus Torvalds
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 ` [PATCH 4/4] ipconfig: cleanup printk usage John Ogness
2020-07-18  0:00 ` [PATCH 0/4] printk: reimplement LOG_CONT handling Linus Torvalds
2020-07-18 14:42   ` John Ogness
2020-07-18 17:42     ` Linus Torvalds
2020-08-11 16:05     ` Petr Mladek
2020-08-12 16:39       ` POC: Alternative solution: " Petr Mladek
2020-08-13  0:24         ` John Ogness
2020-08-13  5:18           ` Sergey Senozhatsky
2020-08-13  7:44             ` John Ogness
2020-08-13  8:41               ` Petr Mladek
2020-08-13 10:29                 ` John Ogness
2020-08-13 11:30                   ` Petr Mladek
2020-08-14  3:34                   ` Sergey Senozhatsky
2020-08-14  8:16                     ` John Ogness
2020-08-14  9:12                       ` Petr Mladek [this message]
2020-08-13 11:54                 ` Sergey Senozhatsky
2020-08-14  9:04                   ` Petr Mladek
2020-08-14 22:46                   ` Linus Torvalds
2020-08-14 23:52                     ` Joe Perches
2020-08-15  2:33                       ` Linus Torvalds
2020-08-15  3:08                         ` Joe Perches
2020-08-15  9:25                       ` David Laight
2020-08-15  5:41                     ` Sergey Senozhatsky
2020-08-13  7:51             ` 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=20200814091240.GL6215@alley \
    --to=pmladek@suse.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=john.ogness@linutronix.de \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.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