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]

Message-ID: <YoXsAkUgzIjJR90W@kroah.com>
Date:   Thu, 19 May 2022 09:04:34 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Chris Down <chris@...isdown.name>
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

On Wed, May 18, 2022 at 09:27:17PM +0100, Chris Down wrote:
> 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?

The two stanzas in my reply do NOT refer to the same thing.

The first one is for the device that is assigned to the class.  That
must be freed and properly reference counted and handled as that is a
dynamic object that can come and go as people add and remove consoles.

The second is the 'struct class' itself.  You can register that and be
done with it if your code can never be unloaded as it can not be a
module.

Hope that explains the confusion better.

thanks,

greg k-h