lkml.org 
[lkml]   [2021]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Sealed memfd & no-fault mmap
On Tuesday, May 4th, 2021 at 6:08 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Tue, May 4, 2021 at 2:29 AM Simon Ser contact@emersion.fr 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

\
 
 \ /
  Last update: 2021-05-05 12:22    [W:0.172 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site