| Message ID | 20210217121543.13010-1-info@metux.net (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | lib: vsprintf: check for NULL device_node name in device_node_string() | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Not a local patch |
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.
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 <info@metux.net> > --- > 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 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
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
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);
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 <info@metux.net> --- lib/vsprintf.c | 4 ++++ 1 file changed, 4 insertions(+)