glusterfs.git/rpc, branch v3.6.3beta1

rdma:vectored write fails for rdma.

2015-01-07T05:41:17+00:00

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

For rdma write with payload count greater than one
will fail due to insuffient memory to hold the
buffers in rpc transport layer. It was expecting
only one vector in payload, So it can only able
to decode the first iovec from payload, and the
rest will be discarded.

Thnaks to Raghavendra Gowdappa for fixing the
same.

BUG: 1166515
Change-Id: I5e44d240366af78df35df326fe0660ef8497147b
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/9247
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/9392
Reviewed-by: Raghavendra Bhat

rdma:client process will hang if server is started to send the request before completing connection establishment

2015-01-06T09:46:06+00:00

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

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: I1797ae8a25163864c338641d74cd4eef6fb34bb5
BUG: 1166515
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 
Reviewed-on: http://review.gluster.org/9178
Reviewed-by: Raghavendra Bhat

rdma: client connection establishment takes more time

2015-01-06T09:43:45+00:00

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

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: I82a8a27f0e65a2e287f321e5e8292d86c6baf5b4
BUG: 1166515
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 
Reviewed-on: http://review.gluster.org/9177
Reviewed-by: Raghavendra Bhat

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

2015-01-06T09:39:15+00:00

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

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: I73f90d7340afa3b0b1278924206f1488e4094a62
BUG: 1166515
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 
Reviewed-on: http://review.gluster.org/9176
Reviewed-by: Raghavendra Bhat

rdma:setting rdma REUSEADDR flag to rdma id.

2015-01-06T09:36:23+00:00

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

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: Ifb191967930d23bac31ceef1b1745d6b9fb0007b
BUG: 1166515
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 
Reviewed-on: http://review.gluster.org/9175
Reviewed-by: Raghavendra Bhat

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

2015-01-06T09:35:32+00:00

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

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: Ie783fdbb4342459e5bc162bf8600bf47c1e2e909
BUG: 1166515
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/8925
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/9174
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra Bhat

rdma: mount hangs for rdma type transport.

2015-01-06T09:33:57+00:00

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

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: Ia15884ab28a0c51cccfef84258c3671a468054d9
BUG: 1166515
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 
Reviewed-on: http://review.gluster.org/9173
Reviewed-by: Raghavendra Bhat

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

2014-12-13T06:04:48+00:00

Thanks for Markiyan Kushnir  for
reporting this

Change-Id: Ia0272e51be4ddede1e6bc188dfb892979626a7cd
BUG: 1171524
Signed-off-by: Harshavardhana 
Reviewed-on: http://review.gluster.org/9252
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos 
Reviewed-by: Raghavendra Bhat 
Tested-by: Raghavendra Bhat

socket: disallow CBC cipher modes

2014-10-29T11:37: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: 1157659
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 
Reviewed-on: http://review.gluster.org/8987
Reviewed-by: Niels de Vos 
Tested-by: Niels de Vos

Use sane OS-dependent defaults for SSL configuration

2014-09-26T12:24:20+00:00

Current code assumes /etc/ssl exists, which may not be the case.
Attempt to guess sane default for a few OS.

Backport of I0f3168f79b8f4275636581041740dfcaf25f3edd

BUG: 1138897
Change-Id: I972c26236cbf070f15c3846add059bd33d60216d
Signed-off-by: Emmanuel Dreyfus 
Reviewed-on: http://review.gluster.org/8861
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur