> 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 > > [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments unless you have verified the sender and know the content is safe. > > 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. Ross
