Re: [PATCH] Using a larger memory to cache filename when decoding FH

[bfields@fieldses.org (J. Bruce Fields)]

On Sat, Mar 23, 2019 at 09:46:33PM +0800, Pei-Feng liu wrote:
> The maximum length of filename string in 'fs/exportfs/expfs.c' is limited to be
> 'NAME_MAX'. But I have a special filesystem driver with longer filename.

That's interesting.  I'm sort of surprised that other parts of the
kernel or libc don't rely on the NAME_MAX assumption.

Anyway, we probably can't consider this for upstream unless the
filesystem driver that needs it is also upstream.

--b.

> When
> exporting it's namespace with NFS, 'exportfs_decode_fh()' can't holds the
> filename if its length is larger than 'NAME_MAX'. And 'dentry' in VFS layer
> doesn't contrain the length of filename within 'NAME_MAX'. I guess the correct
> method is firstly probe the length of filename with 'vfs_statfs()'. With this
> value to malloc a larger enough memory to cache the filename when decoding a FH.
> 
> Pei-Feng liu (1):
>   fs/exportfs: Decoding FH with a larger memory to cache the filename.
> 
>  fs/exportfs/expfs.c | 30 +++++++++++++++++++++++++++++-
>  1 file changed, 29 insertions(+), 1 deletion(-)
> 
> -- 
> 1.8.3.1