Presumably a symlink could be up to PATH_MAX (4096), is there any reason not to fix the client side to be able to handle at least 4096? Any ideas how common long symlink target paths are? On Mon, Nov 18, 2024 at 9:35 AM Paulo Alcantara <pc@xxxxxxxxxxxxx> wrote: > > We can't use PATH_MAX for SMB symlinks because > > (1) Windows Server will fail FSCTL_SET_REPARSE_POINT with > STATUS_IO_REPARSE_DATA_INVALID when input buffer is larger than > 16K, as specified in MS-FSA 2.1.5.10.37. > > (2) The client won't be able to parse large SMB responses that > includes SMB symlink path within SMB2_CREATE or SMB2_IOCTL > responses. > > Fix this by defining a maximum length value (4060) for SMB symlinks > that both client and server can handle. > > Cc: David Howells <dhowells@xxxxxxxxxx> > Signed-off-by: Paulo Alcantara (Red Hat) <pc@xxxxxxxxxxxxx> > --- > fs/smb/client/reparse.c | 5 ++++- > fs/smb/client/reparse.h | 2 ++ > 2 files changed, 6 insertions(+), 1 deletion(-) > > diff --git a/fs/smb/client/reparse.c b/fs/smb/client/reparse.c > index 74abbdf5026c..90da1e2b6217 100644 > --- a/fs/smb/client/reparse.c > +++ b/fs/smb/client/reparse.c > @@ -35,6 +35,9 @@ int smb2_create_reparse_symlink(const unsigned int xid, struct inode *inode, > u16 len, plen; > int rc = 0; > > + if (strlen(symname) > REPARSE_SYM_PATH_MAX) > + return -ENAMETOOLONG; > + > sym = kstrdup(symname, GFP_KERNEL); > if (!sym) > return -ENOMEM; > @@ -64,7 +67,7 @@ int smb2_create_reparse_symlink(const unsigned int xid, struct inode *inode, > if (rc < 0) > goto out; > > - plen = 2 * UniStrnlen((wchar_t *)path, PATH_MAX); > + plen = 2 * UniStrnlen((wchar_t *)path, REPARSE_SYM_PATH_MAX); > len = sizeof(*buf) + plen * 2; > buf = kzalloc(len, GFP_KERNEL); > if (!buf) { > diff --git a/fs/smb/client/reparse.h b/fs/smb/client/reparse.h > index 158e7b7aae64..2a9f4f9f79de 100644 > --- a/fs/smb/client/reparse.h > +++ b/fs/smb/client/reparse.h > @@ -12,6 +12,8 @@ > #include "fs_context.h" > #include "cifsglob.h" > > +#define REPARSE_SYM_PATH_MAX 4060 > + > /* > * Used only by cifs.ko to ignore reparse points from files when client or > * server doesn't support FSCTL_GET_REPARSE_POINT. > -- > 2.47.0 > -- Thanks, Steve