| Message ID | 20220427224924.592546-24-gpiccoli@igalia.com |
|---|---|
| State | New |
| Headers | show |
| Series | The panic notifiers refactor | expand |
On Wed, 27 Apr 2022 19:49:17 -0300 "Guilherme G. Piccoli" <gpiccoli@igalia.com> wrote: > Currently we don't have a way to check if there are dumpers set, > except counting the list members maybe. This patch introduces a very > simple helper to provide this information, by just keeping track of > registered/unregistered kmsg dumpers. It's going to be used on the > panic path in the subsequent patch. FYI, it is considered "bad form" to reference in the change log "this patch". We know this is a patch. The change log should just talk about what is being done. So can you reword your change logs (you do this is almost every patch). Here's what I would reword the above to be: Currently we don't have a way to check if there are dumpers set, except perhaps by counting the list members. Introduce a very simple helper to provide this information, by just keeping track of registered/unregistered kmsg dumpers. This will simplify the refactoring of the panic path. -- Steve
On 10/05/2022 14:40, Steven Rostedt wrote: > On Wed, 27 Apr 2022 19:49:17 -0300 > "Guilherme G. Piccoli" <gpiccoli@igalia.com> wrote: > >> Currently we don't have a way to check if there are dumpers set, >> except counting the list members maybe. This patch introduces a very >> simple helper to provide this information, by just keeping track of >> registered/unregistered kmsg dumpers. It's going to be used on the >> panic path in the subsequent patch. > > FYI, it is considered "bad form" to reference in the change log "this > patch". We know this is a patch. The change log should just talk about what > is being done. So can you reword your change logs (you do this is almost > every patch). Here's what I would reword the above to be: > > Currently we don't have a way to check if there are dumpers set, except > perhaps by counting the list members. Introduce a very simple helper to > provide this information, by just keeping track of registered/unregistered > kmsg dumpers. This will simplify the refactoring of the panic path. Thanks for the hint, you're right - it's almost in all of my patches. I'll reword all of them (except the ones already merged) to remove this "bad form". Cheers, Guilherme
On Wed 2022-05-11 17:03:51, Guilherme G. Piccoli wrote: > On 10/05/2022 14:40, Steven Rostedt wrote: > > On Wed, 27 Apr 2022 19:49:17 -0300 > > "Guilherme G. Piccoli" <gpiccoli@igalia.com> wrote: > > > >> Currently we don't have a way to check if there are dumpers set, > >> except counting the list members maybe. This patch introduces a very > >> simple helper to provide this information, by just keeping track of > >> registered/unregistered kmsg dumpers. It's going to be used on the > >> panic path in the subsequent patch. > > > > FYI, it is considered "bad form" to reference in the change log "this > > patch". We know this is a patch. The change log should just talk about what > > is being done. So can you reword your change logs (you do this is almost > > every patch). Here's what I would reword the above to be: > > > > Currently we don't have a way to check if there are dumpers set, except > > perhaps by counting the list members. Introduce a very simple helper to > > provide this information, by just keeping track of registered/unregistered > > kmsg dumpers. This will simplify the refactoring of the panic path. > > Thanks for the hint, you're right - it's almost in all of my patches. > I'll reword all of them (except the ones already merged) to remove this > "bad form". Shame on me that I do not care that much about the style of the commit message :-) Anyway, the code looks good to me. With the better commit message: Reviewed-by: Petr Mladek <pmladek@suse.com> Best Regards, Petr
On 16/05/2022 11:50, Petr Mladek wrote: > [...] > Shame on me that I do not care that much about the style of the commit > message :-) > > Anyway, the code looks good to me. With the better commit message: > > Reviewed-by: Petr Mladek <pmladek@suse.com> > Heheh, cool - I'll add your tag and improve the message in V2. Thanks, Guilherme
diff --git a/include/linux/kmsg_dump.h b/include/linux/kmsg_dump.h index 906521c2329c..abea1974bff8 100644 --- a/include/linux/kmsg_dump.h +++ b/include/linux/kmsg_dump.h @@ -65,6 +65,8 @@ bool kmsg_dump_get_buffer(struct kmsg_dump_iter *iter, bool syslog, void kmsg_dump_rewind(struct kmsg_dump_iter *iter); +bool kmsg_has_dumpers(void); + int kmsg_dump_register(struct kmsg_dumper *dumper); int kmsg_dump_unregister(struct kmsg_dumper *dumper); @@ -91,6 +93,11 @@ static inline void kmsg_dump_rewind(struct kmsg_dump_iter *iter) { } +static inline bool kmsg_has_dumpers(void) +{ + return false; +} + static inline int kmsg_dump_register(struct kmsg_dumper *dumper) { return -EINVAL; diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index da03c15ecc89..e3a1c429fbbc 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -3399,6 +3399,18 @@ EXPORT_SYMBOL(printk_timed_ratelimit); static DEFINE_SPINLOCK(dump_list_lock); static LIST_HEAD(dump_list); +static int num_dumpers; + +/** + * kmsg_has_dumpers - inform if there is any kmsg dumper registered. + * + * Returns true if there's at least one registered dumper, or false + * if otherwise. + */ +bool kmsg_has_dumpers(void) +{ + return num_dumpers ? true : false; +} /** * kmsg_dump_register - register a kernel log dumper. @@ -3423,6 +3435,7 @@ int kmsg_dump_register(struct kmsg_dumper *dumper) dumper->registered = 1; list_add_tail_rcu(&dumper->list, &dump_list); err = 0; + num_dumpers++; } spin_unlock_irqrestore(&dump_list_lock, flags); @@ -3447,6 +3460,7 @@ int kmsg_dump_unregister(struct kmsg_dumper *dumper) dumper->registered = 0; list_del_rcu(&dumper->list); err = 0; + num_dumpers--; } spin_unlock_irqrestore(&dump_list_lock, flags); synchronize_rcu();
Currently we don't have a way to check if there are dumpers set, except counting the list members maybe. This patch introduces a very simple helper to provide this information, by just keeping track of registered/unregistered kmsg dumpers. It's going to be used on the panic path in the subsequent patch. Notice that the spinlock guarding kmsg_dumpers list also guards increment/decrement of the dumper's counter, but there's no need for that when reading the counter in the panic path, since that is an atomic path and there's no other (planned) user. Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> --- include/linux/kmsg_dump.h | 7 +++++++ kernel/printk/printk.c | 14 ++++++++++++++ 2 files changed, 21 insertions(+)