On 11/3/25 17:47, David Wei wrote:
On 2025-11-03 05:51, Pavel Begunkov wrote:
quoted
On 11/1/25 02:24, David Wei wrote:
quoted
netdev ops must be called under instance lock or rtnl_lock, but
io_register_zcrx_ifq() isn't doing this for netdev_queue_get_dma_dev().
Fix this by taking the instance lock using netdev_get_by_index_lock().
Extended the instance lock section to include attaching a memory
provider. Could not move io_zcrx_create_area() outside, since the dmabuf
codepath IORING_ZCRX_AREA_DMABUF requires ifq->dev.
It's probably fine for now, but this nested waiting feels
uncomfortable considering that it could be waiting for other
devices to finish IO via dmabuf fences.
Only the dmabuf path requires ifq->dev in io_zcrx_create_area(); I could
split this into two and then unlock netdev instance lock between holding
a ref and calling net_mp_open_rxq().
So the new ordering would be:
1. io_zcrx_create_area() for !IORING_ZCRX_AREA_DMABUF
2. netdev_get_by_index_lock(), hold netdev ref, unlock netdev
3. io_zcrx_create_area() for IORING_ZCRX_AREA_DMABUF
4. net_mp_open_rxq()
To avoid dragging it on, can you do it as a follow up please? And
it's better to avoid splitting on IORING_ZCRX_AREA_DMABUF, either it
works for both or it doesn't at all.
--
Pavel Begunkov