fnum chaining and pipes

[Jeremy Allison]

Andrew Tridgell wrote:

> > 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.
> 
> It is set in allocation, yes, but it is also set in
>     file_fsp(char *buf,int where);
> 
> so, how are you getting the fsp pointer if it isn't via this routine?
> There is no other fnum->fsp mapping routine in there.
> 

Well if chain_fnum already is != NULL at this point then
the files_struct * returned from file_fsp isn't the
one from the buffer, it's the one from the chain_fsp.

> hmmm, maybe what happens is that you push the 2nd half of a chained
> OpenX+ReadX onto the queue but not the first? If you processed a ReadX
> without having just processed the OpenX then that could indeed
> stuffup.
> 

No I don't do that - I push the entire message onto
the pending buffer until the oplock break reply is
received.

The reason for the fix is as follows :

1). open_and_X call comes in - causes an oplock break
to ourselves. If you look at the code path, reply_openX()
allocates the new fsp via file_new() - this also sets the
chain_fsp.

2). We go into open_file_shared and decide we need to
break the oplock - and we're the one holding the oplock.
So we recurse into a mini-main look in oplock_break().

3). Any message (read/write/whatever) comes in whilst
we're in the mini-main look in oplock_break(). The
construct_reply call trashes the chain_fsp (resets it
to NULL before processing the message). After the oplock
break request is received the 

4). We come out of the oplock break and go back into
open_file_shared() where we open the file correctly and
then go back into reply_openX() - at the end of which
we call chain_reply() - oh dear. The chain_fsp was trashed
during the oplock break processing and is now incorrect
for the chained SMB.

My fix is at point (2) to save the chain_fsp via a new
call in files.c - file_chain_save() and then restore
it again after coming out of the mini-main look in
oplock_break().

The reason this isn't needed in 1.9.18pXX is that there
is an explicit setting of chain_fnum just before the
chain_reply() call in step 4 above.

At least that's my understanding of it all :-).

Jeremy.

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