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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C0067C77B61 for ; Mon, 24 Apr 2023 12:24:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2F1AF6B0071; Mon, 24 Apr 2023 08:24:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2A0EA6B0074; Mon, 24 Apr 2023 08:24:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 18FDB6B0075; Mon, 24 Apr 2023 08:24:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 0ACB96B0071 for ; Mon, 24 Apr 2023 08:24:05 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id AB8CD1A019A for ; Mon, 24 Apr 2023 12:24:04 +0000 (UTC) X-FDA: 80716201608.14.00306AF Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by imf22.hostedemail.com (Postfix) with ESMTP id AE4BAC001A for ; Mon, 24 Apr 2023 12:24:02 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=MpbmRdOj; spf=pass (imf22.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.53 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682339042; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=9JPB0GklpBQlKrjPHy6vp/0sbrD8fwt4RwTkZmksDdw=; b=a7Ow+BKLTyIgaqgzj0jwnkTsK1u9H+pQWsIOUjZAdy0oTTEH0sJ2kw1P325bvRVb6cwVx7 EakwjemYRuSbdWdevkUIoaovD9YnVWVW9zCznfJK4XifQR+xDo/Vxkk0O9p7B6x4c7mVz3 mQZJiUf5aLn/2lHspSs/e3rNmLStKEE= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=MpbmRdOj; spf=pass (imf22.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.53 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682339042; a=rsa-sha256; cv=none; b=FZIquivea8Yla3nzomNhw/XA0AQgvpZ4uthFqfWu4xWDrYqshSLfCcHkuRzxz91uGywiD6 HbG24xgBfeijenQwUZXLIfqctpnM9S/X+QIlcEPVFhjrZf0JZfgUd9swnFeYJWhuJi0Uky N78q8EnHI+IfOUUkATrpXNc0p4A/vVQ= Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-2fde2879eabso4012199f8f.1 for ; Mon, 24 Apr 2023 05:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682339041; x=1684931041; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=9JPB0GklpBQlKrjPHy6vp/0sbrD8fwt4RwTkZmksDdw=; b=MpbmRdOjwrELouTgY8GUq9LxMaeMBPHKir7+SHb6NJ6MSfT2N3+1F98Y4iwkfNChLK fb5xTQ6o6rgiNps/OlljdNmMSxi7u7YUJ4EYCTeYWLj29F5dI+yplOV8xJ0Zn24yh0y0 bIKFPaw88PQ0JqzyFXKnWw97TdDumbe5fvtIZaOfJsPSRVEUvl5YVSIvOF9ni9lORwo0 WzVVjMjavCDTw1kqO8CP54ES94/3cyOFflusjOnXik9zQpvEwU5nY722rQK4/6J5jmQj HdYRYXrqSvSG0o9K4m2BssbiW3Q5mHWLgSO8RRHWU+nbcDCiD1EEPybU98c7ZEXAIqiL DaOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682339041; x=1684931041; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=9JPB0GklpBQlKrjPHy6vp/0sbrD8fwt4RwTkZmksDdw=; b=lvsGqU8ReK5Yhb+XFaCy5AdFKRY8rcpzI0dTTrMcwRvC8wXd9MopKOR8fk64sHZpC/ gitZKCNDCxSmV3Fjo5uX4nreckHaBCUG7+17DoUL4MAKT1I1RTNie4p5koA5E7Y4R23O yUoEV5HHYk0PfHnA1ja53QWOg0OwAoD8R6UTF8uOzLsrEmvcLMneYLZ4jO6Yh6BJL3YN XS04R8kBllGt+9f/1h8J9yZ+UoEgpQATbC38hmwH+uubdsZrjATMtWxODX1AMddUZINg SEXzc3AqeXQNPu19d212n9q8r+nv+TjaFsIFo3JitN/i0tChLgThu4KOdjROHEcIEIiP zhKQ== X-Gm-Message-State: AAQBX9eMs3TewzUarAEV7N4re9hNexYrdE5g/ohYL6yOyzJ9G2pDtYXz i3s6eLjmcXi/4OFakwOojoEBnWj74aTzrQ== X-Google-Smtp-Source: AKy350YYt5GFR3Zroi/O1GdhfbNtv34k83vpHgqOeHlMCioTCatt1FyZN68v9PGyurIvxLluScsn/g== X-Received: by 2002:a05:6000:12c1:b0:2db:bca:ac7d with SMTP id l1-20020a05600012c100b002db0bcaac7dmr9146698wrx.67.1682339041014; Mon, 24 Apr 2023 05:24:01 -0700 (PDT) Received: from localhost (host86-156-84-164.range86-156.btcentralplus.com. [86.156.84.164]) by smtp.gmail.com with ESMTPSA id b5-20020a056000054500b002e5ff05765esm10752214wrf.73.2023.04.24.05.24.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Apr 2023 05:24:00 -0700 (PDT) Date: Mon, 24 Apr 2023 13:23:59 +0100 From: Lorenzo Stoakes To: Jan Kara Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Andrew Morton , Matthew Wilcox , Mike Kravetz , Muchun Song , Alexander Viro , Christian Brauner , Andy Lutomirski Subject: Re: [RFC PATCH 0/3] permit write-sealed memfd read-only shared mappings Message-ID: <990a5367-c1ba-4451-856e-be81792e0dba@lucifer.local> References: <20230421090126.tmem27kfqamkdaxo@quack3> <20230424121936.lwgqty6hifs7eecp@quack3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230424121936.lwgqty6hifs7eecp@quack3> X-Rspamd-Queue-Id: AE4BAC001A X-Stat-Signature: d4kb8oh6qhbbp8fmnjbb4qqkzg7r1wh6 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1682339042-719543 X-HE-Meta: U2FsdGVkX19log88PyNL9QNGVd4syn7gtJqIuNHWP/zRBxWS2iu7Y7Tud3R6261b2WU4czknK023TG35LZYuo2JFdqGF2DUFaZAJsVK+sEJI0y4xO7kQktYxtj0cTkWX3UUWYCNU6qBF6xgxX3Hrh4Z4OFZraCepiXX0uhWaXQwUkLWYxcXcPapgel3TtL3FAof7+jnu9mjsRFsJ7IEaViYq2lE054pln+iTdPu4Z4HoRHqMgYst5GbUBWwUwJAnRFrsdYKw/qMcClBHfGdHvd1qC3DyQopBODmcZZ0gXIJJSv3Pj35O4mgaUv5Xx96bSbQbA/FxQ1XYrZkeFtlWbjgbrjOt0kCpA8uMO2lNkOIKrZ5linI1eRbFTvjHTq9bPgtwtvN5awl3sJUMeMmZBNBXbxqJ9NSHYxJMLmxld50KfIpW9Yq5/P5D16icjLpo+QJq2ttZElUmmfzna1yS7aD3S/MRRBnLK2yvzYVcJw6H6f0uzG0bM0tnu4aZ3RcTzqYRYMwNCcG749m1jNcq3RBBhhTLcVIa1cE64B5TLsIndKwV9GtLX0wD4JywdznqH5QOu4hdPo1xifh7O4/+HbxFT/VNcIvsHX22UbZCjMmzcyy74Kf6H/IXr7dUeBIcqcYGbgKrU+CkK43Cm09Lw6c7tnQeTvPNkmgt/g+JbqJREYA3kWGNEL7prCJZYstgaI0e+TDNFKD4t8BhudS6nQqOXZM9ZvYtL2fzx2zTIB7Erye1M79WVeombRykWtzX5GSMXgqvb/oVhVwpR7C2fTbmg2EU5LJ5HAt1dY+cgrpcVPwSVKH+PyJYvmzNaQBWDfHkTbswd+HQu4XCS4eCV5Aya7fEKb97jHTunhUxANr8I/xDzYwkQink0jPs1EClz+cgZk2yVQXjPYJvmfcuR6DHpFgM/Fr9iEdkY2cl/+cLksBMtjcpw1oS55/pi9wQJdjiintxd6vKyxpd3WJ jHwuPwA3 MWW1tdM64bqNmnGsMIVW/qEiw2O9SNsn/iUm3hlYxQTqJSVxIRvRGf80DCZlCbaMdqw3mlCADS+vM9B05hl0wdwysXgdKv8asXHIEteMmQnuoASJHq989HQNauQT1pnjWjlELQ0tj2lReMvsjN/QX6+4oMQIL4A9/61tDQ0BZvvDIqaUH6x2YwZBGoN33ogQWDCzE8e2g86QQ+5tZFthOTsD3g1+Z5iWCLPJLjIZdgI5V61iR80IHRMNV6CG1C+zyc8L8O4De/Y1ojgJlblD3eR6ZgD3VHYqts05a3SxjQJUgN/4kzABxoFRWCl0NtVX2Hi/GCQgNKCmn3iyXpcJy/QnLHTrvvNEVqBy3pT8OjOJDYbn1c4gqR0r8VQdf9/IsD0D8Isb1t31UYrl8Ml/iOy3LY6WpZLCeTW6zpv829PfC2aLf1IwoL41UbJeUmopAkt2hFHxbXyMfV/A= 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 Mon, Apr 24, 2023 at 02:19:36PM +0200, Jan Kara wrote: > On Fri 21-04-23 22:23:12, Lorenzo Stoakes wrote: > > On Fri, Apr 21, 2023 at 11:01:26AM +0200, Jan Kara wrote: > > > Hi! > > > > > > On Mon 03-04-23 23:28:29, Lorenzo Stoakes wrote: > > > > This patch series is in two parts:- > > > > > > > > 1. Currently there are a number of places in the kernel where we assume > > > > VM_SHARED implies that a mapping is writable. Let's be slightly less > > > > strict and relax this restriction in the case that VM_MAYWRITE is not > > > > set. > > > > > > > > This should have no noticeable impact as the lack of VM_MAYWRITE implies > > > > that the mapping can not be made writable via mprotect() or any other > > > > means. > > > > > > > > 2. Align the behaviour of F_SEAL_WRITE and F_SEAL_FUTURE_WRITE on mmap(). > > > > The latter already clears the VM_MAYWRITE flag for a sealed read-only > > > > mapping, we simply extend this to F_SEAL_WRITE too. > > > > > > > > For this to have effect, we must also invoke call_mmap() before > > > > mapping_map_writable(). > > > > > > > > As this is quite a fundamental change on the assumptions around VM_SHARED > > > > and since this causes a visible change to userland (in permitting read-only > > > > shared mappings on F_SEAL_WRITE mappings), I am putting forward as an RFC > > > > to see if there is anything terribly wrong with it. > > > > > > So what I miss in this series is what the motivation is. Is it that you need > > > to map F_SEAL_WRITE read-only? Why? > > > > > > > This originated from the discussion in [1], which refers to the bug > > reported in [2]. Essentially the user is write-sealing a memfd then trying > > to mmap it read-only, but receives an -EPERM error. > > > > F_SEAL_FUTURE_WRITE _does_ explicitly permit this but F_SEAL_WRITE does not. > > > > The fcntl() man page states: > > > > Furthermore, trying to create new shared, writable memory-mappings via > > mmap(2) will also fail with EPERM. > > > > So the kernel does not behave as the documentation states. > > > > I took the user-supplied repro and slightly modified it, enclosed > > below. After this patch series, this code works correctly. > > > > I think there's definitely a case for the VM_MAYWRITE part of this patch > > series even if the memfd bits are not considered useful, as we do seem to > > make the implicit assumption that MAP_SHARED == writable even if > > !VM_MAYWRITE which seems odd. > > Thanks for the explanation! Could you please include this information in > the cover letter (perhaps in a form of a short note and reference to the > mailing list) for future reference? Thanks! > > Honza > Sure, apologies for not being clear about that :) I may respin this as a non-RFC (with updated description of course) as its received very little attention as an RFC and I don't think it's so insane/huge a concept as to warrant remaining one. > -- > Jan Kara > SUSE Labs, CR