Problem with async-echo test

[simo]

On Wed, 2011-07-27 at 19:31 +0200, Stefan (metze) Metzmacher wrote:
> Am 27.07.2011 19:02, schrieb simo:
> > On Wed, 2011-07-27 at 18:19 +0200, Volker Lendecke wrote:
> >> On Wed, Jul 27, 2011 at 10:57:42AM +0200, Volker Lendecke wrote:
> >>> Running the async-echo smbtorture3 test I came across a
> >>> problem with the new dcerpc client libraries. That test
> >>> sends a dcerpc_echo_TestSleep_send and then after that some
> >>> cli_write_andx and cli_echo calls with the intention to put
> >>> the server to sleep and walking the async echo responder.
> >>> This does not work anymore, because the RPC request is only
> >>> sent out to the network after the cli_echo and cli_write&x
> >>> calls have been sent out. My impression is that this comes
> >>> via double-queueing via the tstream layer in the rpc
> >>> routines, but this impression might be wrong. I know this
> >>> used to work at some point. See the attached network trace
> >>> for the problem.
> >>>
> >>> I know so far we have not given guarantees about the
> >>> ordering of requests in the async architecture, but my
> >>> assumption so far was that we maintain the ordering between
> >>> requests being sent to the smb client connection. If we now
> >>> have the client libraries freely re-order requests, we need
> >>> to augment them with something like barriers or so.
> >>
> >> A little more analysis: To me it seems that it has to do
> >> with the double-queueing in the following way: The
> >> tstream_writev_queue_send call in rpc_tstream_trans_send
> >> triggers a tevent_schedule_immediate because the queue is
> >> not empty. Then the cli_smb_send calls come in, also
> >> triggering the schedule_immediates. There is a single
> >> immediate dlist in the tevent_context, all
> >> schedule_immediate calls are added to the end of the list.
> >> The first one is the one from tstream_writev_queue_send (the
> >> rpc call). This is called, converting the rpc tstream call
> >> into a smb level call, which triggers another
> >> schedule_immediate. Because it comes after the cli_send_smb
> >> calls from cli_echo_send and so on it has to line up after
> >> all the other calls.
> > 
> > Shouldn't immediate calls use a LIFO paradigm instead of a FIFO one ?
> > At least that would make more sense to me.
> 
> Why? then the first one could be deadlocked by the others.

I guess it really depends on how we consider immediate requests.
Of course if they are abused they'll lead to deadlock, perhaps we need a
separate facility to "nest" immediate-like requests, when "inner" ones
are more important than "outer" ones.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>