2017-11-05 5:35 GMT-08:00 Jeff Layton <jlayton@xxxxxxxxxx>: > On Sat, 2017-11-04 at 18:27 -0700, Pavel Shilovsky wrote: >> 2017-11-04 13:51 GMT-07:00 Jeff Layton <jlayton@xxxxxxxxxx>: >> > From: Jeff Layton <jlayton@xxxxxxxxx> >> > >> > Signed-off-by: Jeff Layton <jlayton@xxxxxxxxx> >> > --- >> > mount.cifs.rst | 7 +++++-- >> > 1 file changed, 5 insertions(+), 2 deletions(-) >> > >> > diff --git a/mount.cifs.rst b/mount.cifs.rst >> > index 9714f795fe76..499b9a778927 100644 >> > --- a/mount.cifs.rst >> > +++ b/mount.cifs.rst >> > @@ -517,7 +517,7 @@ prefixpath=arg >> > vers=arg >> > SMB protocol version. Allowed values are: >> > >> > - - 1.0 - The classic CIFS/SMBv1 protocol. This is the default. >> > + - 1.0 - The classic CIFS/SMBv1 protocol. >> > - 2.0 - The SMBv2.002 protocol. This was initially introduced in >> > Windows Vista Service Pack 1, and Windows Server 2008. Note that >> > the initial release version of Windows Vista spoke a slightly >> > @@ -529,6 +529,10 @@ vers=arg >> > Note too that while this option governs the protocol version used, not >> > all features of each version are available. >> > >> > + In kernels v4.13.5 and later, the client and server negotiate a version >> > + greater than or equal to ``2.1``. In kernels prior to v4.13.5, the default >> > + is ``1.0``. >> >> Between v4.13 and v4.13.4 (included) the default is 3.0, not sure if >> we should be so precise here. >> > > Grumble...the merge of that feature outside the normal merge window > makes this difficult to document. How about this? > > The default since v4.13.5 is for the client and server to negotiate > the highest possible version greater than or equal to ``2.1``. In > kernels prior to v4.13, the default was ``1.0``. For kernels > between v4.13 and v4.13.5 the default is ``3.0``. > > It's still awkward, but I think it's correct. Looks good. Reviewed-by: Pavel Shilovsky <pshilov@xxxxxxxxxxxxx> -- Best regards, Pavel Shilovsky -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
