glusterfs.git/rpc, branch v7.4

rpc: Cleanup SSL specific data at the time of freeing rpc object

2020-02-10T07:50:06+00:00

Problem: At the time of cleanup rpc object ssl specific data
         is not freeing so it has become a leak.

Solution: To avoid the leak cleanup ssl specific data at the
          time of cleanup rpc object

> Credits: l17zhou 
> Fixes: bz#1768407
> Change-Id: I37f598673ae2d7a33c75f39eb8843ccc6dffaaf0
> (cherry picked from commit > > 54ed71dba174385ab0d8fa415e09262f6250430c)

Change-Id: I37f598673ae2d7a33c75f39eb8843ccc6dffaaf0
Fixes: bz#1795540
Signed-off-by: Mohit Agrawal

socket: fix error handling

2019-12-18T10:28:53+00:00

When __socket_proto_state_machine() detected a problem in the size of
the request or it couldn't allocate an iobuf of the requested size, it
returned -ENOMEM (-12). However the caller was expecting only -1 in
case of error. For this reason the error passes undetected initially,
adding back the socket to the epoll object. On further processing,
however, the error is finally detected and the connection terminated.
Meanwhile, another thread could receive a poll_in event from the same
connection, which could cause races with the connection destruction.
When this happened, the process crashed.

To fix this, all error detection conditions have been hardened to be
more strict on what is valid and what not. Also, we don't return
-ENOMEM anymore. We always return -1 in case of error.

An additional change has been done to prevent destruction of the
transport object while it may still be needed.

Backport of:
> Change-Id: I6e59cd81cbf670f7adfdde942625d4e6c3fbc82d
> Fixes: bz#1782495
> Signed-off-by: Xavi Hernandez 

Change-Id: I6e59cd81cbf670f7adfdde942625d4e6c3fbc82d
Fixes: bz#1783227
Signed-off-by: Xavi Hernandez

rpcsvc: fix subnet_mask_v4 check

2019-11-28T10:03:04+00:00

The check we had for subnet mask validation wasn't checking in
proper sequence. Corrected the order of calling `inet_pton()` as
the fix.

Fixes: bz#1777769
Change-Id: I5d31468eb917aa94cbb85f573b37c60023e9daf3
Signed-off-by: Amar Tumballi 
(cherry picked from commit d60935d1011e387115e0445629976196f566b3b1)

rpc: Update address family if it is not provide in cmd-line arguments

2019-09-09T08:48:23+00:00

Problem: After enabling transport-type to inet6 and passed ipv6
         transport.socket.bind-address in glusterd.vol clients are
         not started.

Solution: Need to update address-family based on remote-address for
          all gluster client process

> Change-Id: Iaa3588cd87cebc45231bfd675745c1a457dc9b31
> Fixes: bz#1747746
> Credits: Amgad Saleh 
> Signed-off-by: Mohit Agrawal 
> (cherry picked from commit 80b8cfe3f1386606bada97a76a0cad7acdf6b877)

Change-Id: Iaa3588cd87cebc45231bfd675745c1a457dc9b31
Fixes: bz#1749664
Credits: Amgad Saleh 
Signed-off-by: Mohit Agrawal

event: rename event_XXX with gf_ prefixed

2019-08-21T06:13:38+00:00

I hit one crash issue when using the libgfapi.

In the libgfapi it will call glfs_poller() --> event_dispatch()
in file api/src/glfs.c:721, and the event_dispatch() is defined
by libgluster locally, the problem is the name of event_dispatch()
is the extremly the same with the one from libevent package form
the OS.

For example, if a executable program Foo, which will also use and
link the libevent and the libgfapi at the same time, I can hit the
crash, like:

kernel: glfs_glfspoll[68486]: segfault at 1c0 ip 00007fef006fd2b8 sp
00007feeeaffce30 error 4 in libevent-2.0.so.5.1.9[7fef006ed000+46000]

The link for Foo is:
lib_foo_LADD = -levent $(GFAPI_LIBS)
It will crash.

This is because the glfs_poller() is calling the event_dispatch() from
the libevent, not the libglsuter.

The gfapi link info :
GFAPI_LIBS = -lacl -lgfapi -lglusterfs -lgfrpc -lgfxdr -luuid

If I link Foo like:
lib_foo_LADD = $(GFAPI_LIBS) -levent
It will works well without any problem.

