> From: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx> > Sent: Wednesday, May 17, 2023 2:48 PM > To: Tom Talpey <tom@xxxxxxxxxx>; Ralph Boehme <slow@xxxxxxxxx>; linux-cifs@xxxxxxxxxxxxxxx <linux-cifs@xxxxxxxxxxxxxxx> > Cc: Steve French <sfrench@xxxxxxxxx>; Paulo Alcantara <pc@xxxxxx>; Ronnie Sahlberg <lsahlber@xxxxxxxxxx>; Shyam Prasad N <sprasad@xxxxxxxxxxxxx>; Rohith Surabattula <rohiths@xxxxxxxxxxxxx> > Subject: Re: [PATCH] cifs: Close deferred files that may be open via hard links > > > From: Tom Talpey <tom@xxxxxxxxxx> > > Sent: Wednesday, May 17, 2023 2:24 PM > > To: Ralph Boehme <slow@xxxxxxxxx>; Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>; linux-cifs@xxxxxxxxxxxxxxx <linux-cifs@xxxxxxxxxxxxxxx> > > Cc: Steve French <sfrench@xxxxxxxxx>; Paulo Alcantara <pc@xxxxxx>; Ronnie Sahlberg <lsahlber@xxxxxxxxxx>; Shyam Prasad N <sprasad@xxxxxxxxxxxxx>; Rohith Surabattula <rohiths@xxxxxxxxxxxxx> > > Subject: Re: [PATCH] cifs: Close deferred files that may be open via hard links > > > > On 5/17/2023 6:50 AM, Ralph Boehme wrote: > > > On 5/17/23 10:27, Ross Lagerwall wrote: > > >> In any case, I have attached a packet trace from running the above > > >> Python reproducer. > > > > > > afaict the STATUS_INVALID_PARAMETER comes from the lease code as you're > > > passing the same lease key for the open on the link which is illegal afair. > > > > > > Can you retry the experiment without requesting a lease or ensuring the > > > second open on the link uses a different lease key? > > > > Indeed, the same lease key is coming in both opens, first in > > packet 3 where it opens "test", and again in packet 18 where > > it opens the link "new". So it's triggering this assertion in > > MS-SMB2 section 3.3.5.9.11 > > > > > The server MUST attempt to locate a Lease by performing a lookup in the LeaseTable.LeaseList > > > using the LeaseKey in the SMB2_CREATE_REQUEST_LEASE_V2 as the lookup key. If a lease is found, > > > Lease.FileDeleteOnClose is FALSE, and Lease.Filename does not match the file name for the > > > incoming request, the request MUST be failed with STATUS_INVALID_PARAMETER > > > > Steve/Rohith, is this new behavior in the client code? > > > > Tom. > > It looks like smb2_get_lease_key() returns the lease key stored in the > inode, which clearly breaks that assertion when hard links are > involved. > > I can confirm that when the lease keys are forced to be different, the > test does not fail. > Hi, Am I correct in the assertion that the client is associating lease keys with the inode and that is incompatible with the spec (at least when hard links are involved)? A brief look at the code suggests changing that would be somewhat involved... At least more work than I have time to spare at the moment. Thanks, Ross
