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=-3.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 93FC7C433ED for ; Thu, 29 Apr 2021 15:48:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0034C61446 for ; Thu, 29 Apr 2021 15:48:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0034C61446 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 659546B006C; Thu, 29 Apr 2021 11:48:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 60A436B006E; Thu, 29 Apr 2021 11:48:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 484796B0070; Thu, 29 Apr 2021 11:48:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0068.hostedemail.com [216.40.44.68]) by kanga.kvack.org (Postfix) with ESMTP id 2638F6B006C for ; Thu, 29 Apr 2021 11:48:10 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id D8E358249980 for ; Thu, 29 Apr 2021 15:48:09 +0000 (UTC) X-FDA: 78085835898.05.B6CCBE1 Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by imf27.hostedemail.com (Postfix) with ESMTP id A734780192EA for ; Thu, 29 Apr 2021 15:47:45 +0000 (UTC) Received: by mail-lf1-f43.google.com with SMTP id z13so24572557lft.1 for ; Thu, 29 Apr 2021 08:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=3NyxbJCwhqb1aqLdIOSz5lukrN8T+dDDlsyMoLY0gW4=; b=cbYC8SxTjuN7PL/HHpWnlrg/QN1hbVMX8F6WKSRM2DjP4eDx+2x+t4E0/GMgzTxeUO 8IZnyKtuvzyQ3D8CHxgPBCUcbxohWBWSZeMojKYswbWhlX3U9Q7Th0J/+IhWbre9r0Eb 5cKkEh5sjhR2Us2DIWa/9crBm8yfFuMvC1foJOzjGZQrUSCMc4K4SAcEAyLTokeM1vWn PILewUSWyy4LQur7FqhLQWHTyKwEPBcJDwFFE4IoDouS9bHTEzFU4Ch1b6fDojeAV6on 6mS/xGS/4MMurv31BIf6i016OPdTJjBIyh9tq7CKBVCAiaEeLWvq8GgyjFLUMkr5oOaJ o4FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=3NyxbJCwhqb1aqLdIOSz5lukrN8T+dDDlsyMoLY0gW4=; b=av0AkGus6tAwdKgRzSt02c+0R/HdqhUDl9hnf9qIc8ncKQ4EIlBG+jeBTwXHPgw+sw jnx/NQoVFv90dIJwdyygVLYpQ/poMHvrFHDKLr7XSA9YFF56GR28tMSCqCwdw42M1es0 UBhN9Co+JKhCHXuRGL/SHJJ2lkW+uz7exQPPPVB66ppQz74CamizlW3m6rGb/6VVIDY6 XXXMCz9uT+ScZZDwP0jsyg0S5DdCox+cp66AohRGM72zImnbKNt1g2CJvQ1fzHBkREqx HLl0XnXIuNRY8WnC61xFrctS0kpMlJeqZBCzM9d+UuOJEQQSfW8rGaKKsBImLQ1t7g58 pZRg== X-Gm-Message-State: AOAM533LkcskdhiHehSOr4C/8UAXap41pg5fUGc1dGhzJRejo2UVb+Kt yZxoMeJVLNlYKaDJvxdvxMg/HaBcMrXszA== X-Google-Smtp-Source: ABdhPJxG/sG67SG3OP0g0HlxPZkucJvHMsVb7rMJuwC8Q4cClb/EyKqoa1z0wyOYJzSIY4vZ+1XSmQ== X-Received: by 2002:ac2:5f6a:: with SMTP id c10mr159706lfc.286.1619711287786; Thu, 29 Apr 2021 08:48:07 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id j8sm13949lfg.250.2021.04.29.08.48.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Apr 2021 08:48:06 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id 29D45101C51; Thu, 29 Apr 2021 18:48:07 +0300 (+03) Date: Thu, 29 Apr 2021 18:48:07 +0300 From: "Kirill A. Shutemov" To: Linus Torvalds , Matthew Wilcox , Dan Williams Cc: Simon Ser , "Kirill A. Shutemov" , Peter Xu , Will Deacon , Linux Kernel Mailing List , David Herrmann , "linux-mm@kvack.org" , Greg Kroah-Hartman , "tytso@mit.edu" Subject: Re: Sealed memfd & no-fault mmap Message-ID: <20210429154807.hptls4vnmq2svuea@box> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: A734780192EA X-Stat-Signature: cd4n39ah6n9br5cbekb5e67skk3nsq9d Received-SPF: none (shutemov.name>: No applicable sender policy available) receiver=imf27; identity=mailfrom; envelope-from=""; helo=mail-lf1-f43.google.com; client-ip=209.85.167.43 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619711265-253448 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 Tue, Apr 27, 2021 at 09:51:58AM -0700, Linus Torvalds wrote: > On Tue, Apr 27, 2021 at 1:25 AM Simon Ser wrote: > > > > Rather than requiring changes in all compositors *and* clients, can we > > maybe only require changes in compositors? For instance, OpenBSD has a > > __MAP_NOFAULT flag. When passed to mmap, it means that out-of-bound > > accesses will read as zeroes instead of triggering SIGBUS. Such a flag > > would be very helpful to unblock the annoying SIGBUS situation. > > > > Would something among these lines be welcome in the Linux kernel? > > 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. > > NOTE! Not only is it untested, not only is this a "for your testing > only" (because it does it unconditionally rather than only for > __MAP_NOFAULT), but it might be bogus for other reasons. In > particular, this patch depends on "vmf->address" not being changed by > the ->fault() infrastructure, so that we can just re-use the vmf for > the anonymous case if we get a SIGBUS. > > I think that's all ok these days, because Kirill and Peter Xu cleaned > up those paths, but I didn't actually check. So I'm cc'ing Kirill, > Peter and Will, who have been working in this area for other reasons > fairly recently. > > Side note: this will only ever work for non-shared mappings. I think it's show-stopper for the use-case, no? IIUC, the mappings is used for communication between a compositor and a client and has to be shared. > 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". + Matthew, Dan. DAX uses zero pages in page cache to avoid allocating backing storage read accesses to holes. Maybe we can generalize it beyond DAX to any page cache and add a (per-inode?) flag to do the same for accesses beyond i_size? > 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. > > 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. > > Linus -- Kirill A. Shutemov