glusterfs.git/api/src/glfs-internal.h, branch v3.8.8

gfapi: glfs_subvol_done should NOT wait for graph migration.

2017-01-02T13:11:40+00:00

In graph_setup function glfs_subvol_done is called which
is executed in an epoll thread. glfs_lock waits on other
thread to finish graph migration. This can lead to dead lock
if we consume all the epoll threads.

In general any call-back function executed in epoll thread
should not call any blocking call which waits on a network
reply either directly or indirectly, e.g. syncop functions
should not be called in these threads.

As a fix we should not wait for migration in the call-back path.

> Reviewed-on: http://review.gluster.org/15913
> NetBSD-regression: NetBSD Build System 
> Smoke: Gluster Build System 
> Reviewed-by: Niels de Vos 
> CentOS-regression: Gluster Build System 
(cherry picked from commit 17d10b42fc4041442e6cd0bfda45944edea498c6)

Change-Id: If96d0689fe1b4d74631e383048cdc30b01690dc2
BUG: 1399915
Signed-off-by: Rajesh Joseph 
Reviewed-on: http://review.gluster.org/15977
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan 
Reviewed-by: Niels de Vos

gfapi: redesign the public interface for upcall consumers

2016-10-19T19:18:23+00:00

The glfs_callback_arg and glfs_callback_inode_arg were allocated by
gfapi, and expected to be free()'d by the application. However it is not
reasonable to expect that applications use the same memory allocator to
as the compiled libgfapi.so. For instance, it is possible that gfapi
uses glibc malloc/free, and an application like NFS-Ganesha the versions
from jemalloc. Mismatching of the malloc() and free() functions causes
segmentation faults at best.

In order to prevent problems like this in the future, the API for
applications that consume upcalls has been remodeled. Any of the
structures that gfapi allocates, should be free'd with glfs_free(). The
members of the structures can not be accessed directly anymore, each
has its own function to access now.

Correcting the naming of the functions, structures and constants is a
continuation of commit 2775dc64101ed37c8d9809bf9852dbf0746ee2b6. These
new improvements not only have correct prefixes for the functions and
structures, the naming also reflects more to the upcall framework and
does not use "callback" anymore.

Cherry picked from commit 4721188a154acd9a0a4c096d8d73e97f3bf1b2a9:
> Change-Id: I2b8bd5a0a82036d2abea1a217f5e5975a1d4fe93
> BUG: 1344714
> Signed-off-by: Niels de Vos 
> Reviewed-on: http://review.gluster.org/14701
> Smoke: Gluster Build System 
> NetBSD-regression: NetBSD Build System 
> CentOS-regression: Gluster Build System 
> Reviewed-by: Kaleb KEITHLEY 
> Reviewed-by: soumya k 
> Reviewed-by: jiffin tony Thottan 

For the ease of backporting, this patch also includes the (mostly
overwritten) changes from commit 2775dc64.

Change-Id: I2b8bd5a0a82036d2abea1a217f5e5975a1d4fe93
BUG: 1347717
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/15640
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Kaleb KEITHLEY 
CentOS-regression: Gluster Build System

gfapi: do not cache upcalls if the application is not interested

2016-08-31T07:38:16+00:00

When the volume option 'features.cache-invalidation' is enabled, upcall
events are sent from the brick process to the client. Even if the client
is not interested in upcall events itself, md-cache or other xlators may
benefit from them.

By adding a new 'cache_upcalls' boolean in the 'struct glfs', we can
enable the caching of upcalls when the application called
glfs_h_poll_upcall(). NFS-Ganesha sets up a thread for handling upcalls
in the initialization phase, and calls glfs_h_poll_upcall() before any
NFS-client accesses the NFS-export.

In the future there will be a more flexible registration API for
enabling certain kind of upcall events. Until that is available, this
should work just fine.

Verificatio of this change is not trivial within our current regression
test framework. The bug report contains a description on how to reliably
reproduce the problem with the glusterfs-coreutils.

Cherry picked from commit 218c9b033fa44eacbc27d87491abd830548b362e:
> Change-Id: I818595c92db50e6e48f7bfe287ee05103a4a30a2
> BUG: 1368842
> Signed-off-by: Niels de Vos 
> Reviewed-on: http://review.gluster.org/15191
> Smoke: Gluster Build System 
> Reviewed-by: Poornima G 
> NetBSD-regression: NetBSD Build System 
> CentOS-regression: Gluster Build System 
> Reviewed-by: soumya k 
> Reviewed-by: Kaleb KEITHLEY 

Change-Id: I818595c92db50e6e48f7bfe287ee05103a4a30a2
BUG: 1368841
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/15346
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: soumya k

gfapi: Fix IO error caused when there is consecutive graph switches

2016-08-11T08:35:17+00:00

Backport of http://review.gluster.org/#/c/14722/

This is part 2 of the fix, the part 1 can be found at:
http://review.gluster.org/#/c/14656/

Problem:
=======
Consider a race between, __glfs_active_subvol() and graph_setup().
Lets say @TIME T1:
fs->active_subvol = A
fs->next_subvol = B
__glfs_active_subvol()                //under lock fs->mutex
{
  ....
  new_subvol = fs->next_subvol       //which is B
  ....                               //Start migration from A to B
  __glfs_first_lookup(){
     ....
     unlock fs->mutex                //@TIME T2
     network fop
     lock fs->mutex
     ....
  }
  ....                                //migration continue on B
  fs->active_subvol = fs->next_subvol //which is C (explained below)
  ....
}

