Steve, All Review but do not merge to for-next. This patch still breaks SMBD. I have tested the patch with SMB1/2/3 with and without signing as well as with SMB3 encryption and it works in my tests. The first patch removes the rfc1002 length from all the response structures hopefully making it easier to implement compounding later. It also gets rid of a lot of magic add/subtract 4 from various computations. The second patch updates the demultiplex loop so that it will now be able to handle compounded responses we receive from the server. In theory, we will not know it this works until we can actually send compounded requests. Next steps will be to start implementing the actual compounding. That, I think, will consist of refactoring the SMB2_open/query/close functions into dedicated marshalling functions and then create a new compound_send_recv() function. The second part will require some additional plumbing. In smb2_send_recv() we currently create iovectors as [0] length [1] smb2 header [2+] additional data or, when smb3 encryption is used [0] length [1] transform header [2] smb2 header [3+] additional data Instead, in compound_send_recv() we will need to create an array of iovectors, one for each pdu, that would look like [0] smb2 header [1+] additional data and similar for smb3 encryption. These iovectors would then be propagated down the stack without an initial length field until we are ready to transmit them. So, for the TCP case, we would not prepend the vectors we want to send with a [0] length field until the point where we are just about to start writing the data to the tcp socket. That shouldnt be too hard. But we need these patches first. -- 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