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,DKIMWL_WL_HIGH, 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 880D2C433E0 for ; Sun, 14 Feb 2021 10:00:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 449AE64E56 for ; Sun, 14 Feb 2021 10:00:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229668AbhBNKAY (ORCPT ); Sun, 14 Feb 2021 05:00:24 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:34227 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229575AbhBNKAV (ORCPT ); Sun, 14 Feb 2021 05:00:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1613296735; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FB1Zi7Y2SkOv/JvlFfpIv8DdC9H5NuowZUsuUzsgYnw=; b=fad4dWRm90PFswTbJv9iB9qi1jJhfRMe61awqZs1ietSewBteDCq5TGY+aozecZ2lHLZrm WV/23VXrLqLZMwGpuWSuBwNI5sf4S/zzZ9UxNxqExEWqRG4WccX7F0naK4jzhiVObtfZte XsoYCVyAxcontsUVJ3GbOhQ2cJeStLo= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-397-IoJZBwIjMpOcpVz29VyV1g-1; Sun, 14 Feb 2021 04:58:54 -0500 X-MC-Unique: IoJZBwIjMpOcpVz29VyV1g-1 Received: by mail-wr1-f70.google.com with SMTP id e11so5931139wro.19 for ; Sun, 14 Feb 2021 01:58:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=FB1Zi7Y2SkOv/JvlFfpIv8DdC9H5NuowZUsuUzsgYnw=; b=bAq6197q1Vog4VzsAvH0/c/qO43SAikPFY82bYgrAIBOOStC5p7mXMNh27lefsQrWx qjgsyZlEiZFCHBGr/by3Y5ILfdfzBggrGJ16ZW3QsQkkTdjqPC7lLwOAcP/KE9qnLMaG hd1LBMwMt6bv4ehoZnNHYKCKElP4RbyLR8C6bPBMcGq5ZJ2Tny8WMTtdd9tY+AtgXGfz UvMtiyDCe1+Zd94NGGdrIwx4nXWnfaMdpbkmeJHxVNQB+4OMipdpjmB87cdR9Dx3ge/I Gth37rm90b97HKO7OUqjPfWd8ihdjvV0dhU5ShsRRFV90Vqt39jWhZdfdGKOyFOKSt6l xTig== X-Gm-Message-State: AOAM533a/M7RS0DmbURoyWJbr5SkqKPJgQlvnZMj4KTKkyI/ttqZFxGP IlfpbiLVM6K4TT3i9RQgu8pCCuodQ2cmLFEsfpQIariwMoo4N6NKf3dzA3m5hn191hl7qwPr0ET eYFQdVrY5FmnPXquyD+Cz X-Received: by 2002:a7b:c5c1:: with SMTP id n1mr9687110wmk.163.1613296732940; Sun, 14 Feb 2021 01:58:52 -0800 (PST) X-Google-Smtp-Source: ABdhPJy6AiGKsLxdVOEv3lcfmH3b0B76nApmRsRYcgYL0hyAbXvIT8wdTN/HlT3/mJBi3lug6LzkMg== X-Received: by 2002:a7b:c5c1:: with SMTP id n1mr9687058wmk.163.1613296732697; Sun, 14 Feb 2021 01:58:52 -0800 (PST) Received: from [192.168.3.108] (p4ff23363.dip0.t-ipconnect.de. [79.242.51.99]) by smtp.gmail.com with ESMTPSA id x15sm18554557wro.66.2021.02.14.01.58.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 Feb 2021 01:58:52 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Hildenbrand Mime-Version: 1.0 (1.0) Subject: Re: [PATCH v17 07/10] mm: introduce memfd_secret system call to create "secret" memory areas Date: Sun, 14 Feb 2021 10:58:44 +0100 Message-Id: <052DACE9-986B-424C-AF8E-D6A4277DE635@redhat.com> References: <20210214091954.GM242749@kernel.org> Cc: David Hildenbrand , Michal Hocko , Mike Rapoport , Andrew Morton , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dan Williams , Dave Hansen , 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 In-Reply-To: <20210214091954.GM242749@kernel.org> To: Mike Rapoport X-Mailer: iPhone Mail (18D52) Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org > Am 14.02.2021 um 10:20 schrieb Mike Rapoport : >=20 > =EF=BB=BFOn Fri, Feb 12, 2021 at 10:18:19AM +0100, David Hildenbrand wrote= : >>> On 12.02.21 00:09, Mike Rapoport wrote: >>> On Thu, Feb 11, 2021 at 01:07:10PM +0100, David Hildenbrand wrote: >>>> On 11.02.21 12:27, Mike Rapoport wrote: >>>>> On Thu, Feb 11, 2021 at 10:01:32AM +0100, David Hildenbrand wrote: >>>>=20 >>>> So let's talk about the main user-visible differences to other memfd fi= les >>>> (especially, other purely virtual files like hugetlbfs). With secretmem= : >>>>=20 >>>> - File content can only be read/written via memory mappings. >>>> - File content cannot be swapped out. >>>>=20 >>>> I think there are still valid ways to modify file content using syscall= s: >>>> e.g., fallocate(PUNCH_HOLE). Things like truncate also seems to work ju= st >>>> fine. >>> These work perfectly with any file, so maybe we should have added >>> memfd_create as a flag to open(2) back then and now the secretmem file >>> descriptors? >>=20 >> I think open() vs memfd_create() makes sense: for open, the path specifie= s >> main properties (tmpfs, hugetlbfs, filesystem). On memfd, there is no suc= h >> path and the "type" has to be specified differently. >>=20 >> Also, open() might open existing files - memfd always creates new files. >=20 > Yes, but still open() returns a handle to a file and memfd_create() return= s > a handle to a file. The differences may be well hidden by e.g. O_MEMORY an= d > than features unique to memfd files will have their set of O_SOMETHING > flags. >=20 Let=E2=80=98s agree to disagree. > It's the same logic that says "we already have an interface that's close > enough and it's fine to add a bunch of new flags there". No, not quite. But let=E2=80=98s agree to disagree. >=20 > And here we come to the question "what are the differences that justify a > new system call?" and the answer to this is very subjective. And as such w= e > can continue bikeshedding forever. I think this fits into the existing memfd_create() syscall just fine, and I h= eard no compelling argument why it shouldn=E2=80=98t. That=E2=80=98s all I c= an say.=