From: Alexander H Duyck <alexander.duyck@gmail.com>
To: Alexander Lobakin <aleksander.lobakin@intel.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
Cc: Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
Larysa Zaremba <larysa.zaremba@intel.com>,
Yunsheng Lin <linyunsheng@huawei.com>,
Alexander Duyck <alexanderduyck@fb.com>,
Jesper Dangaard Brouer <hawk@kernel.org>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Simon Horman <simon.horman@corigine.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v4 5/6] page_pool: add a lockdep check for recycling in hardirq
Date: Mon, 07 Aug 2023 07:48:54 -0700 [thread overview]
Message-ID: <692d71dc8068b3d27aba39d7141c811755965786.camel@gmail.com> (raw)
In-Reply-To: <20230804180529.2483231-6-aleksander.lobakin@intel.com>
On Fri, 2023-08-04 at 20:05 +0200, Alexander Lobakin wrote:
> From: Jakub Kicinski <kuba@kernel.org>
>
> Page pool use in hardirq is prohibited, add debug checks
> to catch misuses. IIRC we previously discussed using
> DEBUG_NET_WARN_ON_ONCE() for this, but there were concerns
> that people will have DEBUG_NET enabled in perf testing.
> I don't think anyone enables lockdep in perf testing,
> so use lockdep to avoid pushback and arguing :)
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> Acked-by: Jesper Dangaard Brouer <hawk@kernel.org>
> Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> ---
> include/linux/lockdep.h | 7 +++++++
> net/core/page_pool.c | 2 ++
> 2 files changed, 9 insertions(+)
>
> diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
> index 310f85903c91..dc2844b071c2 100644
> --- a/include/linux/lockdep.h
> +++ b/include/linux/lockdep.h
> @@ -625,6 +625,12 @@ do { \
> WARN_ON_ONCE(__lockdep_enabled && !this_cpu_read(hardirq_context)); \
> } while (0)
>
> +#define lockdep_assert_no_hardirq() \
> +do { \
> + WARN_ON_ONCE(__lockdep_enabled && (this_cpu_read(hardirq_context) || \
> + !this_cpu_read(hardirqs_enabled))); \
> +} while (0)
> +
> #define lockdep_assert_preemption_enabled() \
> do { \
> WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_COUNT) && \
> @@ -659,6 +665,7 @@ do { \
> # define lockdep_assert_irqs_enabled() do { } while (0)
> # define lockdep_assert_irqs_disabled() do { } while (0)
> # define lockdep_assert_in_irq() do { } while (0)
> +# define lockdep_assert_no_hardirq() do { } while (0)
>
> # define lockdep_assert_preemption_enabled() do { } while (0)
> # define lockdep_assert_preemption_disabled() do { } while (0)
> diff --git a/net/core/page_pool.c b/net/core/page_pool.c
> index 03ad74d25959..77cb75e63aca 100644
> --- a/net/core/page_pool.c
> +++ b/net/core/page_pool.c
> @@ -587,6 +587,8 @@ static __always_inline struct page *
> __page_pool_put_page(struct page_pool *pool, struct page *page,
> unsigned int dma_sync_size, bool allow_direct)
> {
> + lockdep_assert_no_hardirq();
> +
> /* This allocator is optimized for the XDP mode that uses
> * one-frame-per-page, but have fallbacks that act like the
> * regular page allocator APIs.
So two points.
First could we look at moving this inside the if statement just before
we return the page, as there isn't a risk until we get into that path
of needing a lock.
Secondly rather than returning an error is there any reason why we
couldn't just look at not returning page and instead just drop into the
release path which wouldn't take the locks in the first place? Either
that or I would even be good with some combination of the two where we
threw a warning, but still just dropped the page so we reduce our risk
further of actually locking things up.
next prev parent reply other threads:[~2023-08-07 14:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-04 18:05 [PATCH net-next v4 0/6] page_pool: a couple of assorted optimizations Alexander Lobakin
2023-08-04 18:05 ` [PATCH net-next v4 1/6] page_pool: split types and declarations from page_pool.h Alexander Lobakin
2023-08-07 20:09 ` Jakub Kicinski
2023-08-04 18:05 ` [PATCH net-next v4 2/6] net: skbuff: don't include <net/page_pool/types.h> to <linux/skbuff.h> Alexander Lobakin
2023-08-04 18:05 ` [PATCH net-next v4 3/6] page_pool: place frag_* fields in one cacheline Alexander Lobakin
2023-08-04 18:05 ` [PATCH net-next v4 4/6] net: skbuff: avoid accessing page_pool if !napi_safe when returning page Alexander Lobakin
2023-08-04 18:05 ` [PATCH net-next v4 5/6] page_pool: add a lockdep check for recycling in hardirq Alexander Lobakin
2023-08-07 14:48 ` Alexander H Duyck [this message]
2023-08-08 13:16 ` Alexander Lobakin
2023-08-08 13:45 ` Alexander Duyck
2023-08-08 13:58 ` Alexander Lobakin
2023-08-08 14:52 ` Alexander Duyck
2023-08-08 15:06 ` Alexander Lobakin
2023-08-08 17:35 ` Alexander Duyck
2023-08-04 18:05 ` [PATCH net-next v4 6/6] net: skbuff: always try to recycle PP pages directly when in softirq Alexander Lobakin
2023-08-07 14:53 ` [PATCH net-next v4 0/6] page_pool: a couple of assorted optimizations Alexander H Duyck
2023-08-07 20:20 ` patchwork-bot+netdevbpf
2023-08-08 13:17 ` Alexander Lobakin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=692d71dc8068b3d27aba39d7141c811755965786.camel@gmail.com \
--to=alexander.duyck@gmail.com \
--cc=aleksander.lobakin@intel.com \
--cc=alexanderduyck@fb.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--cc=kuba@kernel.org \
--cc=larysa.zaremba@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linyunsheng@huawei.com \
--cc=maciej.fijalkowski@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=simon.horman@corigine.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®