Right now we have two separate APIs, one
- 'glfs_h_creat_handle' to create handle & another
- 'glfs_h_open' to create a glfd to return to application

Having two separate routines can result in access errors
while trying to create and write into a read-only file.

Since a fd is opened even during file/directory creation,
introducing a new API to make these two operations atomic i.e,
which can create both handle & fd and pass them to application

This is backport of below mainline patch -
- https://review.gluster.org/#/c/glusterfs/+/23448/
- bz#1753569

release-6:
- https://review.gluster.org/#/c/glusterfs/+/23491/

Change-Id: Ibf513fcfcdad175f4d7eb6fa7a61b8feec6d33b5
fixes: bz#1756002
Signed-off-by: Soumya Koduri <skoduri@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.

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

Change-Id: I38f0200b941bd1cff4bf3066fca2fc1f9a5263aa
updates: bz#1740519
Signed-off-by: Xiubo Li <xiubli@redhat.com>
(cherry picked from commit 799edc73c3d4f694c365c6a7c27c9ab8eed5f260)

As mentioned in bug1733166, there could be potential deadlock
while processing upcalls depending on how each xlator choose
to act on it. The right way of fixing such issues
is to change rpc callback communication process.
- https://github.com/gluster/glusterfs/issues/697

Till then, making changes in gfapi layer to avoid any I/O
processing.

This is backport of below mainline patch
> https://review.gluster.org/#/c/glusterfs/+/23108/
> bz#1733166

Change-Id: I2079e95339e5d761d5060707f4555cfacab95c83
fixes: bz#1736345
Signed-off-by: Soumya Koduri <skoduri@redhat.com>

As release 7 is branched, all future APIs now become 7.0
This change implements the same.

Change-Id: I420e9ea43b07a40a4fb911ee56fb7436c2744edc
Updates: bz#1732875
Signed-off-by: Rinku Kothiya <rkothiya@redhat.com>

in one of the recent patches, we cleaned-up the unneccesary header
file includes. In the order of merging the patches, there cropped
up an compile error.

updates: bz#1193929
Change-Id: I2ad52aa918f9c698d5273bb293838de6dd50ac31
Signed-off-by: Amar Tumballi <amarts@redhat.com>

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 <ykaul@redhat.com>

Currently for an application using glfsapi to use glusterfs, when a
statedump is taken, it uses /var/run/gluster dir to dump info.

There can be concerns as this directory may be owned by some other
user, and hence it may fail taking statedump. Such applications
should have an option to use different path.

This patch provides an API to do so.

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

While sending upcall notifications via synctasks, the argument used to
carry relevant data for these tasks is not initialized properly. This patch
is to fix the same.

Change-Id: I9fa8f841e71d3c37d3819fbd430382928c07176c
fixes: bz#1718316
Signed-off-by: Soumya Koduri <skoduri@redhat.com>

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 <amarts@redhat.com>

* add more fops: f{get,set,list,remove}xattr(), access(), fstat(), fsetattr(),
getxattr(), lgetxattr(), llistxattr(), lsetxattr(), fgetxattr()
* handle some error cases (like volume not found)

Updates: #655
Change-Id: I3334bdf3090eafd83a54e1be12036ea01b181089
Signed-off-by: Amar Tumballi <amarts@redhat.com>
Signed-off-by: Sheetal Pamecha <spamecha@redhat.com>