Question on how smbd handles signals (possible bug)

[tvrtko.ursulin at sophos.com]

Volker Lendecke <Volker.Lendecke at SerNet.DE> wrote on 23/09/2008 18:21:11:

> On Tue, Sep 23, 2008 at 06:09:15PM +0100, tvrtko.ursulin at sophos.com 
wrote:
> > Are you 100% sure about this? I wasn't so I went to read about it and 
> > found at least that you can make open block if you set a lease on the 
> > file. Man page for fcntl (on modern Linux at least) describes this in 
the 
> > 'Leases' section. It says that an open (and truncate) can be blocked 
until 
> > the process holding a lease on that file releases it. If a signal 
arrives 
> > at that point EINTR is documented to happen.
> 
> Ok, which process is sending us the signal? In normal
> operations, this should not happen. The only signal that we
> expect here is the TERM signal which shuts us down anyway.

I don't know - I thought it's something internal? Grepping throught the 
source code I found:

./smbd/aio.c:#define RT_SIGNAL_AIO (SIGRTMIN+3)
./smbd/oplock_linux.c:#define RT_SIGNAL_LEASE (SIGRTMIN+1)

One of these two perhaps? But I failed to figure out how they match this 
from the strace:

6219  --- SIGRT_4 (Real-time signal 2) @ 0 (0) ---

Let alone how SIGRT_4 == Real-time signal 2 ? 

smbd/aio.c in initialize_async_io_handler definitely sets up a signal 
handler without SA_RESTART, and linux_init_kernel_oplocks in 
smbd/oplock_linux.c does the same. I just don't know does any of these two 
in fact is SIGRT_4 as logged by strace...

Tvrtko


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

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