Issues with Linux kernel oplocks
ralphw at de.ibm.com
Tue Jul 23 06:06:04 MDT 2013
we identified an interesting defect with Samba and Linux kernel oplocks:
Having Samba granted an oplock on a file to a CIFS client. Next a
regular user space application running on the Samba system is trying to
access the same file too. The regular procedure would be that the kernel
sends a signal to the Samba process holding the kernel lease for this
file. Samba would receive the signal and inform the CIFS client about
the lease break and after receiving the client response return the lease
for the file.
Unfortunately in our tests the Linux kernel does not always send the
signal to the Samba process. It turned out that the kernel compares in
sigio_perm() the lock/lease owner (fown) euid/uid with the thread's
suid/uid who needs to receive the signal. If they don't match, no signal
will be send. Because Samba is switching its uids back and forth this
compare might fail and the signal will be not send.
In our particular tests Samba is requesting the lease with uid 11000500,
making uid 11000500 the owner of the lease. If Samba is running as root
when the signal comes the compare fails, the signal is not send and
Samba cannot release the lease.
Any idea what would be the rational of this behaviour in the Linux
kernel? Has somebody seen this before?
More information about the samba-technical