glusterfs.git/xlators/mgmt/glusterd/src/glusterd-syncop.c, branch v6.7 glusterd: fix txn-id mem leak 2019-04-16T10:49:09+00:00 Atin Mukherjee amukherj@redhat.com 2019-03-18T10:38:04+00:00 55c5e2ecc77bd13dfa66139a1c320e73f703775b This commit ensures the following: 1. Don't send commit op request to the remote nodes when gluster v status all is executed as for the status all transaction the local commit gets the name of the volumes and remote commit ops are technically a no-op. So no need for additional rpc requests. 2. In op state machine flow, if the transaction is in staged state and op_info.skip_locking is true, then no need to set the txn id in the priv->glusterd_txn_opinfo dictionary which never gets freed. Fixes: bz#1694610 Change-Id: Ib6a9300ea29633f501abac2ba53fb72ff648c822 Signed-off-by: Atin Mukherjee <amukherj@redhat.com> (cherry picked from commit 34e010d64905b7387de57840d3fb16a326853c9b) 
This commit ensures the following:
1. Don't send commit op request to the remote nodes when gluster v
status all is executed as for the status all transaction the local
commit gets the name of the volumes and remote commit ops are
technically a no-op. So no need for additional rpc requests.
2. In op state machine flow, if the transaction is in staged state and
op_info.skip_locking is true, then no need to set the txn id in the
priv->glusterd_txn_opinfo dictionary which never gets freed.

Fixes: bz#1694610
Change-Id: Ib6a9300ea29633f501abac2ba53fb72ff648c822
Signed-off-by: Atin Mukherjee <amukherj@redhat.com>
(cherry picked from commit 34e010d64905b7387de57840d3fb16a326853c9b)
glusterd: glusterd memory leak while running "gluster v profile" in a loop 2019-03-12T20:51:03+00:00 Mohit Agrawal moagrawal@redhat.com 2019-03-05T08:09:46+00:00 0d0b54a9de6ed7e13495d1bbbfcf43d7ac13adc2 Problem: glusterd has memory leak while running "gluster v profile" in a loop Solution: Resolve leak code path to avoid leak > Change-Id: Id608703ff6d0ad34ed8f921a5d25544e24cfadcd > fixes: bz#1685414 > (Cherry pick from commit 9374484917466dff4688d96ff7faa0de1c804a6c) > (Reviewed on link https://review.gluster.org/#/c/glusterfs/+/22301/) Change-Id: I1ca118265f97b188f94b3d5cff649ec36cb18ca0 fixes: bz#1685771 Signed-off-by: Mohit Agrawal <moagrawal@redhat.com> 
Problem: glusterd has memory leak while running "gluster v profile"
         in a loop

Solution: Resolve leak code path to avoid leak

