linux-kernel - Re: [PATCH v2] iio: adc: ad4170-4: Use ERR_PTR() with %pe to improve error logging

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: <CAHp75VfH6xuiPNZA_eGmFgMGxdGTf-y6o+SEKeCbG=wsUOJYfg@mail.gmail.com>
Date: Thu, 7 Aug 2025 23:01:38 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: David Lechner <dlechner@...libre.com>
Cc: Salah Triki <salah.triki@...il.com>, Lars-Peter Clausen <lars@...afoo.de>, 
	Michael Hennerich <Michael.Hennerich@...log.com>, Marcelo Schmitt <marcelo.schmitt@...log.com>, 
	Jonathan Cameron <jic23@...nel.org>, Nuno Sá <nuno.sa@...log.com>, 
	Andy Shevchenko <andy@...nel.org>, linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] iio: adc: ad4170-4: Use ERR_PTR() with %pe to improve
 error logging

On Thu, Aug 7, 2025 at 6:03 PM David Lechner <dlechner@...libre.com> wrote:
> On 8/7/25 3:05 AM, Salah Triki wrote:

...

> >       ret = __ad4170_read_sample(indio_dev, chan, val);
> >       if (ret) {
> > -             dev_err(dev, "failed to read sample: %d\n", ret);
> > +             dev_err(dev, "failed to read sample: %pe\n", ERR_PTR(ret));
> >
> >               ret2 = ad4170_set_channel_enable(st, chan->address, false);
> >               if (ret2)
> > -                     dev_err(dev, "failed to disable channel: %d\n", ret2);
> > +                     dev_err(dev, "failed to disable channel: %pe\n", ERR_PTR(ret2));
> >
> >               return ret;
> >       }
>
> Interesting, I didn't know we had this format specifier. But I think
> this is something we would want to do kernel-wide or not at all to stay
> consistent.

I'm sorry but I didn't follow. This is a kernel-wide format specifier.

> And if we are doing this in more places, it would make sense to have a new
> format specifier for integer error values instead of casting them to
> pointers.

Will _very unlikely_ to happen. This has to be a C standard for that,
otherwise you are suggesting to always have a kernel warning for each
of these cases. The only way we can customize specifiers w/o
introducing a compiler warnings is to continue (and still carefully)
using %p extensions.

-- 
With Best Regards,
Andy Shevchenko