glusterfs.git/api/src, branch v3.8.3

gfapi: add missing glfs_truncate

2016-08-12T11:19:56+00:00

> Reviewed-on: http://review.gluster.org/13927
> Smoke: Gluster Build System 
> CentOS-regression: Gluster Build System 
> NetBSD-regression: NetBSD Build System 
> Reviewed-by: Kaleb KEITHLEY 

BUG: 1366281
Change-Id: I80b016090a4d9d86278a0a5144dd58c0cbfe9bb2
Signed-off-by: Jeff Darcy 
Signed-off-by: Oleksandr Natalenko 
Reviewed-on: http://review.gluster.org/15149
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Prashanth Pai

gfapi: use const qualifier for glfs_*timens()

2016-08-12T11:19:42+00:00

glfs_*timens() functions have the last argument
of struct timespec type that is supposed to be
const. Now using glfs_*timens() in fops, implemented
on top of FUSE library, leads to compiler-time warning
about discarding const qualifier.

Introducing const qualifier does not break ABI,
so let's just fix it.

> Reviewed-on: http://review.gluster.org/15119
> Smoke: Gluster Build System 
> CentOS-regression: Gluster Build System 
> NetBSD-regression: NetBSD Build System 
> Reviewed-by: Niels de Vos 

BUG: 1365864
Change-Id: Iea2a1018de7dce67f67a8229671a5978246de800
Signed-off-by: Oleksandr Natalenko 
Reviewed-on: http://review.gluster.org/15136
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Prashanth Pai

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

glfs/upcall: entries should be removed under mutex lock

2016-08-03T09:26:33+00:00

During poll, upcall entries should be removed from the
upcall_list only under upcall_list_mutex lock. Otherwise
it could result in the list corruption if there are entries
being added during poll resulting in memory leak.

Also addressed a probable leak during any failures with upcall
entry addition.

This is backport of below master patch -
   http://review.gluster.org/14972

>Change-Id: I468183f961eb6faed9a0a1bcb783705f711641fc
>BUG: 1358608
>Signed-off-by: Soumya Koduri 
>Reviewed-on: http://review.gluster.org/14972
>Reviewed-by: Shyamsundar Ranganathan 
>Reviewed-by: Jeff Darcy 
>(cherry picked from commit 89dee8b46e126bc1d7541da90fa60844aa83451e)

Change-Id: I8f83175c7b550d8674dda5030168d5b94ccdd04c
BUG: 1361665
Signed-off-by: Soumya Koduri 
Reviewed-on: http://review.gluster.org/15048
NetBSD-regression: NetBSD Build System 
Reviewed-by: Niels de Vos 
Smoke: Gluster Build System 
Reviewed-by: jiffin tony Thottan 
CentOS-regression: Gluster Build System

gfapi/upcall: Fix a ref leak

2016-08-01T09:01:17+00:00

inode_find (used to create the handle) takes a reference
of the inode. This needs to be un'refernced to avoid leak.

This is backport of below master patch -
   http://review.gluster.org/14984

>Change-Id: I22f03577a8f1d9608cfc62d57202cfc4c2ba12b3
>BUG: 1358608
>Signed-off-by: Soumya Koduri 
>Reviewed-on: http://review.gluster.org/14984
>Reviewed-by: jiffin tony Thottan 
>Reviewed-by: Jeff Darcy 
>(cherry picked from commit bb48eb46910085928efbd7fb491c5b2db25bba98)

Change-Id: I92701af8a948d982fd4dbe31af32334c1bb26347
BUG: 1361665
Signed-off-by: Soumya Koduri 
Reviewed-on: http://review.gluster.org/15049
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Niels de Vos 
Smoke: Gluster Build System

gfapi: update count when glfs_buf_copy is used

2016-07-07T08:54:41+00:00

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

glfs_buf_copy collates all iovecs into a iovec with count=1. If
gio->count is not updated it will lead to dereferencing of invalid
address.

Change-Id: I7c58071d5c6515ec6fee3ab36af206fa80cf37c3
BUG: 1352632
Signed-off-by: Raghavendra Talur 
Signed-off-by: Poornima G 
Reported-By: Lindsay Mathieson 
Reported-By: Dmitry Melekhov 
Reported-By: Tom Emerson 
Reviewed-on: http://review.gluster.org/14858
Smoke: Gluster Build System 
Reviewed-by: Prashanth Pai 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Niels de Vos

gfapi : check the value "iovec" in glfs_io_async_cbk only for read

2016-07-04T13:24:06+00:00

The glfs_io_async_cbk() is called from the cbk of all the async ops
such as write, read, fsync, ftruncate. In all other cases, expect for
read the value for "iovec" is NULL. From the code, glfs_io_async_cbk
checks the value in common routine which may end up in failures.

Thanks Joe Julian for finding issue and suggesting the fix.

Upstream reference
>Change-Id: I0be0123da68f9d8fbb5d94ede2d45566a9add6a5
>BUG: 1349276
>Signed-off-by: Jiffin Tony Thottan 
>Reported-by: Joe Julian 
>Reviewed-on: http://review.gluster.org/14779
>Reviewed-by: Niels de Vos 
>Smoke: Gluster Build System 
>Tested-by: Kaleb KEITHLEY 
>NetBSD-regression: NetBSD Build System 
>CentOS-regression: Gluster Build System 
>Reviewed-by: Joe Julian 
>(cherry picked from commit 61d72b3d91f2655b04de4ef29262f738a8cf7369)

