netdev - Re: [PATCH net-next v3 3/3] page_pool: fix IOMMU crash when driver has already unbound

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <eab44c89-5ada-48b6-b880-65967c0f3b49@huawei.com>
Date: Tue, 12 Nov 2024 20:22:57 +0800
From: Yunsheng Lin <linyunsheng@...wei.com>
To: Toke Høiland-Jørgensen <toke@...hat.com>, Jesper
 Dangaard Brouer <hawk@...nel.org>, <davem@...emloft.net>, <kuba@...nel.org>,
	<pabeni@...hat.com>
CC: <zhangkun09@...wei.com>, <fanghaiqing@...wei.com>,
	<liuyonglong@...wei.com>, Robin Murphy <robin.murphy@....com>, Alexander
 Duyck <alexander.duyck@...il.com>, IOMMU <iommu@...ts.linux.dev>, Andrew
 Morton <akpm@...ux-foundation.org>, Eric Dumazet <edumazet@...gle.com>, Ilias
 Apalodimas <ilias.apalodimas@...aro.org>, <linux-mm@...ck.org>,
	<linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>, kernel-team
	<kernel-team@...udflare.com>
Subject: Re: [PATCH net-next v3 3/3] page_pool: fix IOMMU crash when driver
 has already unbound

On 2024/11/12 2:51, Toke Høiland-Jørgensen wrote:

...

>>
>> Is there any other suggestion/concern about how to fix the problem here?
>>
>> From the previous discussion, it seems the main concern about tracking the
>> inflight pages is about how many inflight pages it is needed.
> 
> Yeah, my hardest objection was against putting a hard limit on the
> number of outstanding pages.
> 
>> If there is no other suggestion/concern , it seems the above concern might be
>> addressed by using pre-allocated memory to satisfy the mostly used case, and
>> use the dynamically allocated memory if/when necessary.
> 
> For this, my biggest concern would be performance.
> 
> In general, doing extra work in rarely used code paths (such as device
> teardown) is much preferred to adding extra tracking in the fast path.
> Which would be an argument for Alexander's suggestion of just scanning
> the entire system page table to find pages to unmap. Don't know enough
> about mm system internals to have an opinion on whether this is
> feasible, though.

Yes, there seems to be many MM system internals, like the CONFIG_SPARSEMEM*
config, memory offline/online and other MM specific optimization that it
is hard to tell it is feasible.

It would be good if MM experts can clarify on this.

> 
> In any case, we'll need some numbers to really judge the overhead in
> practice. So benchmarking would be the logical next step in any case :)

Using POC code show that using the dynamic memory allocation does not
seems to be adding much overhead than the pre-allocated memory allocation
in this patch, the overhead is about 10~20ns, which seems to be similar to
the overhead of added overhead in the patch.

> 
> -Toke
> 
>