Thanks Moritz for providing this information. It seems like a new long-term bug in the client code. The client requested a lease but the server responded with a batch Oplock value (0x9). Since the mount is SMB3.1.1 the client assumes that the server always responds with a lease thus interprets this as a Lease State - 0x9 matches in the bit mask only a READ lease flag (0x1). Later on when the client receives an oplock break from the server caused by the second OPEN, it looks at the caching level which is READ and skips the OPLOCK BREAK ACK step (according to the spec). That's why the app hangs waiting for the oplock break to be timed out. In order to fix it, we would need to tech the client to recognize Oplocks on SMB3+ mounts assuming that the server may return both Oplocks and Leases in response to CREATE command. Ronnie, what is the version of Samba are you using? It is up to the server to decide if Oplock or Lease is returned. -- Best regards, Pavel Shilovsky вт, 24 сент. 2019 г. в 11:12, ronnie sahlberg <ronniesahlberg@xxxxxxxxx>: > > That pcap shows a problem with the lease break. > > I just tried your python reproducer with the current cifs upstream > kernel and the problem does not manifest. > There were oplock related fixes in the cifs.ko module a while ago that > might have fixed the problem you see. > > Which kernel version are you using ? > > > On Tue, Sep 24, 2019 at 10:53 AM Moritz M <mailinglist@xxxxxxxxxxxxxxxx> wrote: > > > > Hi Pavel, > > > > > > > > > Could you please enable debugging logging > > > (https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Enabling_Debugging), > > > reproduce the problem and send us the kernel logs? A network capture > > > of a repro could also be useful > > > (https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Wire_Captures). > > > > see the debug output and the pcap file attached. > > > > Best regards > > Moritz > >
