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 33739C6FD18 for ; Wed, 19 Apr 2023 08:43:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232626AbjDSIny (ORCPT ); Wed, 19 Apr 2023 04:43:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53072 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231902AbjDSInv (ORCPT ); Wed, 19 Apr 2023 04:43:51 -0400 Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2527A86B1 for ; Wed, 19 Apr 2023 01:43:48 -0700 (PDT) Received: by mail-ej1-x62a.google.com with SMTP id u3so27634286ejj.12 for ; Wed, 19 Apr 2023 01:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; t=1681893826; x=1684485826; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=PoaJl359qZUYDJa00LijMCBeZ9q8sK607R/iQiV1/HA=; b=BXBbL/9e5Z/e16fIKN825T7HQfMsjkYbzeD1Ok1tQbttzq1uDjBEhUIzju71+s/hTN rSAQWcYuMavpcUUu2pIa6yqOy4VCUfocRm2PqBjocjDOiY/Nn0C/NAcYLsA1n4HzXYqT iDBMJfHWKMMd8eA7xrCuf3JxLrqq9V7YU4E2U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681893826; x=1684485826; h=content-transfer-encoding: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=PoaJl359qZUYDJa00LijMCBeZ9q8sK607R/iQiV1/HA=; b=Z47uUTKwAT+hL5F7llJIImZQM0sY/jJaVco1925mnBSNYpqx2cgcKyK3DJ9WWRvskY 9I4VNxVLJI4AghmyrqP3w+0ZmDJEEe0PZ4Q7B06Mu7Y+IlJZfeh/E33YAeXqtL8voluZ J/82Zz9zNqsb8Kj7FR6FnFw0cnCqHTzXqF+lK4fQgv7+vu90HcelLJoSrKMwuQViYDW4 f/zWUN5loWv3Kt3tHUrfFy9LcOYwOKtrnjfIWTaFhTdzQIUk3pOrvtdewKLPyTY5PVdl gDrefqvmMhueo52SqKeaTrF/9OrEzF1D0fU81kuRQgKr9eNRB07nvxGLtpnjdIDJGsnJ vuOA== X-Gm-Message-State: AAQBX9dQEvfP68L9V12EtsmKrFdV/MMNyZ67ZzcTr9++6VlX+h+moURE MlEozLMleUIs7vzeqE2mp7IOGdRdzvovBOZSiIRbjA== X-Google-Smtp-Source: AKy350akRy72DX1DUVKexX0fDjnJbHEwbEfB+W1QMyjRxbW6iLu1mB89PVLcrbsjXK09tOFrkIAFDKqDPmOTywH4kd8= X-Received: by 2002:a17:906:3a4b:b0:94e:d72b:d10c with SMTP id a11-20020a1709063a4b00b0094ed72bd10cmr13302303ejf.40.1681893826528; Wed, 19 Apr 2023 01:43:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Miklos Szeredi Date: Wed, 19 Apr 2023 10:43:35 +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" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Wed, 19 Apr 2023 at 10:18, Amir Goldstein wrote: > > On Tue, Apr 18, 2023 at 9:57 PM Miklos Szeredi wrote: > > > > On Tue, 18 Apr 2023 at 17:57, Amir Goldstein wrote= : > > > > > > On Tue, Apr 18, 2023 at 11:54=E2=80=AFAM Miklos Szeredi wrote: > > > > > > - 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 > > > > > > > > > > Do you reckon we just stop recycling mntid? > > > Do we also need to make it 64bit? > > > statx() has already allocated 64bit for stx_mnt_id. > > > In that case, should name_to_handle_at() return a truncated mnt_id? > > > > I'm not sure it's realistic to implement the new 64bit ID such that > > the truncated value retains the properties of the previous mount ID > > implementation. > > > > I think the only sane option is to leave the old mnt_id alone and add > > a new 64bit one that is assigned from an atomic counter at allocation > > and looked up using a hash table. > > > > At the risk of shoehorning, that sounds a bit like file_handle of a mount= . > Meaning that it could be the result of > > name_to_handle_at(...,&mount_handle, &mount_id, AT_MNTID) > > We can possibly use open_by_handle_at() to get a mountfd from > mount_handle - not sure if that makes sesnse. > There are conceptual similarities, yes. Whether reusing the file handle interfaces makes sense or not is another question. > [...] > > > > > 3) allow querying mount parameters via umntid > > I forgot to mention in the context of this topic, that there was a > topic proposal > about using "BFP iterator" [1] to query fs/mount info. > > I don't know if that can be used to get namespace change notifications > or if it meets other requirements (i.e. permissions), but wanted to > mention it here. > > I think we can discuss both topics in the same session. Okay. Thanks, Miklos