glusterfs.git/xlators/cluster/dht/src, branch v3.6.2

Cluster/DHT : Fixed crash due to null deref

2015-01-21T12:00:09+00:00

A lookup on a linkto file whose trusted.glusterfs.dht.linkto
xattr points to a subvol that is not part of the volume
can cause the brick process to segfault due to a null dereference.
Modified to check for a non-null value before attempting to access
the variable.

> Change-Id: Ie8f9df058f842cfc0c2b52a8f147e557677386fa
> BUG: 1159571
> Signed-off-by: Nithya Balachandran 
> Reviewed-on: http://review.gluster.org/9034
> Tested-by: Gluster Build System 
> Reviewed-by: venkatesh somyajulu 
> Reviewed-by: Vijay Bellur 
> Signed-off-by: Raghavendra Bhat 

Change-Id: I53b086289d2386d269648653629a0750baae07a4
BUG: 1184191
Reviewed-on: http://review.gluster.org/9467
Reviewed-by: Vijay Bellur 
Reviewed-by: Shyamsundar Ranganathan 
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra Bhat

cluster/dht: Change log level to avoid annoying logs

2015-01-05T12:59:53+00:00

[2015-01-04 08:03:23.820376] I [dht-common.c:1822:dht_lookup_cbk] 0-patchy-dht:
Entry /tls missing on subvol patchy-replicate-0

Change-Id: Id9eae47213ed39e8bf969e82cc7b935dfada4598
BUG: 1138385
Reviewed-on: http://review.gluster.org/9382
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra Bhat

cluster/dht: Fix dict_t leaks in rebalance process' execution path

2014-09-20T08:56:06+00:00

        Backport of: http://review.gluster.org/8763

Two dict_t objects are leaked for every file migrated in success codepath.
It is the caller's responsibility to unref dict that it gets from calls to
syncop_getxattr(); and rebalance performs two syncop_getxattr()s per file
without freeing them.

Also, syncop_getxattr() on GF_XATTR_LINKINFO_KEY doesn't seem to be using
the response dict. Hence, NULL is now passed as opposed to @dict to
syncop_getxattr().

Change-Id: I48926389db965e006da151bf0ccb6bcaf3585199
BUG: 1144640
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/8785
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

Cluster/DHT: Changing rename log severity

2014-09-18T17:50:39+00:00

Changing log level for a rename message from debug
to info to improve debuggability

Change-Id: I53031fcf97fffd62095692477330ecde0cf47dcd
BUG: 1138395
Signed-off-by: Nithya Balachandran 
Reviewed-on-master: http://review.gluster.org/8582
Reviewed-by: Vijay Bellur 
Tested-by: Gluster Build System 
Signed-off-by: Shyam 
Reviewed-on: http://review.gluster.org/8626

cluster/dht: Changed log level to DEBUG

2014-09-18T17:50:12+00:00

Change-Id: I7a4ee0c5a6a94bd4f31aff510a2971750913ed45
BUG: 1142402
Signed-off-by: Venkatesh Somyajulu 
Reviewed-on-master: http://review.gluster.org/8621
Tested-by: Gluster Build System 
Reviewed-by: Xavier Hernandez 
Reviewed-by: susant palai 
Reviewed-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/8749

cluster/dht: Fixed double UNWIND in lookup everywhere code

2014-09-17T04:29:09+00:00

In dht_lookup_everywhere_done:
Line: 1194 we call DHT_STACK_UNWIND
and in the same if condition we go ahead and call, goto
unwind_hashed_and_cached; which at Line 1371 calls another UNWIND.

As is obvious, higher frames could cleanup their locals and on
receiving the next unwind could cause a coredump of the process.

Fixed the same by calling the required return post the first unwind

Change-Id: Ic5d57da98255b8616a65b4caaedabeba9144fd49
BUG: 1142409
Signed-off-by: Shyam 
Reviewed-on-master: http://review.gluster.org/8666
Reviewed-by: N Balachandran 
Reviewed-by: Vijay Bellur 
Reviewed-by: Jeff Darcy 
Tested-by: Gluster Build System 
Reviewed-by: susant palai 
Reviewed-on: http://review.gluster.org/8751

cluster/dht: fix memory corruption in locking api.

2014-09-17T04:25:56+00:00



     The  contents  of the array are sorted in ascending order
     according to a comparison function pointed to by compar, which is
     called with two arguments that "point to the objects being
     compared".



qsort passes "pointers to members of the array" to comparision
function. Since the members of the array happen to be (dht_lock_t *),
the arguments passed to dht_lock_request_cmp are of type (dht_lock_t
**). Previously we assumed them to be of type (dht_lock_t *), which
resulted in memory corruption.

Change-Id: Iee0758704434beaff3c3a1ad48d549cbdc9e1c96
BUG: 1142406
Signed-off-by: Raghavendra G 
Reviewed-on-master: http://review.gluster.org/8659
Tested-by: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan 
Reviewed-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/8750

cluster/dht: Rename should not fail post hardlink creation

2014-09-17T04:23:00+00:00

In the rename path, we wind the creation of newname hardlink and
linkto file in dst hashed a the same time. If the linkto creation
fails, but the link creation succeeds, we enter the failure code
and cleanup the created newname hardlink.

In the interim if another client looks up newname and finds it as
a hardlink from FUSE, it could send an unlink for oldname instead
of a rename. This combined with the above cleanup code could end
up losing all the files copies, and thereby losing data.

This fix separates these steps into 2 parts, creating the linkto
first and then the link file, so that post link file creation no
failures would cleanup the newname file. If linkto fails then link
is not attempted, thereby not polluting the name space with
newname.

Change-Id: I61da8e906060da16a31ea1076eec2f01fd617f44
BUG: 1138395
Signed-off-by: Shyam 
Reviewed-on-master: http://review.gluster.org/8570
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy 
Reviewed-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/8615

cluster/dht: Treat linkto file rename failure as non-critial error

2014-09-12T14:07:42+00:00

It is a critical failure iff we fail to rename the cached file
if the rename of the linkto failed, it is not a critical failure,
and we do not want to lose the created hard link for the new
name as that could have been read by other clients.

NOTE: If another client is attempting the same oldname -> newname
rename, and finds both file names as existing, and are hard links
to each other, then FUSE would send in an unlink for oldname. In
this time duration if we treat the linkto as a critical error and
unlink the newname we created, we would have effectively lost the
file to rename operations.

Repercussions of treating this as a non-critical error is that
we could leave behind a stale linkto file and/or not create the new
linkto file, the second case would be rectified by a subsequent
lookup, the first case by a rebalance, like for all stale linkto
files

Change-Id: Ia53ad8b43c3cf8f48ef5b43fd1fec4274e807556
BUG: 1138395
Signed-off-by: Shyam 
Reviewed-on-master: http://review.gluster.org/8563
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy 
Reviewed-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/8614

cluster/dht: synchronize rename and file-migration

2014-09-12T14:06:33+00:00

Change-Id: I4f243c946f76d440680b651235f925e3d0ebf0fd
BUG: 1138395
Signed-off-by: Raghavendra G 
Reviewed-on-master: http://review.gluster.org/8523
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/8613