[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <135b671b1b76978fb147d5fee1e1b922e2c61f26.camel@redhat.com>
Date: Tue, 07 Feb 2023 12:36:11 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Jonas Suhr Christensen <jsc@...raculum.org>, netdev@...r.kernel.org
Cc: "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Michal Simek <michal.simek@...inx.com>,
Harini Katakam <harini.katakam@....com>,
Haoyue Xu <xuhaoyue1@...ilicon.com>,
huangjunxian <huangjunxian6@...ilicon.com>,
Wang Qing <wangqing@...o.com>,
Yang Yingliang <yangyingliang@...wei.com>,
Esben Haabendal <esben@...nix.com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net v2 1/2] net: ll_temac: Fix DMA resources leak
On Tue, 2023-02-07 at 12:27 +0100, Paolo Abeni wrote:
> Hi,
>
> On Sun, 2023-02-05 at 21:11 +0100, Jonas Suhr Christensen wrote:
> > Add missing conversion of address when unmapping dma region causing
> > unmapping to silently fail. At some point resulting in buffer
> > overrun eg. when releasing device.
> >
> > Fixes: fdd7454ecb29 ("net: ll_temac: Fix support for little-endian platforms")
> >
> > Signed-off-by: Jonas Suhr Christensen <jsc@...raculum.org>
>
> I'm sorry for nit-picking, but you must avoid empty lines in the tag
> area. Please post a v2 avoiding the empty line between the Fixes and
> sob tags (both here and in the next patch).
>
> You can retain (include in the tag area) the already collected
> reviewed-by/acked-by tags.
I'm sorry, I'm low on coffee. I forgot to mention a more relevant
thing:
> @@ -307,9 +308,14 @@ static void temac_dma_bd_release(struct net_device *ndev)
> for (i = 0; i < lp->rx_bd_num; i++) {
> if (!lp->rx_skb[i])
> break;
> - dma_unmap_single(ndev->dev.parent, lp->rx_bd_v[i].phys,
> +
> + bd = &lp->rx_bd_v[i];
> + dma_unmap_single(ndev->dev.parent, be32_to_cpu(bd->phys),
The above be32_to_cpu() introduces a new build warning. as phys type is
u32. It looks like the existing code generates a lot of similar warns.
You can either try change to phys type to __be32 (likely not suitable
for -net and possibly can introduce even more warnings elsewhere) or
explicitly cast the argument.
Thanks,
Paolo
Powered by blists - more mailing lists