To convert the existing `gf_msg` to `gf_smsg`:

- Define `_STR` of respective Message ID as below(In `*-messages.h`)

  #define PC_MSG_REMOTE_OP_FAILED_STR "remote operation failed."

- Change `gf_msg` to use `gf_smsg`. Convert values into fields and
  add any missing fields. Note: `errno` and `error` fields will be
  added automatically to log message in case errnum is specified.

  Example:

  gf_smsg(
    this->name,                            // Name or log domain
    GF_LOG_WARNING,                        // Log Level
    rsp.op_errno,                          // Error number
    PC_MSG_REMOTE_OP_FAILED,               // Message ID
    "path=%s", local->loc.path,            // Key Value 1
    "gfid=%s", loc_gfid_utoa(&local->loc), // Key Value 2
    NULL                                   // Log End
  );

Key value pairs formatting Help:

  gf_slog(
    this->name,                               // Name or log domain
    GF_LOG_WARNING,                           // Log Level
    rsp.op_errno,                             // Error number
    PC_MSG_REMOTE_OP_FAILED,                  // Message ID
    "op=CREATE",                              // Static Key and Value
    "path=%s", local->loc.path,               // Format for Value
    "brick-%d-status=%s", brkidx, brkstatus,  // Use format for key and val
    NULL                                      // Log End
  );

Before:

[2019-07-03 08:16:18.226819] W [MSGID: 114031] [client-rpc-fops_v2.c \
:2633:client4_0_lookup_cbk] 0-gv3-client-0: remote operation failed. \
Path: / (00000000-0000-0000-0000-000000000001) [Transport endpoint   \
is not connected]

After:

[2019-07-29 07:50:15.773765] W [MSGID: 114031]                   \
[client-rpc-fops_v2.c:2633:client4_0_lookup_cbk] 0-gv1-client-0: \
remote operation failed. [{path=/f1},                            \
{gfid=00000000-0000-0000-0000-000000000000},                     \
{errno=107}, {error=Transport endpoint is not connected}]

To add new `gf_smsg`, Add a Message ID in respective `*-messages.h` file
and the follow the steps mentioned above.

Change-Id: I4e7d37f27f106ab398e991d931ba2ac7841a44b1
Updates: #657
Signed-off-by: Aravinda VK <avishwan@redhat.com>

Problem: In brick_mux environment sometime brick is crashed while
         volume stop/start in a loop.Brick is crashed in janitor task
         at the time of accessing priv.If posix priv is cleaned up before
         call janitor task then janitor task is crashed.

Solution: To avoid the crash in brick_mux environment introduce a new
          flag janitor_task_stop in posix_private and before send CHILD_DOWN event
          wait for update the flag by janitor_task_done

Change-Id: Id9fa5d183a463b2b682774ab5cb9868357d139a4
fixes: bz#1730409
Signed-off-by: Mohit Agrawal <moagrawal@redhat.com>

Moved null pointer check up in order to avoid seg-fault

CID: 1404258
Updates: bz#789278

Change-Id: Ib97e05302bfeb8fe38d6ce9870b9740cb576e492
Signed-off-by: Barak Sason <bsasonro@redhat.com>

Goal: 'libglusterfs' files shouldn't have any dependency outside of
      the tree, specially the header files, shouldn't have '#include'
      from outside the tree.

Fixes:
* Had to introduce libglusterd so, methods and structures required
  for only mgmt/glusterd, and cli/ are separated from 'libglusterfs/'
* Remove rpc/xdr/gen from build, which was used mainly so
  dependency for libglusterfs could be properly satisfied.
* Move rpcsvc_auth_data to client_t.h, so all dependencies could
  be handled.

Updates: bz#1636297
Change-Id: I0e80243a5a3f4615e6fac6e1b947ad08a9363fce
Signed-off-by: Amar Tumballi <amarts@redhat.com>

- Removal of quite a bit of dead code.
- Use dict_set_str_sizen and friends where applicable.
- Moved some functions to be static and initialize values right away.

Change-Id: Ic25b5da4028198694a0e24796dea375661eb66b9
updates: bz#1193929
Signed-off-by: Yaniv Kaul <ykaul@redhat.com>

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.

Fixes: #699

Change-Id: I38f0200b941bd1cff4bf3066fca2fc1f9a5263aa
Signed-off-by: Xiubo Li <xiubli@redhat.com>

This function does length, allocation and serialization for you.

Change-Id: I142a259952a2fe83dd719442afaefe4a43a8e55e
updates: bz#1193929
Signed-off-by: Yaniv Kaul <ykaul@redhat.com>

Two reasons:
* ping responses from glusterd may not be relevant for Halo
  replication. Instead, it might be interested in only knowing whether
  the brick itself is responsive.
* When a brick is killed, propagating GF_EVENT_CHILD_PING of ping
  response from glusterd results in GF_EVENT_DISCONNECT spuriously
  propagated to parent xlators. These DISCONNECT events are from the
  connections client establishes with glusterd as part of its
  reconnect logic. Without GF_EVENT_CHILD_PING, the last event
  propagated to parent xlators would be the first DISCONNECT event
  from brick and hence subsequent DISCONNECTS to glusterd are not
  propagated as protocol/client prevents same event being propagated
  to parent xlators consecutively. propagating GF_EVENT_CHILD_PING for
  ping responses from glusterd would change the last_sent_event to
  GF_EVENT_CHILD_PING and hence protocol/client cannot prevent
  subsequent DISCONNECT events

Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
Fixes: bz#1716979
Change-Id: I50276680c52f05ca9e12149a3094923622d6eaef

* locks/posix.c: key was not freed in one of the cases.
* locks/common.c: lock was being free'd out of context.
* nfs/exports: handle case of missing free.
* protocol/client: handle case of entry not freed.
* storage/posix: handle possible case of double free

CID: 1398628, 1400731, 1400732, 1400756, 1124796, 1325526

updates: bz#789278
Change-Id: Ieeaca890288bc4686355f6565f853dc8911344e8
Signed-off-by: Amar Tumballi <amarts@redhat.com>
Signed-off-by: Sheetal Pamecha <spamecha@redhat.com>

At the moment new stack doesn't populate frame->root->unique in all cases. This
makes it difficult to debug hung frames by examining successive state dumps.
Fuse and server xlators populate it whenever they can, but other xlators won't
be able to assign 'unique' when they need to create a new frame/stack because
they don't know what 'unique' fuse/server xlators already used. What we need is
for unique to be correct. If a stack with same unique is present in successive
statedumps, that means the same operation is still in progress. This makes
'finding hung frames' part of debugging hung frames easier.

fixes bz#1714098
Change-Id: I3e9a8f6b4111e260106c48a2ac3a41ef29361b9e
Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>