@Time T2, lets say in another thread, graph_setup() is called with C,
note that at T2, fs->mutex is unlocked.

graph_stup(C...)
{
  lock fs->mutex
  ....
  if (fs->next_subvol)                // which is B
      destroy subvol (fs->next_subvol)
  ....
  fs->next_subvol = C
  ....
  unlock fs->mutex
}

Thus at the end of this,
fs->old_subvol = A;
fs->active_subvol = C;
fs->next_subvol = NULL;
which is wrong, as B completed migration, but was destroyed by
graph_setup, and C never was migrated.

Solution:
=========
Any new graph can be in one of the 2 states:
- Picked for migration, migration in progress (fs->mip_subvol)
- Not picked so far for migration (fs->next_subvol)
graph_setup() updates fs->next_subvol only, __glfs_active_subvol()
moves fs->next_subvol to fs->mip_subvol and fs->next_subvol = NULL
atomically, and then once the migration is complete, make that the
fs->active_subvol

Change-Id: Ib6ff0565105c5eedb912a43da4017cd413243612
BUG: 1365821
Signed-off-by: Poornima G 
Reviewed-on: http://review.gluster.org/15134
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Rajesh Joseph

libgfapi: glfd close is not correctly handled for async fop

2016-02-11T05:46:30+00:00

There is chance that before the async fop is complete client can send
a close. libgfapi destroys glfd on close. Therefore it can lead to
crash or unexpected behaviour when the pening fop reaches libgfapi
layer. Currently we don't provide any api to cancel these outstanding
fops neither we check if the glfd is already closed or not.

Therefore as a fix provided refcount for glfd. Each fop (sync or async)
will take a ref and once the fop is complete it will unref the refcount.
We should not call the registered callback function if glfd is already
closed. To achieve this we maintain state of glfd so that we can safely
take a call if the fd is closed or not.

Change-Id: Ibe71b2225312db3f1be66b244fcf8826c70c357d
BUG: 1303995
Signed-off-by: Rajesh Joseph 
Reviewed-on: http://review.gluster.org/13340
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan 
NetBSD-regression: NetBSD Build System

api: Fix errno being set to EINVAL even on success

2016-01-05T15:41:10+00:00

BUG: 1289068
Change-Id: I7905ac70a537f23e1844c097a24eaa6cb762fb82
Signed-off-by: Prashanth Pai 
Reviewed-on: http://review.gluster.org/12909
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: jiffin tony Thottan 
Reviewed-by: Kaushal M 
Reviewed-by: Shyamsundar Ranganathan

libgfapi: non-default symbol version macros are incorrect

2015-08-19T16:29:13+00:00

default symbol versions are in form glfs_h_lookupat@@GFAPI_2.7.4,
versus old, non-default versions are in the form glfs_h_lookup@GFAPI_2.4.2

I.e. "@@" versus "@"

Change-Id: I88a6b129558c0b3a6064de7620b3b20425e80bc9
BUG: 1254863
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/11955
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos

rpc: add owner xlator argument to rpc_clnt_new

2015-08-13T06:12:50+00:00

The @owner argument tells RPC layer the xlator that owns
the connection and to which xlator THIS needs be set during
network notifications like CONNECT and DISCONNECT.

Code paths that originate from the head of a (volume) graph and use
STACK_WIND ensure that the RPC local endpoint has the right xlator saved
in the frame of the call (callback pair). This guarantees that the
callback is executed in the right xlator context.

The client handshake process which includes fetching of brick ports from
glusterd, setting lk-version on the brick for the session, don't have
the correct xlator set in their frames. The problem lies with RPC
notifications. It doesn't have the provision to set THIS with the xlator
that is registered with the corresponding RPC programs. e.g,
RPC_CLNT_CONNECT event received by protocol/client doesn't have THIS set
to its xlator. This implies, call(-callbacks) originating from this
thread don't have the right xlator set too.

The fix would be to save the xlator registered with the RPC connection
during rpc_clnt_new. e.g, protocol/client's xlator would be saved with
the RPC connection that it 'owns'. RPC notifications such as CONNECT,
DISCONNECT, etc inherit THIS from the RPC connection's xlator.

Change-Id: I9dea2c35378c511d800ef58f7fa2ea5552f2c409
BUG: 1235582
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/11436
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System 
Reviewed-by: Raghavendra G

libgfapi: Gracefully exit when glfd is invalid

2015-07-07T15:06:43+00:00

When glfs_* methods operating on glfd are invoked after calling
glfs_close(), the program segfaults inside __GLFS_ENTRY_VALIDATE_FD
trying to deference glfd->fd->inode which is invalid.

Also, returning EBADF seemed more specific than EINVAL.

BUG: 1221008
Change-Id: I13a92dca52da9a300252b69e026581b3a9e931fd
Signed-off-by: Prashanth Pai 
Reviewed-on: http://review.gluster.org/10759
Tested-by: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan

build: Mac OS X build issues, gfapi symbol versions

2015-07-04T16:59:18+00:00

fix broken symbol versions

Change-Id: I153b87d80895ddd4718d0a9e51b4c0712b178bd4
BUG: 1238791
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/11514
Reviewed-by: Shyamsundar Ranganathan 
Reviewed-by: Niels de Vos 
Tested-by: Gluster Build System