From: John Ogness <john.ogness@linutronix.de>
To: takakura@valinux.co.jp, pmladek@suse.com
Cc: akpm@linux-foundation.org, bhe@redhat.com, feng.tang@intel.com,
j.granados@samsung.com, linux-kernel@vger.kernel.org,
lukas@wunner.de, nishimura@valinux.co.jp, rostedt@goodmis.org,
senozhatsky@chromium.org, stephen.s.brennan@oracle.com,
taka@valinux.co.jp, takakura@valinux.co.jp, ubizjak@gmail.com,
wangkefeng.wang@huawei.com
Subject: Re: [PATCH v3 2/2] Handle flushing of CPU backtraces during panic
Date: Mon, 26 Aug 2024 17:52:34 +0206 [thread overview]
Message-ID: <877cc38exx.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <20240821050254.69853-1-takakura@valinux.co.jp>
On 2024-08-21, takakura@valinux.co.jp wrote:
>>> /**
>>> * console_try_or_trigger_flush - try to flush consoles directly when
>>> * safe or the trigger deferred flush.
>>> *
>>> * Context: Any
>>> */
>>> void console_try_or_trigger_flush(void)
>>> {
>>> if (!is_printk_legacy_deferred() && console_trylock())
>>> console_unlock();
>>> else
>>> defer_console_output();
>>> }
>>>
>>> and use it instead of printk_trigger_flush() in
>>> nmi_trigger_cpumask_backtrace().
>>
>> Just to be clear, you are talking about removing
>> printk_trigger_flush() entirely and instead provide the new
>> console_try_or_trigger_flush()? Which then also involves updating
>> the call sites:
>>
>> lib/nmi_backtrace.c:nmi_trigger_cpumask_backtrace()
>> arch/powerpc/kernel/watchdog.c:watchdog_timer_interrupt()
>>
>
> Taking a look at [0], in addition to the mentioned call sites,
> nbcon_device_release() will also be calling printk_trigger_flush()?
> For nbcon_device_release(), I thought its better not to be replaced as
> it calles for @legacy_off, in which case printk_trigger_flush() seems
> more suitable as it always defers printing.
The @legacy_off logic would be within console_try_or_trigger_flush(),
so the result would be the same.
> Also taking a look at the [1], for nmi_trigger_cpumask_backtrace(),
> I thought that it will not comply with the syncing of
> legacy_allow_panic_sync. I believe it will allow flushing of legacy consoles
> before printk_legacy_allow_panic_sync() which is out of sync.
But isn't your patch also causing that violation?
printk_legacy_allow_panic_sync() performs a trylock/unlock. Isn't that
good enough?
John
next prev parent reply other threads:[~2024-08-26 15:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-12 7:21 [PATCH v3 0/2] printk: CPU backtrace not printing on panic takakura
2024-08-12 7:27 ` [PATCH v3 1/2] Allow cpu backtraces to be written into ringbuffer during panic takakura
2024-08-13 13:48 ` Petr Mladek
2024-08-15 10:41 ` takakura
2024-08-12 7:29 ` [PATCH v3 2/2] Handle flushing of CPU backtraces " takakura
2024-08-13 13:45 ` Petr Mladek
2024-08-15 10:43 ` takakura
2024-08-19 19:23 ` John Ogness
2024-08-21 5:02 ` takakura
2024-08-26 15:46 ` John Ogness [this message]
2024-08-31 8:20 ` takakura
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=877cc38exx.fsf@jogness.linutronix.de \
--to=john.ogness@linutronix.de \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=feng.tang@intel.com \
--cc=j.granados@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=nishimura@valinux.co.jp \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=stephen.s.brennan@oracle.com \
--cc=taka@valinux.co.jp \
--cc=takakura@valinux.co.jp \
--cc=ubizjak@gmail.com \
--cc=wangkefeng.wang@huawei.com \
/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