linux-kernel - Re: [PATCH v3 22/22] mm/mshare: charge fault handling allocations to the mshare owner

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: <fbbd4b7d-1614-4d6f-9f7c-2821f35404ae@redhat.com>
Date: Mon, 8 Sep 2025 22:28:29 +0200
From: David Hildenbrand <david@...hat.com>
To: Anthony Yznaga <anthony.yznaga@...cle.com>, linux-mm@...ck.org
Cc: akpm@...ux-foundation.org, andreyknvl@...il.com, arnd@...db.de,
 bp@...en8.de, brauner@...nel.org, bsegall@...gle.com, corbet@....net,
 dave.hansen@...ux.intel.com, dietmar.eggemann@....com,
 ebiederm@...ssion.com, hpa@...or.com, jakub.wartak@...lbox.org,
 jannh@...gle.com, juri.lelli@...hat.com, khalid@...nel.org,
 liam.howlett@...cle.com, linyongting@...edance.com,
 lorenzo.stoakes@...cle.com, luto@...nel.org, markhemm@...glemail.com,
 maz@...nel.org, mhiramat@...nel.org, mgorman@...e.de, mhocko@...e.com,
 mingo@...hat.com, muchun.song@...ux.dev, neilb@...e.de, osalvador@...e.de,
 pcc@...gle.com, peterz@...radead.org, pfalcato@...e.de, rostedt@...dmis.org,
 rppt@...nel.org, shakeel.butt@...ux.dev, surenb@...gle.com,
 tglx@...utronix.de, vasily.averin@...ux.dev, vbabka@...e.cz,
 vincent.guittot@...aro.org, viro@...iv.linux.org.uk, vschneid@...hat.com,
 willy@...radead.org, x86@...nel.org, xhao@...ux.alibaba.com,
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arch@...r.kernel.org
Subject: Re: [PATCH v3 22/22] mm/mshare: charge fault handling allocations to
 the mshare owner

On 08.09.25 21:21, Anthony Yznaga wrote:
> 
> 
> On 9/8/25 11:50 AM, David Hildenbrand wrote:
>> On 20.08.25 03:04, Anthony Yznaga wrote:
>>> When handling a fault in an mshare range, redirect charges for page
>>> tables and other allocations to the mshare owner rather than the
>>> current task.
>>>
>>
>> That looks rather weird. I would have thought there would be an easy way
>> to query the mshare owner for a given mshare mapping, and if the current
>> MM corresponds to that owner you know that you are running in the owner
>> context.
>>
>> Of course, we could have a helper like is_mshare_owner(mapping, current)
>> or sth like that.
>>
> 
> I'm not quite following you. Charges for newly faulted pages will be
> automatically directed to the mshare owner because the mshare mm will
> have its mm_owner field pointing to the owner. On the other hand,
> allocations for page table pages are handled differently.
> GFP_PGTABLE_USER causes the accounting to go through
> __memcg_kmem_charge_page() which will charge them to the memcg for the
> current task unless unless current->active_memcg is set to point to
> another memcg.

As a note, I think at some point we discussed re-routing page faults to 
the owner, so the owner can take care of all of that naturally. Is that 
what's happening here?


So, are we running into that code that we have current be another MM 
than vma->vm_mm?

Reminds me of: FOLL_REMOTE->FAULT_FLAG_REMOTE. But I guess, we don't 
take care of different accounting in that case.

Anyhow, what I meant is that you could just check whether you have a 
mshare VMA, and if so check if current is different to the mshare MM 
owner. So I don't immediately see why MMF_MSHARE is required.

-- 
Cheers

David / dhildenb