Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 05 May 2021 10:21:16 +0000
To:     Linus Torvalds <torvalds@linux-foundation.org>
From:   Simon Ser <contact@emersion.fr>
Cc:     Peter Xu <peterx@redhat.com>,
        "Kirill A. Shutemov" <kirill@shutemov.name>,
        Matthew Wilcox <willy@infradead.org>,
        Dan Williams <dan.j.williams@intel.com>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Will Deacon <will@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        David Herrmann <dh.herrmann@gmail.com>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        Greg Kroah-Hartman <greg@kroah.com>,
        "tytso@mit.edu" <tytso@mit.edu>
Reply-To: Simon Ser <contact@emersion.fr>
Subject: Re: Sealed memfd & no-fault mmap
Message-ID: <hnL7s1u925fpeUhs90fXUpD3GG_4gmHlpznN8E0885tSM40QYb3VVTFGkwpmxYQ3U8HkRSUtfqw0ZfBKptA4pIw4FZw1MdRhSHC94iQATEE=@emersion.fr>
In-Reply-To: <CAHk-=wiAs7Ky9gmWAeqk5t7Nkueip13XPGtUcmMiZjwf-sX3sQ@mail.gmail.com>
References: <vs1Us2sm4qmfvLOqNat0-r16GyfmWzqUzQ4KHbXJwEcjhzeoQ4sBTxx7QXDG9B6zk5AeT7FsNb3CSr94LaKy6Novh1fbbw8D_BBxYsbPLms=@emersion.fr> <CAHk-=wgmGv2EGscKSi8SrQWtEVpEQyk-ZN1Xj4EoAB87Dmx1gA@mail.gmail.com> <20210429154807.hptls4vnmq2svuea@box> <20210429183836.GF8339@xz-x1> <lpi4uT69AFMwtmWtwW_qJAmYm_r0jRikL11G_zI4X7wq--6Jtpiej8kGn8gePfv0Dtn4VmzsOqT2Q5-L3ca2niDi0nlC0nVYphbFBnNJnw0=@emersion.fr> <CAHk-=wiAs7Ky9gmWAeqk5t7Nkueip13XPGtUcmMiZjwf-sX3sQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tuesday, May 4th, 2021 at 6:08 PM, Linus Torvalds <torvalds@linux-founda=
tion.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=E2=80=A6 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