Message-ID: <6e356431-5ac9-4363-b876-78a69ae7622a@lucifer.local>
Date: Thu, 20 Feb 2025 08:51:19 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: 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>, Vlastimil Babka <vbabka@...e.cz>,
        "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 Wed, Feb 19, 2025 at 12:56:31PM -0800, Kalesh Singh wrote:
> > We also can't change smaps in the way you want, it _has_ to still give
> > output per VMA information.
>
> Sorry I wasn't suggesting to change the entries in smaps, rather
> agreeing to your marker suggestion. Maybe a set of ranges for each
> smaps entry that has guards? It doesn't solve the use case, but does
> make these regions visible to userspace.

No, you are not providing a usecase for this. /proc/$pid/pagemaps does not
contaminate the smaps output, mess with efforts to make it RCU readable,
require updating the ioctl interface, etc. so it is clearly the better
choice.

>
> >
> > The proposed change that would be there would be a flag or something
> > indicating that the VMA has guard regions _SOMEWHERE_ in it.
> >
> > Since this doesn't solve your problem, adds complexity, and nobody else
> > seems to need it, I would suggest this is not worthwhile and I'd rather not
> > do this.
> >
> > Therefore for your needs there are literally only two choices here:
> >
> > 1. Add a bit to /proc/$pid/pagemap OR
> > 2. a new interface.
> >
> > I am not in favour of a new interface here, if we can just extend pagemap.
> >
> > What you'd have to do is:
> >
> > 1. Find virtual ranges via /proc/$pid/maps
> > 2. iterate through /proc/$pid/pagemaps to retrieve state for all ranges.
> >
>
> Could we also consider an smaps field like:
>
> VmGuards: [AAA, BBB), [CCC, DDD), ...
>
> or something of that sort?

No, absolutely, categorically not. You realise these could be thousands of
characters long right?

/proc/$pid/pagemaps resolves this without contaminating this output.

> > Well I'm glad that you guys find it useful for _something_ ;)
> >
> > Again this wasn't written only for you (it is broadly a good feature for
> > upstream), but I did have your use case in mind, so I'm a little
> > disappointed that it doesn't help, as I like to solve problems.
> >
> > But I'm glad it solves at least some for you...
>
> I recall Liam had a proposal to store the guard ranges in the maple tree?
>
> I wonder if that can be used in combination with this approach to have
> a better representation of this?

This was an alternative proposal made prior to the feature being
implemented (and you and others at Google were welcome to comment and many
were cc'd, etc.).

There is no 'in combination with'. This feature would take weeks/months to
implement, fundamentally impact the maple tree VMA implementation
and... not actually achieve anything + immediately be redundant.

Plus it'd likely be slower, have locking implications, would have kernel
memory allocation implications, a lot more complexity and probably other
problems besides (we discussed this at length at the time and a number of
issues came up, I can't recall all of them).

To be crystal clear - we are empathically NOT changing /proc/$pid/maps to
lie about VMAs regardless of underlying implementation, nor adding
thousands of characters to /proc/$pid/smaps entries.

This is independent of implementation and would have been the case had we
gone with a maple node version.

So in no world is your problem solved here, unfortunately you have
inextricably tied yourself to a VMA representation here.

I still wonder if you could find some means of abstracting this, but
/proc/$pid/pagemaps is where I am likely to expose this information for
anybody who needs it, and will likely send a series for this relatively
soon.

If you _can_ abstract this in some way, then if we provide this information
_anywhere_ you can get it.

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
guarded. But I won't do that unless somebody has an -actual use case- for
it.

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