glusterfs.git/xlators/cluster/dht/src, branch release-3.5

cluster/dht: Fix incorrect updates to parent times

2015-02-05T15:04:47+00:00

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

In directory write FOPs, as far as updates to timestamps associated
with parent by DHT is concerned, there are three possibilities:
a) time (in sec) gotten from child of DHT < time (in sec) in inode ctx
b) time (in sec) gotten from child of DHT = time (in sec) in inode ctx
c) time (in sec) gotten from child of DHT > time (in sec) in inode ctx

In case (c), for time in nsecs, it is the value returned by DHT's child
that must be selected. But what DHT_UPDATE_TIME ends up doing is to choose
the maximum of (time in nsec gotten from DHT's child, time in nsec in inode ctx).

Change-Id: I1388e374c8a2029f3b8919380e68620e7591bde6
BUG: 1186121
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/9496
Tested-by: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri 
Reviewed-by: Shyamsundar Ranganathan 
Reviewed-by: Niels de Vos

Cluster/DHT : Fixed crash due to null deref

2014-12-04T21:30:08+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: 1162767
BUG:1162767
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 
(cherry picked from commit 0da374020c17256141fb3971ae792b62097d72df)
Signed-off-by: Nithya Balachandran 
Reviewed-on: http://review.gluster.org/9099
Reviewed-by: Niels de Vos

core: fix Ubuntu code audit (cppcheck) results

2014-11-26T08:30:12+00:00

See http://review.gluster.org/#/c/7583/ BZ 1086460

AFAICT these are false positives:

[geo-replication/src/gsyncd.c:99]: (error) Memory leak: str
[geo-replication/src/gsyncd.c:395]: (error) Memory leak: argv
[xlators/nfs/server/src/nlm4.c:1200]: (error) Possible null pointer dereference: fde

Program exits, resource leak not an issue
[extras/geo-rep/gsync-sync-gfid.c:105]: (error) Resource leak: fp

Test program:
[extras/test/test-ffop.c:27]: (error) Buffer overrun possible for long command line arguments.

Not built:
[xlators/cluster/ha/src/ha.c:2699]: (error) Possible null pointer dereference: priv

The remainder are fixed with this change-set:

[heal/src/glfs-heal.c:357]: (error) Possible null pointer dereference: remote_subvol
[libglusterfs/src/xlator.c:648]: (error) Uninitialized variable: gfid
[libglusterfs/src/xlator.c:649]: (error) Uninitialized variable: gfid
[xlators/cluster/afr/src/afr-inode-write.c:469]: (error) Possible null pointer dereference: frame
[xlators/cluster/afr/src/afr-self-heal-common.c:1704]: (error) Possible null pointer dereference: local
[xlators/cluster/dht/src/dht-rebalance.c:1643]: (error) Possible null pointer dereference: ctx
[xlators/cluster/stripe/src/stripe.c:4963]: (error) Possible null pointer dereference: local
[xlators/features/changelog/src/changelog.c:1464]: (error) Possible null pointer dereference: priv
[xlators/mgmt/glusterd/src/glusterd-geo-rep.c:1656]: (error) Possible null pointer dereference: command
[xlators/mgmt/glusterd/src/glusterd-replace-brick.c:914]: (error) Resource leak: file
[xlators/mgmt/glusterd/src/glusterd-replace-brick.c:998]: (error) Resource leak: file
[xlators/mgmt/glusterd/src/glusterd-sm.c:248]: (error) Possible null pointer dereference: new_ev_ctx
[xlators/mgmt/glusterd/src/glusterd-store.c:1332]: (error) Possible null pointer dereference: handle
[xlators/mgmt/glusterd/src/glusterd-utils.c:4706]: (error) Possible null pointer dereference: this
[xlators/mgmt/glusterd/src/glusterd-utils.c:5613]: (error) Possible null pointer dereference: this
[xlators/mgmt/glusterd/src/glusterd-utils.c:6342]: (error) Possible null pointer dereference: path_tokens
[xlators/mgmt/glusterd/src/glusterd-utils.c:6343]: (error) Possible null pointer dereference: path_tokens
[xlators/mount/fuse/src/fuse-bridge.c:4591]: (error) Uninitialized variable: finh
[xlators/mount/fuse/src/fuse-bridge.c:3004]: (error) Possible null pointer dereference: state
[xlators/nfs/server/src/nfs-common.c:89]: (error) Dangerous usage of 'volname' (strncpy doesn't always null-terminate it).
[xlators/performance/quick-read/src/quick-read.c:585]: (error) Possible null pointer dereference: iobuf

Rerunning cppcheck afterwards:

As before, test program:
[extras/test/test-ffop.c:27]: (error) Buffer overrun possible for long command line arguments.

As before, believed to be false positive:
[geo-replication/src/gsyncd.c:99]: (error) Memory leak: str
[geo-replication/src/gsyncd.c:395]: (error) Memory leak: argv
[xlators/nfs/server/src/nlm4.c:1200]: (error) Possible null pointer dereference: fde

As before, not built:
[xlators/cluster/ha/src/ha.c:2699]: (error) Possible null pointer dereference: priv

False positive after fix:
[heal/src/glfs-heal.c:356]: (error) Possible null pointer dereference: remote_subvol
[xlators/cluster/stripe/src/stripe.c:4963]: (error) Possible null pointer dereference: local

Change-Id: Ib3029d3223f5a13e2ac386a527d64d5ffe3ecb90
BUG: 1092037
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/7605
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos

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