[PATCH] notifyd

[Jeremy Allison]

On Fri, Jun 19, 2015 at 01:36:23PM +0200, Volker Lendecke wrote:
> Hi!
> 
> Attached find the latest incarnation of the notifyd I've
> been talking about for a while now. Survived a few private
> autobuilds.
> 
> Review appreciated!

Only issue I've found so far.

In source3/smbd/notifyd/notifyd.c

you have notifyd_snoop_broadcast()

1347  * We know the source but the log index does not match. This means we
1348  * lost a message. We just drop the whole peer and wait for the next
1349  * broadcast, which will then trigger a fresh database pull.
1350  */
.....
1386         for (i=0; i<state->num_peers; i++) {
1387                 if (server_id_equal(&state->peers[i]->pid, &src)) {
1388 
1389                         DEBUG(10, ("%s: Applying changes to peer %u\n",
1390                                    __func__, (unsigned)i));
1391 
1392                         notifyd_apply_reclog(state->peers[i],
1393                                              msg + MESSAGE_HDR_LENGTH,
1394                                              msglen - MESSAGE_HDR_LENGTH);
1395 
1396                         state->peers[i]->last_broadcast = time(NULL);
1397                         return;
1398                 }
1399         }

notifyd_apply_reclog() call call TALLOC_FREE on state->peers[i],
and in the destructor it will swap out the entry for
state->peers[i] with state->peers[i] = state->peers[state->num_peers-1];

That means in the log index does not match case we will
set state->peers[i]->last_broadcast = time(NULL) incorrectly,
as the last broadcast time of the deleted record.

I think the correct fix is to change notifyd_apply_reclog()
to return a bool, and just 'continue' the for loop if
it returns false.

Can you confirm this problem (it's complex code :-) ?

If so, do you want me to do the fix or do you want
to post another version ?

Looking forward to getting this code in very soon now,
it's been waiting long enough :-) :-).

Cheers,

	Jeremy.