Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley
        Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United
        Kingdom.
        Registered in England and Wales under Company Registration No. 3798903
From:   David Howells <dhowells@redhat.com>
In-Reply-To: <20200804104108.GC32719@miu.piliscsaba.redhat.com>
References: <20200804104108.GC32719@miu.piliscsaba.redhat.com> <159646178122.1784947.11705396571718464082.stgit@warthog.procyon.org.uk> <159646183662.1784947.5709738540440380373.stgit@warthog.procyon.org.uk>
To:     Miklos Szeredi <miklos@szeredi.hu>
Cc:     dhowells@redhat.com, viro@zeniv.linux.org.uk,
        torvalds@linux-foundation.org, raven@themaw.net,
        mszeredi@redhat.com, christian@brauner.io, jannh@google.com,
        darrick.wong@oracle.com, kzak@redhat.com, jlayton@redhat.com,
        linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org,
        linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 06/18] fsinfo: Add a uniquifier ID to struct mount [ver #21]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2306028.1596636828.1@warthog.procyon.org.uk>
Content-Transfer-Encoding: quoted-printable
Date:   Wed, 05 Aug 2020 15:13:48 +0100
Message-ID: <2306029.1596636828@warthog.procyon.org.uk>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Miklos Szeredi <miklos@szeredi.hu> wrote:

> > +#ifdef CONFIG_FSINFO
> > +	u64	mnt_unique_id;		/* ID unique over lifetime of kernel */
> > +#endif
>
> Not sure if it's worth making conditional.

You can't get at it without CONFIG_FSINFO=3Dy as it stands, but making it
unconditional might be reasonable.

> > -		n.auxiliary_mount	=3D aux->mnt_id;
> > +		n.auxiliary_mount =3D aux->mnt_unique_id;
>
> Hmm, so we now have two ID's:
>
>  - one can be used to look up the mount
>  - one is guaranteed to be unique
>
> With this change the mount cannot be looked up with FSINFO_FLAGS_QUERY_M=
OUNT,
> right?
>
> Should we be merging the two ID's into a single one which has both prope=
rties?

Ideally, yes... but...  The 31-bit mnt_id is currently exposed to userspac=
e in
various places, e.g. /proc, sys_name_to_handle_at().  So we have to keep t=
hat
as is and we can't expand it.

For fsinfo(), however, it might make sense to only use the 64-bit uniquifi=
er
as the identifier to use for direct look up.

However, looking up that identifier requires some sort of structure for do=
ing
this and it's kind of worst case for the IDR tree as the keys are graduall=
y
going to spread out, causing it to eat more memory.  It may be a tradeoff
worth making, and the memory consumption might not be that bad - or we cou=
ld
use some other data structure such as an rbtree.

That's why I was going for the 31-bit identifier + uniquifier so that you =
can at
least tell if the identifier got recycled reasonably quickly.

David