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 9457CC77B76 for ; Tue, 18 Apr 2023 08:54:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230286AbjDRIyl (ORCPT ); Tue, 18 Apr 2023 04:54:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231138AbjDRIyh (ORCPT ); Tue, 18 Apr 2023 04:54:37 -0400 Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3C1EB40D7 for ; Tue, 18 Apr 2023 01:54:24 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id xi5so71206727ejb.13 for ; Tue, 18 Apr 2023 01:54:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; t=1681808062; x=1684400062; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4k3WW0HYYEev3nuwv7vDX4T8/KUYMFlvnkJox7nmgfY=; b=rZgoEYmWcvDFqkdD0nxXePfvBvn3u5ZOur7mt+d4l5P9aQ9Gl/6qCmeGFgQdIDNixe zyd4xFj49Dbjf/+YBEzuWTsI5AHawGdIsTaxkF2LATuyXvEQCNPrCPnDQY7A7rpWaV3I Be0da+ecOYtTG5E4BsnQPezrWLtzlqR+4QPXg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681808062; x=1684400062; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4k3WW0HYYEev3nuwv7vDX4T8/KUYMFlvnkJox7nmgfY=; b=NIaoVknID4/DFznIFgWgzCxfQxq0MJIJccGbw9BTRJ/QgY3MrCo3Ii9sfYoF0gGhjc szd07WYYRf2ciX8arVoUaok8i/9SyLMKix5DzwwpdrXX6yKE0pzVmxN098zmwT2lJrWp zlMZrmBKdsktorEwpPAmMoo/BOBfSwzWIq+0bBzvxNpSLAzmTws1JT0X50bVzD8alBOI MOLs9KrBoOCgLtyBDv2zJ7Oei6xMNIaskC+TgRnmJNYA5ClcuiqO8D1Xu2Df9Y5DouOA iczX11wEAZF4k1JoeRk9GIRZwDK4lSOLMRmkODw+C0U9S/s1/BY3U00hr1uTE47OT6e2 tmXg== X-Gm-Message-State: AAQBX9cQdrP2nxEW+H6Uyp7+AUUsDBJ78XudD8S/CYO/iIHwKrhHpIji 8NCfqghUz9VV2diPCt/vrjq2Ebp7P056D7oLXziZhg== X-Google-Smtp-Source: AKy350ZeR14T6BUocbJhKdgdvJG00gRRWuAG9wyFQ4gTSTVTWmefyGehGfMzmKL4FI9uxUOFNpYalzs+EfMXy3v9vew= X-Received: by 2002:a17:906:149b:b0:948:b9ea:3302 with SMTP id x27-20020a170906149b00b00948b9ea3302mr10922599ejc.1.1681808062685; Tue, 18 Apr 2023 01:54:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Miklos Szeredi Date: Tue, 18 Apr 2023 10:54:11 +0200 Message-ID: Subject: Re: [LSF/MM TOPIC] fsinfo and mount namespace notifications To: Amir Goldstein Cc: Abel Wu , linux-fsdevel , Christian Brauner , Linux API , linux-man , David Howells , Al Viro , Christian Brauner , lsf-pc Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Sat, 15 Apr 2023 at 13:06, Amir Goldstein wrote: > You indicated that you would like to discuss the topic of > "mount info/mount notification" in LSF/MM, so I am resurrecting > this thread [1] from last year's topic. > > Would you be interested to lead a session this year? > So far, it felt like the topic was in a bit of a stalemate. > > Do you have a concrete suggestion of how to escape this stalemate? > I think it is better that we start discussing it a head of LSF/MM if we hope > to reach consensus in LSF/MM, so that people will have a chance to > get re-familiar with the problems and proposed solutions. The reason for the stalemate is possibly that we are not trying to solve the issue at hand... So first of all, here's what we currently have: - reading a process' mount table via /proc/$PID/mountinfo o mount parameters (ID, parent ID, root path, mountpoint path, mount flags, propagation) o super block parameters (devnum, fstype, source, options) o need to iterate the whole list even if interested in just a single mount - notification on mount table change using poll on /proc/$PID/mountinfo o no indication what changed o finding out what changed needs to re-parse possibly the whole mountinfo file o this can lead to performance problems if the table is large and constantly changing - mount ID's do not uniquely identify a mount across time o when a mount is deleted, the ID can be immediately reused The following are the minimal requirements needed to fix the above issues: 1) create a new ID for each mount that is unique across time; lets call this umntid 2) notification needs to indicate the umntid that changed 3) allow querying mount parameters via umntid And I think here's where it gets bogged down due to everyone having their own ideas about how that interface should look like. Proposals that weren't rejected so far: - mount notifications using watch_queue https://lore.kernel.org/all/159645997768.1779777.8286723139418624756.stgit@warthog.procyon.org.uk/ I also explored fsnotify infrastructure for this. I think the API is better fit, since we are talking about filesystem related events, but notifications l would need to be extended with the mount ID. - getxattr(":mntns:$ID:info",...) https://lore.kernel.org/all/YnEeuw6fd1A8usjj@miu.piliscsaba.redhat.com/ Christian would like to see the xattr based interface replaced with a new set of syscalls to avoid confusion with "plain" xattrs. Thanks, Miklos