From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B5AF3C47096 for ; Thu, 3 Jun 2021 13:01:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5E43E613F4 for ; Thu, 3 Jun 2021 13:01:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5E43E613F4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=emersion.fr Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D53016B00A8; Thu, 3 Jun 2021 09:01:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D03806B00A9; Thu, 3 Jun 2021 09:01:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA35E6B00AA; Thu, 3 Jun 2021 09:01:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0154.hostedemail.com [216.40.44.154]) by kanga.kvack.org (Postfix) with ESMTP id 88DB86B00A8 for ; Thu, 3 Jun 2021 09:01:14 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 2DC598287E10 for ; Thu, 3 Jun 2021 13:01:14 +0000 (UTC) X-FDA: 78212423268.10.CAD62D4 Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) by imf24.hostedemail.com (Postfix) with ESMTP id 725D9A000257 for ; Thu, 3 Jun 2021 13:00:59 +0000 (UTC) Date: Thu, 03 Jun 2021 13:01:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emersion.fr; s=protonmail3; t=1622725266; bh=g5sGIL5X/dIixwzZThRSrnzhyX4qPO3WP6FfFa5urDI=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=U+ebCt29XcCUOVQmAKecrKW5cJJH1m2/GrTsXodWhZ8hC3qxWTFmMYm0caVgO0YZF F5Rbv7z64pujOuEjj3FrpFU4uWGpD14HSYAI/pcPh31T50n5zlVURdOiX/A0h43wKS aEvw0cJbgxLFMhLvSZsFufN1qgvWeJZ8Atj7rpSXLarXql90AjGGHezF3XdfJ4ds/0 IEvHCtyDqJwRzqoWFeOYJXTIjDSnvFIJK8bGjRvslX9TLWkLEg+coa5mgB38iJq34A eaZ1pqtkJuTqRQ1mAm2zwaaBGGLYLWqdzNhOUs5mo2DG3wti30tSZml7knY9ZRFNHO cvkAEZj2rFtiw== To: Ming Lin From: Simon Ser Cc: Linus Torvalds , Hugh Dickins , Peter Xu , "Kirill A. Shutemov" , Matthew Wilcox , Dan Williams , "Kirill A. Shutemov" , Will Deacon , Linux Kernel Mailing List , David Herrmann , "linux-mm@kvack.org" , Greg Kroah-Hartman , "tytso@mit.edu" Reply-To: Simon Ser Subject: Re: Sealed memfd & no-fault mmap Message-ID: <8By7yERxX_qlsLZuOeJihJqeU-pZtFxsS2zrQ1ssN6-NkyIRrv-r81Ux_PTcb8qy7QA1HmkRxTeixT5MaJs7NKk0rqxDC9Nu9DoTRmS0UHw=@emersion.fr> In-Reply-To: <0464f8dd-d082-b246-83ff-609f0f48de59@gmail.com> References: <80c87e6b-6050-bf23-2185-ded408df4d0f@gmail.com> <36fc2485-11f1-5252-904d-f26b63a6cd58@gmail.com> <0464f8dd-d082-b246-83ff-609f0f48de59@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=emersion.fr header.s=protonmail3 header.b=U+ebCt29; dmarc=pass (policy=none) header.from=emersion.fr; spf=pass (imf24.hostedemail.com: domain of contact@emersion.fr designates 185.70.40.22 as permitted sender) smtp.mailfrom=contact@emersion.fr X-Stat-Signature: byr8qo1we8zx49e9afwt3ufe4ksxpjrr X-Rspamd-Queue-Id: 725D9A000257 X-Rspamd-Server: rspam02 X-HE-Tag: 1622725259-115604 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tuesday, June 1st, 2021 at 9:08 AM, Ming Lin wrote: > On 5/31/2021 11:24 PM, Linus Torvalds wrote: > > On Mon, May 31, 2021 at 11:13 AM Ming Lin wrote: > >> > >> OK, I borrowed code from filemap_xip.c and implemented this behavior. > > > > I think that "unmap page" is too complicated and fragile. > > > > The only page that could possibly validly be unmapped is a stale zero > > page, but that code in shmem_unmap_nofault_page() seems to try to > > handle other cases too (ie that whole page_remove_rmap() - afaik a > > zero page has no rmap). > > > > I get the feeling that the simpler thing to do is to just say "if you > > use MAP_NOSIGBUS, and you access pages that don't have a backing > > store, you will get zero pages, and they will NOT BE SYNCHRONIZED with > > the backing store possibly later being updated". > > > > IOW, just document the fact that a MAP_NOSIGBUS mapping isn't coherent > > wrt shmem contents that are expanded and filled in later. > > > > Don't try to "fix" it - because any user that uses MAP_NOSIGBUS had > > better just accept that it's not compatible with expanding the shmem > > backing store later. > > > > Keep it simple and stupid. Hmm? > > Simon, > > Is this "simple" solution good enough for Wayland compositor use case? I've tried your patch "mm: adds MAP_NOSIGBUS extension for shmem read" with= a libwayland hack [1] and a Wayland client that shrinks a shm file after the compositor has mmap'ed it [2]. It seems to work nicely, thanks! Regarding the requirements for Wayland: - The baseline requirement is being able to avoid SIGBUS for read-only mapp= ings of shm files. - Wayland clients can expand their shm files. However the compositor doesn'= t need to immediately access the new expanded region. The client will tell = the compositor what the new shm file size is, and the compositor will re-map = it. - Ideally, MAP_NOSIGBUS would work on PROT_WRITE + MAP_SHARED mappings (of course, the no-SIGBUS behavior would be restricted to that mapping). The use-case is writing back to client buffers e.g. for screen capture. From = the earlier discussions it seems like this would be complicated to implement. This means we'll need to come up with a new libwayland API to allow compositors to opt-in to the read-only mappings. This is sub-optimal but seems doable. - Ideally, MAP_SIGBUS wouldn't be restricted to shm. There are use-cases fo= r using it on ordinary files too, e.g. for sharing ICC profiles. But from t= he earlier replies it seems very unlikely that this will become possible, an= d making it work only on shm files would already be fantastic. Thanks again for working on this! Let me know if the above is unclear or if some info is missing. Simon [1]: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/145 [2]: https://github.com/emersion/wleird/blob/master/sigbus.c