netdev - Re: [PATCH net-next v9 08/20] net: expose page_pool_{set,clear}_pp

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: <bcf5a9e8-5014-44cc-85a0-2974e3039cb6@gmail.com>
Date: Thu, 2 Jan 2025 16:21:07 +0000
From: Pavel Begunkov <asml.silence@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: David Wei <dw@...idwei.uk>, io-uring@...r.kernel.org,
 netdev@...r.kernel.org, Jens Axboe <axboe@...nel.dk>,
 Paolo Abeni <pabeni@...hat.com>, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jesper Dangaard Brouer
 <hawk@...nel.org>, David Ahern <dsahern@...nel.org>,
 Mina Almasry <almasrymina@...gle.com>,
 Stanislav Fomichev <stfomichev@...il.com>, Joe Damato <jdamato@...tly.com>,
 Pedro Tammela <pctammela@...atatu.com>
Subject: Re: [PATCH net-next v9 08/20] net: expose
 page_pool_{set,clear}_pp_info

On 12/21/24 02:23, Jakub Kicinski wrote:
> On Sat, 21 Dec 2024 01:07:44 +0000 Pavel Begunkov wrote:
>>>> Memory providers need to set page pool to its net_iovs on allocation, so
>>>> expose page_pool_{set,clear}_pp_info to providers outside net/.
>>>
>>> I'd really rather not expose such low level functions in a header
>>> included by every single user of the page pool API.
>>
>> Are you fine if it's exposed in a new header file?
> 
> I guess.
> 
> I'm uncomfortable with the "outside net/" phrasing of the commit
> message. Nothing outside net should used this stuff. Next we'll have
> a four letter subsystem abusing it and claiming that it's in a header
> so it's a public.

By net/ I purely meant the folder, even though it also dictates
the available API. io_uring is outside, having some glue API
between them is the only way I can think of, even if it looks
different from the current series.

Since there are strong opinions would make sense to shove it into
a new file and name helpers more appropriately, like net_mp_*.

> Maybe we should have a conversation about whether io_uring/zcrx.c
> is considered part of networking, whether all patches will get cross
> posted and need to get acks from both sides etc. Save ourselves
> unpleasant misunderstandings.

That would be terribly inefficient. Net is already quite busy,
would be a shame spamming it even more with io_uring patches that
are not being particularly interesting to networking. Even the
patchwork tooling won't work too well unless patches are sync'ed
with both trees.

IMHO it sounds saner finalising the API and cross posting when it
needs to be changed.

-- 
Pavel Begunkov