[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230823074928.264b946f@kernel.org>
Date: Wed, 23 Aug 2023 07:49:28 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: netdev@...r.kernel.org, Ratheesh Kannoth <rkannoth@...vell.com>, "David
S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Geetha sowjanya <gakula@...vell.com>, Ilias Apalodimas
<ilias.apalodimas@...aro.org>, Jesper Dangaard Brouer <hawk@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, Subbaraya Sundeep <sbhatta@...vell.com>,
Sunil Goutham <sgoutham@...vell.com>, Thomas Gleixner <tglx@...utronix.de>,
hariprasad <hkelam@...vell.com>
Subject: Re: [BUG] Possible unsafe page_pool usage in octeontx2
On Wed, 23 Aug 2023 11:47:57 +0200 Sebastian Andrzej Siewior wrote:
> The pool can be filled in the same context (within allocation if the
> pool is empty). There is also page_pool_recycle_in_cache() which fills
> the pool from within skb free, for instance:
> napi_consume_skb() -> skb_release_all() -> skb_release_data() ->
> napi_frag_unref() -> page_pool_return_skb_page().
>
> The last one has the following check here:
> | napi = READ_ONCE(pp->p.napi);
> | allow_direct = napi_safe && napi &&
> | READ_ONCE(napi->list_owner) == smp_processor_id();
>
> This eventually ends in page_pool_recycle_in_cache() where it adds the
> page to the cache buffer if the check above is true (and BH is disabled).
>
> napi->list_owner is set once NAPI is scheduled until the poll callback
> completed. It is safe to add items to list because only one of the two
> can run on a single CPU and the completion of them ensured by having BH
> disabled the whole time.
One clarification - .napi will be NULL for otx2, it's an opt-in for
drivers which allocate from NAPI, and AFAICT otx2 does not opt in.
Powered by blists - more mailing lists