And if Foo call one private lib, such as handler_glfs.so, and the
handler_glfs.so will link the GFAPI_LIBS directly, while the Foo won't
and it will dlopen(handler_glfs.so), then the crash will be hit everytime.

The link info will be:
foo_LADD = -levent
libhandler_glfs_LIBADD = $(GFAPI_LIBS)

I can avoid the crash temporarily by linking the GFAPI_LIBS in Foo too like:
foo_LADD = $(GFAPI_LIBS) -levent
libhandler_glfs_LIBADD = $(GFAPI_LIBS)

But this is ugly since the Foo won't use any APIs from the GFAPI_LIBS.

And in some cases when the --as-needed link option is added(on many dists
it is added as default), then the crash is back again, the above workaround
won't work.

Backport of:
> https://review.gluster.org/#/c/glusterfs/+/23110/
> Change-Id: I38f0200b941bd1cff4bf3066fca2fc1f9a5263aa
> Fixes: #699
> Signed-off-by: Xiubo Li 

Change-Id: I38f0200b941bd1cff4bf3066fca2fc1f9a5263aa
updates: bz#1740519
Signed-off-by: Xiubo Li 
(cherry picked from commit 799edc73c3d4f694c365c6a7c27c9ab8eed5f260)

rpc: glusterd start is failed and throwing an error Address already in use

2019-08-19T11:41:31+00:00

Problem: Some of the .t are failed due to bind is throwing
         an error EADDRINUSE

Solution: After killing all gluster processes .t is trying
          to start glusterd but somehow if kernel has not cleaned
          up resources(socket) then glusterd startup is failed due to
          bind system call failure.To avoid the issue retries to call
          bind 10 times to execute system call succesfully

> Change-Id: Ia5fd6b788f7b211c1508c1b7304fc08a32266629
> Fixes: bz#1743020
> Signed-off-by: Mohit Agrawal 
> (cherry picked from commit c370c70f77079339e2cfb7f284f3a2fb13fd2f97)

Change-Id: Ia5fd6b788f7b211c1508c1b7304fc08a32266629
Fixes: bz#1743218
Signed-off-by: Mohit Agrawal

ctime: Set mdata xattr on legacy files

2019-08-19T11:27:14+00:00

Problem:
The files which were created before ctime enabled would not
have "trusted.glusterfs.mdata"(stores time attributes) xattr.
Upon fops which modifies either ctime or mtime, the xattr
gets created with latest ctime, mtime and atime, which is
incorrect. It should update only the corresponding time
attribute and rest from backend

Solution:
Creating xattr with values from brick is not possible as
each brick of replica set would have different times.
So create the xattr upon successful lookup if the xattr
is not created

Note To Reviewers:
The time attributes used to set xattr is got from successful
lookup. Instead of sending the whole iatt over the wire via
setxattr, a structure called mdata_iatt is sent. The mdata_iatt
contains only time attributes.

Backport of:
 > Patch:  https://review.gluster.org/22936
 > Change-Id: I5e535631ddef04195361ae0364336410a2895dd4
 > BUG: 1593542
 > Signed-off-by: Kotresh HR 

Change-Id: I5e535631ddef04195361ae0364336410a2895dd4
updates: bz#1739430
Signed-off-by: Kotresh HR

glusterd/svc: update pid of mux volumes from the shd process

2019-07-24T10:29:17+00:00

For a normal volume, we are updating the pid from a the
process while we do a daemonization or at the end of the
init if it is no-daemon mode. Along with updating the pid
we also lock the file, to make sure that the process is
running fine.

With brick mux, we were updating the pidfile from gluterd
after an attach/detach request.

There are two problems with this approach.
1) We are not holding a pidlock for any file other than parent
   process.
2) There is a chance for possible race conditions with attach/detach.
   For example, shd start and a volume stop could race. Let's say
   we are starting an shd and it is attached to a volume.
   While we trying to link the pid file to the running process,
   this would have deleted by the thread that doing a volume stop.

Backport of : https://review.gluster.org/#/c/glusterfs/+/22935/
>Change-Id: I29a00352102877ce09ea3f376ca52affceb5cf1a
>Updates: bz#1722541
>Signed-off-by: Mohammed Rafi KC 

Change-Id: I29a00352102877ce09ea3f376ca52affceb5cf1a
Updates: bz#1732668
Signed-off-by: Mohammed Rafi KC

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