glusterfs.git/api/src, branch v6.7

gfapi: 'glfs_h_creat_open' - new API to create handle and open fd

2019-09-27T11:30:47+00:00

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

Change-Id: Ibf513fcfcdad175f4d7eb6fa7a61b8feec6d33b5
fixes: bz#1755785
Signed-off-by: Soumya Koduri

event: rename event_XXX with gf_ prefixed

2019-08-28T08:34:45+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#1740525
Signed-off-by: Xiubo Li 
(cherry picked from commit 799edc73c3d4f694c365c6a7c27c9ab8eed5f260)

gfapi: Fix deadlock while processing upcall

2019-08-02T10:07:43+00:00

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#1736341
Signed-off-by: Soumya Koduri

gfapi: fix incorrect initialization of upcall syncop arguments

2019-07-05T09:18:40+00:00

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.

This is backport of below mainline fix -
> fixes: bz#1718316
> patch url: https://review.gluster.org/#/c/glusterfs/+/22839/
> Signed-off-by: Soumya Koduri 

Change-Id: I9fa8f841e71d3c37d3819fbd430382928c07176c
fixes: bz#1720635
Signed-off-by: Soumya Koduri 
(cherry picked from commit bc6fd4cfa6ed34de3ffc02e2279fcc713f80f530)

core: avoid dynamic TLS allocation when possible

2019-07-03T06:25:48+00:00

Some interdependencies between logging and memory management functions
make it impossible to use the logging framework before initializing
memory subsystem because they both depend on Thread Local Storage
allocated through pthread_key_create() during initialization.

This causes a crash when we try to log something very early in the
initialization phase.

To prevent this, several dynamically allocated TLS structures have
been replaced by static TLS reserved at compile time using '__thread'
keyword. This also reduces the number of error sources, making
initialization simpler.

Backport of:
> BUG: 1193929
> Change-Id: I8ea2e072411e30790d50084b6b7e909c7bb01d50
> Signed-off-by: Xavi Hernandez 

Updates: bz#1724210
Change-Id: I8ea2e072411e30790d50084b6b7e909c7bb01d50
Signed-off-by: Xavi Hernandez

gfapi: Unblock epoll thread for upcall processing

2019-04-03T04:30:53+00:00

With commit#ad35193,we have made changes to offload
processing upcall notifications to synctask so as not
to block epoll threads. However seems like the issue wasnt
fully addressed.

In "glfs_cbk_upcall_data" -> "synctask_new1" after creating synctask
if there is no callback defined, the thread waits on synctask_join
till the syncfn is finished. So that way even with those changes,
epoll threads are blocked till the upcalls are processed.

Hence the right fix now is to define a callback function for that
synctask "glfs_cbk_upcall_syncop" so as to unblock epoll/notify threads
completely and the upcall processing can happen in parallel by synctask
threads.

Change-Id: I4d8645e3588fab2c3ca534e0112773aaab68a5dd
fixes: bz#1694561
Signed-off-by: Soumya Koduri 
(cherry picked from commit 4a03a71c6171f6e8382664d9d29857d06ef37741)

gfapi: add function to set client-pid

2019-03-29T11:08:32+00:00

This api offers the ability to set the pid of a client to a particular
value, identical to how gluster fuse clients provide the --client-pid
option. This is an internal API to be used by gluster processes only. See
https://lists.gluster.org/pipermail/gluster-devel/2019-March/055925.html
for more details. Currently glfsheal is the only proposed consumer.

updates: bz#1693155
Change-Id: I0620be2127d79d69cdd57cffb29bba44e6e5da1f
Signed-off-by: Ravishankar N 
(cherry picked from commit 08d502c3b05c6f7831bb4cc764bd458b405a99b1)

Updating the glfs_setattr and glfs_fsetattr public APIs to use glfs_stat

2019-02-28T06:30:30+00:00

Change-Id: I0e86c8222c88b4c71087ec287ba81f8353d70822
updates: #389
Signed-off-by: Arjun

api: Update all future API versions to rel-6

2019-02-08T15:47:36+00:00

As release 6 is branched, all future APIs now become 6.0

This change implements the same.

Change-Id: I6db368b4dc8585278ec11d4a411adcd04635de53
Updates: bz#1672818
Signed-off-by: ShyamsundarR 
(cherry picked from commit ddcb3c7438472072daa6fbe3f3b87067b6d7bc54)

api: bad GFAPI_4.1.6 block

2019-01-30T07:01:09+00:00

missing global: line, tabs not spaces

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