Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
Date:   Mon, 18 Sep 2023 16:35:09 +0200
From:   Christian Brauner <brauner@kernel.org>
To:     Jeff Layton <jlayton@kernel.org>
Cc:     Miklos Szeredi <miklos@szeredi.hu>,
        Miklos Szeredi <mszeredi@redhat.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        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 <kzak@redhat.com>,
        Ian Kent <raven@themaw.net>,
        David Howells <dhowells@redhat.com>,
        Al Viro <viro@zeniv.linux.org.uk>,
        Christian Brauner <christian@brauner.io>,
        Amir Goldstein <amir73il@gmail.com>
Subject: Re: [RFC PATCH 2/3] add statmnt(2) syscall
Message-ID: <20230918-geber-kruste-f9491ce3de41@brauner>
References: <20230913152238.905247-1-mszeredi@redhat.com>
 <20230913152238.905247-3-mszeredi@redhat.com>
 <20230914-salzig-manifest-f6c3adb1b7b4@brauner>
 <CAJfpegs-sDk0++FjSZ_RuW5m-z3BTBQdu4T9QPtWwmSZ1_4Yvw@mail.gmail.com>
 <20230914-lockmittel-verknallen-d1a18d76ba44@brauner>
 <3183d8b21e78dce2c1d5cbc8a1304f2937110621.camel@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <3183d8b21e78dce2c1d5cbc8a1304f2937110621.camel@kernel.org>
Precedence: bulk

> Fixed size structs are much nicer to deal with, and most of the fields
> we're talking about don't change ofetn enough to make trying to strive
> for perfect atomicity worthwhile.

I think we can live with mnt_root and mnt_mountpoint in struct statmnt
if we add a length field for both them and make them __u64 pointers.
That's what we did in clone3() for the pid array and bpf is doing that
as well for log buffers and pathnames.

So if Miklos is fine with that then I'm happy to compromise. And I think
that's all the variable length data we want in struct statmount anyway.

> ...and then if the mnt_change_cookie hasn't changed, you know that the
> string option was stable during that window.

Meh, I would really like to sidestep this and keep it as simple as we
can. I like the proposal overall I just don't want it to get diluted too
much by exploding into another overly broad solution.