[RFC][PATCH 09/14] genirq: add irq_kmemdump_register

[Thomas Gleixner]

On Mon, Jun 16 2025 at 13:12, Eugen Hristev wrote:
> On 6/14/25 00:10, Thomas Gleixner wrote:
> #define KMEMDUMP_VAR(sym) \
> 	 static struct entry __UNIQUE_ID(kmemdump_entry_##sym) ...
>
> is when calling it with e.g. `init_mm.pgd` which will make the `.`
> inside the name and that can't happen.
> So I have to figure a way to remove unwanted chars or pass a name to the
> macro.

You can do:

KMEMDUMP_VAR_MEMBER(init_mm, pgd);

and concatenate with a '.' for the symbol
and a '_' for the ID.

or simply

KMEMDUMP_VAR_ID(init_mm.pgg, INIT_MM_PGD);

>> #define kmemdump_alloc(var, id, fn, ...)				\
>> 	({								\
>>         	void *__p = fn(##__VA_ARGS__);				\
>> 									\
>>                 if (__p)						\
>>                 	kmemdump_register(__p, sizeof(*var), id);	\
>> 		__p;
>>         })
>> 
>
> I was thinking into a new variant of kmalloc, like e.g. kdmalloc() which
> would be a wrapper over kmalloc and also register the region into
> kmemdump like you are suggesting.
> It would be like a `dumpable` kmalloc'ed memory.
> And it could take an optional ID , if missing, it could generate one.
>
> However this would mean yet another k*malloc friend, and it would
> default to usual kmalloc if CONFIG_KMEMDUMP=n .
> I am unsure whether this would be welcome by the community

That's definitely more welcome than copying boilerplate code all over
the place. And if you do it the way I suggested, then you only have
_one_ macro for alloc and _one_ for free because you hand in the
allocation function with all of its arguments instead of creating an
ever increasing zoo of dedicated variants. But the MM people might have
different opinions.

Thanks,

        tglx