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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 18 May 2022 21:27:17 +0100
From:   Chris Down <chris@...isdown.name>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, Petr Mladek <pmladek@...e.com>,
        kernel-team@...com
Subject: Re: [RFC PATCH] printk: console: Allow each console to have its own
 loglevel

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.