On Fri, Feb 7, 2025 at 6:39 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
> On Fri, Feb 7, 2025 at 4:46 PM Christian Brauner <brauner@xxxxxxxxxx> wrote:
> >
> > Let FSCONFIG_SET_FD handle O_PATH file descriptors. This is particularly
> > useful in the context of overlayfs where layers can be specified via
> > file descriptors instead of paths. But userspace must currently use
> > non-O_PATH file desriptors which is often pointless especially if
> > the file descriptors have been created via open_tree(OPEN_TREE_CLONE).
> >
>
> Shall we?
> Fixes: a08557d19ef41 ("ovl: specify layers via file descriptors")
>
> I think that was the intention of the API and we are not far enough to fix
> it in 6.12.y.
>
Oh it's not in 6.12. it's in 6.13, so less important to backport I guess.
Thanks,
Amir.
>
> > Signed-off-by: Christian Brauner <brauner@xxxxxxxxxx>
> > ---
> > fs/fs_parser.c | 12 +++++++-----
> > fs/fsopen.c | 7 +++++--
> > fs/overlayfs/params.c | 10 ++++++----
> > include/linux/fs_context.h | 1 +
> > include/linux/fs_parser.h | 6 +++---
> > 5 files changed, 22 insertions(+), 14 deletions(-)
> >
> > diff --git a/fs/fs_parser.c b/fs/fs_parser.c
> > index e635a81e17d9..35aaea224007 100644
> > --- a/fs/fs_parser.c
> > +++ b/fs/fs_parser.c
> > @@ -310,15 +310,17 @@ int fs_param_is_fd(struct p_log *log, const struct fs_parameter_spec *p,
> > }
> > EXPORT_SYMBOL(fs_param_is_fd);
> >
> > -int fs_param_is_file_or_string(struct p_log *log,
> > - const struct fs_parameter_spec *p,
> > - struct fs_parameter *param,
> > - struct fs_parse_result *result)
> > +int fs_param_is_raw_file_or_string(struct p_log *log,
>
> Besides being too long of a helper name I do not think
> that it correctly reflects the spirit of the question.
>
> The arguments for overlayfs upperdir/workdir/lowerdir+/datadir+
> need to be *a path*, either a path string, or an O_PATH fd and
> maybe later on also dirfd+name.
>
> I imagine that if other filesystems would want to use this parser
> helper they would need it for the same purpose.
>
> Can we maybe come up with a name that better reflects that
> intention?
>
> > + const struct fs_parameter_spec *p,
> > + struct fs_parameter *param,
> > + struct fs_parse_result *result)
> > {
> > switch (param->type) {
> > case fs_value_is_string:
> > return fs_param_is_string(log, p, param, result);
> > case fs_value_is_file:
> > + fallthrough;
> > + case fs_value_is_raw_file:
> > result->uint_32 = param->dirfd;
> > if (result->uint_32 <= INT_MAX)
> > return 0;
> > @@ -328,7 +330,7 @@ int fs_param_is_file_or_string(struct p_log *log,
> > }
> > return fs_param_bad_value(log, param);
> > }
> > -EXPORT_SYMBOL(fs_param_is_file_or_string);
> > +EXPORT_SYMBOL(fs_param_is_raw_file_or_string);
> >
> > int fs_param_is_uid(struct p_log *log, const struct fs_parameter_spec *p,
> > struct fs_parameter *param, struct fs_parse_result *result)
> > diff --git a/fs/fsopen.c b/fs/fsopen.c
> > index 094a7f510edf..3b5fc9f1f774 100644
> > --- a/fs/fsopen.c
> > +++ b/fs/fsopen.c
> > @@ -451,11 +451,14 @@ SYSCALL_DEFINE5(fsconfig,
> > param.size = strlen(param.name->name);
> > break;
> > case FSCONFIG_SET_FD:
> > - param.type = fs_value_is_file;
> > ret = -EBADF;
> > - param.file = fget(aux);
> > + param.file = fget_raw(aux);
> > if (!param.file)
> > goto out_key;
> > + if (param.file->f_mode & FMODE_PATH)
> > + param.type = fs_value_is_raw_file;
> > + else
> > + param.type = fs_value_is_file;
> > param.dirfd = aux;
>
> Here it even shouts more to me that the distinction is not needed.
>
> If the parameter would be defined as
> fsparam_path_description("workdir", Opt_workdir),
> and we set param.type = fs_value_is_path_fd;
> unconditional to f_mode & FMODE_PATH, because we
> do not care if fd is O_PATH or not for the purpose of this parameter
> we only care that the parameter *can* be resolved to a path
> and *how* to resolve it to a path, and the answer to those questions
> does not change depending on _mode & FMODE_PATH.
>
> I admit that that's a very long rant about a mostly meaningless nuance,
> and I was also not very involved in the development of the new mount API
> so there may be things about it that I don't understand, so feel free to
> dismiss this rant and add my Ack if you do not share my concerns.
>
> Thanks,
> Amir.
