From: Petr Mladek <pmladek@suse.com>
To: Eugen Hristev <eugen.hristev@linaro.org>
Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
andersson@kernel.org, linux-doc@vger.kernel.org, corbet@lwn.net,
tglx@linutronix.de, mingo@redhat.com, rostedt@goodmis.org,
john.ogness@linutronix.de, senozhatsky@chromium.org,
peterz@infradead.org, mojha@qti.qualcomm.com,
linux-arm-kernel@lists.infradead.org, vincent.guittot@linaro.org,
konradybcio@kernel.org, dietmar.eggemann@arm.com,
juri.lelli@redhat.com
Subject: Re: [RFC][PATCH 07/14] printk: add kmsg_kmemdump_register
Date: Mon, 5 May 2025 17:25:33 +0200 [thread overview]
Message-ID: <aBjYbXJL-GJe4Mh8@localhost.localdomain> (raw)
In-Reply-To: <20250422113156.575971-8-eugen.hristev@linaro.org>
On Tue 2025-04-22 14:31:49, Eugen Hristev wrote:
> Add kmsg_kmemdump_register, which registers prb, log_buf and infos/descs
> to kmemdump.
> This will allow kmemdump to be able to dump specific log buffer areas on
> demand.
>
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -4650,6 +4651,18 @@ int kmsg_dump_register(struct kmsg_dumper *dumper)
> }
> EXPORT_SYMBOL_GPL(kmsg_dump_register);
>
> +void kmsg_kmemdump_register(void)
> +{
> + kmemdump_register("log_buf", (void *)log_buf_addr_get(), log_buf_len_get());
> + kmemdump_register("prb", (void *)&prb, sizeof(prb));
> + kmemdump_register("prb", (void *)prb, sizeof(*prb));
This looks strange. "prb" is a pointer to "struct printk_ringbuffer".
It should be enough to register the memory with the structure.
> + kmemdump_register("prb_descs", (void *)_printk_rb_static_descs,
> + sizeof(_printk_rb_static_descs));
> + kmemdump_register("prb_infos", (void *)_printk_rb_static_infos,
> + sizeof(_printk_rb_static_infos));
Also this looks wrong. These are static buffers which are used during
early boot. They might later be replaced by dynamically allocated
buffers when a bigger buffer is requested by "log_buf_len" command
line parameter.
I think that we need to register the memory of the structure
and 3 more buffers. See how the bigger buffer is allocated in
setup_log_buf().
I would expect something like:
unsigned int descs_count;
unsigned long data_size;
descs_count = 2 << prb->desc_ring.count_bits;
data_size = 2 << prb->data_ring.size_bits;
kmemdump_register("prb", (void *)prb, sizeof(*prb));
kmemdump_register("prb_descs", (void *)prb->desc_ring->descs,
descs_count * sizeof(struct prb_desc));
kmemdump_register("prb_infos", (void *)prb->desc_ring->infos,
descs_count * sizeof(struct printk_info));
kmemdump_register("prb_data", (void *)prb->data_ring->data, data_size);
But I wonder if this is enough. The current crash dump code also needs
to export the format of the used structures, see
log_buf_vmcoreinfo_setup().
Is the CONFIG_VMCORE_INFO code shared with the kmemdump, please?
> +}
> +EXPORT_SYMBOL_GPL(kmsg_kmemdump_register);
> +
Best Regards,
Petr
next prev parent reply other threads:[~2025-05-05 15:27 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-22 11:31 [RFC][PATCH 00/14] introduce kmemdump Eugen Hristev
2025-04-22 11:31 ` [RFC][PATCH 01/14] Documentation: add kmemdump Eugen Hristev
2025-05-09 17:31 ` Trilok Soni
2025-04-22 11:31 ` [RFC][PATCH 02/14] kmemdump: introduce kmemdump Eugen Hristev
2025-04-23 14:29 ` kernel test robot
2025-04-23 15:10 ` kernel test robot
2025-04-23 16:43 ` kernel test robot
2025-05-09 22:38 ` Bjorn Andersson
2025-04-22 11:31 ` [RFC][PATCH 03/14] kmemdump: introduce qcom-md backend driver Eugen Hristev
2025-05-09 23:21 ` Bjorn Andersson
2025-04-22 11:31 ` [RFC][PATCH 04/14] soc: qcom: smem: add minidump device Eugen Hristev
2025-05-07 16:56 ` Bjorn Andersson
2025-04-22 11:31 ` [RFC][PATCH 05/14] Documentation: kmemdump: add section for coreimage ELF Eugen Hristev
2025-04-22 11:31 ` [RFC][PATCH 06/14] kmemdump: add coreimage ELF layer Eugen Hristev
2025-04-22 11:31 ` [RFC][PATCH 07/14] printk: add kmsg_kmemdump_register Eugen Hristev
2025-05-05 15:25 ` Petr Mladek [this message]
2025-05-05 15:51 ` Eugen Hristev
2025-05-06 7:24 ` Petr Mladek
2025-04-22 11:31 ` [RFC][PATCH 08/14] kmemdump: coreimage: add kmsg registration Eugen Hristev
2025-04-22 11:31 ` [RFC][PATCH 09/14] genirq: add irq_kmemdump_register Eugen Hristev
2025-05-07 10:18 ` Thomas Gleixner
2025-05-07 10:27 ` Eugen Hristev
2025-06-13 14:33 ` Eugen Hristev
2025-06-13 21:10 ` Thomas Gleixner
2025-06-16 10:12 ` Eugen Hristev
2025-06-17 8:33 ` Thomas Gleixner
2025-04-22 11:31 ` [RFC][PATCH 10/14] kmemdump: coreimage: add irq registration Eugen Hristev
2025-04-22 11:31 ` [RFC][PATCH 11/14] panic: add panic_kmemdump_register Eugen Hristev
2025-04-22 11:31 ` [RFC][PATCH 12/14] kmemdump: coreimage: add panic registration Eugen Hristev
2025-04-22 11:31 ` [RFC][PATCH 13/14] sched: add sched_kmemdump_register Eugen Hristev
2025-04-22 11:31 ` [RFC][PATCH 14/14] kmemdump: coreimage: add sched registration Eugen Hristev
2025-04-23 7:04 ` [RFC][PATCH 00/14] introduce kmemdump Trilok Soni
2025-05-07 16:54 ` Bjorn Andersson
2025-05-09 15:19 ` Eugen Hristev
2025-06-02 8:46 ` Eugen Hristev
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=aBjYbXJL-GJe4Mh8@localhost.localdomain \
--to=pmladek@suse.com \
--cc=andersson@kernel.org \
--cc=corbet@lwn.net \
--cc=dietmar.eggemann@arm.com \
--cc=eugen.hristev@linaro.org \
--cc=john.ogness@linutronix.de \
--cc=juri.lelli@redhat.com \
--cc=konradybcio@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mojha@qti.qualcomm.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=tglx@linutronix.de \
--cc=vincent.guittot@linaro.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.