From: Yunsheng Lin <linyunsheng@huawei.com>
To: Jesper Dangaard Brouer <hawk@kernel.org>, <davem@davemloft.net>,
<kuba@kernel.org>, <pabeni@redhat.com>
Cc: <liuyonglong@huawei.com>, <fanghaiqing@huawei.com>,
<zhangkun09@huawei.com>, Robin Murphy <robin.murphy@arm.com>,
Alexander Duyck <alexander.duyck@gmail.com>,
IOMMU <iommu@lists.linux.dev>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Eric Dumazet <edumazet@google.com>,
Simon Horman <horms@kernel.org>, <netdev@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC v4 2/3] page_pool: fix IOMMU crash when driver has already unbound
Date: Tue, 26 Nov 2024 19:46:33 +0800 [thread overview]
Message-ID: <caabd226-e80b-4cd7-acdf-0f1355e04b4f@huawei.com> (raw)
In-Reply-To: <554e768b-e990-49ff-bad4-805ee931597f@kernel.org>
On 2024/11/26 18:22, Jesper Dangaard Brouer wrote:
...
>>>
>>> Once the a page is release from a page pool it becomes a normal page,
>>> that adhere to normal page refcnt'ing. That is how it worked before with
>>> page_pool_release_page().
>>> The later extensions with page fragment support and devmem might have
>>> complicated this code path.
>>
>> As page_pool_return_page() and page_pool_destroy() both try to "release"
>> the page concurrently for a specific page, I am not sure how using some
>> simple *atomic* can avoid this kind of concurrency even before page
>> fragment and devmem are supported, it would be good to be more specific
>> about that by using some pseudocode.
>>
>
> Okay, some my simple atomic idea will not work.
>
> NEW IDEA:
>
> So, the my concern in this patchset is that BH-disabling spin_lock pool->destroy_lock is held in the outer loop of page_pool_inflight_unmap() that scans all pages. Disabling BH for this long have nasty side-effects.
>
> Will it be enough to grab the pool->destroy_lock only when we detect a page that belongs to our page pool? Of-cause after obtaining the lock. the code need to recheck if the page still belongs to the pool.
>
That means there will be page_pool_return_page() called between the scanning,
it seems like a lot like the idea of 'page_pool_get_dma_addr() need to be
checked to decide if the mapping is already done or not for each page.' as
there are two cases when page_pool_return_page() is called during scanning:
1. page_pool_get_dma_addr() returns non-zero dma address, which means the dma
unmapping is not done by scanning yet, page_pool_return_page() need to do
the dma unmapping before calling put_page()
2. page_pool_get_dma_addr() returns zero dma address, which means the dma
unmapping is done by scanning, page_pool_return_page() just skip the dma
unmapping and only call put_page().
It seems there is only one case for scanning:
1. page_pool_get_dma_addr() for a page_pool owned page returns non-zero dma
address, which means page_pool_return_page() is not called for that page yet,
scanning will the do the mapping for page_pool_return_page() and reset the
dma address of the page to indicate the dma unmapping is done for that page.
It seems there is no case of page_pool owned page having zero dma address during
scanning, as both page->pp_magic is cleared and dma unmapping is already done in
page_pool_return_page().
next prev parent reply other threads:[~2024-11-26 11:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-20 10:34 [PATCH RFC v4 0/3] fix two bugs related to page_pool Yunsheng Lin
2024-11-20 10:34 ` [PATCH RFC v4 2/3] page_pool: fix IOMMU crash when driver has already unbound Yunsheng Lin
2024-11-20 15:10 ` Jesper Dangaard Brouer
2024-11-21 8:03 ` Yunsheng Lin
2024-11-25 15:25 ` Jesper Dangaard Brouer
2024-11-26 8:22 ` Yunsheng Lin
2024-11-26 10:22 ` Jesper Dangaard Brouer
2024-11-26 11:46 ` Yunsheng Lin [this message]
2024-11-26 21:51 ` Mina Almasry
2024-11-26 23:53 ` Alexander Duyck
2024-11-27 9:35 ` Yunsheng Lin
2024-11-27 15:31 ` Robin Murphy
2024-11-27 16:27 ` Alexander Duyck
2024-12-04 11:16 ` Yunsheng Lin
2024-11-27 19:39 ` Mina Almasry
2024-11-20 10:34 ` [PATCH RFC v4 3/3] page_pool: skip dma sync operation for inflight pages Yunsheng Lin
2024-11-20 16:17 ` Robin Murphy
2024-11-21 8:04 ` Yunsheng Lin
2024-11-21 13:44 ` Robin Murphy
2024-11-22 7:20 ` Yunsheng Lin
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=caabd226-e80b-4cd7-acdf-0f1355e04b4f@huawei.com \
--to=linyunsheng@huawei.com \
--cc=alexander.duyck@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fanghaiqing@huawei.com \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--cc=iommu@lists.linux.dev \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liuyonglong@huawei.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=robin.murphy@arm.com \
--cc=zhangkun09@huawei.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