On a customer system with "kernel oplocks = yes" and named streams (vfs_fruit and vfs_streams_xattr), I'm seeing the following the logs: [2017/05/12 15:31:18.526757, 0, pid=25666] ../source3/lib/util.c:791(smb_panic_s3) PANIC (pid 25666): Kernel oplock holder didn't respond to break message and [2017/05/11 15:25:06.026989, 0, pid=35643] ../source3/smbd/oplock_linux.c:184(linux_release_kernel_oplock) linux_release_kernel_oplock: Error when removing kernel oplock on file ... Error was Resource temporarily unavailable This is with 4.6.3. Still investigating, but I can reproduce the second message with an smbtorture test modelled after the failure from a pcap. The problem is related to opening the base file for a stream from vfs_streams_xattr when there's an existing kernel oplock on the file. Looks like the previous fix for bug #7537 doesn't work for all cases. I'm currently testing a fix which involves a larger change to vfs_streams_xattr to not return and use real fds anymore. All filesytem IO operations are converted to path based versions and streams_xattr_open() will just return a dupped pipe fd.
Created attachment 13459 [details] Patch for 4.5 an 4.6 backported from master
Created attachment 13460 [details] Patch for 4.7 cherry-picked from master
Pushed to autobuild-v4-{7,6,5}-test.
(In reply to Karolin Seeger from comment #3) Pushed to all branches. Closing out bug report. Thanks!