Issues with Linux kernel oplocks

[Jeremy Allison]

On Tue, Jul 23, 2013 at 02:06:04PM +0200, Ralph Wuerthner wrote:
> 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?

Ouch. Looks like a kernel bug to me. The kernel shouldn't
care who the owner is when sending the lease break signal.

Jeremy.