Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Wed, 18 May 2022 21:27:17 +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: <YoVWpZKHD7aec0CJ@chrisdown.name>
References: <YoUBh5BSsURDO71Z@chrisdown.name>
 <YoUR6RlzkCNG7BU0@kroah.com>
 <YoVM+KbdyJm8RSSr@chrisdown.name>
 <YoVO23+fvsNPnpKh@kroah.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <YoVO23+fvsNPnpKh@kroah.com>
User-Agent: Mutt/2.2.4 (c3baa83e) (2022-04-30)
Precedence: bulk

Greg Kroah-Hartman writes:
>> If you're talking about properly freeing the memory, I suppose it should
>> happen by doing something like the following in unregister_console():
>>
>>     if (!console_drivers)
>>         /* free the class object under console lock */
>>
>> ...right? Let me know if I'm misunderstanding you.
>
>You can't do that as the driver core should now be managing the
>lifespace of that object.  You can't "know" when the object's memory is
>to be freed EXCEPT in the release function.
>
>So free it there please.
>
>Or do not tie the lifepan of the console class device object to the
>console object, and keep it separate.  I don't remember exactly how you
>tied them together here, sorry.

[...]

>> > Do you ever free the class?
>>
>> Currently no. What do you think about the above proposal to do it once the
>> console driver list is exhausted?
>
>If the code can never be unloaded, no, don't worry about it.

So just so I understand, there's no problem here if we're not going to free the 
class object, correct? These two stanzas in your reply refer to the same thing, 
right?

For context: the class comes up with printk, and printk can never be unloaded, 
so the class is never freed.

The devices that attach to this class are stored in `struct console', which has 
its lifecycle managed externally from this code.

I feel like I'm missing something here, but the two quoted parts of your reply 
seem to contradict each other (the first one talks about the right place to 
free the class, whereas the second says it's not necessary to free the class), 
so I'm a bit confused.