Hi Linus, On Sun, Jul 07, 2024 at 11:19:46AM -0700, Linus Torvalds wrote: > (c) we could actually use the PROT_xyz bits, which we have a ton of As I just wrote to David, I'll move this to PROT_xyz. By the way, in addition to the PROT_SEM historical artifact, there's also architecture specific ones like PROT_ADI on SPARC, PROT_SAO on PowerPC, and PROT_BTI and PROT_MTE on arm64. So the MAP_ vs PROT_ distinction seems kind of blurred anyway. > And we actually have had the "get signal on access" before: that's > what VM_DONTCOPY is. > > And it was the *less* useful model, which is why we added > VM_WIPEONCOPY, because that's the semantics people actually wanted. > > So I think the "signal on thrown out data access" is interesting, but > not necessarily the *more* interesting case. FYI, I looked into using VM_DONTCOPY/MADV_DONTFORK for my purposes, because it could possibly make another problem easier, but I couldn't figure out how to make it smoothly work. Specifically, a program has a bunch of threads, and some of them have a vgetrandom state in use, carved out of the same page. One of the threads forks. In the VM_WIPEONFORK case, the fork child has to reclaim the states that were in use by other threads at the time of the fork and return them to the pool of available slices. In the VM_DONTCOPY case, that's not necessary, which is kind of nice. But if the program forked in the signal handler and then returned to an in progress vgetrandom operation, now there's a signal that needs to be handled internally, identified as belonging to the internal state areas, and not bubbled up to other code. This seems difficult and fraught. It's far easier to just have the memory be zeroed and have the code unconditionally check for that at the same time it's doing other consistency checks. So yea it just seems a lot more desirable to have the behavior be zeroing rather than an asynchronous signal, because code can straightforwardly deal with that inline. Jason
