[PATCH] - New Version ! Fix bug #SMB1 blocking locks can fail notification on unlock, causing client timeout.

[Jeremy Allison]

Here's the fixed version that doesn't leave
pending lock records on the queue if a lock
request times out :-).

Please review !

Cheers,

	Jeremy.
----------------------------------------------------------
Here's a really interesting bug I discovered
when looking at the SMB1 version of the bug
that Hemanth found in our SMB2 blocking lock code.

Going back 5 years or so I think this is a bug
that Herb originally discovered but we never
got a reproducible test case. Now we have :-).

It's best illustrated by looking at a
theoretical SMB1 torture test case:

Consider the following client scenario, as coded up from smbtorture to Windows.

Client                        Server
-------------------------------------------
Mid:

1)  -> open file /foo
                            <-- Success mid #1

2)  -> LockingX containing 2 lock requests 100->109, 120->129.

                            <-- locks granted mid #2

3)  -> LockingX on different context, block indefinitely for
       the ranges 100->109, 120->129.

                            (Server pushes request on blocking queue).


4)  -> Unlock range 100->109.

                            <-- Success mid #4

5)  -> Unlock range 120->129.

                            <-- Success mid #5

                            Server can now release blocking
                            request mid #3, which was queued,
                            and return success for mid #3.

                            <-- Success mid #3

Run the same test against Samba, and we fail to awaken the
server on mid #5. This is because we don't correctly update
the pending blocking record after mid #4 unlocks the range
we're currently pending on. So when mid #5 unlocks, smbd checks
the unlock request range 120->129 for overlap with the previous
range 100->109, and fails to notify.

The attached patchset fixes this, by immediately
removing the pending lock record when re-processing
each blocked lock, and then causing the functions
that actually retry the blocking lock to re-add a pending
lock record (if it hasn't expired) when they fail to get it.

That's the place we really know we're going to have to
continue to wait, and also have the up-to-date info on what
lock range and count we're blocking on.

It also adds a torture test to raw.locks that
implements this exact scenario. Running it
without the fix causes smbtorture to hang
and time out against the server, with the
fix it completes correctly.

This smbtortute test has also been run
against Windows Server 2012 successfully.

Please review !

Cheers,

        Jeremy.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug-10684-master.patch
Type: text/x-diff
Size: 13976 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140702/aa02262c/attachment.patch>