On Wed, 12 Oct 2011 14:28:42 -0500 Steve French <smfrench@xxxxxxxxx> wrote: > On Wed, Oct 12, 2011 at 2:22 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > On Wed, 12 Oct 2011 14:06:13 -0500 > > Steve French <smfrench@xxxxxxxxx> wrote: > > > >> On Wed, Oct 12, 2011 at 12:25 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > >> > On Wed, 12 Oct 2011 12:15:29 -0500 > >> > Steve French <smfrench@xxxxxxxxx> wrote: > >> > > >> >> Reviewing changes to fs/cifs/connect.c in > >> >> http://git.samba.org/?p=jlayton/linux.git;a=commit;h=b82a25501cb18b86fd247da15c886762fdc5404c > >> >> > >> >> It looks like the following logic changes from setting rsize to what > >> >> the server claims it can support (negotiated maxBuf) to what our > >> >> maximum buffer size is: > >> >> > >> >> @@ -3130,8 +3130,7 @@ try_mount_again: > >> >> cFYI(DBG2, "no very large read support, rsize now 127K"); > >> >> } > >> >> if (!(tcon->ses->capabilities & CAP_LARGE_READ_X)) > >> >> - cifs_sb->rsize = min(cifs_sb->rsize, > >> >> - (tcon->ses->server->maxBuf - MAX_CIFS_HDR_SIZE)); > >> >> + cifs_sb->rsize = min(cifs_sb->rsize, CIFSMaxBufSize); > >> >> > >> >> > >> >> Is that what we want? > >> >> > >> > > >> > I think so, yes. That's part of untangling the mess. > >> > > >> > According to the protocol docs, the server should only be bound by the > >> > client's MaxBufSize for reads. Therefore, the maxBuf advertised by the > >> > server should have no bearing on the rsize. > >> > >> That may be true, but the following phrase in the description of > >> SMB Read (not ReadX) worried me: > >> > >> "If a read requests more data than can be placed in a message of > >> MaxBufferSize for the SMB > >> connection, the server MUST abort the connection to the client." > >> > > > > I don't think that cifs.ko ever does old-school SMB Read calls, does > > it? We don't seem to even have the command defined in cifspdu.h... > > We don't do the older SMB Read, but it brought up the obvious > question - would a server process the newer SMB ReadX and > and the older style read the same way when evaluating that > read size is not too large. > > In any case - probably safe enough as you noted. > I'm not sure -- most servers from this millenium set CAP_LARGE_READX so the point is somewhat moot... It's hard to get too worked up on the others, but I'll note that MS-CIFS is a bit unclear on this point. In most places it seems to treat the client and server's MaxBufferSize independently. But, in some places (like the above quote you pointed out), it seems to co-mingle them and refer to a MaxBufferSize for the connection. In any case, for READ_ANDX, I used this quote as my guide, which seems to indicate that only the client's MaxBufferSize matters for reads: "If reading the requested number of bytes would lead to a response message size larger than the established Server.Connection.ClientMaxBufferSize and Server.Connection.ClientCapabilities does not have CAP_LARGE_READX set, the server MUST abort the connection to the client. If Server.Connection.ClientCapabilities has CAP_LARGE_READX set, the response message MAY exceed the negotiated buffer size if the FID refers to a disk file." -- Jeff Layton <jlayton@xxxxxxxxxx>
Attachment:
signature.asc
Description: PGP signature
