[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9c861191-ac9e-4d26-b2a2-1facfa45de44@redhat.com>
Date: Thu, 24 Jul 2025 23:53:52 +0200
From: David Hildenbrand <david@...hat.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
Jeff Xu <jeffxu@...omium.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
"Liam R . Howlett" <Liam.Howlett@...cle.com>,
Vlastimil Babka <vbabka@...e.cz>, Jann Horn <jannh@...gle.com>,
Pedro Falcato <pfalcato@...e.de>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, Kees Cook <kees@...nel.org>,
linux-hardening@...r.kernel.org
Subject: Re: [PATCH v3 2/5] mm/mseal: update madvise() logic
>
>> 4. We could ask applications to switch to non-destructive madvise,
>> like MADV_COLD or MADV_PAGEOUT. Or, another option is that we could
>> switch the kernel to use non-destructive madvise implicitly for
>> destructive madvise in suitable situations.
>
> Umm what? I don't understand your point.
>
>> 5. We could investigate more based on vma->anon_vma
>
> I have no idea what you mean by this. I am an rmap maintainer and have
> worked extensively with anon_vma, what's the point exactly?
I think, the idea would be to add an additional anon_vma check: so if
you have a MAP_PRIVATE file mapping, you could still allow for
MADV_DONTNEED if you are sure that there are no anon folios in there.
If there is an anon_vma, the only way to find out is actually looking at
the page tables.
To be completely precise, one would have to enlighten the zap logic to
refuse to zap if there is any anon folio there, and bail out.
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists