On 08/03/2022 09:54, Petr Mladek wrote:
> [...]
> Honestly, I am not that keen about enforcing the priorities.
>
> It would make sense only when the ordering is really important.
> Then there should be some rules. It should be obvious why
> something has to be done earlier than something else.
>
On Mon 2022-03-07 11:25:30, Guilherme G. Piccoli wrote:
> On 07/03/2022 11:04, b...@redhat.com wrote:
> > [...]
> > Ah, sorry, I even didn't notice that. That's awesome if we can make use
> > of that. While I still have concerns:
> >
>
> Thanks, nice that you liked the idea.
>
> > 1) about
On 07/03/2022 11:04, b...@redhat.com wrote:
> [...]
> Ah, sorry, I even didn't notice that. That's awesome if we can make use
> of that. While I still have concerns:
>
Thanks, nice that you liked the idea.
> 1) about those we have decided to take out from panic notifier list and
> put before
On 03/07/22 at 10:11am, Guilherme G. Piccoli wrote:
> On 07/03/2022 00:42, b...@redhat.com wrote:
> > [...]
> >> Let me know your thoughts Petr / Baoquan - it would add slightly more
> >> code / complexity, but in my opinion the payback is very good.
> >> Cheers,
> >
> > The ideal situation is
On 07/03/2022 00:42, b...@redhat.com wrote:
> [...]
>> Let me know your thoughts Petr / Baoquan - it would add slightly more
>> code / complexity, but in my opinion the payback is very good.
>> Cheers,
>
> The ideal situation is each panic notifier has an order or index to
> indicate its
On 03/06/22 at 11:21am, Guilherme G. Piccoli wrote:
> On 28/01/2022 10:38, Petr Mladek wrote:
> > [...]
> > I think about the following solution:
> >
> > + split the notifiers into three lists:
> >
> > + info: stop watchdogs, provide extra info
> > + hypervisor: poke hypervisor
> >
On 28/01/2022 10:38, Petr Mladek wrote:
> [...]
> I think about the following solution:
>
> + split the notifiers into three lists:
>
> + info: stop watchdogs, provide extra info
> + hypervisor: poke hypervisor
> + reboot: actions needed only when crash dump did not happen
On 10/02/2022 14:26, Michael Kelley (LINUX) wrote:
> From: Guilherme G. Piccoli Sent: Thursday, February 10,
> 2022 8:40 AM
> [...]>> I'll need to study the Hyper-V code and how it's done today -
>
> Let me know if you need any assistance or explanation as you look
> at the Hyper-V code.
>
From: Guilherme G. Piccoli Sent: Thursday, February 10,
2022 8:40 AM
>
> On 08/02/2022 21:31, b...@redhat.com wrote:
> > [...]
> >> So, what are the opinions from kdump maintainers about this idea?
> >> Baoquan / Vivek / Dave, does it make sense to you? Do you have any
> >> suggestions/concerns
On 08/02/2022 21:31, b...@redhat.com wrote:
> [...]
>> So, what are the opinions from kdump maintainers about this idea?
>> Baoquan / Vivek / Dave, does it make sense to you? Do you have any
>> suggestions/concerns to add on top of Petr draft?
>
> Yeah, it's reasonable. As I replied to Michael in
On 02/08/22 at 03:51pm, Guilherme G. Piccoli wrote:
> On 28/01/2022 10:38, Petr Mladek wrote:
> > [...] On Thu 2022-01-27 14:16:20, Guilherme G. Piccoli wrote:
> > First, I am sorry for the very long mail. But the problem is really
> > complicated. I did my best to describe it a clean way.
> >
>
On 28/01/2022 10:38, Petr Mladek wrote:
> [...] On Thu 2022-01-27 14:16:20, Guilherme G. Piccoli wrote:
> First, I am sorry for the very long mail. But the problem is really
> complicated. I did my best to describe it a clean way.
>
> I have discussed these problems with a colleague and he had
On 01/26/22 at 02:20pm, Petr Mladek wrote:
> On Wed 2022-01-26 11:10:39, Baoquan He wrote:
> > On 01/24/22 at 11:48am, Guilherme G. Piccoli wrote:
> > > On 24/01/2022 10:59, Baoquan He wrote:
> > > > [...]
> > > > About pre_dump, if the dump is crash dump, hope those pre_dump notifiers
> > > >
On Thu 2022-01-27 14:16:20, Guilherme G. Piccoli wrote:
> On 25/01/2022 10:06, d.hatay...@fujitsu.com wrote:
> >
> > But the pre_dump cannot avoid calling multiple unnecessary handlers, right?
> > It's more risky than the previous idea...
> >
>
> I think we could have 2 kernel parameters then:
On 25/01/2022 10:06, d.hatay...@fujitsu.com wrote:
>
> But the pre_dump cannot avoid calling multiple unnecessary handlers, right?
> It's more risky than the previous idea...
>
I think we could have 2 kernel parameters then:
crash_kernel_disable_pre_notitifers (of course we can think in some
On Wed 2022-01-26 11:10:39, Baoquan He wrote:
> On 01/24/22 at 11:48am, Guilherme G. Piccoli wrote:
> > On 24/01/2022 10:59, Baoquan He wrote:
> > > [...]
> > > About pre_dump, if the dump is crash dump, hope those pre_dump notifiers
> > > will be executed under conditional check, e.g only if
> >
> On 01/24/22 at 11:48am, Guilherme G. Piccoli wrote:
> > On 24/01/2022 10:59, Baoquan He wrote:
> > > [...]
> > > About pre_dump, if the dump is crash dump, hope those pre_dump notifiers
> > > will be executed under conditional check, e.g only if
> > > 'crash_kexec_post_notifiers'
> > > is
On 01/24/22 at 11:48am, Guilherme G. Piccoli wrote:
> On 24/01/2022 10:59, Baoquan He wrote:
> > [...]
> > About pre_dump, if the dump is crash dump, hope those pre_dump notifiers
> > will be executed under conditional check, e.g only if
> > 'crash_kexec_post_notifiers'
> > is specified in kernel
> Hi, thanks for the review. First of all, notice that it's very likely
> this patch isn't gonna get merged this way, we are considering a
> refactor that included 2 panic notifiers: one a bit earlier (pre_dump),
> that includes functions less risky, as watchdog unloaders, kernel offset
> dump,
On 25/01/2022 08:50, d.hatay...@fujitsu.com wrote:
>> + while ((func = strsep(, ","))) {
>> + addr = kallsyms_lookup_name(func);
>> + if (!addr) {
>> + pr_warn("panic_notifier_filter: invalid symbol
>> %s\n", func);
>> +
> @@ -146,6 +157,34 @@ void nmi_panic(struct pt_regs *regs, const char *msg)
> }
> EXPORT_SYMBOL(nmi_panic);
>
> +static int __init panic_notifier_filter_setup(char *buf)
> +{
> + char *func;
> + unsigned long addr;
> +
> + while ((func = strsep(, ","))) {
> +
On 24/01/2022 10:59, Baoquan He wrote:
> [...]
> About pre_dump, if the dump is crash dump, hope those pre_dump notifiers
> will be executed under conditional check, e.g only if
> 'crash_kexec_post_notifiers'
> is specified in kernel cmdline.
Hi Baoquan, based on Petr's suggestion, I think
On 01/24/22 at 11:43am, d.hatay...@fujitsu.com wrote:
>
> > On 01/21/22 at 05:31pm, Guilherme G. Piccoli wrote:
> > ..
> > > > IMHO, the right solution is to split the callbacks into 2 or more
> > > > notifier list. Then we might rework panic() to do:
> > > >
> > > > void panic(void)
> > > >
On 01/23/22 at 10:07pm, Masami Hiramatsu wrote:
> On Sat, 22 Jan 2022 18:55:14 +0800
> Baoquan He wrote:
>
> > On 01/21/22 at 05:31pm, Guilherme G. Piccoli wrote:
> > ..
> > > > IMHO, the right solution is to split the callbacks into 2 or more
> > > > notifier list. Then we might rework
> On 01/21/22 at 05:31pm, Guilherme G. Piccoli wrote:
> ..
> > > IMHO, the right solution is to split the callbacks into 2 or more
> > > notifier list. Then we might rework panic() to do:
> > >
> > > void panic(void)
> > > {
> > > [...]
> > >
> > > /* stop watchdogs + extra info */
>
On Sat, 22 Jan 2022 18:55:14 +0800
Baoquan He wrote:
> On 01/21/22 at 05:31pm, Guilherme G. Piccoli wrote:
> ..
> > > IMHO, the right solution is to split the callbacks into 2 or more
> > > notifier list. Then we might rework panic() to do:
> > >
> > > void panic(void)
> > > {
> > > [...]
On 01/21/22 at 05:31pm, Guilherme G. Piccoli wrote:
..
> > IMHO, the right solution is to split the callbacks into 2 or more
> > notifier list. Then we might rework panic() to do:
> >
> > void panic(void)
> > {
> > [...]
> >
> > /* stop watchdogs + extra info */
> >
Hi Petr, thanks for the great response, and for CCing more (potentially)
interested parties! Some comments inline below; also, I'm CCing Michael
Kelley as well.
On 20/01/2022 12:14, Petr Mladek wrote:
> Adding some more people into Cc. Some modified the logic in the past.
> Some are familiar
Adding some more people into Cc. Some modified the logic in the past.
Some are familiar with some interesting areas where the panic
notfiers are used.
On Sat 2022-01-08 12:34:51, Guilherme G. Piccoli wrote:
> The kernel notifier infrastructure allows function callbacks to be
> added in multiple
On 17/01/2022 23:31, Dave Young wrote:
> [...]
> Hi Guilherme, thank you for making it a formal patch! Yes, it is a
> nice improvement.
> I'm sorry I did not get time to review the code, I will leave it to
> other people to review :)
Hi Dave, no worries - thanks for your opinion, much
On 16/01/2022 10:11, Baoquan He wrote:
> [...]
> This patch looks good to me, thx.
>
> Acked-by: Baoquan He
>
Thanks a lot Baoquan He !
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On 01/08/22 at 12:34pm, Guilherme G. Piccoli wrote:
..
> So, this patch aims to ease this decision: we hereby introduce a filter
> for the panic notifier list, in which users may select specifically
> which callbacks they wish to run, allowing a safer kdump. The allowlist
> should be provided
Hey folks, sorry for the ping.
But is there any extra reviews? All comments are much appreciated!
Dave, what do you think about the patch? I remember we talked about it
in [0], seems you considered that a good idea right?
Thanks in advance,
Guilherme
[0]
The kernel notifier infrastructure allows function callbacks to be
added in multiple lists, which are then called in the proper time,
like in a reboot or panic event. The panic_notifier_list specifically
contains the callbacks that are executed during a panic event. As any
other notifier list, the
34 matches
Mail list logo
