Question on how smbd handles signals (possible bug)

tvrtko.ursulin at sophos.com tvrtko.ursulin at sophos.com
Thu Sep 25 09:39:08 GMT 2008


Volker Lendecke <Volker.Lendecke at SerNet.DE> wrote on 24/09/2008 18:13:55:

> On Wed, Sep 24, 2008 at 10:40:54AM +0100, tvrtko.ursulin at sophos.com 
wrote:
> 
> > This suggest that Samba is expecting signals from lock breakers in 
order 
> > to release files but that is not in line with what you just said. So I 
am 
> > confused. Why it should be necessary to turn off oplocks, even the man 

> > page says that should never be needed?
> 
> The problem is that so far nobody but Samba makes use of the
> lease calls, so we might have bugs here. Your host
> apparently has an application that takes oplocks, and this
> is a new situation. Timely responding to external oplock
> break signals under all circumstances is a major rewrite
> that will not be done soon.

I will try and collect information on what else is running on the machine 
and get back to you with that. In the meantime, could you help me 
understand what you think is happening and how it is related to "kernel 
oplocks = yes"? (and I will also find out if setting this option to "no" 
helps)

If the only problem is Samba was not expecting to find itself in a lock 
breaker role, or in other words to sleep in open on a locked file, while 
at the same time possibly receiving signals caused by the fact it is also 
holding leases/locks itself, then the only problem is that EINTR from open 
should be handled. It wouldn't change any behaviour becuase it only 
changed the assumption that open cannot block and therefore cannot be 
interrupted by a signal in which case patch like you posted earlier could 
be sufficient? 

Code which handles lock-break signals would still be called and do 
whatever it currently does. No?

Am I missing something?

Tvrtko


Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,
OX14 3YP, United Kingdom.

Company Reg No 2096520. VAT Reg No GB 348 3873 20.



More information about the samba-technical mailing list