[SCM] Samba Shared Repository - branch master updated - release-4-0-0alpha8-1366-gbdc7bdb

[simo]

On Thu, 2009-09-03 at 09:22 -0700, Jeremy Allison wrote:
> On Thu, Sep 03, 2009 at 11:31:19AM -0400, simo wrote:
> > On Thu, 2009-09-03 at 09:49 -0500, Jeremy Allison wrote:
> > > If the open is chained onto the close, and
> > >     the fd on the new open is the same as the old closed fd, then it's
> > >     possible this race will occur. However, all that will happen is
> > > that
> > >     we'll lose the oplock on this file. A shame, but not a fatal
> > > event.
> > 
> > Can't you prevent this by coupling the fd information with some other
> > information unique to the connection (not sure vuid is never reclied,
> > but some unique connection identifier would do) so that even if the fd
> > is they same you can still realize it is not the one you are looking
> > for ?
> > 
> > Or would this complicate the code so mush the benefit is not worth the
> > effort ?
> 
> The fd is attached by the kernel when the signal
> handler is called - it's part of the siginfo_t
> struct. So we don't get a chance to associate
> any extra info with the fd (there's no "private"
> pointer - and such a thing wouldn't be signal
> instance specific anyway).

Uhmm right didn't think about that.

> The only way to completely prevent the race
> is within the close_fsp call to block the
> kernel signal from being delivered, then walk
> the pending signals array and delete any
> pending signal that would be delivered on
> the fd that's about to be closed. I considered
> that for the code, but that opens up the guts
> of tevent_signal in a way I really didn't want
> to expose.

Makes sense,
thanks for explaining.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>