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 4BA8AC433E0 for ; Thu, 11 Feb 2021 08:39:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CC9B664E01 for ; Thu, 11 Feb 2021 08:39:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CC9B664E01 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 495C66B009C; Thu, 11 Feb 2021 03:39:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 444FC6B009D; Thu, 11 Feb 2021 03:39:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 30C636B009E; Thu, 11 Feb 2021 03:39:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0137.hostedemail.com [216.40.44.137]) by kanga.kvack.org (Postfix) with ESMTP id 175A86B009C for ; Thu, 11 Feb 2021 03:39:43 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id D9830362B for ; Thu, 11 Feb 2021 08:39:42 +0000 (UTC) X-FDA: 77805338604.08.35C68AD Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf26.hostedemail.com (Postfix) with ESMTP id DB57340001DE for ; Thu, 11 Feb 2021 08:39:40 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1613032781; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=yBq3iw3Hxf5kl5qFk9wqJn0npOtP/MF9I3GQgQJS4pk=; b=u961p/CVGwFkVGfzw2vxHz/DcUNkZOUsf1lthOsGgL6mzdvVuiB6SuvgEKE7XlfMey/5G0 1xCda7eopAWyYPkO03tmFVZjkKh/uPhEA4bdAQF0mz9hK2L7xX/997Rt4ZchBs+DBDQuoF YHCF391jUf7tv4cSybYQ6okEIBckLRU= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id BFF9DAE36; Thu, 11 Feb 2021 08:39:40 +0000 (UTC) Date: Thu, 11 Feb 2021 09:39:38 +0100 From: Michal Hocko To: Mike Rapoport Cc: Mike Rapoport , Andrew Morton , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dan Williams , Dave Hansen , David Hildenbrand , Elena Reshetova , "H. Peter Anvin" , Ingo Molnar , James Bottomley , "Kirill A. Shutemov" , Matthew Wilcox , Mark Rutland , Michael Kerrisk , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Rick Edgecombe , Roman Gushchin , Shakeel Butt , Shuah Khan , Thomas Gleixner , Tycho Andersen , Will Deacon , linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-nvdimm@lists.01.org, linux-riscv@lists.infradead.org, x86@kernel.org, Hagen Paul Pfeifer , Palmer Dabbelt Subject: Re: [PATCH v17 07/10] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: References: <20210208084920.2884-1-rppt@kernel.org> <20210208084920.2884-8-rppt@kernel.org> <20210208212605.GX242749@kernel.org> <20210209090938.GP299309@linux.ibm.com> <20210211071319.GF242749@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210211071319.GF242749@kernel.org> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: DB57340001DE X-Stat-Signature: 6fsqtoddnxpdspycq6rfnuk3kmnaees1 Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf26; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1613032780-72920 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 Thu 11-02-21 09:13:19, Mike Rapoport wrote: > On Tue, Feb 09, 2021 at 02:17:11PM +0100, Michal Hocko wrote: > > On Tue 09-02-21 11:09:38, Mike Rapoport wrote: [...] > > > Citing my older email: > > > > > > I've hesitated whether to continue to use new flags to memfd_create() or to > > > add a new system call and I've decided to use a new system call after I've > > > started to look into man pages update. There would have been two completely > > > independent descriptions and I think it would have been very confusing. > > > > Could you elaborate? Unmapping from the kernel address space can work > > both for sealed or hugetlb memfds, no? Those features are completely > > orthogonal AFAICS. With a dedicated syscall you will need to introduce > > this functionality on top if that is required. Have you considered that? > > I mean hugetlb pages are used to back guest memory very often. Is this > > something that will be a secret memory usecase? > > > > Please be really specific when giving arguments to back a new syscall > > decision. > > Isn't "syscalls have completely independent description" specific enough? No, it's not as you can see from questions I've had above. More on that below. > We are talking about API here, not the implementation details whether > secretmem supports large pages or not. > > The purpose of memfd_create() is to create a file-like access to memory. > The purpose of memfd_secret() is to create a way to access memory hidden > from the kernel. > > I don't think overloading memfd_create() with the secretmem flags because > they happen to return a file descriptor will be better for users, but > rather will be more confusing. This is quite a subjective conclusion. I could very well argue that it would be much better to have a single syscall to get a fd backed memory with spedific requirements (sealing, unmapping from the kernel address space). Neither of us would be clearly right or wrong. A more important point is a future extensibility and usability, though. So let's just think of few usecases I have outlined above. Is it unrealistic to expect that secret memory should be sealable? What about hugetlb? Because if the answer is no then a new API is a clear win as the combination of flags would never work and then we would just suffer from the syscall multiplexing without much gain. On the other hand if combination of the functionality is to be expected then you will have to jam it into memfd_create and copy the interface likely causing more confusion. See what I mean? I by no means do not insist one way or the other but from what I have seen so far I have a feeling that the interface hasn't been thought through enough. Sure you have landed with fd based approach and that seems fair. But how to get that fd seems to still have some gaps IMHO. -- Michal Hocko SUSE Labs