glusterfs.git/xlators/protocol/client/src/client-handshake.c, branch v3.10.6

protocol/client: Fix double free of client fdctx destroy

2017-02-15T12:33:24+00:00

This patch fixes the race between fd re-open code and fd release code,
both of which free the fd context due to a race in certain variable
checks as explained below:

1. client process (shd in the case of this BZ) sends an opendir to its
children (client xlators) which send the fop to the bricks to get a valid fd.

2. Client xlator loses connection to the brick. fdctx->remotefd is -1

3. Client re-establishes connection. After handshake, it reopens the dir
and sets fdctx->remotefd to a valid fd in client3_3_reopendir_cbk().

4. Meanwhile, shd sends a fd unref after it is done with the opendir.
This triggers a releasedir (since fd->refcount becomes 0).

5. client3_3_releasedir() sees that fdctx-->remotefd is a valid number
(i.e not -1), sets fdctx->released=1 and calls  client_fdctx_destroy()

6. As a continuation of step3, client_reopen_done() is called by
client3_3_reopendir_cbk(), which sees that fdctx->released==1 and
again calls client_fdctx_destroy().

Depending on when step-5 does GF_FREE(fdctx), we may crash at any place in
step-6 in client3_3_reopendir_cbk() when it tries to access
fdctx->{whatever}.


> Reviewed-on: https://review.gluster.org/16521
> CentOS-regression: Gluster Build System 
> NetBSD-regression: NetBSD Build System 
> Smoke: Gluster Build System 
> Reviewed-by: Pranith Kumar Karampuri 

(cherry picked from commit 25fc74f9d1f2b1e7bab76485a99f27abadd10b7b)
Change-Id: Ia50873d11763e084e41d2a1f4d53715438e5e947
BUG: 1422350
Signed-off-by: Ravishankar N 
Reviewed-on: https://review.gluster.org/16619
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan

core: run many bricks within one glusterfsd process

2017-02-02T00:54:58+00:00

This patch adds support for multiple brick translator stacks running in
a single brick server process.  This reduces our per-brick memory usage
by approximately 3x, and our appetite for TCP ports even more.  It also
creates potential to avoid process/thread thrashing, and to improve QoS
by scheduling more carefully across the bricks, but realizing that
potential will require further work.

Multiplexing is controlled by the "cluster.brick-multiplex" global
option.  By default it's off, and bricks are started in separate
processes as before.  If multiplexing is enabled, then *compatible*
bricks (mostly those with the same transport options) will be started in
the same process.

Backport of:
> Change-Id: I45059454e51d6f4cbb29a4953359c09a408695cb
> BUG: 1385758
> Reviewed-on: https://review.gluster.org/14763

Change-Id: I4bce9080f6c93d50171823298fdf920258317ee8
BUG: 1418091
Signed-off-by: Jeff Darcy 
Reviewed-on: https://review.gluster.org/16496
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan

glusterd: Add info on op-version for clients in vol status output

2017-01-12T18:20:59+00:00

Currently the `gluster volume status  clients` command
gives us the following information on clients:
1. Brick name
2. Client count for each brick
3. hostname:port for each client
4. Bytes read and written for each client

There is no information regarding op-version for each client. This
patch adds that to the output.

Change-Id: Ib2ece93ab00c234162bb92b7c67a7d86f3350a8d
BUG: 1409078
Signed-off-by: Samikshan Bairagya 
Reviewed-on: http://review.gluster.org/16303
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Atin Mukherjee

socket: socket disconnect should wait for poller thread exit

2016-12-22T04:49:19+00:00

When SSL is enabled or if "transport.socket.own-thread" option is set
then socket_poller is run as different thread. Currently during
disconnect or PARENT_DOWN scenario we don't wait for this thread
to terminate. PARENT_DOWN will disconnect the socket layer and
cleanup resources used by socket_poller.

Therefore before disconnect we should wait for poller thread to exit.

Change-Id: I71f984b47d260ffd979102f180a99a0bed29f0d6
BUG: 1404181
Signed-off-by: Rajesh Joseph 
Reviewed-on: http://review.gluster.org/16141
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Kaushal M 
Reviewed-by: Raghavendra Talur 
Reviewed-by: Raghavendra G

protocol/client: Fix potential mem-leaks

2016-12-16T09:07:27+00:00

Commit 93eaeb9c93be3232f24e840044d560f9f0e66f71 introduces
leaks in INODELK callback where a dict is unserialized twice,
leading to dict leaks.

