fnum chaining and pipes

[Jeremy Allison]

Andrew Tridgell wrote:
> 
> while we are on this topic, here is something for Jeremy. In your
> various packet queueing bits of code, do you handle the chain_fsp
> correctly? I'm thinking of the case where in a OpenX+ReadX the OpenX
> causes a oplock break and the ReadX gets queued for later, does the
> readX get the correct chained fnum from the OpenX when it is finally
> dequeued? Remember that during the oplock break the chain_fsp may have
> been clobbered by the client calling a open/close etc.

I wrote:

> Yes you are right, that could potentially fail. I'll add 
> that code to the 'save context'/'restore context' part of
> the oplock break processing code.
> 
> I will also fix this in the code going out as 1.9.18p10.

Actually, I just looked at the code in 1.9.18 and the reason
it doesn't work in the head branch is your changes broke
it :-) :-).

Seriously, in 1.9.18 the chain_fnum is set just before
'chain_reply' is called - which means it is not in any
danger in any of the oplock processing code. In the
HEAD branch, however, the chain_fnum is set on the allocation
of the new file, which means the oplock processing code
can stomp on it.

I've just checked in a fix for this, but I don't think
I need to for the 1.9.18 branch.

The nttrans code is not chained, so I don't have to worry
about this in my nttrans queueing code. The lockingX queue
is chained however, and I am in the process of dealing with
this issue at the moment.

Cheers,

	Jeremy.

-- 
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------