Re: [RFC PATCH] printk: console: Allow each console to have its own loglevel

Chris Down
2022-05-19T15:55:16Z

Greg Kroah-Hartman writes:
>On Thu, May 19, 2022 at 04:08:04PM +0100, Chris Down wrote:
>> Greg Kroah-Hartman writes:
>> > > struct console {
>> > > char name[16];
>> > > void (*write)(struct console *, const char *, unsigned);
>> > > @@ -179,9 +173,11 @@ struct console {
>> > > void *data;
>> > > struct console *next;
>> > > int level;
>> > > - struct device classdev;
>> > > + struct device *classdev;
>> >
>> > Ick, no, keep the real structure here. It can properly handle the
>> > reference counting for the object. Just correctly clean up in the
>> > release function, not anywhere else.
>>
>> Sorry, I'm getting more and more confused about what you're asking me to do,
>> and less and less clear on the rationale.
>>
>> Can you please clarify what "correctly cleaning up" would mean for a
>> non-pointer `struct device'?
>>
>> Is your concern that...
>>
>> register_console(c)
>> device_initialize(c->d)
>> device_add(c->d)
>> unregister_console(c)
>> device_unregister(c->d) console_classdev_release(c->d)
>> register_console(c)
>> device_initialize(c->d) <-- classdev was not previously zeroed out
>> in console_classdev_release() and bad things may happen
>
>Note, you can not "recycle" a structure in the driver model. So when
>the console is unregistered, it should be freed. When it is registered,
>it should be created. Perhaps that is the confusion here?

I suspect you're close to the source of the confusion. So your point is that
the `struct console' should be freed when the driver refcount drops to 0 rather
than trying to do it the other way around. Right?

So, just to try to come to a solution, here's the lay of the land as I
understand it. Currently pretty much all consoles are statically defined (and
most of the non-static cases are false positives)

% git grep 'struct console.*=' -- '*.c' | awk '/static/ { print "static"; } !/static/ { print "non-static" }' | sort | uniq -c
15 non-static
105 static

These consoles are defined statically largely because they may come up early
enough that we don't yet have the kmalloc() infrastructure ready.

One might then think we could have these early consoles use memblock_alloc(),
but there is a problem. memblock_alloc_try_nid() inside memblock_alloc() is
__init, so while we can still use the memory later, we can't call
memblock_alloc() after __init data is freed up.

This is a problem because some consoles decide if they are early or not at
runtime, not compile time:

% git grep -E -- '->(write|read) = .*early' | wc -l
40

So depending on runtime configuration, those consoles may either be too early
to allocate with kmalloc(), or too late to allocate with memblock_alloc().

This and other reasons are why I am really trying to avoid changing the way
that the `struct console' lifecycle works -- it's already extremely complex,
and the chance of breaking something is very high, which is made even worse by
the fact that one can only test on a very small subset of available hardware.

Maybe a driver is not the best thing to use here to expose things in sysfs? Is
there something else you would recommend?

Thanks again for all your help and advice. :-)