Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Thu, 19 May 2022 16:55:08 +0100
From:   Chris Down <chris@chrisdown.name>
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     linux-kernel@vger.kernel.org, Petr Mladek <pmladek@suse.com>,
        kernel-team@fb.com
Subject: Re: [RFC PATCH] printk: console: Allow each console to have its own
 loglevel
Message-ID: <YoZoXOghSuCy9Bi+@chrisdown.name>
References: <YoUBh5BSsURDO71Z@chrisdown.name>
 <YoUR6RlzkCNG7BU0@kroah.com>
 <YoVM+KbdyJm8RSSr@chrisdown.name>
 <YoVO23+fvsNPnpKh@kroah.com>
 <YoVWpZKHD7aec0CJ@chrisdown.name>
 <YoXsAkUgzIjJR90W@kroah.com>
 <YoZQQwtG12Ypr2IC@chrisdown.name>
 <YoZVvA5FP4wFLSH9@kroah.com>
 <YoZdVCfK4T8Ts2oS@chrisdown.name>
 <YoZhXe9CZE5o73fG@kroah.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <YoZhXe9CZE5o73fG@kroah.com>
User-Agent: Mutt/2.2.4 (c3baa83e) (2022-04-30)
Precedence: bulk

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. :-)