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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 23A47EEAA7E for ; Fri, 15 Sep 2023 01:20:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229487AbjIOBUw (ORCPT ); Thu, 14 Sep 2023 21:20:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58442 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230100AbjIOBUv (ORCPT ); Thu, 14 Sep 2023 21:20:51 -0400 Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AA2B42100; Thu, 14 Sep 2023 18:20:47 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 33767320093B; Thu, 14 Sep 2023 21:20:46 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 14 Sep 2023 21:20:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=themaw.net; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1694740845; x=1694827245; bh=pmP7OP8Teh0wQAibyNwOhpBxRHvDRLuM8su 1niOjxnQ=; b=NqhFWMnVCcxQHZPlXyLw0n7dKBIX2C8Jsn5W9axT3zoFM/sTGxj LnECOWQ4SqR878gxfxPCxd/HgY2M/ZSbwbVr59gkl42U4aJlAMfk+/nf5HWLok5S e3DpNyYJTIdf2aBgi3JKEFdxgXf7MBIn8FFLAX/yKQU+0BNkxyrM7f3+jJpcgL8i RT571MYz/JY1HNPzAuOz205Os1PT3HqMHwmHoCBW7rgwjKs8r/FC3f8HO3qvgboS VO6elqDybO+zYZa17Ka72MvynEGydL+3iuFv90+tXt1xVRedRjgyKeVVGg64hwe+ mUiM5PggvTS7Qbdthzpd3EN5s9TMrLuiFyg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1694740845; x=1694827245; bh=pmP7OP8Teh0wQAibyNwOhpBxRHvDRLuM8su 1niOjxnQ=; b=jE3sXdcqMRKGAL+0avRoWasTzWML+Ek8m0C6HJCGg+2+rMqgiaT XX2cw0J9LpAzI2nVaYHletTIve0xGkLbQ14U1g5SdxegqbKPow4EjcMV1cUokrCS 0OuobbOJjUAwzDw4deAmvx4qmzXr8EBiXCdykPwlfKxray0HP+FlaURGnvcLyxmS 6Eo8xEl6/7jt8/kTEueJjK/UKnUmiZtTk88/gUtHva+fiSGqS2EQajs2jsEky1Ie BBnrG/0/bproKk9CGIQvpWAeUnd4DGISXc78UHFeAtbDxBoSzRc0gCje6ns2Pvz2 EYvXhiPuUCih68Wu89aareqB/caTtuEJ5LQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudejuddggeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpefkrghn ucfmvghnthcuoehrrghvvghnsehthhgvmhgrfidrnhgvtheqnecuggftrfgrthhtvghrnh epgedvteevvdefiedvueeujeegtedvheelhfehtefhkefgjeeuffeguefgkeduhfejnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhgrvhgvnh esthhhvghmrgifrdhnvght X-ME-Proxy: Feedback-ID: i31e841b0:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 14 Sep 2023 21:20:40 -0400 (EDT) Message-ID: <904a8d17-b6df-e294-fcf6-6f95459e1ffa@themaw.net> Date: Fri, 15 Sep 2023 09:20:38 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [RFC PATCH 0/3] quering mount attributes Content-Language: en-US To: Amir Goldstein , Miklos Szeredi Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-man@vger.kernel.org, linux-security-module@vger.kernel.org, Karel Zak , David Howells , Linus Torvalds , Al Viro , Christian Brauner References: <20230913152238.905247-1-mszeredi@redhat.com> From: Ian Kent In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On 14/9/23 14:47, Amir Goldstein wrote: > On Wed, Sep 13, 2023 at 6:22 PM Miklos Szeredi wrote: >> Implement the mount querying syscalls agreed on at LSF/MM 2023. This is an >> RFC with just x86_64 syscalls. >> >> Excepting notification this should allow full replacement for >> parsing /proc/self/mountinfo. > Since you mentioned notifications, I will add that the plan discussed > in LFSMM was, once we have an API to query mount stats and children, > implement fanotify events for: > mount [mntuid] was un/mounted at [parent mntuid],[dirfid+name] > > As with other fanotify events, the self mntuid and dirfid+name > information can be omitted and without it, multiple un/mount events > from the same parent mntuid will be merged, allowing userspace > to listmnt() periodically only mntuid whose child mounts have changed, > with little risk of event queue overflow. > > The possible monitoring scopes would be the entire mount namespace > of the monitoring program or watching a single mount for change in > its children mounts. The latter is similar to inotify directory children watch, > where the watches needs to be set recursively, with all the weight on > userspace to avoid races. It's been my belief that the existing notification mechanisms don't quite fully satisfy the needs of users of these calls (aka. the need I found when implementing David's original calls into systemd). Specifically the ability to process a batch of notifications at once. Admittedly the notifications mechanism that David originally implemented didn't fully implement what I found I needed but it did provide for a settable queue length and getting a batch of notifications at a time. Am I mistaken in my belief? Don't misunderstand me, it would be great for the existing notification mechanisms to support these system calls, I just have a specific use case in mind that I think is important, at least to me. Ian