glusterfs.git/xlators/cluster/dht/src, branch v3.5.3beta2

cluster/dht: fix memory corruption in locking api.

2014-10-01T10:37:41+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: 1140556
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/8659
Tested-by: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan 
Reviewed-by: Vijay Bellur 
(cherry picked from commit ed4a754f7b6b103b23b2c3e29b8b749cd9db89f3)
Signed-off-by: Nithya Balachandran 
Reviewed-on: http://review.gluster.org/8733
Reviewed-by: Niels de Vos

cluster/dht: Fixed double UNWIND in lookup everywhere code

2014-10-01T10:37:24+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: 1140549
Signed-off-by: Shyam 
Reviewed-on: 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 
(cherry picked from commit b3314ea6e820fb659255d0e6e9a32ea259b7526d)
Signed-off-by: Nithya Balachandran 
Reviewed-on: http://review.gluster.org/8732
Reviewed-by: Niels de Vos

cluster/dht: Added code to capture races in dht-lookup path

2014-10-01T10:37:12+00:00

Change-Id: I9270d2d40ebd4b113ff961583dfda7754741f15b
BUG: 1129541
Signed-off-by: Venkatesh Somyajulu 
Reviewed-on: http://review.gluster.org/8430
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur 
(cherry picked from commit bb2d5f49b5684e6484af16a580870cfe104aecd2)
Signed-off-by: Nithya Balachandran 
Reviewed-on: http://review.gluster.org/8731
Reviewed-by: Niels de Vos

Cluster/DHT: Changing rename log severity

2014-10-01T10:36:52+00:00

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

Change-Id: I53031fcf97fffd62095692477330ecde0cf47dcd
BUG: 1140348
Signed-off-by: Nithya Balachandran 
Reviewed-on: http://review.gluster.org/8582
Reviewed-by: Vijay Bellur 
Tested-by: Gluster Build System 
(cherry picked from commit c087e5f634a0b2262118d61ab9c1d5c8e18c8819)
Signed-off-by: Nithya Balachandran 
Reviewed-on: http://review.gluster.org/8730
Reviewed-by: venkatesh somyajulu 
Reviewed-by: Niels de Vos

cluster/dht: Rename should not fail post hardlink creation

2014-10-01T10:36:35+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: 1140348
Signed-off-by: Shyam 
Reviewed-on: http://review.gluster.org/8570
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy 
Reviewed-by: Vijay Bellur 
(cherry picked from commit 4ce3db8e508e715a43352b082e861fd0e729951f)
Signed-off-by: Nithya Balachandran 
Reviewed-on: http://review.gluster.org/8728
Reviewed-by: Niels de Vos

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

2014-10-01T10:36:11+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: 1140348
Signed-off-by: Shyam 
Reviewed-on: http://review.gluster.org/8563
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy 
Reviewed-by: Vijay Bellur 
(cherry picked from commit 890ab583a519b3b189a61c5fd563b4326836b988)
Signed-off-by: Nithya Balachandran 
Reviewed-on: http://review.gluster.org/8727
Reviewed-by: Niels de Vos

cluster/dht: synchronize rename and file-migration

2014-10-01T10:35:55+00:00

Change-Id: I4f243c946f76d440680b651235f925e3d0ebf0fd
BUG: 1140348
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/8523
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur 
(cherry picked from commit 21c8946b0bc05d0bc8f84906e16b8c2cbca4c9f9)
Signed-off-by: Nithya Balachandran 
Reviewed-on: http://review.gluster.org/8726
Reviewed-by: Krutika Dhananjay 
Reviewed-by: Niels de Vos

cluster/dht: invoke callback when there are no locks to be unlocked.

2014-10-01T10:34:26+00:00

Change-Id: I375cb68f1075c2d58cf9d09ed6bd5e2746e1637d
BUG: 1140348
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/8549
Tested-by: Gluster Build System 
Reviewed-by: N Balachandran 
Reviewed-by: Vijay Bellur 
(cherry picked from commit a1b02e53a5fdf706290ce143fbbf8a09845105d0)
Signed-off-by: Nithya Balachandran 
Reviewed-on: http://review.gluster.org/8724
Reviewed-by: Shyamsundar Ranganathan 
Reviewed-by: Niels de Vos

cluster/dht: introduce dht locking api.

2014-10-01T10:33:51+00:00

Change-Id: I41389ba91951d3e63e617aa32cd0bee848261c72
BUG: 1140348
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/8521
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur 
(cherry picked from commit a1fe3d72e373bf0deaed152842d12d94bb9129dc)
Signed-off-by: Nithya Balachandran 
Reviewed-on: http://review.gluster.org/8722
Reviewed-by: Krutika Dhananjay 
Reviewed-by: Niels de Vos

cluster/dht: Fix dht_access treating directory like files

2014-09-29T10:50:14+00:00

When the cluster topology changes due to add-brick, all sub
volumes of DHT will not contain the directories till a rebalance
is completed. Till the rebalance is run, if a caller bypasses
lookup and calls access due to saved/cached inode information
(like NFS server does) then, dht_access misreads the error
(ESTALE/ENOENT) from the new subvolumes and incorrectly tries
to handle the inode as a file. This results in the directories
in memory state in DHT to be corrupted and not heal even post
a rebalance.

This commit fixes the problem in dht_access thereby preventing
DHT from misrepresenting a directory as a file in the case
presented above.

Change-Id: Idcdaa3837db71c8fe0a40ec0084a6c3dbe27e772
BUG: 1140338
Signed-off-by: Shyam 
Reviewed-on: http://review.gluster.org/8462
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur 
(cherry picked from commit 6630fff4812f4e8617336b98d8e3ac35976e5990)
Signed-off-by: Nithya Balachandran 
Reviewed-on: http://review.gluster.org/8721
Reviewed-by: Niels de Vos