Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7;
Date:   Mon, 18 Sep 2023 16:24:55 +0200
From:   Christian Brauner <brauner@kernel.org>
To:     Miklos Szeredi <mszeredi@redhat.com>
Cc:     Miklos Szeredi <miklos@szeredi.hu>,
        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-hierbei-erhielten-ba5ef74a5b52@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>
 <CAJfpegt-VPZP3ou-TMQFs1Xupj_iWA5ttC2UUFKh3E43EyCOQQ@mail.gmail.com>
 <20230918-grafik-zutreffen-995b321017ae@brauner>
 <CAOssrKfS79=+F0h=XPzJX2E6taxAPmEJEYPi4VBNQjgRR5ujqw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAOssrKfS79=+F0h=XPzJX2E6taxAPmEJEYPi4VBNQjgRR5ujqw@mail.gmail.com>
Precedence: bulk

On Mon, Sep 18, 2023 at 04:14:02PM +0200, Miklos Szeredi wrote:
> On Mon, Sep 18, 2023 at 3:51 PM Christian Brauner <brauner@kernel.org> wrote:
> 
> > I really would prefer a properly typed struct and that's what everyone
> > was happy with in the session as well. So I would not like to change the
> > main parameters.
> 
> I completely  agree.  Just would like to understand this point:
> 
>   struct statmnt *statmnt(u64 mntid, u64 mask, unsigned int flags);
> 
> What's not properly typed about this interface?
> 
> I guess the answer is that it's not a syscall interface, which will
> have an added [void *buf, size_t bufsize], while the buffer sizing is
> done by a simple libc wrapper.
> 
> Do you think that's a problem?  If so, why?

Sorry, I think we just talked passed each other.
I didn't realize you were talking about a glibc wrapper.
I'm not so much concerned with that they can expose this in whathever
way they like. But we will have a lot of low-level userspace that will
directly use statmount() or not even have glibc like go and other
languages.

The system call should please have a proper struct like you had in your
first proposal. This is what I'm concerned about:

int statmount(u64 mnt_id,
              struct statmnt __user *st,
              size_t size,
              unsigned int flags)

instead of taking an void pointer.