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

Jeremy Allison jra at samba.org
Thu Sep 3 10:22:56 MDT 2009

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).

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.


More information about the samba-technical mailing list