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: <40c9b515-1284-4c49-bdce-c9eeff5092f9@huawei.com>
Date: Mon, 18 Nov 2024 17:08:25 +0800
From: Yunsheng Lin <linyunsheng@...wei.com>
To: Jesper Dangaard Brouer <hawk@...nel.org>,
	Toke Høiland-Jørgensen <toke@...hat.com>,
	<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 22:19, Jesper Dangaard Brouer wrote:
>>
>> 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.
>>
> 
> Yes, please.  Can Alex Duyck or MM-experts point me at some code walking
> entire system page table?
> 
> Then I'll write some kernel code (maybe module) that I can benchmark how
> long it takes on my machine with 384GiB. I do like Alex'es suggestion,
> but I want to assess the overhead of doing this on modern hardware.
> 

After looking more closely into MM subsystem, it seems there is some existing
pattern or API to walk the entire pages from the buddy allocator subsystem,
see the kmemleak_scan() in mm/kmemleak.c:
https://elixir.bootlin.com/linux/v6.12/source/mm/kmemleak.c#L1680

I used that to walk the pages in a arm64 system with over 300GB memory,
it took about 1.3 sec to do the walking, which seems acceptable?