From: Enlin Mu <enlin.mu@unisoc.com>

the module is out-of-tree, it saves kernel logs when panic

Signed-off-by: Enlin Mu <enlin.mu@unisoc.com>
---
 kernel/printk/printk.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 357a4d18f638..f381442512b3 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -538,12 +538,14 @@ char *log_buf_addr_get(void)
 {
 	return log_buf;
 }
+EXPORT_SYMBOL_GPL(log_buf_addr_get);
 
 /* Return log buffer size */
 u32 log_buf_len_get(void)
 {
 	return log_buf_len;
 }
+EXPORT_SYMBOL_GPL(log_buf_len_get);
 
 /*
  * Define how much of the log buffer we could take at maximum. The value
-- 
2.25.1

On Tue, Aug 15, 2023 at 10:07:11AM +0800, Yunlong Xing wrote:
> From: Enlin Mu <enlin.mu@unisoc.com>
> 
> the module is out-of-tree, it saves kernel logs when panic

As with all other symbols not used in tree:

NAK out of policy.

On Tue 2023-08-15 10:07:11, Yunlong Xing wrote:
> From: Enlin Mu <enlin.mu@unisoc.com>
> 
> the module is out-of-tree, it saves kernel logs when panic
> 
> Signed-off-by: Enlin Mu <enlin.mu@unisoc.com>

I am fine with it. After all, this API seems to here for
similar purposes.

Acked-by: Petr Mladek <pmladek@suse.com>

Of course, it would be better to maintain the module in upstream.
Is there any chance to get it upstream? It seems that it
is GPL-compatible so...

Best Regards,
Petr

Petr Mladek <pmladek@suse.com> 于2023年8月15日周二 21:55写道：
>
> On Tue 2023-08-15 10:07:11, Yunlong Xing wrote:
> > From: Enlin Mu <enlin.mu@unisoc.com>
> >
> > the module is out-of-tree, it saves kernel logs when panic
> >
> > Signed-off-by: Enlin Mu <enlin.mu@unisoc.com>
>
> I am fine with it. After all, this API seems to here for
> similar purposes.
Thanks.
>
> Acked-by: Petr Mladek <pmladek@suse.com>
>
> Of course, it would be better to maintain the module in upstream.
> Is there any chance to get it upstream? It seems that it
> is GPL-compatible so...
Yes, currently under development. Once the code debugging is stable,
it will be pushed to the community.
>
> Best Regards,
> Petr

Best Regards,

Enlin

On Wed 2023-08-16 09:24:29, Enlin Mu wrote:
> Petr Mladek <pmladek@suse.com> 于2023年8月15日周二 21:55写道：
> >
> > On Tue 2023-08-15 10:07:11, Yunlong Xing wrote:
> > > From: Enlin Mu <enlin.mu@unisoc.com>
> > >
> > > the module is out-of-tree, it saves kernel logs when panic
> > >
> > > Signed-off-by: Enlin Mu <enlin.mu@unisoc.com>
> >
> > I am fine with it. After all, this API seems to here for
> > similar purposes.
> Thanks.
> >
> > Acked-by: Petr Mladek <pmladek@suse.com>
> >
> > Of course, it would be better to maintain the module in upstream.
> > Is there any chance to get it upstream? It seems that it
> > is GPL-compatible so...
> Yes, currently under development. Once the code debugging is stable,
> it will be pushed to the community.

Great.

One more thing which came to my mind.

The log buffer contains the plain text and "id" of the related
metadata. Namely, there is always an "unsigned long" before
each message, see struct prb_data_block.

You might consider using the kmsg_dump API. It has been added
for this purpose. It allows to read and store the messages
one by one. And the messages are formatted the same way
as on console or by dmesg.

The registered dumpers are automatically called in panic().
See kmsg_dump(KMSG_DUMP_PANIC) in panic().

There are few users of this API. Look for kmsg_dump_register()
to get some inspiration.

Best Regards,
Petr

Petr Mladek <pmladek@suse.com> 于2023年8月16日周三 17:31写道：
>
> On Wed 2023-08-16 09:24:29, Enlin Mu wrote:
> > Petr Mladek <pmladek@suse.com> 于2023年8月15日周二 21:55写道：
> > >
> > > On Tue 2023-08-15 10:07:11, Yunlong Xing wrote:
> > > > From: Enlin Mu <enlin.mu@unisoc.com>
> > > >
> > > > the module is out-of-tree, it saves kernel logs when panic
> > > >
> > > > Signed-off-by: Enlin Mu <enlin.mu@unisoc.com>
> > >
> > > I am fine with it. After all, this API seems to here for
> > > similar purposes.
> > Thanks.
> > >
> > > Acked-by: Petr Mladek <pmladek@suse.com>
> > >
> > > Of course, it would be better to maintain the module in upstream.
> > > Is there any chance to get it upstream? It seems that it
> > > is GPL-compatible so...
> > Yes, currently under development. Once the code debugging is stable,
> > it will be pushed to the community.
>
> Great.
>
> One more thing which came to my mind.
>
> The log buffer contains the plain text and "id" of the related
> metadata. Namely, there is always an "unsigned long" before
> each message, see struct prb_data_block.
>
> You might consider using the kmsg_dump API. It has been added
> for this purpose. It allows to read and store the messages
> one by one. And the messages are formatted the same way
> as on console or by dmesg.
>
> The registered dumpers are automatically called in panic().
> See kmsg_dump(KMSG_DUMP_PANIC) in panic().
Yes, I have use this API in panic.

But there is a special case where when the system hangs and all cores
are unable to execute panic processes, this API  cannot be used
anymore.

When this module starts, it obtains the virtual address of the log,
converts it into a physical one, and saves it to the specified
address. When uboot starts, obtain the above information, extract the
kernel log, and debug the cause of the exception.

>
> There are few users of this API. Look for kmsg_dump_register()
> to get some inspiration.
>
> Best Regards,
> Petr

Best Regards,
Enlin

On (23/08/15 15:55), Petr Mladek wrote:
> On Tue 2023-08-15 10:07:11, Yunlong Xing wrote:
> > From: Enlin Mu <enlin.mu@unisoc.com>
> > 
> > the module is out-of-tree, it saves kernel logs when panic
> > 
> > Signed-off-by: Enlin Mu <enlin.mu@unisoc.com>
> 
> I am fine with it. After all, this API seems to here for
> similar purposes.

Indeed, I didn't know that powerpc uses it.

> Acked-by: Petr Mladek <pmladek@suse.com>

Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>