[Bugs] [Bug 1194546] New: Write behind returns success for a write irrespective of a conflicting lock held by another application

[bugzilla at redhat.com]

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

            Bug ID: 1194546
           Summary: Write behind returns success for a write irrespective
                    of a conflicting lock held by another application
           Product: GlusterFS
           Version: mainline
         Component: write-behind
          Severity: medium
          Assignee: bugs at gluster.org
          Reporter: achiraya at redhat.com
                CC: bugs at gluster.org, gluster-bugs at redhat.com



Created attachment 993827
  --> https://bugzilla.redhat.com/attachment.cgi?id=993827&action=edit
Contains the required patch and test program

Description of problem:
When mandatory-locking is enabled for a particular volume and a write is
performed on a particular file, write-behind immediately returns success
irrespective of a conflicting lock held by another application.

Version-Release number of selected component (if applicable):
mainline

How reproducible:
Always

Steps to Reproduce:
Apply the attached patch, install and perform the following steps.
1. Create and start a basic distributed volume with mandatory-locks enabled.
   Note:- volume set option for enabling mandatory-locks is as follows
          gluster volume set <VOLNAME> mandatory-locks on 
2. Fuse mount the volume at two different mount-points.
3. Create an empty file from mount-point.
4. Run app1.c [see attachment] from one mount-point, with path to the empty
file as command-line argument till it acquires a shared lock on it.
5. Run app2.c [see attachment] with path to the empty file as command-line
argument.

Actual results:
Write returned success.

Expected results:
Write should wait[blocking mode] or should fail[non-blocking mode]

Additional info:
Compile the attached programs and run as per the above mentioned steps.

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