Issues with Linux kernel oplocks

[Ralph Wuerthner]

Hi,

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?

Regards

   Ralph