[Bugs] [Bug 1291762] New: Improve handling of fcntl blocking lock requests

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1291762

            Bug ID: 1291762
           Summary: Improve handling of fcntl blocking lock requests
           Product: GlusterFS
           Version: mainline
         Component: locks
          Severity: medium
          Assignee: bugs at gluster.org
          Reporter: achiraya at redhat.com
                CC: bugs at gluster.org, gluster-bugs at redhat.com



Changes from commit 79db3aced2ffca84a696192343d5b811833eb671 were done in an
attempt to avoid lock upgrade/downgrade problems for a conflicting F_SETLKW
lock request as explained below.

Consider the following sequence of events acting upon a file:
    1. App1 requests shared blocking byte range lock request
       from offset 0 to 5 and is granted.
    2. App2 requests shared blokcing byte range lock request
       from offset 0 to 5 and is granted.
    3. App1 requests exclusive blocking byte range lock request
       from offset 0 to 5 and is blocked.

Before the specified commit hash eventhough App2 releases its lock, App1's
blocked lock request could not be granted due to lack of lock owner and related
checks inside first_overlap() which is invoked from grant_blocked_locks() as
soon as the release happens from App2. This undefined wait/hang was fixed via
the commit in such a way that we unlock App1's previously held lock as soon as
we receive a blocking lock request from App1 which conflicts with App2's lock.
This would mean that we break the promise of granted shared lock given to App1
temporarily. pl_send_prelock_unlock() implements this early unlock.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.