linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
Date: Wed, 18 May 2022 20:46:00 +0100	[thread overview]
Message-ID: <YoVM+KbdyJm8RSSr@chrisdown.name> (raw)
In-Reply-To: <YoUR6RlzkCNG7BU0@kroah.com>

Greg Kroah-Hartman writes:
>>  .../admin-guide/kernel-parameters.txt         |  18 +-
>>  .../admin-guide/per-console-loglevel.rst      | 116 ++++++
>
>All sysfs attributes need to be documented in Documentation/ABI/ so that
>the automated tools can properly pick them up and check them.  Please
>don't bury them in some other random Documentation file.

Ack.

>> +static ssize_t loglevel_show(struct device *dev, struct device_attribute *attr,
>> +			     char *buf)
>> +{
>> +	struct console *con = container_of(dev, struct console, classdev);
>> +
>> +	if (con->flags & CON_LOGLEVEL)
>> +		return sprintf(buf, "%d\n", con->level);
>> +	else
>> +		return sprintf(buf, "unset\n");
>
>sysfs_emit() is your friend, always use it please.  For all of the sysfs
>attributes.

Ack.

>> +static struct attribute *console_sysfs_attrs[] = {
>> +	&dev_attr_loglevel.attr,
>> +	&dev_attr_effective_loglevel_source.attr,
>> +	&dev_attr_effective_loglevel.attr,
>> +	&dev_attr_enabled.attr,
>> +	NULL,
>> +};
>> +
>> +ATTRIBUTE_GROUPS(console_sysfs);
>
>Thanks for using an attribute group properly, that's nice to see.

Hah, I have no idea what I'm doing with the device model in general, but at 
least I vaguely know how to keep the code tidy ;-)

>> +static void console_classdev_release(struct device *dev)
>> +{
>> +	struct console *con = container_of(dev, struct console, classdev);
>> +
>> +	/*
>> +	 * `struct console' objects are statically allocated (or at the very
>> +	 * least managed outside of our lifecycle), nothing to do. Just set a
>> +	 * flag so that we know we are no longer waiting for anyone and can
>> +	 * return control in unregister_console().
>> +	 */
>> +	con->flags &= ~CON_CLASSDEV_ACTIVE;
>> +}
>
>The old documentation rules said I could complain about this a lot, so
>I'll be nice here just say "this is not ok at all."  You have a dynamic
>object, properly free the memory here please.  class objects can NOT be
>static, sorry.  If you are doing that here, it is really wrong and
>broken and will cause problems when you try to remove the device from
>the system.

Let me check I understand you correctly. The class is:

     static struct class *console_class;
     [...]
     console_class = class_create(THIS_MODULE, "console");

Which exists within printk.c. This class exists to contain all consoles which 
present themselves over the lifetime of the kernel.

console_classdev_release is the release for a single console's "classdev" 
object, rather than the release of the class itself.

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.

Any suggestions you have here are more than welcome, I'm definitely not that 
familiar with the device/class API.

>> +static void console_register_device(struct console *new)
>> +{
>> +	/*
>> +	 * We might be called from register_console() before the class is
>> +	 * registered. If that happens, we'll take care of it in
>> +	 * printk_late_init.
>
>If so, is the device properly registered there as well?  I missed that
>logic...

We call console_register_device() on all previously known consoles at 
late_initcall() time. Or were you thinking of something else?

>> +	 */
>> +	if (IS_ERR_OR_NULL(console_class))
>> +		return;
>> +
>> +	new->flags |= CON_CLASSDEV_ACTIVE;
>> +	device_initialize(&new->classdev);
>> +	dev_set_name(&new->classdev, "%s", new->name);
>> +	new->classdev.release = console_classdev_release;
>> +	new->classdev.class = console_class;
>> +	if (WARN_ON(device_add(&new->classdev)))
>
>What is with these random WARN_ON() stuff?  Don't do that, just handle
>the error and move on properly.  Systems with panic_on_warn() should not
>fail from stuff like this, that's rude to cause them to reboot.

Oh, that's fair enough, I hadn't thought of that. Ack.

>> +	console_class = class_create(THIS_MODULE, "console");
>> +	if (!WARN_ON(IS_ERR(console_class)))
>> +		console_class->dev_groups = console_sysfs_groups;
>
>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?

>> +static int printk_sysctl_deprecated(struct ctl_table *table, int write,
>> +				    void __user *buffer, size_t *lenp,
>> +				    loff_t *ppos)
>> +{
>> +	int res = proc_dointvec(table, write, buffer, lenp, ppos);
>> +
>> +	if (write)
>> +		pr_warn_ratelimited(
>> +			"printk: The kernel.printk sysctl is deprecated and will be removed soon. Use kernel.force_console_loglevel, kernel.default_message_loglevel, kernel.minimum_console_loglevel, or kernel.default_console_loglevel instead.\n"
>
>Please define "soon".

Petr, what do you think about the timebounds here? :-)

Thanks for the feedback!

Chris

  reply	other threads:[~2022-05-18 19:46 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-18 14:24 [RFC PATCH] printk: console: Allow each console to have its own loglevel Chris Down
2022-05-18 14:32 ` Chris Down
2022-05-18 15:34 ` Greg Kroah-Hartman
2022-05-18 19:46   ` Chris Down [this message]
2022-05-18 19:54     ` Greg Kroah-Hartman
2022-05-18 20:27       ` Chris Down
2022-05-19  7:04         ` Greg Kroah-Hartman
2022-05-19 14:12           ` Chris Down
2022-05-19 14:35             ` Greg Kroah-Hartman
2022-05-19 15:08               ` Chris Down
2022-05-19 15:24                 ` Greg Kroah-Hartman
2022-05-19 15:25                 ` Greg Kroah-Hartman
2022-05-19 15:55                   ` Chris Down
2022-05-19 17:45                     ` Greg Kroah-Hartman
2022-05-19 17:55                       ` Chris Down
2022-05-24  9:19     ` Petr Mladek
2022-05-30 10:48       ` [OFFLIST] " Chris Down
2022-05-30 10:49         ` Chris Down
2022-05-19  7:26 ` Geert Uytterhoeven
2022-05-19 14:37   ` Chris Down
2022-05-19 17:48     ` Geert Uytterhoeven
2022-05-19 18:05       ` Chris Down
2022-05-19 13:59 ` [printk] 6f922c8d53: BUG:kernel_NULL_pointer_dereference,address kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YoVM+KbdyJm8RSSr@chrisdown.name \
    --to=chris@chrisdown.name \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmladek@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).