Under rare circumstances it may happen that a device node's name is NULL
(most likely kernel bug in some other place). In such situations anything
but helpful, if the debug printout crashes, and nobody knows what actually
happened here.
Therefore protect it by an explicit NULL check and print out an extra
warning.
Signed-off-by: Enrico Weigelt, metux IT consult <[email protected]>
---
lib/vsprintf.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 3b53c73580c5..050a60b88073 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -2013,6 +2013,10 @@ char *device_node_string(char *buf, char *end, struct device_node *dn,
break;
case 'n': /* name */
p = fwnode_get_name(of_fwnode_handle(dn));
+ if (!p) {
+ pr_warn("device_node without name. Kernel bug ?\n");
+ p = "<NULL>";
+ }
precision = str_spec.precision;
str_spec.precision = strchrnul(p, '@') - p;
buf = string(buf, end, p, str_spec);
--
2.11.0
On Wed, Feb 17, 2021 at 01:15:43PM +0100, Enrico Weigelt, metux IT consult wrote:
> Under rare circumstances it may happen that a device node's name is NULL
> (most likely kernel bug in some other place).
What circumstances? How can I reproduce this? More information, please!
> In such situations anything
> but helpful, if the debug printout crashes, and nobody knows what actually
> happened here.
>
> Therefore protect it by an explicit NULL check and print out an extra
> warning.
...
> + pr_warn("device_node without name. Kernel bug ?\n");
If it's not once, then it's possible to have log spammed with this, right?
...
> + p = "<NULL>";
We have different standard de facto for NULL pointers to be printed. Actually
if you wish, you may gather them under one definition (maybe somewhere under
printk) and export to everybody to use.
--
With Best Regards,
Andy Shevchenko
On (21/02/17 13:15), Enrico Weigelt, metux IT consult wrote:
> Under rare circumstances it may happen that a device node's name is NULL
> (most likely kernel bug in some other place). In such situations anything
> but helpful, if the debug printout crashes, and nobody knows what actually
> happened here.
>
> Therefore protect it by an explicit NULL check and print out an extra
> warning.
>
> Signed-off-by: Enrico Weigelt, metux IT consult <[email protected]>
> ---
> lib/vsprintf.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 3b53c73580c5..050a60b88073 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -2013,6 +2013,10 @@ char *device_node_string(char *buf, char *end, struct device_node *dn,
> break;
> case 'n': /* name */
> p = fwnode_get_name(of_fwnode_handle(dn));
> + if (!p) {
> + pr_warn("device_node without name. Kernel bug ?\n");
> + p = "<NULL>";
> + }
> precision = str_spec.precision;
> str_spec.precision = strchrnul(p, '@') - p;
> buf = string(buf, end, p, str_spec);
What about other fwnode_get_name() calls in vsprintf?
-ss
On Wed 2021-02-17 15:50:00, Andy Shevchenko wrote:
> On Wed, Feb 17, 2021 at 01:15:43PM +0100, Enrico Weigelt, metux IT consult wrote:
> > Under rare circumstances it may happen that a device node's name is NULL
> > (most likely kernel bug in some other place).
>
> What circumstances? How can I reproduce this? More information, please!
>
> > In such situations anything
> > but helpful, if the debug printout crashes, and nobody knows what actually
> > happened here.
> >
> > Therefore protect it by an explicit NULL check and print out an extra
> > warning.
>
> ...
>
> > + pr_warn("device_node without name. Kernel bug ?\n");
>
> If it's not once, then it's possible to have log spammed with this, right?
>
> ...
>
> > + p = "<NULL>";
>
> We have different standard de facto for NULL pointers to be printed. Actually
> if you wish, you may gather them under one definition (maybe somewhere under
> printk) and export to everybody to use.
Please, use
if (check_pointer(&buf, end, p, spec))
return buf;
It will print "(null)" instead of the name. It should be enough
to inform the user this way. The extra pr_warn() does not help
much to localize the problem anyway. And it is better to avoid
recursion in this path.
Best Regards,
Petr
On 18.02.21 13:53, Petr Mladek wrote:
> Please, use
>
> if (check_pointer(&buf, end, p, spec))
> return buf;
>
> It will print "(null)" instead of the name. It should be enough
> to inform the user this way. The extra pr_warn() does not help
> much to localize the problem anyway. And it is better to avoid
> recursion in this path.
thx, going to use it in v2.
--mtx
--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
[email protected] -- +49-151-27565287
On 17.02.21 14:50, Andy Shevchenko wrote:
> On Wed, Feb 17, 2021 at 01:15:43PM +0100, Enrico Weigelt, metux IT consult wrote:
>> Under rare circumstances it may happen that a device node's name is NULL
>> (most likely kernel bug in some other place).
>
> What circumstances? How can I reproduce this? More information, please!
Observed it when applying a broken overlay. (sorry, didn't keep that
broken code :o). In this case, the device_node was left without a name
(pointing to NULL).
>> + pr_warn("device_node without name. Kernel bug ?\n");
>
> If it's not once, then it's possible to have log spammed with this, right?
It only has occoured once for me. I don't think spamming could happen,
unless one's hacking deeply in the oftree code.
>> + p = "<NULL>";
>
> We have different standard de facto for NULL pointers to be printed. Actually
> if you wish, you may gather them under one definition (maybe somewhere under
> printk) and export to everybody to use.
Seen it in Petr's reply ... going to use that in v2.
--mtx
--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
[email protected] -- +49-151-27565287