glusterfs.git/xlators/mgmt/glusterd/src/glusterd-server-quorum.c, branch v7.0rc2

glusterd: Fix coverity defects & put coverity annotations

2019-05-02T08:06:06+00:00

Along with fixing few defect, put the required annotations for the defects which
are marked ignore/false positive/intentional as per the coverity defect sheet.
This should avoid the per component graph showing many defects as open in the
coverity glusterfs web page.

Updates: bz#789278
Change-Id: I19461dc3603a3bd8f88866a1ab3db43d783af8e4
Signed-off-by: Atin Mukherjee

libglusterfs: Move devel headers under glusterfs directory

2018-12-05T21:47:04+00:00

libglusterfs devel package headers are referenced in code using
include semantics for a program, this while it works can be better
especially when dealing with out of tree xlator builds or in
general out of tree devel package usage.

Towards this, the following changes are done,
- moved all devel headers under a glusterfs directory
- Included these headers using system header notation <> in all
code outside of libglusterfs
- Included these headers using own program notation "" within
libglusterfs

This change although big, is just moving around the headers and
making it correct when including these headers from other sources.

This helps us correctly include libglusterfs includes without
namespace conflicts.

Change-Id: Id2a98854e671a7ee5d73be44da5ba1a74252423b
Updates: bz#1193929
Signed-off-by: ShyamsundarR

glusterd: perform rcu_read_lock/unlock() under cleanup_lock mutex

2018-12-03T17:03:57+00:00

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

Land part 2 of clang-format changes

2018-09-12T12:22:45+00:00

Change-Id: Ia84cc24c8924e6d22d02ac15f611c10e26db99b4
Signed-off-by: Nigel Babu

glusterd: connect to an existing brick process when qourum status is NOT_APPLICABLE_QUORUM

2018-01-05T07:31:43+00:00

First of all, this patch reverts commit 635c1c3 as the same is causing a
regression with bricks not coming up on time when a node is rebooted.
This patch tries to fix the problem in a different way by just trying to
connect to an existing running brick when quorum status is not
applicable.

Change-Id: I0efb5901832824b1c15dcac529bffac85173e097
BUG: 1509845
Signed-off-by: Atin Mukherjee

glusterd: restart the brick if qorum status is NOT_APPLICABLE_QUORUM

2017-11-09T05:10:36+00:00

If a volume is not having server quorum enabled and in a trusted storage
pool all the glusterd instances from other peers are down, on restarting
glusterd the brick start trigger doesn't happen resulting into the
brick not coming up.

Change-Id: If1458e03b50a113f1653db553bb2350d11577539
BUG: 1509845
Signed-off-by: Atin Mukherjee

glusterd: Fix few coverity errors

2017-11-06T03:56:48+00:00

Fixes issues 810, 248, 491, 499, 85, 786, 811, 43, and 44
from the report at [1].

[1]: https://download.gluster.org/pub/gluster/glusterfs/static-analysis/master/glusterfs-coverity/2017-10-30-9aa574a5/html/

BUG: 789278
Change-Id: I27ebae2ffb2256b8eef0757d768cc46e5a942e9f
Signed-off-by: Prashanth Pai

glusterd: fix brick restart parallelism

2017-11-01T03:41:36+00:00

glusterd's brick restart logic is not always sequential as there is
atleast three different ways how the bricks are restarted.
1. through friend-sm and glusterd_spawn_daemons ()
2. through friend-sm and handling volume quorum action
3. through friend handshaking when there is a mimatch on quorum on
friend import.

In a brick multiplexing setup, glusterd ended up trying to spawn the
same brick process couple of times as almost in fraction of milliseconds
two threads hit glusterd_brick_start () because of which glusterd didn't
have any choice of rejecting any one of them as for both the case brick
start criteria met.

As a solution, it'd be better to control this madness by two different
flags, one is a boolean called start_triggered which indicates a brick
start has been triggered and it continues to be true till a brick dies
or killed, the second is a mutex lock to ensure for a particular brick
we don't end up getting into glusterd_brick_start () more than once at
same point of time.

Change-Id: I292f1e58d6971e111725e1baea1fe98b890b43e2
BUG: 1506513
Signed-off-by: Atin Mukherjee

glusterd: persist brickinfo's port change into glusterd's store

2017-10-31T04:34:10+00:00

Problem:
Consider a case where node reboot is performed and prior to reboot
brick was listening to 49153. Post reboot glusterd assigned 49152
to brick and started the brick process but the new port was never
persisted. Now when glusterd restarts glusterd always read the port
from its persisted store i.e 49153 however pmap signin happens with
the correct port i.e 49152.

Fix:
Make sure when glusterd_brick_start is called, glusterd_store_volinfo is
eventually invoked.

Change-Id: Ic0efbd48c51d39729ed951a42922d0e59f7115a1
BUG: 1506589
Signed-off-by: Gaurav Yadav

glusterd: streamline logic flow in glusterd_validate_quorum()

2017-08-01T10:11:37+00:00

Make an earlier exit when the volume is not of server quorum.
Thereby it spares the actual quorum calculation in this case.
This also increases the overall readability of the function.

The patch is best seen with the --patience diff option to
understand what it does (e.g. "git show --patience").

Change-Id: Ifce50bc3f73d79d3d6226473661a83696d65149a
BUG: 1476719
Signed-off-by: Michael Adam 
Reviewed-on: https://review.gluster.org/17924
Smoke: Gluster Build System 
Tested-by: Atin Mukherjee 
CentOS-regression: Gluster Build System 
Reviewed-by: Amar Tumballi 
Reviewed-by: Atin Mukherjee