On Fri, 17 Jun 2011 10:40:21 -0500 Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> wrote: > On Fri, Jun 17, 2011 at 9:13 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > On Fri, 17 Jun 2011 08:58:40 -0500 > > Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> wrote: > > > >> On Fri, Jun 17, 2011 at 8:06 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > >> > Hi Shirish, > >> > > >> > I've been working on some backports of some upstream patch series and > >> > have run into what I think is a problem with the new crypto code. The > >> > problem mainly seems to manifest itself as bad signatures in write > >> > calls. This causes a win2k8 server (at least) to reject the call with > >> > STATUS_ACCESS_DENIED and stop responding to other calls on the socket. > >> > > >> > I did a bisect of sorts, and got to this patch: > >> > > >> > commit ca83ce3d5b9ad321ee24f5870a77f0b21ac5a5de > >> > Author: Jeff Layton <jlayton@xxxxxxxxxx> > >> > Date: Tue Apr 12 09:13:44 2011 -0400 > >> > > >> > cifs: don't allow mmap'ed pages to be dirtied while under writeback (try #3) > >> > > >> > My original thought was that something was altering these pages while > >> > they were under writeback, but I did some instrumentation and found > >> > that not to be the case. The signature is the same before and after > >> > the send when this occurs. A key change in this patch is that when > >> > signing is enabled, the code started using CIFSSMBWrite2(), which > >> > marshals up the send buffer in an array of kvecs. > >> > > >> > That leads me to believe that the cifs_sign_smb2 codepath is busted. > >> > > >> > I'll see if I can come up with a testcase, but I'm not that familiar > >> > with the kernel crypto code. Is this something you've seen in your > >> > testing? Any immediate thoughts as to where the problem may be? > >> > > >> > -- > >> > Jeff Layton <jlayton@xxxxxxxxxx> > >> > > >> > > > > (fixing cc list since I goofed it earlier...) > > > >> Jeff, no I have not seen this. You think some iozone testing against > >> a Windows server with the latest cifs code might expose this problem? > >> I will try both Windows 2003 server and Windows 2008 server. > >> > > > > I'm using fsstress against win2k8, and it seems to fail on the initial > > write calls. > > > >> cifs_sign_smb and cifs_sign_smb2 do the same exact thing except that > >> the messages that gets used in signature calculation are different in these > >> routines. > >> > >> My initial thought was/is the same as yours, the content of message > >> used in calculating signature is different at the server and client resulting > >> in different signatures hence dropped smb connection by the server. > >> But it is possible cifs_sign_smb2 and/or cifs_calc_signature2 have a bug! > >> > > > > I did a test where I recalculated the signature after calling smb_sendv > > and then compared it to the original signature and they matched, but > > the server rejected it. I'm still trying to nail down the problem, so > > the bug could be anywhere really. > > > > -- > > Jeff Layton <jlayton@xxxxxxxxxx> > > > > Strange, iozone just hangs when I issue a command against a file on > a Windows 2003 server > > Run began: Fri Jun 17 10:34:13 2011 > > Auto Mode > Command line used: > /usr/src/iozone/iozone3_323/src/current/iozone -a -f /mnt/smb_a/nfile1 > Output is in Kbytes/sec > Time Resolution = 0.000001 seconds. > Processor cache size set to 1024 Kbytes. > Processor cache line size set to 32 bytes. > File stride size set to 17 * record size. > random > random bkwd record stride > KB reclen write rewrite read reread read > write read rewrite read fwrite frewrite fread freread > 64 4 > > The last packets 9n wireshark trace on the server is > > write andx response: status access denied > locking andx request fid: xyz > > and then cifs client reconnects. > > (may be this is the dropping/locking smb connection because signature > in the write andx request is invalid). Right, that's basically what I see. win2k8 just replies with status access denied. I suspect that that's because the signature is incorrect. I've noticed too that it only happens with larger writes. Right now, I'm trying to figure out the size where it breaks. -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