> Change-Id: Id608703ff6d0ad34ed8f921a5d25544e24cfadcd
> fixes: bz#1685414
> (Cherry pick from commit 9374484917466dff4688d96ff7faa0de1c804a6c)
> (Reviewed on link https://review.gluster.org/#/c/glusterfs/+/22301/)

Change-Id: I1ca118265f97b188f94b3d5cff649ec36cb18ca0
fixes: bz#1685771
Signed-off-by: Mohit Agrawal <moagrawal@redhat.com>
glusterd: migrating rebalance commands to mgmt_v3 framework 2018-12-18T04:01:52+00:00 Sanju Rakonde srakonde@redhat.com 2018-11-30T10:46:55+00:00 0b4b111fbd80a5d400a07d61e2b99f230f9be76f Current rebalance commands use the op_state machine framework. Porting it to use the mgmt_v3 framework. Change-Id: I6faf4a6335c2e2f3d54bbde79908a7749e4613e7 fixes: bz#1655827 Signed-off-by: Sanju Rakonde <srakonde@redhat.com> 
Current rebalance commands use the op_state machine framework.
Porting it to use the mgmt_v3 framework.

Change-Id: I6faf4a6335c2e2f3d54bbde79908a7749e4613e7
fixes: bz#1655827
Signed-off-by: Sanju Rakonde <srakonde@redhat.com>
glusterd: perform rcu_read_lock/unlock() under cleanup_lock mutex 2018-12-03T17:03:57+00:00 Sanju Rakonde srakonde@redhat.com 2018-11-28T10:43:58+00:00 2bb0e89e4bb113a93c6e786446a140cd99261af8 Problem: glusterd should not try to acquire locks on any resources, when it already received a SIGTERM and cleanup is started. Otherwise we might hit segfault, since the thread which is going through cleanup path will be freeing up the resouces and some other thread might be trying to acquire locks on freed resources. Solution: perform rcu_read_lock/unlock() under cleanup_lock mutex. fixes: bz#1654270 Change-Id: I87a97cfe4f272f74f246d688660934638911ce54 Signed-off-by: Sanju Rakonde <srakonde@redhat.com> 
Problem: glusterd should not try to acquire locks on any resources,
when it already received a SIGTERM and cleanup is started. Otherwise
we might hit segfault, since the thread which is going through
cleanup path will be freeing up the resouces and some other thread
might be trying to acquire locks on freed resources.

Solution: perform rcu_read_lock/unlock() under cleanup_lock mutex.

fixes: bz#1654270
Change-Id: I87a97cfe4f272f74f246d688660934638911ce54
Signed-off-by: Sanju Rakonde <srakonde@redhat.com>
Land part 2 of clang-format changes 2018-09-12T12:22:45+00:00 Gluster Ant bugzilla-bot@gluster.org 2018-09-12T12:22:45+00:00 e16868dede6455cab644805af6fe1ac312775e13 Change-Id: Ia84cc24c8924e6d22d02ac15f611c10e26db99b4 Signed-off-by: Nigel Babu <nigelb@redhat.com> 
Change-Id: Ia84cc24c8924e6d22d02ac15f611c10e26db99b4
Signed-off-by: Nigel Babu <nigelb@redhat.com>
glusterd : fix some coverity issues in glusterd-syncop.c 2018-08-30T12:15:52+00:00 Sunny Kumar sunkumar@redhat.com 2018-08-28T20:09:28+00:00 a38f9cb7a6c9a25ceef9a0638add39dfd2b0c0d9 This patch fixes CID 1382344, 1124655 and 1325537. Change-Id: I2412d6b88483e32a5de1baebb3823a985b2dcfb0 updates: bz#789278 Signed-off-by: Sunny Kumar <sunkumar@redhat.com> 
This patch fixes CID 1382344, 1124655 and 1325537.

Change-Id: I2412d6b88483e32a5de1baebb3823a985b2dcfb0
updates: bz#789278
Signed-off-by: Sunny Kumar <sunkumar@redhat.com>
glusterd: fix some coverity issues 2018-08-20T12:10:45+00:00 Bhumika Goyal bgoyal@redhat.com 2018-08-17T18:36:58+00:00 788cda4cd36574092bef1449ecda579163d06776 Fixes CID: 1241481 1241482 1274079 1274118 1274121 1274131 1274198 1274214 1274220 1274224 1394663 1394641 382454 1382453 1382449 1288095 Link: https://scan6.coverity.com/reports.htm#v42388/p10714/fileInstanceId=84772667&defectInstanceId=25770661&mergedDefectId=744716 Change-Id: Idaf434186231c8b0fff4b27c57fa23636a89c8a7 updates: bz#789278 Signed-off-by: Bhumika Goyal <bgoyal@redhat.com> 
Fixes CID: 1241481 1241482 1274079 1274118 1274121  1274131 1274198
1274214 1274220 1274224 1394663 1394641 382454 1382453 1382449 1288095

Link: https://scan6.coverity.com/reports.htm#v42388/p10714/fileInstanceId=84772667&defectInstanceId=25770661&mergedDefectId=744716

Change-Id: Idaf434186231c8b0fff4b27c57fa23636a89c8a7
updates: bz#789278
Signed-off-by: Bhumika Goyal <bgoyal@redhat.com>
changed 'sometime' messsages to 'some time' 2018-06-01T23:44:23+00:00 Levi Baber baber@iastate.edu 2018-05-31T20:17:26+00:00 e3563f6dfda6c3f44ecff52ac22738ff74413ae1 Change-Id: I0936229fc84c011db7791218bb566c971fdea174 fixes: bz#1584864 Signed-off-by: Levi Baber <baber@iastate.edu> 
Change-Id: I0936229fc84c011db7791218bb566c971fdea174
fixes: bz#1584864
Signed-off-by: Levi Baber <baber@iastate.edu>
glusterd: glusterd is releasing the locks before timeout 2018-05-28T14:10:45+00:00 Sanju Rakonde srakonde@redhat.com 2018-04-17T12:40:01+00:00 c54702a34aa1feb86e2f5f2b1b238966a52ae37b Problem: We introduced lock timer in mgmt v3, which will realease the lock after 3 minutes from command execution. Some commands related to heal/profile will take more time to execute. For these comands timeout is set to 10 minutes. As the lock timer is set to 3 minutes glusterd is releasing the lock after 3 minutes. That means locks are released before the command is completed its execution. Solution: Pass a timeout parameter from cli to glusterd, when there is a change in default timeout value(i.e, default timeout value can be changed through command line or for the commands related to profile/heal we will change the default timeout value to 10 minutes.) glusterd will set the lock timer timeout according to the timeout value passed. Change-Id: I7b7a9a4f95ed44aca39ef9d9907f546bca99c69d fixes: bz#1577731 Signed-off-by: Sanju Rakonde <srakonde@redhat.com> 
Problem: We introduced lock timer in mgmt v3, which will realease
the lock after 3 minutes from command execution. Some commands related
to heal/profile will take more time to execute. For these comands
timeout is set to 10 minutes. As the lock timer is set to 3 minutes
glusterd is releasing the lock after 3 minutes. That means locks are
released before the command is completed its execution.

Solution: Pass a timeout parameter from cli to glusterd, when there
is a change in default timeout value(i.e, default timeout value can
be changed through command line or for the commands related to profile/heal
we will change the default timeout value to 10 minutes.) glusterd will
set the lock timer timeout according to the timeout value passed.

Change-Id: I7b7a9a4f95ed44aca39ef9d9907f546bca99c69d
fixes: bz#1577731
Signed-off-by: Sanju Rakonde <srakonde@redhat.com>
glusterd: handling brick termination in brick-mux 2018-05-07T15:31:59+00:00 Sanju Rakonde srakonde@redhat.com 2018-04-05T20:23:45+00:00 4da244caccd38a77de5428b6954f565219ef0719 Problem: There's a race between the glusterfs_handle_terminate() response sent to glusterd from last brick of the process and the socket disconnect event that encounters after the brick process got killed. Solution: When it is a last brick for the brick process, instead of sending GLUSTERD_BRICK_TERMINATE to brick process, glusterd will kill the process (same as we do it in case of non brick multiplecing). The test case is added for https://bugzilla.redhat.com/show_bug.cgi?id=1549996 Change-Id: If94958cd7649ea48d09d6af7803a0f9437a85503 fixes: bz#1545048 Signed-off-by: Sanju Rakonde <srakonde@redhat.com> 
Problem: There's a race between the glusterfs_handle_terminate()
response sent to glusterd from last brick of the process and the
socket disconnect event that encounters after the brick process
got killed.

Solution: When it is a last brick for the brick process, instead of
sending GLUSTERD_BRICK_TERMINATE to brick process, glusterd will
kill the process (same as we do it in case of non brick multiplecing).

The test case is added for https://bugzilla.redhat.com/show_bug.cgi?id=1549996

Change-Id: If94958cd7649ea48d09d6af7803a0f9437a85503
fixes: bz#1545048
Signed-off-by: Sanju Rakonde <srakonde@redhat.com>