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 331FCC47082 for ; Sat, 29 May 2021 15:44:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A31B361185 for ; Sat, 29 May 2021 15:44:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A31B361185 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 95BBB6B0036; Sat, 29 May 2021 11:44:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9031A6B006E; Sat, 29 May 2021 11:44:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4464E6B0070; Sat, 29 May 2021 11:44:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0038.hostedemail.com [216.40.44.38]) by kanga.kvack.org (Postfix) with ESMTP id 0418A6B0036 for ; Sat, 29 May 2021 11:44:21 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 89DC498B2 for ; Sat, 29 May 2021 15:44:21 +0000 (UTC) X-FDA: 78194690322.18.E249C83 Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) by imf19.hostedemail.com (Postfix) with ESMTP id 61F379001E49 for ; Sat, 29 May 2021 15:44:09 +0000 (UTC) Received: by mail-lj1-f177.google.com with SMTP id e11so9016698ljn.13 for ; Sat, 29 May 2021 08:44:20 -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=Px0k6uGG2CnOum+p/ZWgGxzncHuTfKCARvtckW6PHDs=; b=hYJ5sA/+8PZo8Zuy8hAFVJE7Dugd0xm/7egwKn8DEQsakaaek0tGdIJ+irzSataFeA TVuOaz1OeyI1ughj61bKh9aQLN+ZpNpZdmrVcIh/Y9u9khLamSF8Jj2rYRAXKP+YUodN RbdvVhrO2rlWpvC9GSSIBZDfaT1cxxMKYNAz8= 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=Px0k6uGG2CnOum+p/ZWgGxzncHuTfKCARvtckW6PHDs=; b=YrysSV4D0P9nrg6qqX+3ANxS31pTRMXAicrRPfQfe6GelLLIykRgQV1dy9OSRK/yZK 2+v58T4zTbUIqETWZoPG41SrHZIf467AybrKM6L1HXsxbo6bBow/Pt/5+HrE4yNXW9uJ 3hP0tGQJteEy7E8JgkUpycm3FO6ZQ/BM960srfISsnPHtfmPLreffaJosU6VIUkp0ZnV OG4FptpRTKcZnGHc0VWv6PHlTAGQvHbsRGPx/7FADb+AifRqJgeMNd1DWF6x1he3ZbF5 WgKGcqQOK/9yz4axl3sZvOXfz2aTSJSSmlv6I3kXtR+AVo39YzzKg08Cc578FZXOF53o r0Tg== X-Gm-Message-State: AOAM532Jq0p4B+BUmgDNsEwfUajsXO+EthYR2JRVfqjABteY4AgyfHZS FZ0DTlajSbRX8l8q9WhvICHWELpuaZFw88BdBBg= X-Google-Smtp-Source: ABdhPJxUyKCW0yXJSGrXTqfBolfSiJTYRp6G5dJvfN8JAilO3YU20AZoJRwGBZFTmYuvx/aSXDMeWw== X-Received: by 2002:a2e:a717:: with SMTP id s23mr10663905lje.154.1622303059154; Sat, 29 May 2021 08:44:19 -0700 (PDT) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com. [209.85.167.46]) by smtp.gmail.com with ESMTPSA id a25sm900679ljp.11.2021.05.29.08.44.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 29 May 2021 08:44:18 -0700 (PDT) Received: by mail-lf1-f46.google.com with SMTP id e17so9901151lfb.2 for ; Sat, 29 May 2021 08:44:17 -0700 (PDT) X-Received: by 2002:a05:6512:36c5:: with SMTP id e5mr9308841lfs.41.1622303056980; Sat, 29 May 2021 08:44:16 -0700 (PDT) MIME-Version: 1.0 References: <20210429154807.hptls4vnmq2svuea@box> <20210429183836.GF8339@xz-x1> <7718ec5b-0a9e-ffa6-16f2-bc0b6afbd9ab@gmail.com> <80c87e6b-6050-bf23-2185-ded408df4d0f@gmail.com> In-Reply-To: <80c87e6b-6050-bf23-2185-ded408df4d0f@gmail.com> From: Linus Torvalds Date: Sat, 29 May 2021 05:44:01 -1000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Sealed memfd & no-fault mmap To: "Lin, Ming" Cc: Hugh Dickins , Simon Ser , 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: imf19.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b="hYJ5sA/+"; spf=pass (imf19.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.177 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 61F379001E49 X-Stat-Signature: i37yzmk1soxgwy6oeitpebif5napkt9f X-HE-Tag: 1622303049-242451 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 Fri, May 28, 2021 at 9:31 PM Lin, Ming wrote: > > I should check the vma is not writable. > > - if (!IS_NOFAULT(inode)) > + if (!IS_NOFAULT(inode) || (vma->vm_flags & VM_WRITE)) > return -EINVAL; That might be enough, yes. But if this is sufficient for the compositor needs, and the rule is that this only works for read-only mappings, then I think the flag in the inode becomes the wrong thing to do. Because if it's a read-only mapping, and we only ever care about inserting zero pages into the page tables - and they never become part of the shared memory region itself, then it really is purely about that mmap, not about the shm inode. So then it really does become purely about one particular mmap, and it really should be a "madvise()" issue, not a "mark inode as no-fault". I'd almost be inclined to just add a new "flags" field to the vma. We've been running out of vma flags for a long time, to the point that some of them are only available on 64-bit architectures. I get the feeling that we should just bite the bullet and make "vm_flags" be an u64. Or possibly make it two explicitly 32-bit entities (vm_flags and vm_extra). Get rid of the silly 64-bit-only "high" flags, and get rid of our artificial "we don't have enough bits". Because we already in practice *do* have enough bits, we've just artificially limited ourselves to "on 32-bit architectures we only have 32 bits in that field". But all of this is very much dependent on that "this NOFAULT case really only works for reads, not for writes". (Alternatively, we could allow the *mapping* itself to be writable, but always fault on writes, and only insert a read-only zero page) Linus