netdev - Re: [PATCH v6] virtio_net: add page_pool support for buffer allocation

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] [day] [month] [year] [list]

Message-ID: <5184bd60-2a96-451e-8b0a-bc1132b1498d@meta.com>
Date: Mon, 9 Feb 2026 11:34:27 -0800
From: Vishwanath Seshagiri <vishs@...a.com>
To: Xuan Zhuo <xuanzhuo@...ux.alibaba.com>
Cc: Eugenio Pérez <eperezma@...hat.com>,
        Andrew Lunn <andrew+netdev@...n.ch>,
        "David S . Miller"
 <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, David Wei <dw@...idwei.uk>,
        Matteo Croce <technoboy85@...il.com>,
        Ilias Apalodimas <ilias.apalodimas@...aro.org>, netdev@...r.kernel.org,
        virtualization@...ts.linux.dev, linux-kernel@...r.kernel.org,
        kernel-team@...a.com, "Michael S . Tsirkin" <mst@...hat.com>,
        Jason Wang <jasowang@...hat.com>
Subject: Re: [PATCH v6] virtio_net: add page_pool support for buffer
 allocation



On 2/8/26 11:12 PM, Xuan Zhuo wrote:
>>>>
>>>> +static void virtnet_put_page(struct receive_queue *rq, struct page *page,
>>>> +			     bool allow_direct)
>>>> +{
>>>> +	if (page_pool_page_is_pp(page))
>>>> +		page_pool_put_page(rq->page_pool, page, -1, allow_direct);
>>>> +	else
>>>> +		put_page(page);
>>>> +}
>>>
>>> Why we need this?
>>> For the caller, we should know which one should be used?
>>>
>>
>> This was after some feedback to unify the alloc/free path checks in v4.
>> But you raise a valid point - callers already know the mode via
>> virtnet_no_page_pool(). I can simplify this to just call
>> page_pool_put_page() directly, since virtnet_put_page() is only called
>> from paths that already checked we're using page_pool. Would you prefer
>> that?
> 
> 
> Based on my understanding, the big mode should directly call the Page API, while
> all other modes should directly call the PP API. Therefore, I believe it's
> better for each mode to directly invoke its respective API.

ack. I will move this into each callsite.

>>>>
>>>> +static int virtnet_create_page_pools(struct virtnet_info *vi)
>>>> +{
>>>> +	int i, err;
>>>> +
>>>> +	if (!vi->mergeable_rx_bufs && vi->big_packets)
>>>> +		return 0;
>>>> +
>>>> +	for (i = 0; i < vi->max_queue_pairs; i++) {
>>>> +		struct receive_queue *rq = &vi->rq[i];
>>>> +		struct page_pool_params pp_params = { 0 };
>>>> +		struct device *dma_dev;
>>>> +
>>>> +		if (rq->page_pool)
>>>> +			continue;
>>>> +
>>>> +		if (rq->xsk_pool)
>>>> +			continue;
>>>> +
>>>> +		pp_params.order = 0;
>>>> +		pp_params.pool_size = virtqueue_get_vring_size(rq->vq);
>>>> +		pp_params.nid = dev_to_node(vi->vdev->dev.parent);
>>>> +		pp_params.netdev = vi->dev;
>>>> +		pp_params.napi = &rq->napi;
>>>> +
>>>> +		/* Check if backend supports DMA API (e.g., vhost, virtio-pci).
>>>> +		 * If so, use page_pool's DMA mapping for premapped buffers.
>>>> +		 * Otherwise (e.g., VDUSE), page_pool only handles allocation.
>>>> +		 */
>>>> +		dma_dev = virtqueue_dma_dev(rq->vq);
>>>> +		if (dma_dev) {
>>>> +			pp_params.dev = dma_dev;
>>>> +			pp_params.flags = PP_FLAG_DMA_MAP;
>>>> +			pp_params.dma_dir = DMA_FROM_DEVICE;
>>>> +			rq->use_page_pool_dma = true;
>>>> +		} else {
>>>> +			pp_params.dev = vi->vdev->dev.parent;
>>>> +			pp_params.flags = 0;
>>>> +			rq->use_page_pool_dma = false;
>>>
>>> Can the page pool handles dma with vi->vdev->dev.parent?
>>
>> No, we cannot use the page_pool DMA with vi->vdev->dev.parent in VDUSE
>> case because VDUSE uses its own address translation. virtqueue_dma_dev()
>> returns NULL, virtio doesn't use standard DMA API at all. Now that I
>> think about it, setting pp_params.dev in this branch is unnecessary
>> since it is never accessed. I can remove it, if you prefer.
> 
> If that's the case, then it is indeed a bit troublesome. I don't know if VDUSE
> has a better solution. What I don't like is use_page_pool_dma -- it
> introduces many branches into the code, making it more chaotic. We may need to
> look for a better unified solution.
> 
> Thanks.

VDUSE does not have a DMA device. virtqueue_dma_dev() returns NULL and
virtqueue_map_single_attrs() just returns virt_to_phys(). There's
nothing to map or sync. These branches exist because page_pool's DMA
APIs require a configured DMA device. I can remove the use_page_pool_dma
and check pool->dma_map directly to reduce state. However, some amount
of branching is unavoidable unless page_pool adds a no-op variant of its
DMA functions.

To bring parity with vhost/virtio-pci, VDUSE would need to implement the
standard DMA API, which conflicts with VDUSE's fundamental architecture
since it uses its own IOVA translation for userpsace access. I don't see
a way to avoid these branches without dropping page_pool for VDUSE,
which I'd prefer not to do. Open to suggestions if I have missed
something.

> 
>>
>>
>>>
>>> Thanks.
>>>