Re: [RFC PATCH 8/9] block: genhd: export-GPL generic disk device type

[Mathieu Desnoyers]

----- On Apr 10, 2020, at 2:33 AM, Greg Kroah-Hartman gregkh@xxxxxxxxxxxxxxxxxxx wrote:

> On Thu, Apr 09, 2020 at 03:35:42PM -0400, Mathieu Desnoyers wrote:
>> Iteration on class devices is exported for use by GPL modules, but
>> there is no exported function for getting the generic disk device type
>> which is required to perform iteration on the generic disks.
>> 
>> Export a new getter for disk device type for use by GPL modules. This is
>> useful for tracing a meaningful list of block devices from tracers
>> implemented as GPL modules.
>> 
>> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx>
>> Cc: Tejun Heo <tj@xxxxxxxxxx>
>> Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
>> Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
>> ---
>>  block/genhd.c         | 9 +++++++++
>>  include/linux/genhd.h | 2 ++
>>  2 files changed, 11 insertions(+)
> 
> I understand your need here, however we do not export things for
> modules, when there are no in-kernel module users, sorry.
> 
> I have your last thread somewhere in my todo pile, to try to respond as
> to how to make this not be an issue for you, sorry I haven't gotten to
> it.

Thanks for taking time to look into this.

Unfortunately, having commit 0bd476e6c6 "kallsyms: unexport kallsyms_lookup_name()
and kallsyms_on_each_symbol()" now merged into mainline before that discussion
was completed now makes it an immediate issue. I would have preferred to have more
time to discuss the possible solutions before seeing that commit upstream.

> Why can't you just add a tracepoint instead of having to dig through
> this mess?  Wouldn't that solve a lot of these issues for block devices?

The problem here is that it's not something which can be exported with "just"
a tracepoint. This is really a "kernel state dumping" facility meant to be
used by kernel tracers. We can indeed use tracepoints as data-export hooking
mechanism (I actually do this already within the LTTng statedump module), but
we need a function symbol which can be called by the tracer to trigger a dump
of the relevant kernel data structures.

I'm very much open to contribute any parts of the LTTng statedump facility
to the kernel, but last time this was discussed (a few years ago), I recall
that dumping kernel state was not deemed useful for the use-cases targeted
by perf and ftrace maintainers. But maybe the situation has changed now ?

For LTTng, this statedump facility is the underlying foundation which allows
doing stateful analyses at post-processing.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com