Patches for https://bugzilla.samba.org/show_bug.cgi?id=11182

[Michael Adam]

On 2015-05-07 at 06:52 +0200, Michael Adam wrote:
> On 2015-05-06 at 15:59 -0700, Jeremy Allison wrote:
> > On Wed, May 06, 2015 at 09:29:00PM +0200, Michael Adam wrote:
> > > 
> > > Metze's argument (I briefly discussed with him) is that
> > > it was this way before. And since only the last in a
> > > compound (except for oplock breaking create) can go async
> > > and is taken out of the compound then, we are not in danger.
> > 
> > Metze is (of course :-) correct in that we will
> > *always* call tevent_req_cancel() on a notify,
> > as the cannot be inside a compound, and can only
> > be at the end - in which case it's split out.
> 
> I probably need to understand better how we process
> these notifies in a compound, i.e. when the get
> split out, but the concern was what happens
> when the session_shutdown is called when we are still
> occupied with the earlier parts of the compound and
> have not yet split the notify out. If that can not
> happen - great! (I will revisit the relevant code in
> order to fully understand..)

I reviewed the code together with Metze (him explainig) today
and I think I should post the explanation here, why don't
have a problem:

If the session_shutdown code hits when a request from
the middle of a coumpounded request is in progress, then
the compound indeed cotains the final notify still.
So it has not been split out of the compound yet, and
the session_shutdown code does currently_not_ send a cancel
for this notify (or any other requests of the compound).

So far our analysis was correct.

The explanation why this does not cause the queue to block
indefinitely at the notify is this:

When the next request of the compound is processed,
the processing schedules the processing of the next
request in the compound by creating an immediate
event. And the dispatch for the next req checks (among
other things) for a valid session. Since the
smb2srv_session_shutdown_send() code has previously
set the session to NT_STATUS_USER_SESSION_DELETED,
the dispatch code will not let any of the requests
go async any more but simply reply with the session
deleted or other appropriate error code.
(In the case of compounds collecting all replies
and sending them out when the final req is processed.)

Hence the notify does not block!

Cheers - Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150507/caa55e9c/attachment.pgp>