[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5fe78422-f348-414c-9ff2-78812ba9a949@suse.cz>
Date: Thu, 20 Feb 2025 10:22:29 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
Kalesh Singh <kaleshsingh@...gle.com>
Cc: David Hildenbrand <david@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Suren Baghdasaryan <surenb@...gle.com>,
"Liam R . Howlett" <Liam.Howlett@...cle.com>,
Matthew Wilcox <willy@...radead.org>, "Paul E . McKenney"
<paulmck@...nel.org>, Jann Horn <jannh@...gle.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, Shuah Khan <shuah@...nel.org>,
linux-kselftest@...r.kernel.org, linux-api@...r.kernel.org,
John Hubbard <jhubbard@...dia.com>, Juan Yescas <jyescas@...gle.com>
Subject: Re: [PATCH 0/4] mm: permit guard regions for file-backed/shmem
mappings
On 2/20/25 09:51, Lorenzo Stoakes wrote:
> On Wed, Feb 19, 2025 at 12:56:31PM -0800, Kalesh Singh wrote:
>
> As I said to you earlier, the _best_ we could do in smaps would be to add a
> flag like 'Grd' or something to indicate some part of the VMA is
In smaps we could say how many kB is covered by guard ptes and it would be
in line with the current output, and the fact it's already scanning page
tables, so virtually no new overhead. But it wouldn't tell you the address
ranges, of course.
> guarded. But I won't do that unless somebody has an -actual use case- for
> it.
Right, we need to hear that first. Also I'm a bit confused about what's the
issue with the existing Android apps and the proposals. Do the existing apps
expect to see particular PROT_NONE regions, which would be gone (become part
of the surrounding vma's) when using guards instead? Then clearly there's no
way to use guards for them without breaking their assumptions.
But assuming future versions of these apps for future android versions would
have to adapt to guards instead of PROT_NONE, why do we have to promise them
to represent the guards, if the point is just so they adapt to the new state
of smaps in their dubious security checking code, and not break anymore?
(but geez, if android apps are to use the android apis, which is java based
(IIRC?) why were there ever allowed to read /proc in the first place? such a
mistake, sigh)
> David's /proc/$pid/pagemaps suggestion is excellent, avoids all the
> pitfalls, exposes guard regions to anybody who really really wants to know
> and doesn't interfere with anything else, so this is what we'll go with.
>
> Regards, Lorenzo
Powered by blists - more mailing lists