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

[Michael Adam]

On 2015-05-07 at 13:08 +0200, Michael Adam wrote:
> 
> 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!

Thinking about it further, the fact that immediate
events are used for processing compound requets
implies that we will never even call the session_shutdown
when a compound has not been processed completely,
doesn't it?
(That chain of events could only be interrupted by
a signal event.)

But it is good to know that things would also work out
if we did not use immediate events. :)

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/357cbabc/attachment.pgp>