From: Thomas Gleixner <tglx@linutronix.de>
To: Eugen Hristev <eugen.hristev@linaro.org>,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org
Cc: linux-doc@vger.kernel.org, corbet@lwn.net, mingo@redhat.com,
rostedt@goodmis.org, john.ogness@linutronix.de,
senozhatsky@chromium.org, pmladek@suse.com, 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,
andersson@kernel.org
Subject: Re: [RFC][PATCH 09/14] genirq: add irq_kmemdump_register
Date: Fri, 13 Jun 2025 23:10:06 +0200 [thread overview]
Message-ID: <87ikkzpcup.ffs@tglx> (raw)
In-Reply-To: <f916cf7f-6d0d-4d31-8e4b-24fc7da13f4d@linaro.org>
On Fri, Jun 13 2025 at 17:33, Eugen Hristev wrote:
> On 5/7/25 13:27, Eugen Hristev wrote:
>>> Let KMEMDUMP_VAR() store the size and the address of 'nr_irqs' in a
>>> kmemdump specific section and then kmemdump can just walk that section
>>> and dump stuff. No magic register functions and no extra storage
>>> management for static/global variables.
>>>
>>> No?
>>
>> Thank you very much for your review ! I will try it out.
>
> I have tried this way and it's much cleaner ! thanks for the
> suggestion.
Welcome.
> The thing that I am trying to figure out now is how to do something
> similar for a dynamically allocated memory, e.g.
> void *p = kmalloc(...);
> and then I can annotate `p` itself, it's address and size, but what I
> would also want to so dump the whole memory region pointed out by p. and
> that area address and size cannot be figured out at compile time hence I
> can't instantiate a struct inside the dedicated section for it.
> Any suggestion on how to make that better ? Or just keep the function
> call to register the area into kmemdump ?
Right. For dynamically allocated memory there is obviously no compile
time magic possible.
But I think you can simplify the registration for dynamically allocated
memory significantly.
struct kmemdump_entry {
void *ptr;
size_t size;
enum kmemdump_uids uid;
};
You use that layout for the compile time table and the runtime
registrations.
I intentionally used an UID as that avoids string allocation and all of
the related nonsense. Mapping UID to a string is a post processing
problem and really does not need to be done in the kernel. The 8
character strings are horribly limited and a simple 4 byte unique id is
achieving the same and saving space.
Just stick the IDs into include/linux/kmemdump_ids.h and expose the
content for the post processing machinery.
So you want KMEMDUMP_VAR() for the compile time created table to either
automatically create that ID derived from the variable name or you add
an extra argument with the ID.
kmemdump_init()
// Use a simple fixed size array to manage this
// as it avoids all the memory allocation nonsense
// This stuff is neither performance critical nor does allocating
// a few hundred entries create a memory consumption problem
// It consumes probably way less memory than the whole IDR/XARRAY allocation
// string duplication logic consumes text and data space.
kmemdump_entries = kcalloc(NR_ENTRIES, sizeof(*kmemdump_entries), GFP_KERNEL);
kmemdump_register(void *ptr, size_t size, enum kmemdump_uids uid)
{
guard(entry_mutex);
entry = kmemdump_find_empty_slot();
if (!entry)
return;
entry->ptr = ptr;
entry->size = size;
entry->uid = uid;
// Make this unconditional by providing a dummy backend
// implementation. If the backend changes re-register all
// entries with the new backend and be done with it.
backend->register(entry);
}
kmemdump_unregister(void *ptr)
{
guard(entry_mutex);
entry = find_entry(ptr);
if (entry) {
backend->unregister(entry);
memset(entry, 0, sizeof(*entry);
}
}
You get the idea.
Coming back to the registration at the call site itself.
struct foo = kmalloc(....);
if (!foo)
return;
kmemdump_register(foo, sizeof(*foo), KMEMDUMP_ID_FOO);
That's a code duplication shitshow. You can wrap that into:
struct foo *foo = kmemdump_alloc(foo, KMEMDUMP_ID_FOO, kmalloc, ...);
#define kmemdump_alloc(var, id, fn, ...) \
({ \
void *__p = fn(##__VA_ARGS__); \
\
if (__p) \
kmemdump_register(__p, sizeof(*var), id); \
__p;
})
or something daft like that. And provide the matching magic for the free
side.
Thoughts?
Thanks,
tglx
next prev parent reply other threads:[~2025-06-13 21:13 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
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 [this message]
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=87ikkzpcup.ffs@tglx \
--to=tglx@linutronix.de \
--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=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--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.