Re: [PATCH v4 0/5] implement lightweight guard pages

[Lorenzo Stoakes]

On Wed, Mar 19, 2025 at 03:52:56PM +0100, David Hildenbrand wrote:
> On 19.03.25 15:50, Alexander Mikhalitsyn wrote:
> > On Mon, Oct 28, 2024 at 02:13:26PM +0000, Lorenzo Stoakes wrote:

[snip]


> >
> > Dear Lorenzo,
> > Dear colleagues,
> >
> > sorry about raising an old thread.
> >

No worries!

> > It looks like this feature is now used in glibc [1]. And we noticed failures in CRIU [2]
> > CI on Fedora Rawhide userspace. Now a question is how we can properly detect such
> > "guarded" pages from user space. As I can see from MADV_GUARD_INSTALL implementation,
> > it does not modify VMA flags anyhow, but only page tables. It means that /proc/<pid>/maps
> > and /proc/<pid>/smaps interfaces are useless in this case. (Please, correct me if I'm missing
> > anything here.)

Sorry to hear that.

> >
> > I wonder if you have any ideas / suggestions regarding Checkpoint/Restore here. We (CRIU devs) are happy
> > to develop some patches to bring some uAPI to expose MADV_GUARDs, but before going into this we decided
> > to raise this question in LKML.

There's no need.

>
>
> See [1] and [2]
>
> [1]
> https://lkml.kernel.org/r/cover.1740139449.git.lorenzo.stoakes@xxxxxxxxxx
> [2] https://lwn.net/Articles/1011366/

As per David, there is already a feature heading for 6.15 which will allow
this to be exposed by /proc/$pid/pagemap.

In addition, I plan to add a 'maybe has guard regions' flag that can be
observed in smaps to assist narrowing down which VMAs to check.

However unfortunately due to the nature of the feature there is no getting
around the need to traverse page tables.

That thread (and LWN article :) go into extensive detail as to why. In
essence - it's the basis of its design to express this information at the
page table level only, and any attempt to encode this at the VMA level
(other than a 'maybe' flag) would eliminate the purpose of the feature.

Let me know if there's any way I can help!

Cheers, Lorenzo

>
>
> --
> Cheers,
>
> David / dhildenb
>