Change-Id: I219ccb2279f237ebc2e4fc366af4775a461929b8
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/16156
Smoke: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Raghavendra G 
CentOS-regression: Gluster Build System

protocol/client (no 2): fix unused variable warnings/errors

2016-09-05T11:11:34+00:00

http://review.gluster.org/14085 fixes a/the "leak" - via the
generated rpc/xdr headers - of pragmas that mask these warnings.

However 14085 won't pass the smoke test until all the warnings are
fixed.

BUG: 1369124
Change-Id: I54055b3b1038374b4e21432da48fdaeca2938289
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/15339
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Anuradha Talur 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Niels de Vos

protocol/server: Fix client/server compatibility

2016-06-28T20:27:23+00:00

The 3.8 client expects a child_up key from the server
indicating the status of the server translators. This
key is not being sent by the servers running older
versions, thereby breaking compatibility.

With this patch we are treating the absence of the said
key as an indication that the server trying to connect
to this client is running an older version and hence
in such a case we are setting conf->child_up as
_gf_true explicitly. This should suffice in emulating
the older behavior.

Due to the nature of this bug, requiring two version to
be reproducible, there are no testcases added for the same.

Change-Id: I29e0a5c63b55380dc9db8e42852d7e95b64a2b2e
BUG: 1350327
Signed-off-by: Avra Sengupta 
Reviewed-on: http://review.gluster.org/14811
Reviewed-by: Raghavendra G 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Smoke: Gluster Build System 
Tested-by: Gluster Build System

protocol client/server: Fix client-server handshake

2016-03-10T17:24:33+00:00

Problem:
Currently on a successful connection between protocol
server and client, the protocol client initiates a
CHILD_UP event in the client stack. At this point in
time, only the connection between server and client is
established, and there is no guarantee that the server
side stack is ready to serve requests.

It works fine now, as most server side translators are
not dependent on any other factors, before being able
to serve requests today and hence they are up by the time
the client stack translators receive the CHILD_UP (initiated
by client handshake).

The gap here is exposed when certain server side translators
like NSR-Server for example, have a couple of protocol clients
as their child(connecting them to other bricks), and they
can't really serve requests till a quorum of their children are
up. Hence these translators should defer sending CHILD_UP
till they have enough children up, and the same needs to be
propagated to the client stack translators.

Fix:
Maintain a child_up variable in both the protocol client
and protocol server translators. The protocol server should
update this value based on the CHILD_UP and CHILD_DOWN
events it receives from the translators below it. On receiving
such an event it should forward that event to the client.
The protocol client on receiving such an event should forward
it up the client stack, thereby letting the client translators
correctly know that the server is up and ready to serve.

The clients connecting later(long after a server has initialized
and processed it's CHILD_UP events), will receive a child_up status
as part of the handshake, and based on the status of the server's
child_up, can either propagate a CHILD_UP event or defer it.

Change-Id: I0807141e62118d8de9d9cde57a53a607be44a0e0
BUG: 1312845
Signed-off-by: Avra Sengupta 
Reviewed-on: http://review.gluster.org/13549
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Jeff Darcy

protocol/client: Remove dead code from client_rpc_notify

2015-09-28T11:57:54+00:00

Normally GF_EVENT_CHILD_UP is dispatched after client
handshake. But we have some dead code in client_rpc_notify
which is assumed to do the same on receiving RPC_CLNT_CONNECT.
This dispatch is based on a condition whether "disable-handshake"
is enabled or not. Since we require client-handshake everytime
we have a connect this check for "disable-handshake" is invalid
and no longer required. Moreover this option is never handled
in any of the translators.

Change-Id: Ic862d6ac08cd3b18cf231f50140cd00e84e52ca0
BUG: 1227667
Signed-off-by: Anoop C S 
Reviewed-on: http://review.gluster.org/12170
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Krishnan Parthasarathi 
Reviewed-by: Raghavendra G

protocol/client: Properly handle return value in clnt_release_reopen_fd

2015-06-25T16:53:07+00:00

On account of a lock reacquire failure [in clnt_release_reopen_fd()]
the return value, on submitting the client request for release of
reopened fd, is not honoured correctly.

Change-Id: Iff11523b2cc6f284e806855f32a13d8c4432f1c6
BUG: 1227667
Signed-off-by: Anoop C S 
Reviewed-on: http://review.gluster.org/11088
Tested-by: NetBSD Build System 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G