linux-kernel - Re: [PATCH v2] remoteproc: use %pe format string to print return error code

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: <20211213072015.32235-1-mark-pk.tsai@mediatek.com>
Date:   Mon, 13 Dec 2021 15:20:15 +0800
From:   Mark-PK Tsai <mark-pk.tsai@...iatek.com>
To:     <mathieu.poirier@...aro.org>
CC:     <bjorn.andersson@...aro.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>,
        <linux-mediatek@...ts.infradead.org>,
        <linux-remoteproc@...r.kernel.org>, <mark-pk.tsai@...iatek.com>,
        <matthias.bgg@...il.com>, <ohad@...ery.com>,
        <yj.chiang@...iatek.com>
Subject: Re: [PATCH v2] remoteproc: use %pe format string to print return error code

> Good day,
> 
> On Tue, Nov 16, 2021 at 09:57:03PM +0800, Mark-PK Tsai wrote:
> > > > > > Use %pe format string to print return error code which
> > > > > > make the error message easier to understand.
> > > > > >
> > > > > > Signed-off-by: Mark-PK Tsai <mark-pk.tsai@...iatek.com>
> > > > > > ---
> > > > > >  drivers/remoteproc/remoteproc_core.c | 4 ++--
> > > > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> > > > > > index 502b6604b757..2242da320368 100644
> > > > > > --- a/drivers/remoteproc/remoteproc_core.c
> > > > > > +++ b/drivers/remoteproc/remoteproc_core.c
> > > > > > @@ -575,8 +575,8 @@ static int rproc_handle_vdev(struct rproc *rproc, void *ptr,
> > > > > >                                            dma_get_mask(rproc->dev.parent));
> > > > > >         if (ret) {
> > > > > >                 dev_warn(dev,
> > > > > > -                        "Failed to set DMA mask %llx. Trying to continue... %x\n",
> > > > > > -                        dma_get_mask(rproc->dev.parent), ret);
> > > > > > +                        "Failed to set DMA mask %llx. Trying to continue... (%pe)\n",
> > > > > > +                        dma_get_mask(rproc->dev.parent), ERR_PTR(ret));
> > > > >
> > > > > Macro ERR_PTR() is used to convert error codes to pointer type when
> > > > > returning from a function - I fail to see how doing so in a dev_warn()
> > > > > context can make the message easier to understand.  Can you provide an
> > > > > example?
> > > >
> > > > Hi,
> > > >
> > > > When dma_coerce_mask_and_coherent() fail, the output log will be as following.
> > > >
> > > > format          log
> > > > %x              Trying to continue... fffffffb
> > > > %d              Trying to continue... -5
> > > > %pe             Trying to continue... -5        (if CONFIG_SYMBOLIC_ERRNAME is not set)
> > > > %pe             Trying to continue... -EIO      (if CONFIG_SYMBOLIC_ERRNAME=y)
> > >
> > > When failing, functions dma_coerce_mask_and_coherent() returns -EIO.
> > > Casting that to a (void *) with ERR_PTR() does not change that value.
> > > Since variable @ret is already declared as "int" the real fix is to
> > > change "%x" to "%d".
> > 
> > There're some other drivers do the same thing in the recent kernel, so I think
> > it's fine to casting the `ret` to a (void *) for more user friendly.
> > But I suppose it would depend on the maintainer's opinion.
> > 
> > So how about previous patch I sent, which also fix this issue by using %d.
> > 
> > https://lore.kernel.org/lkml/20211102120805.27137-1-mark-pk.tsai@mediatek.com/
> 
> I had not seen Russell's reply in the link you posted above.  I am not
> completely sure about his solution but his insight and guidance in kernel
> programming have precedence over mine.
> 
> I will take this patch.
> 
> Thanks,
> Mathieu
> 

Hi,

Sorry to disturb you.
Is this patch queued?
Just want to make sure it has not been forgotten.