glusterfs.git/rpc, branch v8dev

core: fedora 30 compiler warnings

2019-06-18T10:53:49+00:00

warning: ‘%s’ directive argument is null [-Wformat-overflow=]

Change-Id: I69b8d47f0002c58b00d1cc947fac6f1c64e0b295
updates: bz#1193929
Signed-off-by: SheetalPamecha

multiple files: another attempt to remove includes

2019-06-14T16:50:32+00:00

There are many include statements that are not needed.
A previous more ambitious attempt failed because of *BSD plafrom
(see https://review.gluster.org/#/c/glusterfs/+/21929/ )

Now trying a more conservative reduction.
It does not solve all circular deps that we have, but it
does reduce some of them. There is just too much to handle
reasonably (dht-common.h includes dht-lock.h which includes
dht-common.h ...), but it does reduce the overall number of lines
of include we need to look at in the future to understand and fix
the mess later one.

Change-Id: I550cd001bdefb8be0fe67632f783c0ef6bee3f9f
updates: bz#1193929
Signed-off-by: Yaniv Kaul

across: clang-scan: fix NULL dereferencing warnings

2019-06-04T10:30:29+00:00

All these checks are done after analyzing clang-scan report produced
by the CI job @ https://build.gluster.org/job/clang-scan

updates: bz#1622665
Change-Id: I590305af4ceb779be952974b2a36066ffc4865ca
Signed-off-by: Amar Tumballi

If bind-address is IPv6 return it successfully

2019-05-28T17:10:05+00:00

Change-Id: Ibd37b6ea82b781a1a266b95f7596874134f30079
fixes: bz#1713730
Signed-off-by: Amgad Saleh

Fix some "Null pointer dereference" coverity issues

2019-05-26T13:59:13+00:00

This patch fixes the following CID's:

  * 1124829
  * 1274075
  * 1274083
  * 1274128
  * 1274135
  * 1274141
  * 1274143
  * 1274197
  * 1274205
  * 1274210
  * 1274211
  * 1288801
  * 1398629

Change-Id: Ia7c86cfab3245b20777ffa296e1a59748040f558
Updates: bz#789278
Signed-off-by: Xavi Hernandez

Revert "rpc: implement reconnect back-off strategy"

2019-05-21T08:36:32+00:00

This reverts commit 59841f7e1ff0511b04884015441a181a56d07bea.

This revert is done as a 'possible' fix for frequent regression
failures, which are random in nature too (ie, different tests fails
in different runs).

Why exactly this patch? Because this patch seemed like most probable
candidate which got merged in last 15days, and after which regressions
are failing more often.

Updates: bz#1711827
Change-Id: I35333162fcd4064f9609525ca93c666053c6d959

rpc: implement reconnect back-off strategy

2019-05-11T14:25:53+00:00

When a connection failure happens, gluster tries to reconnect every 3
seconds. In some cases the failure is spurious, so a delay of 3 seconds
could be unnecessarily long.

This patch implements a back-off strategy that tries a reconnect as soon
as 1 tenth of a second. If this fails, the time is doubled until it's
around 3 seconds. After that, the reconnect is attempted every 3 seconds
as before.

Change-Id: Icb3fbe20d618f50cbbb599dce542b4e871c22149
Updates: bz#1193929
Signed-off-by: Xavier Hernandez

protocol: remove compound fop

2019-04-29T05:29:44+00:00

Compound fops are kept on wire as a backward compatibility with
older AFR modules. The AFR module used beyond 4.x releases are
not using compound fops. Hence removing the compound fop in the
protocol code.

Note that, compound-fops was already an 'option' in AFR, and
completely removed since 4.1.x releases.

So, point to note is, with this change, we have 2 ways to upgrade
when clients of 3.x series are present.

i) set 'use-compound-fops' option to 'false' on any volume which
   is of replica type. And then upgrade the servers.

ii) Do a two step upgrade. First from current version (which will
    already be EOL if it's using compound) to a 4.1..6.x version,
    and then an upgrade to 7.x.

Consider the overall code which we are removing for the option
seems quite high, I believe it is worth it.

updates: bz#1693692
Signed-off-by: Amar Tumballi 
Change-Id: I0a8876d0367a15e1410ec845f251d5d3097ee593

rpclib: slow floating point math and libm

2019-04-03T04:40:15+00:00

In release-6 rpc/rpc-lib (libgfrpc) added the function
get_rightmost_set_bit() which calls log2(3), a call that takes
a floating point parameter.

It's used thusly:
    right_most_unset_bit = get_rightmost_set_bit(...);

(So is it really the right-most unset bit, or the right-most set bit?)

It's unclear to me whether this is in the data path or not. If it is,
it's rather scary to think about integer-to-float conversions and slow
calls to libm functions in the data path.

gcc and clang have __builtin_ctz() which returns the same result as
get_rightmost_set_bit(), and does it substantially faster. Approx
20M iterations of get_rightmost_set_bit() took ~33sec of wall clock
time on my devel machine, while 20M iterations of __builtin_ctz()
took < 9sec; get_rightmost_set_bit() is 3x slower than __builtin_ctz().

And as a side benefit, we can again eliminate the need to link libgfrpc
with libm.

Change-Id: If9e7e80874577c52223f8125b385fc930de20699
updates: bz#1193929
Signed-off-by: Kaleb S. KEITHLEY

transport/socket: log shutdown msg occasionally

2019-04-03T04:12:52+00:00

Change-Id: If3fc0884e7e2f45de2d278b98693b7a473220a5f
Signed-off-by: Raghavendra G 
Fixes: bz#1691616