On Tue, Aug 19, 2025 at 8:03 PM Viacheslav Dubeyko
<Slava.Dubeyko@xxxxxxx> wrote:
>
> On Tue, 2025-08-19 at 19:31 +0530, Kotresh Hiremath Ravishankar wrote:
> > On Wed, Aug 13, 2025 at 11:52 PM Viacheslav Dubeyko
> > <Slava.Dubeyko@xxxxxxx> wrote:
> > >
> > >
>
> <skipped>
>
> > >
> > > OK. I agree that restriction creation of filesystem names greater than NAME_MAX
> > > length should be considered as independent task.
> > >
> >
> > Are you suggesting to use the inline buffer for fsname with NAME_MAX
> > as the limit
> > with this patch ?
> >
>
> Potentially, inline buffer for fsname could be better solution. However, if the
> user-space side can create the name bigger than NAME_MAX, currently, then we
> cannot afford the inline buffer yet for this patch.
We have had many instances of the kernel client not supporting (e.g.
by refusing the mount or continuously throwing an error after mounting)
something that is possible or even officially supported on the
userspace side. The most recent example is the case-folding feature,
before that the big one was limited support for inline data, no support
for the old way of doing quotas, etc. If justified, I don't see
anything wrong with restricting the length of the FS name irrespective
of whether it remains a dynamically allocated string or gets an inline
buffer. The userspace side can catch up and implement the create-time
check that would generate an appropriate warning or just fail the
creation of the filesystem later.
Thanks,
Ilya
