Message ID | 20220427224924.592546-12-gpiccoli@igalia.com (mailing list archive) |
---|---|
State | Not Applicable |
Headers | show |
Series | The panic notifiers refactor | expand |
Context | Check | Description |
---|---|---|
netdev/tree_selection | success | Not a local patch, async |
On Wed 2022-04-27 19:49:05, Guilherme G. Piccoli wrote: > Currently the panic notifiers from user mode linux don't follow > the convention for most of the other notifiers present in the > kernel (indentation, priority setting, numeric return). > More important, the priorities could be improved, since it's a > special case (userspace), hence we could run the notifiers earlier; > user mode linux shouldn't care much with other panic notifiers but > the ordering among the mconsole and arch notifier is important, > given that the arch one effectively triggers a core dump. It is not clear to me why user mode linux should not care about the other notifiers. It might be because I do not know much about the user mode linux. Is the because they always create core dump or are never running in a hypervisor or ...? AFAIK, the notifiers do many different things. For example, there is a notifier that disables RCU watchdog, print some extra information. Why none of them make sense here? > This patch fixes that by running the mconsole notifier as the first > panic notifier, followed by the architecture one (that coredumps). > Also, we remove a useless header inclusion. Best Regards, Petr
On 10/05/2022 11:28, Petr Mladek wrote: > [...] > It is not clear to me why user mode linux should not care about > the other notifiers. It might be because I do not know much > about the user mode linux. > > Is the because they always create core dump or are never running > in a hypervisor or ...? > > AFAIK, the notifiers do many different things. For example, there > is a notifier that disables RCU watchdog, print some extra > information. Why none of them make sense here? > Hi Petr, my understanding is that UML is a form of running Linux as a regular userspace process for testing purposes. With that said, as soon as we exit in the error path, less "pollution" would happen, so users can use GDB to debug the core dump for example. In later patches of this series (when we split the panic notifiers in 3 lists) these UML notifiers run in the pre-reboot list, so they run after the informational notifiers for example (in the default level). But without the list split we cannot order properly, so my gut feeling is that makes sense to run them rather earlier than later in the panic process... Maybe Anton / Johannes / Richard could give their opinions - appreciate that, I'm not attached to the priority here, it's more about users' common usage of UML I can think of... Cheers, Guilherme
On Wed, 2022-05-11 at 17:22 -0300, Guilherme G. Piccoli wrote: > On 10/05/2022 11:28, Petr Mladek wrote: > > [...] > > It is not clear to me why user mode linux should not care about > > the other notifiers. It might be because I do not know much > > about the user mode linux. > > > > Is the because they always create core dump or are never running > > in a hypervisor or ...? > > > > AFAIK, the notifiers do many different things. For example, there > > is a notifier that disables RCU watchdog, print some extra > > information. Why none of them make sense here? > > > > Hi Petr, my understanding is that UML is a form of running Linux as a > regular userspace process for testing purposes. Correct. > With that said, as soon > as we exit in the error path, less "pollution" would happen, so users > can use GDB to debug the core dump for example. > > In later patches of this series (when we split the panic notifiers in 3 > lists) these UML notifiers run in the pre-reboot list, so they run after > the informational notifiers for example (in the default level). > But without the list split we cannot order properly, so my gut feeling > is that makes sense to run them rather earlier than later in the panic > process... > > Maybe Anton / Johannes / Richard could give their opinions - appreciate > that, I'm not attached to the priority here, it's more about users' > common usage of UML I can think of... It's hard to say ... In a sense I'm not sure it matters? OTOH something like the ftrace dump notifier (kernel/trace/trace.c) might still be useful to run before the mconsole and coredump ones, even if you could probably use gdb to figure out the information. Personally, I don't have a scenario where I'd care about the trace buffers though, and most of the others I found would seem irrelevant (drivers that aren't even compiled, hung tasks won't really happen since we exit immediately, and similar.) johannes
On 13/05/2022 11:44, Johannes Berg wrote: > [...] >> Maybe Anton / Johannes / Richard could give their opinions - appreciate >> that, I'm not attached to the priority here, it's more about users' >> common usage of UML I can think of... > > It's hard to say ... In a sense I'm not sure it matters? > > OTOH something like the ftrace dump notifier (kernel/trace/trace.c) > might still be useful to run before the mconsole and coredump ones, even > if you could probably use gdb to figure out the information. > > Personally, I don't have a scenario where I'd care about the trace > buffers though, and most of the others I found would seem irrelevant > (drivers that aren't even compiled, hung tasks won't really happen since > we exit immediately, and similar.) > > johannes Thanks Johannes, I agree with you. We don't have great ordering now, one thing we need to enforce is the order between the 2 UML notifiers, and this patch is doing that..trying to order against other callbacks like the ftrace dumper is messy in the current code. OTOH if this patch set is accepted at some point, we'll likely have 3 lists, and with that we can improve ordering a lot - this notifier for instance would run in the pre-reboot list, *after* the ftrace dumper (if a kmsg dumper is set). So, my intention is to keep this patch as is for V2 (with some changes Johannes suggested before), unless Petr or the other maintainers want something different. Cheers, Guilherme
diff --git a/arch/um/drivers/mconsole_kern.c b/arch/um/drivers/mconsole_kern.c index 8ca67a692683..2ea0421bcc3f 100644 --- a/arch/um/drivers/mconsole_kern.c +++ b/arch/um/drivers/mconsole_kern.c @@ -11,7 +11,6 @@ #include <linux/list.h> #include <linux/mm.h> #include <linux/module.h> -#include <linux/notifier.h> #include <linux/panic_notifier.h> #include <linux/reboot.h> #include <linux/sched/debug.h> @@ -846,13 +845,12 @@ static int notify_panic(struct notifier_block *self, unsigned long unused1, mconsole_notify(notify_socket, MCONSOLE_PANIC, message, strlen(message) + 1); - return 0; + return NOTIFY_DONE; } static struct notifier_block panic_exit_notifier = { - .notifier_call = notify_panic, - .next = NULL, - .priority = 1 + .notifier_call = notify_panic, + .priority = INT_MAX, /* run as soon as possible */ }; static int add_notifier(void) diff --git a/arch/um/kernel/um_arch.c b/arch/um/kernel/um_arch.c index 0760e24f2eba..4485b1a7c8e4 100644 --- a/arch/um/kernel/um_arch.c +++ b/arch/um/kernel/um_arch.c @@ -246,13 +246,13 @@ static int panic_exit(struct notifier_block *self, unsigned long unused1, bust_spinlocks(0); uml_exitcode = 1; os_dump_core(); - return 0; + + return NOTIFY_DONE; } static struct notifier_block panic_exit_notifier = { - .notifier_call = panic_exit, - .next = NULL, - .priority = 0 + .notifier_call = panic_exit, + .priority = INT_MAX - 1, /* run as 2nd notifier, won't return */ }; void uml_finishsetup(void)
Currently the panic notifiers from user mode linux don't follow the convention for most of the other notifiers present in the kernel (indentation, priority setting, numeric return). More important, the priorities could be improved, since it's a special case (userspace), hence we could run the notifiers earlier; user mode linux shouldn't care much with other panic notifiers but the ordering among the mconsole and arch notifier is important, given that the arch one effectively triggers a core dump. This patch fixes that by running the mconsole notifier as the first panic notifier, followed by the architecture one (that coredumps). Also, we remove a useless header inclusion. Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Richard Weinberger <richard@nod.at> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> --- arch/um/drivers/mconsole_kern.c | 8 +++----- arch/um/kernel/um_arch.c | 8 ++++---- 2 files changed, 7 insertions(+), 9 deletions(-)