On Thu, Dec 14, 2023 at 6:07 PM Stephen Röttger <[email protected]> wrote: > > On Thu, Dec 14, 2023 at 2:31 AM Linus Torvalds > <[email protected]> wrote: > > > > On Wed, 13 Dec 2023 at 16:36, Jeff Xu <[email protected]> wrote: > > > > > > > > > > IOW, when would you *ever* say "seal this area, but MADV_DONTNEED is > > > > ok"? > > > > > > > The MADV_DONTNEED is OK for file-backed mapping. > > > > Right. It makes no semantic difference. So there's no point to it. > > > > My point was that you added this magic flag for "not ok for RO anon > > mapping". > > > > It's such a *completely* random flag, that I go "that's just crazy > > random - make sealing _always_ disallow that case". > > > > So what I object to in this series is basically random small details > > that should just eb part of the basic act of sealing. > > > > I think sealing should just mean "you can't do any operations that > > have semantic meaning for the mapping, because it is SEALED". > > > > So I think sealing should automatically mean "can't do MADV_DONTNEED > > on anon memory", because that's basically equivalent to a munmap/remap > > operation. > > In Chrome, we have a use case to allow MADV_DONTNEED on sealed memory.
I don't want to be that guy (*believe me*), but what if there was a way to attach BPF programs to mm's? Such that you could handle 'seal failures' in BPF, and thus allow for this sort of weird semantics? e.g: madvise(MADV_DONTNEED) on a sealed region fails, kernel invokes the BPF program (that chrome loaded), BPF program sees it was a MADV_DONTNEED and allows it to proceed. It requires BPF but sounds like a good compromise in order to not get an ugly API? -- Pedro
