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,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 5092DC433ED for ; Wed, 5 May 2021 18:42:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AA6776105A for ; Wed, 5 May 2021 18:42:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AA6776105A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 362BE6B006E; Wed, 5 May 2021 14:42:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3000D6B0073; Wed, 5 May 2021 14:42:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 17BCF6B0074; Wed, 5 May 2021 14:42:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0211.hostedemail.com [216.40.44.211]) by kanga.kvack.org (Postfix) with ESMTP id F1E386B006E for ; Wed, 5 May 2021 14:42:38 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id A8A4A181AEF0B for ; Wed, 5 May 2021 18:42:38 +0000 (UTC) X-FDA: 78108048396.05.2D37D21 Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by imf17.hostedemail.com (Postfix) with ESMTP id A359940002FC for ; Wed, 5 May 2021 18:42:33 +0000 (UTC) Received: by mail-lf1-f54.google.com with SMTP id z9so3999649lfu.8 for ; Wed, 05 May 2021 11:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZtVgorg1zZS8VLz6ZkmKBwpxdrKeM7t+NX3g8df9hyo=; b=fi/t3BnthT3poNXreQ6uLoaV03s0lm1WWZczRRqTuTs3qxP9jJknjHU5ah47WMVazy MN9JWJuif6XkC1SfR6fZSi7FSYJLDZq9P3hTTF9ZtARuYc5NrhmjVxCzcdP5g8CpAXNN QhkKSS62haSnoPmNyChnQ6bDHRBGTumBek7TE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZtVgorg1zZS8VLz6ZkmKBwpxdrKeM7t+NX3g8df9hyo=; b=HBCD4zUfVcSSO/9LNYmsbhrw7CFhszHCFVpxtbEIIEs+Yyjti1bVG9b/zQtmY5G4yY lj+yra9Sq+e1QD4/LYqJEUg5K65w5fHnS2GaQLnGUn3f3cPfr/vAsco2XI9F2Br0f8uJ v5h2CDeObGyPmDELckBr0xRwj5yxK93CWbdZTYW+8UOj/G7iaMEoJ+ufRVZel+l6Jrp1 vkKKDFInlULGk3Hi8+Glpk4EOnCOTs3tELLGfgw9gu4AIIza68raZb02wsGBm+qCwE3S odC+XDRMtn7zG1rkKhz2ufOJyaD+6L1sd54NcL2L9K7dD8hjj0lCIkbWUVuh8i5BiolX TX1g== X-Gm-Message-State: AOAM5303oOqVf7o/U1/tGwtkA1DF446LVJ7cDCofHq9SKY0OG6K5YIU7 yfo7uMhFUC5GLrXEV/rpKcoj7JXM52QpS/PbFhY= X-Google-Smtp-Source: ABdhPJydCiC+nHslQvByaBmH+u0iMRmUC3jizJ3srHxiE7dMOTn86sGjw5sBWanhvhdZwqiQflWA4w== X-Received: by 2002:ac2:52b7:: with SMTP id r23mr139822lfm.451.1620240156418; Wed, 05 May 2021 11:42:36 -0700 (PDT) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com. [209.85.208.178]) by smtp.gmail.com with ESMTPSA id m11sm8326ljp.36.2021.05.05.11.42.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 May 2021 11:42:34 -0700 (PDT) Received: by mail-lj1-f178.google.com with SMTP id v6so3787093ljj.5 for ; Wed, 05 May 2021 11:42:33 -0700 (PDT) X-Received: by 2002:a05:651c:3de:: with SMTP id f30mr161074ljp.251.1620240153569; Wed, 05 May 2021 11:42:33 -0700 (PDT) MIME-Version: 1.0 References: <20210429154807.hptls4vnmq2svuea@box> <20210429183836.GF8339@xz-x1> In-Reply-To: From: Linus Torvalds Date: Wed, 5 May 2021 11:42:17 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Sealed memfd & no-fault mmap To: Simon Ser Cc: 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" Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b="fi/t3Bnt"; dmarc=none; spf=pass (imf17.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.54 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org X-Stat-Signature: fpj7dqo36kfrt96etmimtq51ryixbqa7 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: A359940002FC Received-SPF: none (linuxfoundation.org>: No applicable sender policy available) receiver=imf17; identity=mailfrom; envelope-from=""; helo=mail-lf1-f54.google.com; client-ip=209.85.167.54 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620240153-71696 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 Wed, May 5, 2021 at 3:21 AM Simon Ser wrote: > > > > 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? All of those should be anonymous in the sense that the backing store is all the kernel's notion of anonymous pages, and there is no actual file backing. The mappings may then be shared, of course. So that does make Peter's idea to have some inode flag for "don't SIGBUS on fault" be more reasonable, because there isn't some random actual filesystem involved, only the core VM layer. I'm not going to write the patch, though, but maybe you can convince somebody else to try it.. Linus