On Tuesday, May 4th, 2021 at 6:08 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Tue, May 4, 2021 at 2:29 AM Simon Ser contact@xxxxxxxxxxx wrote: > > > The remaining 10% is when the compositor needs a writable mapping for > > things like screen capture. It doesn't seem like a SIGBUS handler can > > be avoided in this case then… Oh well. > > So as Peter Xu mentioned, if we made it a "per inode" thing, we > probably could make such an inode do the zero page fill on its own, > and it might be ok for certain cases even for shared mappings. > However, realistically I think it's a horrible idea for the generic > situation, because I think that basically requires the filesystem > itself to buy into it. And we have something like 60+ different > filesystems. > > Is there some very specific and targeted pattern for that "shared > mapping" case? For example, if it's always a shared anonymous mapping > with no filesystem backing, then that would possibly be a simpler case > than the "random arbitrary shared file descriptor". Yes. I don't know of any Wayland client using buffers with real filesystem backing. I think the main cases are: - shm_open(3) immediately followed by shm_unlink(3). On Linux, this is implemented with /dev/shm which is a tmpfs. - Abusing /tmp or /run's tmpfs by creating a file there and unlinking it immediately afterwards. Kind of similar to the first case. - memfd_create(2) on Linux. Is this enough to make it work on shared memory mappings? Is it important that the mapping is anonymous? Thanks, Simon
