Re: [PATCH 06/11] CIFS: Respect MaxMpxCount field

["Christopher R. Hertel" <crh-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>]

On 03/01/2012 10:48 AM, Jeremy Allison wrote:
> On Thu, Mar 01, 2012 at 01:37:47PM -0500, Jeff Layton wrote:
>>
>> (cc'ing Chris and Jeremy to make sure I understand)
>>
>> The description above is a good start but doesn't quite outline the
>> clear concise "rules" for this that I was looking for.
>>
>> So if I understand what Steve wrote above, he's basically saying that
>> we should enforce the maxmpx for everything but blocking locks and
>> echoes? Is that correct? If so then I think that's wrong and won't fix
>> any of the problems that people have reported with the existing code.
>>
>> It's all well and good that *some* servers allow you to exceed the
>> maxmpx in *some* cases, but we can't code to that assumption. We know
>> well that many servers do not handle exceeding the maxmpx gracefully at
>> all. As always we have to code to the lowest common denominator by
>> default, and then optionally allow people to exceed that if they choose
>> to do so.
>>
>> I think this is a case where we need a good description in a human
>> language (preferably english) of how this should work (aka a
>> specification), and then write code to match that description (aka code
>> to the spec).
>>
>> Anything else is going to send us down the rabbit hole where we are
>> today with cifs.ko -- a bunch of ad-hoc, broken code that no one really
>> understands.
>>
>> While we may not like it, a hard cap on the number of outstanding
>> requests is required by the protocol docs that Chris helped write.
>>
>> Allow me to quote from MS-CIFS:
>>
>> MaxMpxCount (2 bytes): The maximum number of outstanding SMB operations
>> that the server supports. This value includes existing OpLocks, the
>> NT_TRANSACT_NOTIFY_CHANGE subcommand, and any other commands that are
>> pending on the server.
>>
>> There's nothing in there that says anything about certain commands
>> being excepted from that value.
>
> The only way to know this for sure is to put in a request
> to Microsoft doc-help to ask if SMBecho and blocking SMB
> locks are exempted from the maxmpx count.

I recall, from the code, that the SMBecho is handled "out of band".  I can't 
speak to the blocking locks.

Internally, the system keeps a per-connection table keyed on [PID,MID].  The 
MaxMpxCount indicates the fixed size of this table.  Outstanding commands, 
including things like ChangeNotify and OpLocks (which are handled as if they 
were incomplete commands, pending on the server) are kept in this table.

The doc talks about needing to disable OpLocks if the MaxMpxCount is less 
than 2.  That's because clients can break their own OpLocks.  If a client 
has an OpLock on a file, and then opens the file again (the same or 
different process...it doesn't matter) there won't be enough slots in the 
[PID,MID] table to allow the open to occur.  The client's second Open 
request will not be able to be queued (it becomes a pending command since it 
cannot be answered until the OpLock break either times out or completes) 
because the pending command table is full.

Okay, so...  The question is this:  When are commands added to the server's 
pending queue (the table indexed on [PID,MID].

The answer is scattered across section 3 of the [MS-CIFS] doc.  If the 
command needs to be added to the pending queue, it'll say so in the doc.  It 
should all be under section 3.3.5.

Look for information about the PendingRequestTable, starting at section 
3.3.5.2.1.

Chris -)-----

--
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh-jFlgvBokg3lg9hUCZPvPmw@public.gmane.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh-zuGDro9SezXYtjvyW6yDsg@public.gmane.org