Date:   Mon, 25 Mar 2019 19:21:13 -0400
To:     Pei-Feng liu <liupeifeng@horiscale.com>
Cc:     linux-nfs@vger.kernel.org
Subject: Re: [PATCH] Using a larger memory to cache filename when decoding FH
Message-ID: <20190325232113.GB23190@fieldses.org>
References: <1553348794-4505-1-git-send-email-liupeifeng@horiscale.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1553348794-4505-1-git-send-email-liupeifeng@horiscale.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
From:   bfields@fieldses.org (J. Bruce Fields)
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

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