[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250311090025.kyc657febhgxrhoa@uda0492258>
Date: Tue, 11 Mar 2025 14:30:25 +0530
From: "s-vadapalli@...com" <s-vadapalli@...com>
To: "Sverdlin, Alexander" <alexander.sverdlin@...mens.com>
CC: "s-vadapalli@...com" <s-vadapalli@...com>,
"andrew+netdev@...n.ch"
<andrew+netdev@...n.ch>,
"dan.carpenter@...aro.org"
<dan.carpenter@...aro.org>,
"davem@...emloft.net" <davem@...emloft.net>,
"jpanis@...libre.com" <jpanis@...libre.com>, "srk@...com" <srk@...com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"pabeni@...hat.com"
<pabeni@...hat.com>,
"horms@...nel.org" <horms@...nel.org>,
"edumazet@...gle.com" <edumazet@...gle.com>,
"rogerq@...nel.org"
<rogerq@...nel.org>,
"vigneshr@...com" <vigneshr@...com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"kuba@...nel.org"
<kuba@...nel.org>
Subject: Re: [PATCH net] net: ethernet: ti: am65-cpsw: Fix NAPI registration
sequence
On Tue, Mar 11, 2025 at 08:56:49AM +0000, Sverdlin, Alexander wrote:
> Hi Siddharth!
>
> On Tue, 2025-03-11 at 14:21 +0530, s-vadapalli@...com wrote:
> > > > Registering the interrupts for TX or RX DMA Channels prior to registering
> > > > their respective NAPI callbacks can result in a NULL pointer dereference.
> > > > This is seen in practice as a random occurrence since it depends on the
> > > > randomness associated with the generation of traffic by Linux and the
> > > > reception of traffic from the wire.
> > > >
> > > > Fixes: 681eb2beb3ef ("net: ethernet: ti: am65-cpsw: ensure proper channel cleanup in error path")
> > >
> > > The patch Vignesh mentions here...
> > >
> > > > Signed-off-by: Vignesh Raghavendra <vigneshr@...com>
> > > > Co-developed-by: Siddharth Vadapalli <s-vadapalli@...com>
> > > > Signed-off-by: Siddharth Vadapalli <s-vadapalli@...com>
>
> ...
>
> > > > --- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> > > > +++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> > > > @@ -2314,6 +2314,9 @@ static int am65_cpsw_nuss_ndev_add_tx_napi(struct am65_cpsw_common *common)
> > > > hrtimer_init(&tx_chn->tx_hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL_PINNED);
> > > > tx_chn->tx_hrtimer.function = &am65_cpsw_nuss_tx_timer_callback;
> > > >
> > > > + netif_napi_add_tx(common->dma_ndev, &tx_chn->napi_tx,
> > > > + am65_cpsw_nuss_tx_poll);
> > > > +
> > > > ret = devm_request_irq(dev, tx_chn->irq,
> > > > am65_cpsw_nuss_tx_irq,
> > > > IRQF_TRIGGER_HIGH,
> > > > @@ -2323,9 +2326,6 @@ static int am65_cpsw_nuss_ndev_add_tx_napi(struct am65_cpsw_common *common)
> > > > tx_chn->id, tx_chn->irq, ret);
> > > > goto err;
> > > > }
> > > > -
> > > > - netif_napi_add_tx(common->dma_ndev, &tx_chn->napi_tx,
> > > > - am65_cpsw_nuss_tx_poll);
> > >
> > > ... has accounted for the fact ..._napi_add_... happens after [possibly unsuccessful] request_irq,
> > > please grep for "for (--i ;". Is it necessary to adjust both loops, in the below case too?
> >
> > Yes! The order within the cleanup path has to be reversed too i.e.
>
> Not only reverting the order...
> What I'm referring is: when requesting i-th IRQ fails there has been
> i-th NAPI already added, but the cleanup loops start from [i-1]-th instance.
> It looks like a potential leak to me...
Thank you for clarifying. I will address this and the previous feedback in
the v2 patch.
Regards,
Siddharth.
Powered by blists - more mailing lists