From: Jakub Kicinski <kuba@kernel.org>
To: Liang Chen <liangchen.linux@gmail.com>
Cc: ilias.apalodimas@linaro.org, edumazet@google.com,
hawk@kernel.org, davem@davemloft.net, pabeni@redhat.com,
netdev@vger.kernel.org, alexander.duyck@gmail.com,
linyunsheng@huawei.com
Subject: Re: [PATCH v3] skbuff: Fix a race between coalescing and releasing SKBs
Date: Wed, 12 Apr 2023 21:08:16 -0700 [thread overview]
Message-ID: <20230412210816.072b5fe3@kernel.org> (raw)
In-Reply-To: <20230411022640.8453-1-liangchen.linux@gmail.com>
On Tue, 11 Apr 2023 10:26:40 +0800 Liang Chen wrote:
> /* In general, avoid mixing slab allocated and page_pool allocated
> - * pages within the same SKB. However when @to is not pp_recycle and
> - * @from is cloned, we can transition frag pages from page_pool to
> - * reference counted.
> - *
> - * On the other hand, don't allow coalescing two pp_recycle SKBs if
> - * @from is cloned, in case the SKB is using page_pool fragment
> - * references (PP_FLAG_PAGE_FRAG). Since we only take full page
> - * references for cloned SKBs at the moment that would result in
> - * inconsistent reference counts.
> + * pages within the same SKB. However don't allow coalescing two
The word 'however' no longer works here because there's no
contradiction, it's an additional rule.
> + * pp_recycle SKBs if @from is cloned, in case the SKB is using
> + * page_pool fragment references (PP_FLAG_PAGE_FRAG). Since we only
> + * take full page references for cloned SKBs at the moment that would
> + * result in inconsistent reference counts.
> */
> - if (to->pp_recycle != (from->pp_recycle && !skb_cloned(from)))
> + if (to->pp_recycle != from->pp_recycle ||
> + (from->pp_recycle && skb_cloned(from)))
How about we change the comment to:
/* In general, avoid mixing page_pool and non-page_pool allocated
* pages within the same SKB. Additionally avoid dealing with clones
* containing page_pool pages, in case the SKB is using page_pool fragment
* references (PP_FLAG_PAGE_FRAG). Since we only take full page
* references for cloned SKBs at the moment that would result in
* inconsistent reference counts.
* In theory we could take full references if from is cloned and
* !@to->pp_recycle but its tricky (due to potential race with the clone
* disappearing) and rare, so not worth dealing with.
*/
Please also add:
Fixes: 53e0961da1c7 ("page_pool: add frag page recycling support in page pool")
and Eric's review tag.
prev parent reply other threads:[~2023-04-13 4:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-11 2:26 [PATCH v3] skbuff: Fix a race between coalescing and releasing SKBs Liang Chen
2023-04-12 14:04 ` Eric Dumazet
2023-04-13 4:08 ` Jakub Kicinski [this message]
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=20230412210816.072b5fe3@kernel.org \
--to=kuba@kernel.org \
--cc=alexander.duyck@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--cc=liangchen.linux@gmail.com \
--cc=linyunsheng@huawei.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.