linux-kernel - Re: [PATCH net-next v9 1/9] netmem: add niov->type attribute to distinguish different net

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

Message-ID: <5d2f86ce-e2bb-406a-8d53-58a464958d2d@gmail.com>
Date: Tue, 22 Apr 2025 20:53:41 +0100
From: Pavel Begunkov <asml.silence@...il.com>
To: Mina Almasry <almasrymina@...gle.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-doc@...r.kernel.org, io-uring@...r.kernel.org,
 virtualization@...ts.linux.dev, kvm@...r.kernel.org,
 linux-kselftest@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
 Donald Hunter <donald.hunter@...il.com>, Jonathan Corbet <corbet@....net>,
 Andrew Lunn <andrew+netdev@...n.ch>, Jeroen de Borst <jeroendb@...gle.com>,
 Harshitha Ramamurthy <hramamurthy@...gle.com>,
 Kuniyuki Iwashima <kuniyu@...zon.com>, Willem de Bruijn
 <willemb@...gle.com>, Jens Axboe <axboe@...nel.dk>,
 David Ahern <dsahern@...nel.org>, Neal Cardwell <ncardwell@...gle.com>,
 "Michael S. Tsirkin" <mst@...hat.com>, Jason Wang <jasowang@...hat.com>,
 Xuan Zhuo <xuanzhuo@...ux.alibaba.com>, Eugenio Pérez
 <eperezma@...hat.com>, Stefan Hajnoczi <stefanha@...hat.com>,
 Stefano Garzarella <sgarzare@...hat.com>, Shuah Khan <shuah@...nel.org>,
 sdf@...ichev.me, dw@...idwei.uk, Jamal Hadi Salim <jhs@...atatu.com>,
 Victor Nogueira <victor@...atatu.com>, Pedro Tammela
 <pctammela@...atatu.com>, Samiullah Khawaja <skhawaja@...gle.com>
Subject: Re: [PATCH net-next v9 1/9] netmem: add niov->type attribute to
 distinguish different net_iov types

On 4/22/25 15:03, Mina Almasry wrote:
> On Tue, Apr 22, 2025 at 1:16 AM Pavel Begunkov <asml.silence@...il.com> wrote:
>>
>> On 4/18/25 00:15, Mina Almasry wrote:
>>> Later patches in the series adds TX net_iovs where there is no pp
>>> associated, so we can't rely on niov->pp->mp_ops to tell what is the
>>> type of the net_iov.
>>
>> That's fine, but that needs a NULL pp check in io_uring as well,
>> specifically in io_zcrx_recv_frag().
>>
> 
> I think you mean this update in the code:
> 
> if (!niov->pp || niov->pp->mp_ops != &io_uring_pp_zc_ops ||
>      io_pp_to_ifq(niov->pp) != ifq)
> return -EFAULT;
> 
> Yes, thanks, will do.

That will work. I'm assuming that those pp-less niovs can
end up in the rx path. I think it was deemed not impossible,
right?

>> You can also move it to struct net_iov_area and check niov->owner->type
>> instead. It's a safer choice than aliasing with struct page, there is
>> no cost as you're loading ->owner anyway (e.g. for
>> net_iov_virtual_addr()), and it's better in terms of normalisation /
>> not unnecessary duplicating it, assuming we'll never have niovs of
>> different types bound to the same struct net_iov_area.
>>
> 
> Putting it in niov->owner->type is an alternative approach. I don't
> see a strong reason to go with one over the other. I'm thinking there
> will be fast code paths that want to know the type of the frag or skb> and don't need the owner, so it will be good to save loading another
> cacheline. We have more space in struct net_iov than we know what to
> do with anyway.

That's fine. I wouldn't say it's about space, we can grow net_iov
private bits beyond the pp fields in sturct page, but it's rather
about the mess from the aliasing page. The fact that it's net_iov
makes it better, but I'd rather avoid any additional aliasing
altogether.

-- 
Pavel Begunkov