Change-Id: I0be0123da68f9d8fbb5d94ede2d45566a9add6a5
BUG: 1350789
Signed-off-by: Jiffin Tony Thottan 
Reported-by: Joe Julian 
Reviewed-on: http://review.gluster.org/14821
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Poornima G 
Reviewed-by: Kaleb KEITHLEY 
CentOS-regression: Gluster Build System

gfapi/handleops: Avoid using glfd during create

2016-07-01T09:36:46+00:00

To avoid leaking glfd while creating a file using handleops and
since application shall not be interested in it, use the 'fd'
object directly which can be un'refed post create.

Upstream refernce :
>Change-Id: I119874ffb63fb4aa18f846ba1fdbe77874b66a54
>BUG: 1339553
>Signed-off-by: Soumya Koduri 
>Signed-off-by: Jiffin Tony Thottan 
>Reviewed-on: http://review.gluster.org/14532
>NetBSD-regression: NetBSD Build System 
>Reviewed-by: Niels de Vos 
>CentOS-regression: Gluster Build System 
>Tested-by: Gluster Build System 
>Smoke: Gluster Build System 
>(cherry picked from commit 763ed1017b0011934ad2414d7396c46e528ea5b3)

Change-Id: I119874ffb63fb4aa18f846ba1fdbe77874b66a54
BUG: 1350787
Signed-off-by: Soumya Koduri 
Signed-off-by: Jiffin Tony Thottan 
Reviewed-on: http://review.gluster.org/14820
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Niels de Vos

gfapi/upcall: Ignore handle create failures

2016-06-17T12:25:29+00:00

In "glfs_h_poll_cache_invalidation", we need to send upcall only if there
is a corresponding inode entry in the gfapi inode table for that handle.

That's because the application will have reference to the inode as long as
it operates on any handle. That means the only case in which we cannot find
inode is when the application has closed the handle (either as part of unlink
or for any other purpose). But since it will have no more references and will
not be interested in any upcall event for that handle, we can safely ignore such
cases.

Note: This will affect only that particular applicaiton process/local libgfapi
client.

This is backport of below mainline patch -
   http://review.gluster.org/14132

Change-Id: I9499cd9c284350d4a271e58f2a0966db65a7a61c
BUG: 1347590
Signed-off-by: Soumya Koduri 
Reviewed-on: http://review.gluster.org/14132
Reviewed-by: jiffin tony Thottan 
Reviewed-by: Kaleb KEITHLEY 
(cherry picked from commit fb77938fc7810dc5ac16b0de9694157cde93635e)
Reviewed-on: http://review.gluster.org/14756
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

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

2016-06-17T11:35:25+00:00

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

Issue:
Consider a simple situation, where glfs_init() is done, i.e. initial
graph is up. Now perform 2 volume sets that results in 2 client side
graph changes. After this perform some IO, the IO fails with ENOTCON.
The only way to recover this client is i guess another graph switch
or restart.

What actually is happening from code perspective:
Initial graph lets say A, followed by 2 consecutive graph switches
to B and C without any IO those two switches.

- graph_setup (A) as a result of GF_EVENT_CHILD_UP, and
fs->next_subvol = A

- glfs_init() results in fs->active_subvol = A, fs->next_subvol = NULL

- graph_setup (B) as a result of GF_EVENT_CHILD_UP, and
fs->next_subvol = B

- graph_setup (C) as a result of GF_EVENT_CHILD_UP, and
fs->next_subvol = C. It also sees that the previous graph B was never
set as fs->active_subvol, i.e. no IO or anything happened on B, so
can safely send GF_EVENT_PARENT_DOWN (by calling glfs_subvol_done(B)).
This parent down on B, results in child_down(B), which is fine.
But child_down also triggers graph_setup(B).

- graph_setup(B) as a result of GF_EVENT_CHILD_DOWN, and
fs->next_subvol = B, and GF_EVENT_PARENT_DOWN on C as explained
above. This again leads to GF_EVENT_CHILD_DOWN on C.

- graph_setup(C) as a result of GF_EVENT_CHILD_DOWN, and
fs->next_subvol = C, and GF_EVENT_PARENT_DOWN on B as explained
above.

Thus both the graphs B and C are disconnected, and hence the ENOTCON

Solution:
Remove the call to graph_setup() when the event is GF_EVENT_CHILD_DOWN.
It don't see any reason why graph_setup should be called when there is
child_down. Not sure what the original reason was, to have graph_setup
in child_down. git hostory shows the first patch itself had this call.

Change-Id: I9de86555f66cc94a05649ac863b40ed3426ffd4b
BUG: 1347489
Signed-off-by: Poornima G 
Reviewed-on: http://review.gluster.org/14656
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Jeff Darcy 
(cherry picked from commit b8ac20e888fbacad9d90cd8f1c6ff8579a5cefe9)
Reviewed-on: http://review.gluster.org/14747