[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250320125349.GN280585@kernel.org>
Date: Thu, 20 Mar 2025 12:53:49 +0000
From: Simon Horman <horms@...nel.org>
To: Meghana Malladi <m-malladi@...com>
Cc: pabeni@...hat.com, kuba@...nel.org, edumazet@...gle.com,
davem@...emloft.net, andrew+netdev@...n.ch, bpf@...r.kernel.org,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, kory.maincent@...tlin.com,
javier.carrasco.cruz@...il.com, diogo.ivo@...mens.com,
jacob.e.keller@...el.com, john.fastabend@...il.com, hawk@...nel.org,
daniel@...earbox.net, ast@...nel.org, srk@...com,
Vignesh Raghavendra <vigneshr@...com>,
Roger Quadros <rogerq@...nel.org>, danishanwar@...com
Subject: Re: [PATCH net-next 1/3] net: ti: prueth: Fix kernel warning while
bringing down network interface
On Mon, Mar 17, 2025 at 03:45:48PM +0530, Meghana Malladi wrote:
> During network interface initialization, the NIC driver needs to register
> its Rx queue with the XDP, to ensure the incoming XDP buffer carries a
> pointer reference to this info and is stored inside xdp_rxq_info.
>
> While this struct isn't tied to XDP prog, if there are any changes in
> Rx queue, the NIC driver needs to stop the Rx queue by unregistering
> with XDP before purging and reallocating memory. Drop page_pool destroy
> during Rx channel reset and this is already handled by XDP during
> xdp_rxq_info_unreg (Rx queue unregister), failing to do will cause the
> following warning:
>
> [ 271.494611] ------------[ cut here ]------------
> [ 271.494629] WARNING: CPU: 0 PID: 2453 at /net/core/page_pool.c:1108 0xffff8000808d5f60
I think it would be nice to include a bit more of the stack trace here.
>
> Fixes: 46eeb90f03e0 ("net: ti: icssg-prueth: Use page_pool API for RX buffer allocation")
> Signed-off-by: Meghana Malladi <m-malladi@...com>
It is a shame that we now have more asymmetry regarding
the allocation of the pool and unwind on error prueth_prepare_rx_chan().
But if I see things correctly the freeing of the pool via
xdp_rxq_info_unreg() is unconditional. And with that in mind
I agree the approach taken by this patch makes sense.
Reviewed-by: Simon Horman <horms@...nel.org>
...
Powered by blists - more mailing lists