Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2904406pxj; Mon, 31 May 2021 14:16:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwDOIQL8+NngVt33e2+che0+de7KmrzxVfCqbEDAaVbTfeZy2H0JXZxM8xXXXlC99rdio3/ X-Received: by 2002:a05:6e02:5a5:: with SMTP id k5mr19066375ils.108.1622495789185; Mon, 31 May 2021 14:16:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622495789; cv=none; d=google.com; s=arc-20160816; b=l1gAD4u1aBxpY8yqz0kCpAK8+ANaqpB3302CG5f2RP9iGA2eaRfHTttbitWOo1kaiI o9T80vmtCjvvFNhTfI4Z3YWJi6SsjyGV5eH64U/ppMphzPQusPHfHNXAsEp2CZiasu4n BDbZEB8QORv0/jyn/RS4EhfP1aQM5gWJF5Slpbji4lJSxOr6Bgw3nzfQH0afU0VF8AZk umvdPsIBdmaoj1Ww2BvOiBGS2NAGX2t3lDQWxlrCTRfEH0zzKmGjZSTCxWzCqTPXD35S 344MKbBZiUjmnGNTAM/axbwQadUtcHisFEWLplcdppDeilxgnW3Fo0s+SZ15A29gpQYD EgwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:references:cc :to:from:subject:dkim-signature; bh=LW0vl/hPnVGSly3VDkGIzhu2V9/k+bcQNfCUTpERlgM=; b=WXAOwwZrywWyxubXT4f/7fGgBR2EgRmw9b6g8ILAHmGlCUV7CDrB1nWzOdz52P9UIr yrGXBarkFSmuDOCfU/6ehKWtuq7awmjZnSN0IhEfn4GFaPyNeP5Y4H5aUxi8dfY7y4Sp WrUcOx4s0yT261AFVNrfOZe69DZowh5aIoSANALc3RwQ0Mmv0weVcErOVrsc63Lukz40 DAD/S26giCqRw0hIyvJjf7WfdxyCqEK0mNEmR4Sp2TBxwM3GGKSOQyqabBRCkhlP2lAz zFwc5SkT0cChXHTu5cGRv/0p3sMkhl2b7Svo2bJzxjk5lZsZrl9ME+IQ2B6A0qZljET/ IKnA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=YWhF1lBk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p20si9245613ilc.83.2021.05.31.14.16.15; Mon, 31 May 2021 14:16:29 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=YWhF1lBk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231240AbhEaVPR (ORCPT + 99 others); Mon, 31 May 2021 17:15:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48178 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230032AbhEaVPQ (ORCPT ); Mon, 31 May 2021 17:15:16 -0400 Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B7274C061574 for ; Mon, 31 May 2021 14:13:35 -0700 (PDT) Received: by mail-pj1-x102c.google.com with SMTP id i22so590467pju.0 for ; Mon, 31 May 2021 14:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=LW0vl/hPnVGSly3VDkGIzhu2V9/k+bcQNfCUTpERlgM=; b=YWhF1lBk/tLmGWtD5cy8ck7UqSAiRSXGygv3obAjb1C3oRikFyW6m29zQJxQeMzorV N2QTxnSTXrYkgZS7lL3QkLFHjBEnmD45o4fvJGHwlyAAowgUvXGf0PEWnADScA6sBlBR cJrG87p6Fry51970S10NjqiSUuh+QZNkJpFHEw8b5BOnk//6FbnAxK3TBIpLe1QdaHUA UqM7KPQWZXaak6TQwY/XDDNYXDYnMqcc1Cwa78QBG937BZNzZyZ+LM/EEBbnb5uN/sU3 xnYbaPUPnoI6NphARwkya9+ZmxoHTL4kO+EbP2+PFsUcgXS3ENNB0e9l1WiRicW56kuL njxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=LW0vl/hPnVGSly3VDkGIzhu2V9/k+bcQNfCUTpERlgM=; b=KuAbrvgNZYLIEKVuZ7eOzmCus0jN1i0d42B6FgnshgFkOyK9t8GUOtBoJakYJjdpqh t0AB+xb4GJzg7KHBEFudphxpzQ+es+UN0FK3F7RFkS1dYHFHaHI2HnzmzKuO8WbvYgPP IkISuL/UoLRUfTxWTDNv59/bJI5MzOAM82yDPwZDodgNiJjmVXOsuqDPkMIt9ggfWJ/9 L4XFq6IaFVzfbvH0uS8It/PfS6RL1Ym6gcqJwIHdknoCz3XDSGq5rDUjipeppiLYmh1p ANhv/QNRn7u4ZO9UZCN4lPY69YzUa0cuStHAvJ1naMWOSD35YmFJM6QHBBBlTeMcb69Q oajA== X-Gm-Message-State: AOAM530+psxmNNhyh3WUlv2E9nEKxlLa71dZFiR4Kw2bSoL6vaaHB8S/ uq2GFMxaWQnrLMz63mCsXkY= X-Received: by 2002:a17:90a:80c5:: with SMTP id k5mr1004969pjw.129.1622495615154; Mon, 31 May 2021 14:13:35 -0700 (PDT) Received: from [192.168.0.15] (c-73-158-171-241.hsd1.ca.comcast.net. [73.158.171.241]) by smtp.gmail.com with ESMTPSA id bv3sm501772pjb.1.2021.05.31.14.13.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 May 2021 14:13:34 -0700 (PDT) Subject: Re: Sealed memfd & no-fault mmap From: Ming Lin To: Hugh Dickins , Linus Torvalds , 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" References: <20210429154807.hptls4vnmq2svuea@box> <20210429183836.GF8339@xz-x1> <7718ec5b-0a9e-ffa6-16f2-bc0b6afbd9ab@gmail.com> <80c87e6b-6050-bf23-2185-ded408df4d0f@gmail.com> <36fc2485-11f1-5252-904d-f26b63a6cd58@gmail.com> Message-ID: Date: Mon, 31 May 2021 14:13:28 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: <36fc2485-11f1-5252-904d-f26b63a6cd58@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/29/2021 4:36 PM, Ming Lin wrote: > On 5/29/2021 1:15 PM, Hugh Dickins wrote: > >> >> I believe the correct behaviour would be to unmap the nofault page >> then, allowing the proper page to be faulted in after.  That is >> certainly doable (the old mm/filemap_xip.c used to do so), but might >> get into some awkward race territory, with filesystem dependence >> (reminiscent of hole punch, in reverse).  shmem could operate that >> way, and be the better for it: but I wouldn't want to add that, >> without also cleaning away all the shmem_recalc_inode() stuff. OK, I borrowed code from filemap_xip.c and implemented this behavior. Simon, Before I send out the patches for review, would you mind have a quick test? https://github.com/minggr/linux, branch shmem_no_sigbus In Wayland compositors, you only need to pass in MAP_NOSIGBUS in mmap(). For example, //fd should be received from Wayland compositors client #define MAP_NOSIGBUS 0x200000 addr = mmap(NULL, size, PROT_READ, MAP_SHARED|MAP_NOSIGBUS, fd, offset) Thanks, Ming