glusterfs.git/xlators/features/locks/src, branch v4.1.0

protocol/server : unwind as per op version

2018-05-03T07:16:21+00:00

Change-Id: Id6717640ac14881b490e512c4682e45ffffa7f5b
fixes: bz#1570538
BUG: 1570538
Signed-off-by: Ashish Pandey

build: add --without-server option

2018-02-19T17:38:55+00:00

With Gluster 4.0 we will not provide the server components for EL6 and
older. At one point Gluster 4.x will get GlusterD2, which requires
Golang tools in the distribution. EL6 does not contain these at the
moment.

With this change, it is possible to `./configure --without-server` which
prevents building glusterd and the xlators for the bricks. Building RPMs
can pass `--without server` and the glusterfs-server sub-package will
not be created.

Change-Id: I97f5ccf9f2c76e60d9af83915fc59fae57ad6d25
BUG: 1074947
Signed-off-by: Niels de Vos

libgfapi: Add new api for supporting mandatory-locks

2018-01-22T09:54:02+00:00

The current API for byte-range locks [glfs_posix_lock()] doesn't
allow applications to specify whether it is advisory or mandatory
type locks. This particular change is to introduce an extended
byte-range lock API with an additional argument for including
the byte-range lock mode to be one among advisory(default) or
mandatory. Patch also includes a gfapi test case which make use
of this new api to acquire mandatory locks.

Ref: https://github.com/gluster/glusterfs-specs/blob/master/done/GlusterFS%203.8/Mandatory%20Locks.md

Change-Id: Ia09042c755d891895d96da857321abc4ce03e20c
Updates #393
Signed-off-by: Anoop C S

features/locks: volume option fixes for GD2

2018-01-19T03:52:39+00:00

Updates #302
Signed-off-by: Pranith Kumar K 
Change-Id: I1667fc32b7a31562b289fcab878d94be202407e4

locks: added inodelk/entrylk contention upcall notifications

2018-01-16T10:37:22+00:00

The locks xlator now is able to send a contention notification to
the current owner of the lock.

This is only a notification that can be used to improve performance
of some client side operations that might benefit from extended
duration of lock ownership. Nothing is done if the lock owner decides
to ignore the message and to not release the lock. For forced
release of acquired resources, leases must be used.

Change-Id: I7f1ad32a0b4b445505b09908a050080ad848f8e0
Signed-off-by: Xavier Hernandez

all: Simplify component message id's definition

2017-12-14T02:33:51+00:00

This patch creates a new way of defining message id's that is easier
and less error prone because it doesn't require so many manual changes
each time a new component is defined or a new message created.

Change-Id: I71ba8af9ac068f5add7e74f316a2478bc991c67b
Signed-off-by: Xavier Hernandez

features/locks: Fix memory leaks

2017-11-22T10:12:47+00:00

Change-Id: Ic1d2e17a7d14389b6734d1b88bd28c0a2907bbd6
BUG: 1515161
Signed-off-by: Xavier Hernandez

Coverity Issue: PW.INCLUDE_RECURSION in several files

2017-11-09T13:21:11+00:00

Coverity ID: 407, 408, 409, 410, 411, 412, 413, 414, 415, 416, 417,
418, 419, 423, 424, 425, 426, 427, 428, 429, 436, 437, 438, 439,
440, 441, 442, 443

Issue: Event include_recursion

Removed redundant, recursive includes from the files.

Change-Id: I920776b1fa089a2d4917ca722d0075a9239911a7
BUG: 789278
Signed-off-by: Girjesh Rajoria

features/locks: Maintain separation of lock->client_pid, flock->l_pid

2017-09-27T05:20:34+00:00

Problem:
grant_blocked_locks() constructs flock from lock. Locks xlator uses
frame->root->pid interchangeably flock->l_pid. With gNFS frame->root->pid
(which translates to lock->client_pid) is not same as flock->l_pid, this leads
to lk's cbk returning flock with l_pid from lock->client_pid instead of input
flock->l_pid. This triggers EC's error code path leading to failure of lk call,
because the response' flock->l_pid is different from request's flock->l_pid.

Fix:
Maintain separation of lock->client_pid, flock->l_pid. Always unwind with
flock with correct pid.

BUG: 1472961
Change-Id: Ifab35c458662cf0082b902f37782f8c5321d823d
Signed-off-by: Pranith Kumar K

multiple: fix struct/typedef inconsistencies

2017-06-30T10:31:02+00:00

The most common pattern, both in our code and elsewhere, is this:

   struct _xyz {
      ...
   };
   typedef struct _xyz xyz_t;

These exceptions - especially call_frame/call_stack - have been slowing
down code navigation for years.  By converging on a single pattern,
navigating from xyz_t in code to the actual definition of struct _xyz
(i.e. without having to visit the typedef first) might even be
automatable.

Change-Id: I0e5dd1f51f98e000173c62ef4ddc5b21d9ec44ed
Signed-off-by: Jeff Darcy 
Reviewed-on: https://review.gluster.org/17650
Smoke: Gluster Build System 
Tested-by: Jeff Darcy 
CentOS-regression: Gluster Build System 
Reviewed-by: Amar Tumballi 
Reviewed-by: Niels de Vos