directory change notification patch

[Derrell.Lipman at UnwiredUniverse.com]

Mark Weaver <mark-clist at npsl.co.uk> writes:

> - smbd code assumes that (change notify) signals are delivered via EINTR
> when calling select.  Since notification polling is disabled in the present
> code if kernel change notification is active, the assumption would seem to
> be that the notification is reliable.

and

> In summary (and I probably should have said this at the start), the change is
> simply a fix to what appears to be the intended mechanism of signal delivery,
> which is currently broken.  You can test this quite easily for change notify
> by having a script change a directory repeatedly and observing that "kernel
> change notify on" is missing from the logs on occasion.  Since change notify
> is one-shot, this is somewhat of a disaster.

These two statements may be at odds.  If there is supposed to be a one-to-one
correspondence between a change notification and a signal, EINTR does not
guarantee that.  Multiple signals can be merged into a single signal if they
occur before being caught by the application.  This is why Linux added "real
time signals" which may be queued, and the number of generated signals is
guaranteed to be what the application receives.  Is a one-to-one
correspondence between a change notification and a signal necessary?

> The mechanism for signal delivery is to write to a pipe in select.c (via
> sys_select_signal()) and report it later in sys_select.  - When a signal is
> delivered and any other fd is ready then sys_select does not return
> -1/EINTR, but yet reads from the pipe.  This leads to signal notifications
> being lost.  I chose to report EINTR in preference to any fds being ready
> (alternatively, you could not read from the pipe and report EINTR later --
> this is simply a priority preference).  Note that I am assuming that the
> caller of sys_select is ready to deal with EINTR.

Inspection of the code seems to confirm what you say: signal notifications can
get lost if data is available to be read AND data is available on the pipe due
to a previous signal.  There does appear to be a bug.

> - sys_select_intr is a wrapper function for sys_select that eats EINTR. This
> also looses signals.  I changed this function to simply call select()
> directly and copied other wrapper code from sys_select.  The rational was
> that there there is no point waiting on the signal pipe if the result is
> going to be tossed anyway.

This seems to be *changing* the meaning of sys_select_intr().  Instead of
ignoring EINTR, you are leaving them queued (in the pipe).  The next up-to 256
calls to sys_select() will return with EINTR (assuming the previous bug is
fixed).  That sounds like something to be cautious of.

(This does raise the question as to why 256 queued signals are required.  I
suspect there's a good reason for queuing a bunch of them, I'm just not seeing
it right now.  If they don't get lost, one should be enough.  Was it an
attempt to change the semantics of signals, and try to ensure a one-to-one
correspondence between generation of a signal and delivery of same?  It still
doesn't guarantee that...???)

Derrell