From: Felix Fietkau <nbd@nbd.name>
To: Alexander H Duyck <alexander.duyck@gmail.com>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: netdev@vger.kernel.org, Jesper Dangaard Brouer <hawk@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Lorenzo Bianconi <lorenzo@kernel.org>,
linux-kernel@vger.kernel.org,
Yunsheng Lin <linyunsheng@huawei.com>
Subject: Re: [PATCH] net: page_pool: fix refcounting issues with fragmented allocation
Date: Wed, 25 Jan 2023 19:42:33 +0100 [thread overview]
Message-ID: <0c0e96a7-1cf1-b856-b339-1f3df36a562c@nbd.name> (raw)
In-Reply-To: <595c5e36b0260ba16833c2a8d9418fd978ca9300.camel@gmail.com>
On 25.01.23 19:26, Alexander H Duyck wrote:
> On Wed, 2023-01-25 at 18:32 +0100, Felix Fietkau wrote:
>> On 25.01.23 18:11, Alexander H Duyck wrote:
>> > On Tue, 2023-01-24 at 22:30 +0100, Felix Fietkau wrote:
>> > > On 24.01.23 22:10, Alexander H Duyck wrote:
>> > > > On Tue, 2023-01-24 at 18:22 +0100, Felix Fietkau wrote:
>> > > > > On 24.01.23 15:11, Ilias Apalodimas wrote:
>> > > > > > Hi Felix,
>> > > > > >
>> > > > > > ++cc Alexander and Yunsheng.
>> > > > > >
>> > > > > > Thanks for the report
>> > > > > >
>> > > > > > On Tue, 24 Jan 2023 at 14:43, Felix Fietkau <nbd@nbd.name> wrote:
>> > > > > > >
>> > > > > > > While testing fragmented page_pool allocation in the mt76 driver, I was able
>> > > > > > > to reliably trigger page refcount underflow issues, which did not occur with
>> > > > > > > full-page page_pool allocation.
>> > > > > > > It appears to me, that handling refcounting in two separate counters
>> > > > > > > (page->pp_frag_count and page refcount) is racy when page refcount gets
>> > > > > > > incremented by code dealing with skb fragments directly, and
>> > > > > > > page_pool_return_skb_page is called multiple times for the same fragment.
>> > > > > > >
>> > > > > > > Dropping page->pp_frag_count and relying entirely on the page refcount makes
>> > > > > > > these underflow issues and crashes go away.
>> > > > > > >
>> > > > > >
>> > > > > > This has been discussed here [1]. TL;DR changing this to page
>> > > > > > refcount might blow up in other colorful ways. Can we look closer and
>> > > > > > figure out why the underflow happens?
>> > > > > I don't see how the approch taken in my patch would blow up. From what I
>> > > > > can tell, it should be fairly close to how refcount is handled in
>> > > > > page_frag_alloc. The main improvement it adds is to prevent it from
>> > > > > blowing up if pool-allocated fragments get shared across multiple skbs
>> > > > > with corresponding get_page and page_pool_return_skb_page calls.
>> > > > >
>> > > > > - Felix
>> > > > >
>> > > >
>> > > > Do you have the patch available to review as an RFC? From what I am
>> > > > seeing it looks like you are underrunning on the pp_frag_count itself.
>> > > > I would suspect the issue to be something like starting with a bad
>> > > > count in terms of the total number of references, or deducing the wrong
>> > > > amount when you finally free the page assuming you are tracking your
>> > > > frag count using a non-atomic value in the driver.
>> > > The driver patches for page pool are here:
>> > > https://patchwork.kernel.org/project/linux-wireless/patch/64abb23f4867c075c19d704beaae5a0a2f8e8821.1673963374.git.lorenzo@kernel.org/
>> > > https://patchwork.kernel.org/project/linux-wireless/patch/68081e02cbe2afa2d35c8aa93194f0adddbd0f05.1673963374.git.lorenzo@kernel.org/
>> > >
>> > > They are also applied in my mt76 tree at:
>> > > https://github.com/nbd168/wireless
>> > >
>> > > - Felix
>> >
>> > So one thing I am thinking is that we may be seeing an issue where we
>> > are somehow getting a mix of frag and non-frag based page pool pages.
>> > That is the only case I can think of where we might be underflowing
>> > negative. If you could add some additional debug info on the underflow
>> > WARN_ON case in page_pool_defrag_page that might be useful.
>> > Specifically I would be curious what the actual return value is. I'm
>> > assuming we are only hitting negative 1, but I would want to verify we
>> > aren't seeing something else.
>> I'll try to run some more tests soon. However, I think I found the piece
>> of code that is incompatible with using pp_frag_count.
>> When receiving an A-MSDU packet (multiple MSDUs within a single 802.11
>> packet), and it is not split by the hardware, a cfg80211 function
>> extracts the individual MSDUs into separate skbs. In that case, a
>> fragment can be shared across multiple skbs, and get_page is used to
>> increase the refcount.
>> You can find this in net/wireless/util.c: ieee80211_amsdu_to_8023s (and
>> its helper functions).
>
> I'm not sure if it is problematic or not. Basically it is trading off
> by copying over the frags, calling get_page on each frag, and then
> using dev_kfree_skb to disassemble and release the pp_frag references.
> There should be other paths in the kernel that are doing something
> similar.
>
>> This code also has a bug where it doesn't set pp_recycle on the newly
>> allocated skb if the previous one has it, but that's a separate matter
>> and fixing it doesn't make the crash go away.
>
> Adding the recycle would cause this bug. So one thing we might be
> seeing is something like that triggering this error. Specifically if
> the page is taken via get_page when assembling the new skb then we
> cannot set the recycle flag in the new skb otherwise it will result in
> the reference undercount we are seeing. What we are doing is shifting
> the references away from the pp_frag_count to the page reference count
> in this case. If we set the pp_recycle flag then it would cause us to
> decrement pp_frag_count instead of the page reference count resulting
> in the underrun.
Couldn't leaving out the pp_recycle flag potentially lead to a case
where the last user of the page drops it via page_frag_free instead of
page_pool_return_skb_page? Is that valid?
>> Is there any way I can make that part of the code work with the current
>> page pool frag implementation?
>
> The current code should work. Basically as long as the references are
> taken w/ get_page and skb->pp_recycle is not set then we shouldn't run
> into this issue because the pp_frag_count will be dropped when the
> original skb is freed and the page reference count will be decremented
> when the new one is freed.
>
> For page pool page fragments the main thing to keep in mind is that if
> pp_recycle is set it will update the pp_frag_count and if it is not
> then it will just decrement the page reference count.
What takes care of DMA unmap and other cleanup if the last reference to
the page is dropped via page_frag_free?
- Felix
next prev parent reply other threads:[~2023-01-25 18:43 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-24 12:43 [PATCH] net: page_pool: fix refcounting issues with fragmented allocation Felix Fietkau
2023-01-24 14:11 ` Ilias Apalodimas
2023-01-24 15:57 ` Alexander H Duyck
2023-01-24 16:59 ` Felix Fietkau
2023-01-26 10:31 ` Ilias Apalodimas
2023-01-26 15:41 ` Alexander Duyck
2023-01-26 16:05 ` Ilias Apalodimas
2023-01-24 17:22 ` Felix Fietkau
2023-01-24 21:10 ` Alexander H Duyck
2023-01-24 21:30 ` Felix Fietkau
2023-01-25 17:11 ` Alexander H Duyck
2023-01-25 17:32 ` Felix Fietkau
2023-01-25 18:26 ` Alexander H Duyck
2023-01-25 18:42 ` Felix Fietkau [this message]
2023-01-25 19:02 ` Alexander H Duyck
2023-01-25 19:10 ` Felix Fietkau
2023-01-25 19:40 ` Felix Fietkau
2023-01-25 20:02 ` Felix Fietkau
2023-01-25 22:14 ` Alexander H Duyck
2023-01-26 6:12 ` Felix Fietkau
2023-01-26 9:14 ` Felix Fietkau
2023-01-26 16:08 ` Alexander Duyck
2023-01-26 16:40 ` Alexander Duyck
2023-01-26 17:44 ` Felix Fietkau
2023-01-26 18:38 ` Alexander H Duyck
2023-01-26 18:43 ` Felix Fietkau
2023-01-26 19:06 ` [net PATCH] skb: Do mix page pool and page referenced frags in GRO Alexander Duyck
2023-01-26 19:14 ` Toke Høiland-Jørgensen
2023-01-26 19:48 ` Alexander Duyck
2023-01-26 21:35 ` Toke Høiland-Jørgensen
2023-01-26 23:13 ` Jakub Kicinski
2023-01-27 7:15 ` Ilias Apalodimas
2023-01-27 7:21 ` Felix Fietkau
2023-01-30 16:49 ` Jesper Dangaard Brouer
2023-01-28 2:37 ` Yunsheng Lin
2023-01-28 5:26 ` Jakub Kicinski
2023-01-28 7:08 ` Eric Dumazet
2023-01-30 8:50 ` Paolo Abeni
2023-01-30 16:17 ` Alexander Duyck
2023-01-28 7:15 ` Eric Dumazet
2023-01-28 17:08 ` Alexander Duyck
2023-01-28 7:50 ` patchwork-bot+netdevbpf
2023-01-26 10:32 ` [PATCH] net: page_pool: fix refcounting issues with fragmented allocation Ilias Apalodimas
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=0c0e96a7-1cf1-b856-b339-1f3df36a562c@nbd.name \
--to=nbd@nbd.name \
--cc=alexander.duyck@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linyunsheng@huawei.com \
--cc=lorenzo@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).