From: Adrian Ratiu <adrian.ratiu@collabora.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
kernel@collabora.com, linux-kernel@vger.kernel.org,
"Guillaume Tucker" <gtucker.collabora@gmail.com>,
"Enric Balletbò" <enric.balletbo@collabora.com>
Subject: Re: [RFC PATCH 1/1] drivers: base: Expose probe failures via debugfs
Date: Thu, 03 Jun 2021 23:00:14 +0300 [thread overview]
Message-ID: <87wnrawwfl.fsf@collabora.com> (raw)
In-Reply-To: <YLjWKwhp7akqyR1S@kroah.com>
On Thu, 03 Jun 2021, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Thu, Jun 03, 2021 at 03:55:34PM +0300, Adrian Ratiu wrote:
>> This adds a new devices_failed debugfs attribute to list driver
>> probe failures excepting -EPROBE_DEFER which are still handled
>> as before via their own devices_deferred attribute.
>
> Who is going to use this?
>
It's for KernelCI testing, I explained the background in my other
reply.
>> This is useful on automated test systems like KernelCI to avoid
>> filtering dmesg dev_err() messages to extract potential probe
>> failures.
>
> I thought we listed these already some other way today?
>
The only other place is the printk buffer via dev_err() and only
the result subset of -EPROBE_DEFER info is exported via debugfs.
An additional problem with this new interface implementation is
that it is based on the new-ish driver core "dev_err_probe" helper
to which not all drivers have been converted (yet...), so there
will be a mismatch between printk and this new interface.
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafael
>> J. Wysocki" <rafael@kernel.org> Cc: Guillaume Tucker
>> <gtucker.collabora@gmail.com> Suggested-by: Enric Balletbò
>> <enric.balletbo@collabora.com> Signed-off-by: Adrian Ratiu
>> <adrian.ratiu@collabora.com> ---
>> drivers/base/core.c | 76
>> +++++++++++++++++++++++++++++++++++++++++++--
>> lib/Kconfig.debug | 23 ++++++++++++++ 2 files changed, 96
>> insertions(+), 3 deletions(-)
>> diff --git a/drivers/base/core.c b/drivers/base/core.c index
>> b8a8c96dca58..74bf057234b8 100644 --- a/drivers/base/core.c +++
>> b/drivers/base/core.c @@ -9,7 +9,9 @@
>> */
>> #include <linux/acpi.h>
>> +#include <linux/circ_buf.h>
>> #include <linux/cpufreq.h>
>> +#include <linux/debugfs.h>
>> #include <linux/device.h> #include <linux/err.h> #include
>> <linux/fwnode.h>
>> @@ -53,6 +55,15 @@ static DEFINE_MUTEX(fwnode_link_lock);
>> static bool fw_devlink_is_permissive(void); static bool
>> fw_devlink_drv_reg_done;
>> +#ifdef CONFIG_DEBUG_FS_PROBE_ERR +#define
>> PROBE_ERR_BUF_ELEM_SIZE 64 +#define PROBE_ERR_BUF_SIZE (1
>> << CONFIG_DEBUG_FS_PROBE_ERR_BUF_SHIFT) +static struct circ_buf
>> probe_err_crbuf; +static char
>> failed_probe_buffer[PROBE_ERR_BUF_SIZE]; +static
>> DEFINE_MUTEX(failed_probe_mutex); +static struct dentry
>> *devices_failed_probe; +#endif
>
> All of this just for a log buffer? The kernel provides a great
> one, printk, let's not create yet-another-log-buffer if at all
> possible please.
Yes, that is correct, this is esentially duplicating information
already exposed via the printk buffer.
>
> If the existing messages are "hard to parse", what can we do to
> make them "easier" that would allow systems to do something with
> them?
>
> What _do_ systems want to do with this information anyway? What
> does it help with exactly?
>
I know driver core probe error message formats are unlikely to
change over time and debugfs in theory is as "stable" as printk,
but I think the main concern is to find a a more reliable way than
parsing printk to extract probe erros, like for the existing
devices_deferred in debugfs.
The idea in my specific case is to be able to reliably run driver
tests in KernelCI for expected or unexpected probe errors like
-EINVAL.
>
>
>> +
>> /**
>> * fwnode_link_add - Create a link between two fwnode_handles.
>> * @con: Consumer end of the link.
>> @@ -3769,6 +3780,29 @@ struct device *device_find_child_by_name(struct device *parent,
>> }
>> EXPORT_SYMBOL_GPL(device_find_child_by_name);
>>
>> +/*
>> + * failed_devs_show() - Show devices & drivers which failed to probe.
>> + */
>> +#ifdef CONFIG_DEBUG_FS_PROBE_ERR
>
> .c files shouldn't have #ifdefs if at all possible, so this patch isn't
> good for that reason alone :(
>
>
>> +static int failed_devs_show(struct seq_file *s, void *data)
>> +{
>> + size_t offset;
>> +
>> + mutex_lock(&failed_probe_mutex);
>> +
>> + for (offset = 0;
>> + offset < PROBE_ERR_BUF_SIZE;
>> + offset += PROBE_ERR_BUF_ELEM_SIZE)
>> + if (probe_err_crbuf.buf[offset])
>> + seq_printf(s, "%s\n", probe_err_crbuf.buf + offset);
>> +
>> + mutex_unlock(&failed_probe_mutex);
>> +
>> + return 0;
>> +}
>> +DEFINE_SHOW_ATTRIBUTE(failed_devs);
>> +#endif
>> +
>> int __init devices_init(void)
>> {
>> devices_kset = kset_create_and_add("devices", &device_uevent_ops, NULL);
>> @@ -3784,6 +3818,12 @@ int __init devices_init(void)
>> if (!sysfs_dev_char_kobj)
>> goto char_kobj_err;
>>
>> +#ifdef CONFIG_DEBUG_FS_PROBE_ERR
>> + devices_failed_probe = debugfs_create_file("devices_failed", 0444, NULL,
>> + NULL, &failed_devs_fops);
>> + probe_err_crbuf.buf = failed_probe_buffer;
>
> Nit, no need to save the dentry here, you can look it up if you really
> need it later on, but most importantly, you NEVER do anything with this
> dentry so why save it at all?
>
> And again, #ifdef is not ok, that makes the code much more
> unmaintainable over time.
>
> thanks,
>
> greg k-h
next prev parent reply other threads:[~2021-06-03 20:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-03 12:55 [RFC PATCH 0/1] Initialize debugfs/ksysfs earlier? Adrian Ratiu
2021-06-03 12:55 ` [RFC PATCH 1/1] drivers: base: Expose probe failures via debugfs Adrian Ratiu
2021-06-03 13:16 ` Greg Kroah-Hartman
2021-06-03 20:00 ` Adrian Ratiu [this message]
2021-06-04 12:58 ` Greg Kroah-Hartman
2021-06-03 13:13 ` [RFC PATCH 0/1] Initialize debugfs/ksysfs earlier? Greg Kroah-Hartman
2021-06-03 20:00 ` Adrian Ratiu
2021-06-04 12:56 ` Greg Kroah-Hartman
2021-06-04 16:06 ` Adrian Ratiu
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=87wnrawwfl.fsf@collabora.com \
--to=adrian.ratiu@collabora.com \
--cc=akpm@linux-foundation.org \
--cc=enric.balletbo@collabora.com \
--cc=gregkh@linuxfoundation.org \
--cc=gtucker.collabora@gmail.com \
--cc=kernel@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
/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