Thanks for reporting the issue. The problem is with the recent fix which changes the error code from -EINTR to -ERESTARTSYS: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/cifs/transport.c?id=6988a619f5b79e4efadea6e19dcfe75fbcd350b5 and this problem happens here: https://git.samba.org/sfrench/?p=sfrench/cifs-2.6.git;a=blob;f=fs/cifs/smb2pdu.c;h=067eb44c7baa863c1e7ccd2c2f599be0b067f320;hb=236237ab6de1cde004b0ab3e348fc530334270d5#l3251 So, interrupted close commands don't get restarted by the client and the client leaks open handles on the server. The offending patch was tagged stable, so the fix seems quite urgent. The fix itself should be simple: replace -EINTR with -ERESTARTSYS in the IF condition or even amend it with "||". Adding Paulo and Steve to comment. -- Best regards, Pavel Shilovsky ср, 13 янв. 2021 г. в 04:31, Aurélien Aptel <aaptel@xxxxxxxx>: > > Duncan Findlay <duncf@xxxxxxxx> writes: > > There seems to be a problem with the CIFS module in Linux 5.10. Files > > that are opened and not cleanly closed end up in an inconsistent > > state. This can be triggered by writing to a file and interrupting the > > writer with Ctrl-C. Once this happens, attempting to delete the file > > causes access to the mount to hang. Afterwards, the files are visible > > to ls, but cannot be accessed or deleted. > > > > I'm running Debian unstable with a Debian unstable kernel > > (5.10.5-1). I attempted to but could not reproduce this with a 4.19 kernel. > > > > > > Repro steps: > > > > $ sudo mount -t cifs //test/share /mnt/test --verbose -o > > rw,user,auto,nosuid,uid=user,gid=user,vers=3.1.1,credentials=/home/user/tmp/creds > > $ mkdir /mnt/test/subdir > > $ cat > /mnt/test/subdir/foo > > [ Hit Ctrl-C to interrupt ] > > $ ls /mnt/test/subdir/ > > foo > > $ rm /mnt/test/subdir/foo > > [ Hangs for 35 seconds, errors in dmesg log -- see below ] > > $ ls /mnt/test/subdir/ > > foo > > $ stat /mnt/test/subdir/foo > > stat: cannot statx '/mnt/test/subdir/foo': No such file or directory > > > > At this point, the file still exists on the server side, and > > restarting the server causes it to be deleted. > > > > I can provide pcaps if necessary. It looks like with 4.19, when the > > cat command is killed, the client sends a Close Request, and on 5.10 > > no commands are sent. > > I can reproduce this on Steve's current for-next branch but only against > a Samba server. > > On Windows server, doing ^C kills cat properly but the output file is > never created, which is also a bug. > > Cheers, > -- > Aurélien Aptel / SUSE Labs Samba Team > GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 > SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE > GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München) >
