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 19D7FC636D6 for ; Thu, 23 Feb 2023 00:55:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E7E06B0072; Wed, 22 Feb 2023 19:55:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 772396B0073; Wed, 22 Feb 2023 19:55:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EA0F6B0074; Wed, 22 Feb 2023 19:55:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 477B76B0072 for ; Wed, 22 Feb 2023 19:55:21 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 1E06040E04 for ; Thu, 23 Feb 2023 00:55:21 +0000 (UTC) X-FDA: 80496738042.15.082199E Received: from mail-yw1-f202.google.com (mail-yw1-f202.google.com [209.85.128.202]) by imf14.hostedemail.com (Postfix) with ESMTP id 69484100012 for ; Thu, 23 Feb 2023 00:55:18 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="ll/kgw4E"; spf=pass (imf14.hostedemail.com: domain of 3dbn2YwsKCOgKMUObVOidXQQYYQVO.MYWVSXeh-WWUfKMU.YbQ@flex--ackerleytng.bounces.google.com designates 209.85.128.202 as permitted sender) smtp.mailfrom=3dbn2YwsKCOgKMUObVOidXQQYYQVO.MYWVSXeh-WWUfKMU.YbQ@flex--ackerleytng.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677113718; 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:dkim-signature; bh=3azLqXR2vSKV5L2PaJh+3T6s1vBztgHEFOD2woEyPYw=; b=Km3YjjywsNWfDQhDVwEcRxVzEmENAJKFGMVsS906NYH4VEy/K+q751PXKb9skXb2DQ2rv0 rOJnJuF1kGPI31lP2YayyhzFZhMACW1Ev1fJfRz/ndcj7uCP4O8kFPQnWKYEQnp0ygq0tU QSM1+Z0lT1nQM8CTGZP3Hanb0LNTSao= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="ll/kgw4E"; spf=pass (imf14.hostedemail.com: domain of 3dbn2YwsKCOgKMUObVOidXQQYYQVO.MYWVSXeh-WWUfKMU.YbQ@flex--ackerleytng.bounces.google.com designates 209.85.128.202 as permitted sender) smtp.mailfrom=3dbn2YwsKCOgKMUObVOidXQQYYQVO.MYWVSXeh-WWUfKMU.YbQ@flex--ackerleytng.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677113718; a=rsa-sha256; cv=none; b=QZSSABfFD4XYJHMowUIcSb7QWMrKKGdBhgnSykuchJlQQEclKmJLxZ/zU/lj8H0Yy3TgDi CEFcw6Ds5AmryvL24Rt+m5+YLJchVgsq2SGvx3p24gvp+FFWac0Abcs8T4mvzffmCsWxiV wXBQuAd8wEYdwcAK/ehMmkEOScSWKd8= Received: by mail-yw1-f202.google.com with SMTP id 00721157ae682-536bf635080so100891667b3.23 for ; Wed, 22 Feb 2023 16:55:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:mime-version:in-reply-to:date:from:to :cc:subject:date:message-id:reply-to; bh=3azLqXR2vSKV5L2PaJh+3T6s1vBztgHEFOD2woEyPYw=; b=ll/kgw4EhN1QBjkzhFZB0Ail1ORJy+AyUBj3Zon2zA6YZR6bvv6MRVw4xL88tq8Az8 UNfJYuIlxPRqkMZxma4EfhQVLDz+WB3n7N3GgnS6/N71B9VGL9L1wJxicWIzPEsnhNbY jwqQtYqGUwQCJ7O/Ie7nc1bEP4GmGEJpB8DCFusadZrYSFRLnQZARIT1I0plRhGyCTgj klqga5wY1X/qhy0ohB1y16mctfilFHsYR3l8CX6UQd0Ok2HUyZRCt5JjEmEyFz3N4ySp AUxoMU/xS8Z5QEE7WS4WTYYb6USgkUVSpxiH8hOE9if2xvRinxF+p0VrjEGBhDPd5C7e 03hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:mime-version:in-reply-to:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3azLqXR2vSKV5L2PaJh+3T6s1vBztgHEFOD2woEyPYw=; b=pMeRkNGoCwCmI69flTOW31zWNEcQDFnL3oZ0ZrP05HkCogizZHiDr4At5eXJOwpfNy KXvEUWICFh7ooYTTaoo29gURSOUn+Rifw8Rsq385FT6G7ZktjrA0825VXrogZp5GKyH1 2IkGzqnxPjuiVsUAa1DHjGoT6FKcnTCNirDvvEaw50Z6+6hqSGHSKuXZyZtnuyrS+K+A vZ5AWAiXMVfri5rfAQiF64eaW0kzxkMb5d+FfvlEGd7ytHO6CdassV8bHX+O8IiIyBVQ BT4tGtdTKoUpeiIShdxXB8j4vLpkhLMnk8p/2Y1cke51sP7DlS4Phi7OBkpny3wQE77h AauA== X-Gm-Message-State: AO0yUKW8Cyph0CWc36rwddJ7Fb0Fyrdmmfs0R6Pf2wxargj9yzSslX49 hmeff5M45WEwFxmvnOC5ZEj5M5u/86NxODlyfg== X-Google-Smtp-Source: AK7set/bRW8kyMySNfR/6zy0z0kR68DNc8Wiwl2R9ueq8c35MSB8zjbIqdtnOK6awXZtxDJCM5SBJnFOM9ODRuSA8Q== X-Received: from ackerleytng-cloudtop.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:1f5f]) (user=ackerleytng job=sendgmr) by 2002:a05:6902:1028:b0:a27:3ecd:6 with SMTP id x8-20020a056902102800b00a273ecd0006mr761629ybt.1.1677113717462; Wed, 22 Feb 2023 16:55:17 -0800 (PST) Date: Thu, 23 Feb 2023 00:55:16 +0000 In-Reply-To: <20230216100150.yv2ehwrdcfzbdhcq@box.shutemov.name> (kirill@shutemov.name) Mime-Version: 1.0 Message-ID: Subject: Re: [RFC PATCH 1/2] mm: restrictedmem: Allow userspace to specify mount_path for memfd_restricted From: Ackerley Tng To: "Kirill A. Shutemov" Cc: kvm@vger.kernel.org, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, qemu-devel@nongnu.org, chao.p.peng@linux.intel.com, aarcange@redhat.com, ak@linux.intel.com, akpm@linux-foundation.org, arnd@arndb.de, bfields@fieldses.org, bp@alien8.de, corbet@lwn.net, dave.hansen@intel.com, david@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, hpa@zytor.com, hughd@google.com, jlayton@kernel.org, jmattson@google.com, joro@8bytes.org, jun.nakajima@intel.com, kirill.shutemov@linux.intel.com, linmiaohe@huawei.com, luto@kernel.org, mail@maciej.szmigiero.name, mhocko@suse.com, michael.roth@amd.com, mingo@redhat.com, naoya.horiguchi@nec.com, pbonzini@redhat.com, qperret@google.com, rppt@kernel.org, seanjc@google.com, shuah@kernel.org, steven.price@arm.com, tabba@google.com, tglx@linutronix.de, vannapurve@google.com, vbabka@suse.cz, vkuznets@redhat.com, wanpengli@tencent.com, wei.w.wang@intel.com, x86@kernel.org, yu.c.zhang@linux.intel.com Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 69484100012 X-Stat-Signature: ghin9z6xfmnb7gjizd11t3i3wn4gqmam X-Rspam-User: X-HE-Tag: 1677113718-739217 X-HE-Meta: U2FsdGVkX18isCJ1jVZQKbVI2sJ7s6+xXypAEwIUqb8qjFpk7a+Wuaw9OY19/vtsWlIYeNpX99+j0XyFNhcZ5Gp2zIJeAqKbuEQn/RPtFyUjczn8jsabs2E48kcKAsWYfeDjF/BBqS8J8pjxgzkpslA9CmL8CAQjhF7wo37Tuf/x3frO2HDQ1nCwfY1oOjNoPDPPn25T/4wVPHg3oaTW28hWuYqhYzY3NtAPXCrkOmihviNmAWqy3Lv8zeDV92OeiGR+NsNHyg2eHWUhJ2lw7GtAo3l9YXbgo/FsdyVkAjxjoLk9yKLYBlKtavSpPLqxmeOnzCBT5TZa8hed0jA1T25nsBZKpdilI+zzkiHSRH+6mnPdxcIlB0VOq2E1qJioZ4by7U7urOxDeNTl7+W0AMxbfMbZsleNLVvZbgqlGLAD1KrlE1Col2p3QY4fOthVigLoWT+jEueU8r68ozXpBFX72mtfrs87qQDZkDAkXtyMIi2LJe3k6WB9/GMg7ktcG2QTo4xdXTrwDplzeK11fwHZk64P41JYnps4/FMBVjybQxOwJouowRI27+f/HqNs0mXmNwyxCd76Pov2DDs8ka307TI9Km/76VvpPiANT5X0iL2wkbb9l7HVd4URH8mRYVAtlp485nA2TeG21/OKEoEZsOrLE4sPjcdoW0NgWU9TGzlD/wJ3TSxhnHvJNcv3rVXmxiH9Aqoo9Ew1iZaGTqQ974Y/R4x47xoPdNFL3Bh86Zs+WPpJkqWssb9XAZu+IdrTc1+cI5NniWjwMS/CmjEoTp0VXMdP0yN4xQpX1l0VPtbn2tn40Nu8mjhpA9TjJLm6RrmZR7FZcblSF0jjVOQLhuJ3doFJW4OrOFfuObO2r7gyqqVy9yQ0EOLPIitXY8lBU7sVphnIKhIoSXmZ/94FhbReXPCMhdguVLuAViNYhUrlCg/WzcgujbXZxO2c3N1sxeO48nHuxF0lQz5 N39H8CMf h7lz/bIMjTi1ZUZ7V4uK6dhIe9M9RQLHBesbL6DixRf6Nq3Exem6EU1yt+ZfVxMvhv4x3rwvHKwh7soygGZmncKnCOj8otls81onx8G+pvUW8c1FxKeGAQABku0OR+Y3tvP8Yrh45E6L5qHO+l9eb6jTVZXQqJSf5dBcio7NHJIvo6X0Jj195eoekwISrLCul1IaAPvQwXSuE14O0vl7nuaDSI0lFuy4GKy1n4UXOQnepbFKYx3DFTkITwsjD+Xh80mZwv9ZbfUbimOdS0P7n9Hc50t68saMPearopGt3rcsLVq3Tn/J8HIWpSa1LcR54qPOR9r6MgBI7aeERO71pKLSaTmlob2MfK13hpZ8785OukJWvFnz4bJOiXTpEDLhcEMHHhy9QDMO2L4QF5MHqKxwJJZ41Nst/GTIVIJXP1aIy6ay/cn8ossOzpyA1tEIkUs741IkuoPXiKUonNahMfdeiY/k4o0+IR+xYLE8yEnzr1E3i+wOSHjCd/m4TbpCUsXSijoCdAAubmj+BHlsyGjou7NVQLG3Cf2yupUv6GHZE1pi3uH/INPQP0S7qpz2bUIocHDDRhX0ZE0guJt1p9vnmmZTNFDqSos8/cPjPZfaLU4Ma8NpAMqr4VClBDK2E0dLuj4x+JGcaT3ka/kCKSjwVZVeoxc/ib/4R 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: "Kirill A. Shutemov" writes: > On Thu, Feb 16, 2023 at 12:41:16AM +0000, Ackerley Tng wrote: >> By default, the backing shmem file for a restrictedmem fd is created >> on shmem's kernel space mount. >> With this patch, an optional tmpfs mount can be specified, which will >> be used as the mountpoint for backing the shmem file associated with a >> restrictedmem fd. >> This change is modeled after how sys_open() can create an unnamed >> temporary file in a given directory with O_TMPFILE. >> This will help restrictedmem fds inherit the properties of the >> provided tmpfs mounts, for example, hugepage allocation hints, NUMA >> binding hints, etc. >> Signed-off-by: Ackerley Tng >> --- >> include/linux/syscalls.h | 2 +- >> include/uapi/linux/restrictedmem.h | 8 ++++ >> mm/restrictedmem.c | 63 +++++++++++++++++++++++++++--- >> 3 files changed, 66 insertions(+), 7 deletions(-) >> create mode 100644 include/uapi/linux/restrictedmem.h >> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h >> index f9e9e0c820c5..4b8efe9a8680 100644 >> --- a/include/linux/syscalls.h >> +++ b/include/linux/syscalls.h >> @@ -1056,7 +1056,7 @@ asmlinkage long sys_memfd_secret(unsigned int >> flags); >> asmlinkage long sys_set_mempolicy_home_node(unsigned long start, >> unsigned long len, >> unsigned long home_node, >> unsigned long flags); >> -asmlinkage long sys_memfd_restricted(unsigned int flags); >> +asmlinkage long sys_memfd_restricted(unsigned int flags, const char >> __user *mount_path); >> /* >> * Architecture-specific system calls > I'm not sure what the right practice now: do we provide string that > contains mount path or fd that represents the filesystem (returned from > fsmount(2) or open_tree(2)). > fd seems more flexible: it allows to specify unbind mounts. I tried out the suggestion of passing fds to memfd_restricted() instead of strings. One benefit I see of using fds is interface uniformity: it feels more aligned with other syscalls like fsopen(), fsconfig(), and fsmount() in terms of using and passing around fds. Other than being able to use a mount without a path attached to the mount, are there any other benefits of using fds over using the path string? Should I post the patches that allows specifying a mount using fds? Should I post them as a separate RFC, or as a new revision to this RFC?