netdev - Re: [PATCH net-next v8 07/17] net: page_pool: introduce page_pool_mp_return_in

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: <6fdcd8b4-00d8-4ad7-a9bb-7b208ea54e9d@gmail.com>
Date: Mon, 9 Dec 2024 17:28:54 +0000
From: Pavel Begunkov <asml.silence@...il.com>
To: Mina Almasry <almasrymina@...gle.com>, David Wei <dw@...idwei.uk>
Cc: io-uring@...r.kernel.org, netdev@...r.kernel.org,
 Jens Axboe <axboe@...nel.dk>, Jakub Kicinski <kuba@...nel.org>,
 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>,
 Stanislav Fomichev <stfomichev@...il.com>, Joe Damato <jdamato@...tly.com>,
 Pedro Tammela <pctammela@...atatu.com>
Subject: Re: [PATCH net-next v8 07/17] net: page_pool: introduce
 page_pool_mp_return_in_cache

On 12/9/24 17:15, Mina Almasry wrote:
> On Wed, Dec 4, 2024 at 9:22 AM David Wei <dw@...idwei.uk> wrote:
...
>> +/*
>> + * page_pool_mp_return_in_cache() - return a netmem to the allocation cache.
>> + * @pool:      pool from which pages were allocated
>> + * @netmem:    netmem to return
>> + *
>> + * Return already allocated and accounted netmem to the page pool's allocation
>> + * cache. The function doesn't provide synchronisation and must only be called
>> + * from the napi context.
>> + */
>> +void page_pool_mp_return_in_cache(struct page_pool *pool, netmem_ref netmem)
>> +{
>> +       if (WARN_ON_ONCE(pool->alloc.count >= PP_ALLOC_CACHE_REFILL))
>> +               return;
>> +
> 
> Really the caller needs to check this, and if the caller is checking
> it then this additional check is unnecessarily defensive I would say.
> But not really a big deal. I think I gave this feedback on the
> previous iteration.

I think I already killed it. Nevertheless, that's true, the caller
has to check it, which is why it's a warning.

> Reviewed-by: Mina Almasry <almasrymina@...gle.com>

-- 
Pavel Begunkov