Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3;
From:   David Laight <David.Laight@ACULAB.COM>
To:     'Jeff Layton' <jlayton@kernel.org>,
        Christian Brauner <brauner@kernel.org>,
        Miklos Szeredi <miklos@szeredi.hu>
CC:     Miklos Szeredi <mszeredi@redhat.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
        "linux-man@vger.kernel.org" <linux-man@vger.kernel.org>,
        "linux-security-module@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
Thread-Topic: [RFC PATCH 2/3] add statmnt(2) syscall
Thread-Index: AQHZ6lITJ6lmDHl4dUW3VQsauHaorbAjeA4A
Date:   Wed, 20 Sep 2023 09:43:13 +0000
Message-ID: <ac0f42e8ace2474a941b702fb4fa85a3@AcuMS.aculab.com>
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>
In-Reply-To: <3183d8b21e78dce2c1d5cbc8a1304f2937110621.camel@kernel.org>
Accept-Language: en-GB, en-US
MIME-Version: 1.0
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Precedence: bulk

From: Jeff Layton
> Sent: 18 September 2023 15:30
....
> A bit tangential to this discussion, but one thing we could consider is
> adding something like a mnt_change_cookie field that increments on any
> significant changes on the mount: i.e. remounts with new options,
> changes to parentage or propagation, etc.
> 
> That might make it more palatable to do something with separate syscalls
> for the string-based fields. You could do:
> 
> statmnt(...);
> getmntattr(mnt, "mnt.fstype", ...);
> statmnt(...);
> 
> ...and then if the mnt_change_cookie hasn't changed, you know that the
> string option was stable during that window.

That would also help with the problem of the mount options
being changed while processing a page fault on the user buffer.

Of, with a call to just get the cookie, could find that nothing
has changed so there is no point looking again.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)