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: <7f49ac72-1868-4dcf-b73d-343c0d523a11@redhat.com>
Date: Wed, 23 Oct 2024 15:28:49 +0200
From: David Hildenbrand <david@...hat.com>
To: "Kirill A. Shutemov" <kirill@...temov.name>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 cgroups@...r.kernel.org, x86@...nel.org, linux-fsdevel@...r.kernel.org,
 Andrew Morton <akpm@...ux-foundation.org>,
 "Matthew Wilcox (Oracle)" <willy@...radead.org>, Tejun Heo <tj@...nel.org>,
 Zefan Li <lizefan.x@...edance.com>, Johannes Weiner <hannes@...xchg.org>,
 Michal Koutný <mkoutny@...e.com>,
 Jonathan Corbet <corbet@....net>, Andy Lutomirski <luto@...nel.org>,
 Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH v1 08/17] mm/rmap: initial MM owner tracking for large
 folios (!hugetlb)

On 23.10.24 15:08, Kirill A. Shutemov wrote:
> On Thu, Aug 29, 2024 at 06:56:11PM +0200, David Hildenbrand wrote:
>> +#ifdef CONFIG_MM_ID
>> +/*
>> + * For init_mm and friends, we don't allocate an ID and use the dummy value
>> + * instead. Limit ourselves to 1M MMs for now: even though we might support
>> + * up to 4M PIDs, having more than 1M MM instances is highly unlikely.
>> + */
> 
> Hm. Should we lower PID_MAX_LIMIT limit then?

Note that each thread gets a PID, but all threads share a MM struct. 
Also we are concerned about PID reuse, but not for MM IDs.

So I don't think we should be touching PID_MAX_LIMIT.

> 
> Also, do we really need IDA? Can't we derive the ID from mm_struct
> address?

Yes, that's the whole purpose of it. We need something < 30bit to save 
space in struct page.

The description touches on that:

"As we have to squeeze this information into the "struct folio" of even
folios of order-1 (2 pages), and we generally want to reduce the 
required metadata, we'll assign each MM a unique ID that consumes less 
than 32 bit. We'll limit the IDs to 20bit / 1M for now: we could allow 
for up to 30bit, but getting even 1M IDs is unlikely in practice. If 
required, we could raise the limit later, and the 1M limit might come in 
handy in the future with other tracking approaches."

-- 
Cheers,

David / dhildenb


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