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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 57734C433B4 for ; Tue, 4 May 2021 09:30:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7B4FD613BC for ; Tue, 4 May 2021 09:30:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7B4FD613BC 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 C63A16B0036; Tue, 4 May 2021 05:30:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BEC466B006E; Tue, 4 May 2021 05:30:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A8C366B0070; Tue, 4 May 2021 05:30:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0218.hostedemail.com [216.40.44.218]) by kanga.kvack.org (Postfix) with ESMTP id 895606B0036 for ; Tue, 4 May 2021 05:30:00 -0400 (EDT) Received: from smtpin37.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 352E1181AF5C1 for ; Tue, 4 May 2021 09:30:00 +0000 (UTC) X-FDA: 78103026960.37.EA85BFA Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) by imf24.hostedemail.com (Postfix) with ESMTP id CA843A0002C7 for ; Tue, 4 May 2021 09:29:46 +0000 (UTC) Date: Tue, 04 May 2021 09:29:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emersion.fr; s=protonmail3; t=1620120596; bh=8iedi1sBuOfuU+AkuHmOzKPH2PiTW40aDNApIMiPXLA=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=tAiyHvRC8v8kPq68agftdrYPHDxDVNL7m4bPC7JlHMKGC8VOcVvgzDhHnEDilDOGQ wOIzmq7e59KCBq+O2mcWmQFdfko89fvthHPX8BlVJ3K8UjGHpp9677/lZd3+DwWihW ySBr9RH/6OcaFlob4DSW6VB8XvCWxfg293MAPBBuGJb7Cs6nrBOwhPSWSRA7KkHG4U jXzhFWc5FZPlbg6BO45/YgDUuz1rBG0R+5QCmR32EkJ/oyf6b2iufODTMdQBuK8dSf rZuFyvoMjozWTMPVbOaHnEWcS/JsbAvEgy1IlsalVXfKuU7RNelAkP0cJ26qji1ibV MwepNZanJfCpg== To: Peter Xu From: Simon Ser Cc: "Kirill A. Shutemov" , Linus Torvalds , 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: In-Reply-To: <20210429183836.GF8339@xz-x1> References: <20210429154807.hptls4vnmq2svuea@box> <20210429183836.GF8339@xz-x1> 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=tAiyHvRC; spf=pass (imf24.hostedemail.com: domain of contact@emersion.fr designates 185.70.40.136 as permitted sender) smtp.mailfrom=contact@emersion.fr; dmarc=pass (policy=none) header.from=emersion.fr X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: CA843A0002C7 X-Stat-Signature: prgykiqkozqkodewk8t36magy85bphbi Received-SPF: none (emersion.fr>: No applicable sender policy available) receiver=imf24; identity=mailfrom; envelope-from=""; helo=mail-40136.protonmail.ch; client-ip=185.70.40.136 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620120586-557747 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, April 27th, 2021 at 6:51 PM, Linus Torvalds wrote: > Hmm. It doesn't look too hard to do. The biggest problem is actually > that we've run out of flags in the vma (on 32-bit architectures), but > you could try this UNTESTED patch that just does the MAP_NOFAULT thing > unconditionally. Oh, thanks for the patch! Will test. > Side note: this will only ever work for non-shared mappings. That's > fundamental. We won't add an anonymous page to a shared mapping, and > do_anonymous_page() does verify that. So a MAP_SHARED mappign will > still return SIGBUS even with this patch (although it's not obvious > from the patch - the VM_FAULT_SIGBUS will just be re-created by > do_anonymous_page()). > > So if you want a _shared_ mapping to honor __MAP_NOFAULT and insert > random anonymous pages into it, I think the answer is "no, that's not > going to be viable". > > So _if_ this works for you, and if it's ok that only MAP_PRIVATE can > have __MAP_NOFAULT, and if Kirill/Peter/Will don't say "Oh, Linus, > you're completely off your rocker and clearly need to be taking your > meds", something like this - if we figure out the conditional bit - > might be doable. Hm, that's unfortunate. For the use-case of a Wayland compositor this doesn't seem like a complete show-stopper: in 90% of cases the compositor only needs a read-only mapping. Wayland clients submit buffers they're rendered pixels to, compositors only need to read them. So the compositor could map with MAP_PRIVATE and still get up-to-date pages from a client process I think. 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. > That's a fair number of "ifs". > > Ok, back to the merge window for me, I'll be throwing away this crazy > untested patch immediately after hitting "send". This is very much a > "throw the idea over to other people" patch, in other words. Got it. I'll take over the patch if this is a good way forward.