linux-kernel - Re: [PATCH v2 1/3] mm: fixup pfnmap memory failure handling to use pgoff

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] [day] [month] [year] [list]

Message-ID: <f83bf67a-166e-f224-8b5c-821d8314ca0c@huawei.com>
Date: Thu, 18 Dec 2025 10:18:05 +0800
From: Miaohe Lin <linmiaohe@...wei.com>
To: Ankit Agrawal <ankita@...dia.com>
CC: Neo Jia <cjia@...dia.com>, Zhi Wang <zhiw@...dia.com>, Krishnakant Jaju
	<kjaju@...dia.com>, Yishai Hadas <yishaih@...dia.com>, "kevin.tian@...el.com"
	<kevin.tian@...el.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>, Vikram Sethi <vsethi@...dia.com>,
	Jason Gunthorpe <jgg@...dia.com>, Matt Ochs <mochs@...dia.com>,
	"jgg@...pe.ca" <jgg@...pe.ca>, Shameer Kolothum <skolothumtho@...dia.com>,
	"alex@...zbot.org" <alex@...zbot.org>, "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>, "nao.horiguchi@...il.com"
	<nao.horiguchi@...il.com>
Subject: Re: [PATCH v2 1/3] mm: fixup pfnmap memory failure handling to use
 pgoff

On 2025/12/18 2:10, Ankit Agrawal wrote:
>>>        i_mmap_lock_read(mapping);
>>>        rcu_read_lock();
>>> @@ -2226,9 +2230,12 @@ static void collect_procs_pfn(struct address_space *mapping,
>>>                t = task_early_kill(tsk, true);
>>>                if (!t)
>>>                        continue;
>>> -             vma_interval_tree_foreach(vma, &mapping->i_mmap, pfn, pfn) {
>>> -                     if (vma->vm_mm == t->mm)
>>> -                             add_to_kill_pfn(t, vma, to_kill, pfn);
>>> +             vma_interval_tree_foreach(vma, &mapping->i_mmap, 0, ULONG_MAX) {
>>> +                     pgoff_t pgoff;
>>
>> IIUC, all vma will be traversed to find the final pgoff. This might not be a good idea
>> because rcu lock is held and this traversal might take a really long time. Or am I miss
>> something?
> 
> Hi Miaohe, the VMAs on the registered address space will be checked. For the nvgrace-gpu
> user of this API in 3/3, there are only 3 VMAs on the registered address space (that are
> associated with the vfio file).

Oh, I see. Thanks for your explanation. :)