From: Petr Mladek <pmladek@suse.com>
To: Sergey Senozhatsky <senozhatsky@chromium.org>
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>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org,
Michael Ellerman <mpe@ellerman.id.au>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Eric Biederman <ebiederm@xmission.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Nicholas Piggin <npiggin@gmail.com>,
Alistair Popple <alistair@popple.id.au>,
Jordan Niethe <jniethe5@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Kees Cook <keescook@chromium.org>,
Tiezhu Yang <yangtiezhu@loongson.cn>,
Alexey Kardashevskiy <aik@ozlabs.ru>, Yue Hu <huyue2@yulong.com>,
Rafael Aquini <aquini@redhat.com>,
"Guilherme G. Piccoli" <gpiccoli@canonical.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
linuxppc-dev@lists.ozlabs.org, kexec@lists.infradead.org
Subject: Re: [PATCH printk v2 2/5] printk: remove safe buffers
Date: Tue, 6 Apr 2021 13:17:48 +0200 [thread overview]
Message-ID: <YGxDXBJAolBCtojY@alley> (raw)
In-Reply-To: <YGZ9+kfQKxASmVDR@google.com>
On Fri 2021-04-02 11:14:18, Sergey Senozhatsky wrote:
> On (21/04/01 16:17), Petr Mladek wrote:
> > > For the long term, we should introduce a printk-context API that allows
> > > callers to perfectly pack their multi-line output into a single
> > > entry. We discussed [0][1] this back in August 2020.
> >
> > We need a "short" term solution. There are currently 3 solutions:
> >
> > 1. Keep nmi_safe() and all the hacks around.
> >
> > 2. Serialize nmi_cpu_backtrace() by a spin lock and later by
> > the special lock used also by atomic consoles.
> >
> > 3. Tell complaining people how to sort the messed logs.
>
> Are we talking about nmi_cpu_backtrace()->dump_stack() or some
> other path?
It is about serializing
if (regs)
show_regs(regs);
else
dump_stack();
in nmi_cpu_backtrace() when it is triggered on many(all) CPUs
at the same time.
> dump_stack() seems to be already serialized by `dump_lock`. Hmm,
> show_regs() is not serialized, seems like it should be under the
> same `dump_lock` as dump_stack().
Ah, I think that you already mentioned it in the past and I forget it.
Yes, we would need to synchronize all these dump/show functions using
the same lock. It is already the lock that might be taken recursively
on the same CPU.
In each case, we must not introduce another lock in
nmi_cpu_backtrace() because it might cause deadlock with
@dump_lock.
Anyway, I would really like to keep the dumps serialized. So, we
either need to use the same lock everywhere or we need to keep
nmi_safe buffers for now.
I would like to remove the nmi_safe buffers in the long term
but I am fine with doing it later after the consoles rework.
I'll leave the prioritization for John who is doing the work
and might have some preferences.
Best Regards,
Petr
WARNING: multiple messages have this Message-ID (diff)
From: Petr Mladek <pmladek@suse.com>
To: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Paul Mackerras <paulus@samba.org>,
Tiezhu Yang <yangtiezhu@loongson.cn>,
Rafael Aquini <aquini@redhat.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
Alexey Kardashevskiy <aik@ozlabs.ru>, Yue Hu <huyue2@yulong.com>,
Jordan Niethe <jniethe5@gmail.com>,
Kees Cook <keescook@chromium.org>,
John Ogness <john.ogness@linutronix.de>,
Alistair Popple <alistair@popple.id.au>,
"Guilherme G. Piccoli" <gpiccoli@canonical.com>,
Nicholas Piggin <npiggin@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Eric Biederman <ebiederm@xmission.com>,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH printk v2 2/5] printk: remove safe buffers
Date: Tue, 6 Apr 2021 13:17:48 +0200 [thread overview]
Message-ID: <YGxDXBJAolBCtojY@alley> (raw)
In-Reply-To: <YGZ9+kfQKxASmVDR@google.com>
On Fri 2021-04-02 11:14:18, Sergey Senozhatsky wrote:
> On (21/04/01 16:17), Petr Mladek wrote:
> > > For the long term, we should introduce a printk-context API that allows
> > > callers to perfectly pack their multi-line output into a single
> > > entry. We discussed [0][1] this back in August 2020.
> >
> > We need a "short" term solution. There are currently 3 solutions:
> >
> > 1. Keep nmi_safe() and all the hacks around.
> >
> > 2. Serialize nmi_cpu_backtrace() by a spin lock and later by
> > the special lock used also by atomic consoles.
> >
> > 3. Tell complaining people how to sort the messed logs.
>
> Are we talking about nmi_cpu_backtrace()->dump_stack() or some
> other path?
It is about serializing
if (regs)
show_regs(regs);
else
dump_stack();
in nmi_cpu_backtrace() when it is triggered on many(all) CPUs
at the same time.
> dump_stack() seems to be already serialized by `dump_lock`. Hmm,
> show_regs() is not serialized, seems like it should be under the
> same `dump_lock` as dump_stack().
Ah, I think that you already mentioned it in the past and I forget it.
Yes, we would need to synchronize all these dump/show functions using
the same lock. It is already the lock that might be taken recursively
on the same CPU.
In each case, we must not introduce another lock in
nmi_cpu_backtrace() because it might cause deadlock with
@dump_lock.
Anyway, I would really like to keep the dumps serialized. So, we
either need to use the same lock everywhere or we need to keep
nmi_safe buffers for now.
I would like to remove the nmi_safe buffers in the long term
but I am fine with doing it later after the consoles rework.
I'll leave the prioritization for John who is doing the work
and might have some preferences.
Best Regards,
Petr
WARNING: multiple messages have this Message-ID (diff)
From: Petr Mladek <pmladek@suse.com>
To: Sergey Senozhatsky <senozhatsky@chromium.org>
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>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org,
Michael Ellerman <mpe@ellerman.id.au>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Eric Biederman <ebiederm@xmission.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Nicholas Piggin <npiggin@gmail.com>,
Alistair Popple <alistair@popple.id.au>,
Jordan Niethe <jniethe5@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Kees Cook <keescook@chromium.org>,
Tiezhu Yang <yangtiezhu@loongson.cn>,
Alexey Kardashevskiy <aik@ozlabs.ru>, Yue Hu <huyue2@yulong.com>,
Rafael Aquini <aquini@redhat.com>,
"Guilherme G. Piccoli" <gpiccoli@canonical.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
linuxppc-dev@lists.ozlabs.org, kexec@lists.infradead.org
Subject: Re: [PATCH printk v2 2/5] printk: remove safe buffers
Date: Tue, 6 Apr 2021 13:17:48 +0200 [thread overview]
Message-ID: <YGxDXBJAolBCtojY@alley> (raw)
In-Reply-To: <YGZ9+kfQKxASmVDR@google.com>
On Fri 2021-04-02 11:14:18, Sergey Senozhatsky wrote:
> On (21/04/01 16:17), Petr Mladek wrote:
> > > For the long term, we should introduce a printk-context API that allows
> > > callers to perfectly pack their multi-line output into a single
> > > entry. We discussed [0][1] this back in August 2020.
> >
> > We need a "short" term solution. There are currently 3 solutions:
> >
> > 1. Keep nmi_safe() and all the hacks around.
> >
> > 2. Serialize nmi_cpu_backtrace() by a spin lock and later by
> > the special lock used also by atomic consoles.
> >
> > 3. Tell complaining people how to sort the messed logs.
>
> Are we talking about nmi_cpu_backtrace()->dump_stack() or some
> other path?
It is about serializing
if (regs)
show_regs(regs);
else
dump_stack();
in nmi_cpu_backtrace() when it is triggered on many(all) CPUs
at the same time.
> dump_stack() seems to be already serialized by `dump_lock`. Hmm,
> show_regs() is not serialized, seems like it should be under the
> same `dump_lock` as dump_stack().
Ah, I think that you already mentioned it in the past and I forget it.
Yes, we would need to synchronize all these dump/show functions using
the same lock. It is already the lock that might be taken recursively
on the same CPU.
In each case, we must not introduce another lock in
nmi_cpu_backtrace() because it might cause deadlock with
@dump_lock.
Anyway, I would really like to keep the dumps serialized. So, we
either need to use the same lock everywhere or we need to keep
nmi_safe buffers for now.
I would like to remove the nmi_safe buffers in the long term
but I am fine with doing it later after the consoles rework.
I'll leave the prioritization for John who is doing the work
and might have some preferences.
Best Regards,
Petr
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2021-04-06 11:17 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-30 15:35 [PATCH printk v2 0/5] printk: remove safe buffers John Ogness
2021-03-30 15:35 ` John Ogness
2021-03-30 15:35 ` John Ogness
2021-03-30 15:35 ` John Ogness
2021-03-30 15:35 ` [PATCH printk v2 1/5] printk: track/limit recursion John Ogness
2021-04-01 10:00 ` Petr Mladek
2021-04-02 2:03 ` Sergey Senozhatsky
2021-03-30 15:35 ` [PATCH printk v2 2/5] printk: remove safe buffers John Ogness
2021-03-30 15:35 ` John Ogness
2021-03-30 15:35 ` John Ogness
2021-03-31 7:59 ` John Ogness
2021-03-31 7:59 ` John Ogness
2021-03-31 7:59 ` John Ogness
2021-04-01 12:21 ` Petr Mladek
2021-04-01 12:21 ` Petr Mladek
2021-04-01 12:21 ` Petr Mladek
2021-04-01 13:19 ` John Ogness
2021-04-01 13:19 ` John Ogness
2021-04-01 13:19 ` John Ogness
2021-04-01 14:17 ` Petr Mladek
2021-04-01 14:17 ` Petr Mladek
2021-04-01 14:17 ` Petr Mladek
2021-04-02 2:14 ` Sergey Senozhatsky
2021-04-02 2:14 ` Sergey Senozhatsky
2021-04-02 2:14 ` Sergey Senozhatsky
2021-04-06 11:17 ` Petr Mladek [this message]
2021-04-06 11:17 ` Petr Mladek
2021-04-06 11:17 ` Petr Mladek
2021-04-06 11:01 ` John Ogness
2021-04-06 11:01 ` John Ogness
2021-04-06 11:01 ` John Ogness
2021-03-30 15:35 ` [PATCH printk v2 3/5] printk: remove NMI tracking John Ogness
2021-03-30 15:35 ` John Ogness
2021-03-30 15:35 ` John Ogness
2021-04-01 14:37 ` Petr Mladek
2021-04-01 14:37 ` Petr Mladek
2021-04-01 14:37 ` Petr Mladek
2021-03-30 15:35 ` [PATCH printk v2 4/5] printk: convert @syslog_lock to mutex John Ogness
2021-04-01 15:13 ` Petr Mladek
2021-03-30 15:35 ` [PATCH printk v2 5/5] printk: syslog: close window between wait and read 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=YGxDXBJAolBCtojY@alley \
--to=pmladek@suse.com \
--cc=aik@ozlabs.ru \
--cc=akpm@linux-foundation.org \
--cc=alistair@popple.id.au \
--cc=aneesh.kumar@linux.ibm.com \
--cc=aquini@redhat.com \
--cc=benh@kernel.crashing.org \
--cc=christophe.leroy@csgroup.eu \
--cc=ebiederm@xmission.com \
--cc=gpiccoli@canonical.com \
--cc=huyue2@yulong.com \
--cc=jniethe5@gmail.com \
--cc=john.ogness@linutronix.de \
--cc=keescook@chromium.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=paulmck@kernel.org \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=tglx@linutronix.de \
--cc=yangtiezhu@loongson.cn \
/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.