glusterfs.git/rpc/rpc-transport, branch bug-deprecated

Ignore all deprecated warnings for OPENSSL on DARWIN

2015-01-12T20:54:48+00:00

build: FreeBSD 11-Current causes libtool to fail with '-shared'

2014-12-12T09:21:49+00:00

Thanks for Markiyan Kushnir  for
reporting this

Change-Id: I7f637295c7c2d54c33a4c16e29daf0b518874911
BUG: 1111774
Signed-off-by: Harshavardhana 
Reviewed-on: http://review.gluster.org/9251
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos

rpc/rpcsvc: add peername to log messages

2014-12-11T06:35:03+00:00

This would allow users/developers to associate rpc layer log messages
to the corresponding connection.

Change-Id: I040f79248dced7174a4364d9f995612ed3540dd4
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/8535
Tested-by: Gluster Build System 
Reviewed-by: Rajesh Joseph 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G

rdma:client process will hang if server is started to send

2014-11-18T10:38:33+00:00

the request before completing connection establishment

in rdma, client and server will interchange their available
buffers during the handshake to post incoming messages.
Initially the available buffer is set to one, for the first message
during handshake,when first message is received, quota for
the buffer will set to proper value. So before receiving the message
if server started to send the message, then the reserverd buffer for
handshake will be utilised, then the handshake will fail because
of lack of buffers. So we should block sending messages by server
before proper connection establishment.

Change-Id: I68ef44998f5df805265d3f42a5df7c31cb57f136
BUG: 1158746
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/9003
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G

rdma: client connection establishment takes more time

2014-11-18T08:50:13+00:00

For rdma type only volume client connection establishment
with server takes more than three seconds. Because for
tcp,rdma type volume, will have 2 ports one for tcp and
one for rdma, tcp port is stored with brickname and rdma
port is stored as "brickname.rdma" during pamap_sighin.
During the handshake when trying to get the brick port
for rdma clients, since we are not aware of server
transport type, we will append '.rdma' with brick name.
So for tcp,rdma volume there will be an entry with
'.rdma', but it will fail for rdma type only volume.
So we will try again, this time without appending '.rdma'
using a flag variable need_different_port, and it will succeed,
but the reconnection happens only after 3 seconds.
In this patch for rdma only type volume 
we will append '.rdma' during the pmap_signin. So during the
handshake we will get the correct port for first try itself.
Since we don't need to retry , we can remove the
need_different_port flag variable.

Change-Id: Ie8e3a7f532d4104829dbe995e99b35e95571466c
BUG: 1153569
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/8934
Tested-by: Gluster Build System 
Reviewed-by: Krishnan Parthasarathi 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G

rdma:rdma fuse mount hangs for tcp,rdma volumes if brick is down.

2014-11-18T07:30:55+00:00

When we try to mount a tcp,rdma volume as rdma
transport using FUSE protocol, then mount will
hang if the brick is down. When we kill a process,
signal will be received in glusterfsd process and
it will call pmap_signout with port listening on tcp only.
In case of the tcp,rdma there will be two ports,
and port which is listening for rdma will not
called for sign out. 
So the mount process will try to connect to a port
which is not open and it will keep trying to connect.
This patch will call pmap_signout for rdma port also,
So when mount tries to get the brick port,it will fail.

Change-Id: I23676f65f96eb90b69b76478f7a21412a6aba70f
BUG: 1143886
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/8762
Tested-by: Gluster Build System 
Reviewed-by: Krishnan Parthasarathi 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G

rdma: glusterd crash if rdma_disconnect is called as soon as connect a request.

2014-11-14T12:03:59+00:00

we are initializing connection in server side immediately after
rdma_accept is called. But we are delaying adding the transport
to listener list until getting RDMA_CM_EVENT_ESTABLISHED event.
Before getting this event if disconnect is called glusterd will
try to remove the transport from list which is not added. So if
the list is empty it causes a glusterd crash . In this patch we
will call the function to initialize the connection as soon as
rdma_accept is called.

Change-Id: I019480297a85349ede3101ee9c7c1596dc5c73e2
Signed-off-by: Mohammed Rafi KC 
BUG: 1164079
Reviewed-on: http://review.gluster.org/8925
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G

rdma:setting rdma REUSEADDR flag to rdma id.

2014-11-14T05:57:41+00:00

When we restart the process, it will go TIME_WAIT state to make sure that
all the data in the transport is successfully delivered. REUSEADDR 
allows server to bind to an address which is in TIME_WAIT state.

Change-Id: Ic7deb0d7442c29494fe088598ffe9c87977c04ff
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/9005
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G

socket: disallow CBC cipher modes

2014-10-27T11:40:55+00:00

This is related to CVE-2014-3566 a.k.a. POODLE.

	http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3566

POODLE is specific to CBC cipher modes in SSLv3.  Because there is no
way to prevent SSLv3 fallback on a system with an unpatched version of
OpenSSL, users of such systems can only be protected by disallowing CBC
modes.  The default cipher-mode specification in our code has been
changed accordingly.  Users can still set their own cipher modes if they
wish.  To support them, the ssl-authz.t test script provides an example
of how to combine the CBC exclusion with other criteria in a script.

Change-Id: Ib1fa547082fbb7de9df94ffd182b1800d6e354e5
BUG: 1155328
Signed-off-by: Jeff Darcy 
Reviewed-on: http://review.gluster.org/8962
Tested-by: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Vijay Bellur

rdma: mount hangs for rdma type transport.

2014-10-08T08:44:36+00:00

rdma transport type mount will hang if there is a delay
in network to receive,we will set transport as connected
if we get an event type RDMA_CM_EVENT_ESTABLISHED,
we cannot assure whether client or server will get the
event first, the only condition is that the side which
sends the first request should wait for the event.
If client gets the event first, then it sends DUMP request,
in server side the request will reach, but it will reject
the rpc request since it didn't get the RDMA_CM_EVENT_ESTABLISHED.
So in server we will set the connected flag as soon
as rdma_accept is called.

Change-Id: Iac5845e3592666daa575c727822889779b5bd203
BUG: 1146492
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/8850
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G