On Thu, Dec 14, 2023 at 6:07 PM Stephen Röttger <sroettger@xxxxxxxxxx> wrote: > > On Thu, Dec 14, 2023 at 2:31 AM Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > On Wed, 13 Dec 2023 at 16:36, Jeff Xu <jeffxu@xxxxxxxxxx> 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
