Re: [PATCH v1 1/2] mseal: Two fixes for madvise(MADV_DONTNEED) when sealed
From: Pedro Falcato
Date: Thu Oct 17 2024 - 15:38:01 EST
On Thu, Oct 17, 2024 at 12:51:04AM +0000, jeffxu@xxxxxxxxxxxx wrote:
> From: Jeff Xu <jeffxu@xxxxxxxxxxxx>
>
> Two fixes for madvise(MADV_DONTNEED) when sealed.
>
Please separate these fixes into two separate patches.
> For PROT_NONE mappings, the previous blocking of
> madvise(MADV_DONTNEED) is unnecessary. As PROT_NONE already prohibits
> memory access, madvise(MADV_DONTNEED) should be allowed to proceed in
> order to free the page.
I don't get it. Is there an actual use case for this?
> For file-backed, private, read-only memory mappings, we previously did
> not block the madvise(MADV_DONTNEED). This was based on
> the assumption that the memory's content, being file-backed, could be
> retrieved from the file if accessed again. However, this assumption
> failed to consider scenarios where a mapping is initially created as
> read-write, modified, and subsequently changed to read-only. The newly
> introduced VM_WASWRITE flag addresses this oversight.
We *do not* need this. It's sufficient to just block discard operations on read-only
private mappings. Sending a possible (fully untested) fix. If you like this approach
I can resend properly, or Andrew can pick it up, whatever floats people's boats.
----8<----