glusterfs.git/api/src/glfs-fops.c, branch exp

gfapi: async fops should unref in callbacks

2016-11-05T20:32:58+00:00

If fd is unref'd at the end of async call then the unref in cbks would
lead to double unref and possible crash. Removing duplicate unrefs.

Added unref only in failure cases.

A simple test case has been added to test async write case. Need to
extend the same for other async APIs too.

Details:
All glfd based calls in libgfapi, except for glfs_open and glfs_close,
behave in the same way. At the start of the operation, they take a ref
on glfd and fd. At the end of the operation, they unref it. Async calls
are a little different as they unref in the cbk function. A successfull
open call does not unref either the glfd or fd, thereby functioning as a
reference for a OPEN file object. glfs_close makes a syncop_flush call
sandwiched between a fd ref and unref(this can be removed, more on this
below), followed by a call to glfs_mark_glfd_for_deletion which unrefs
glfd and also calls glfs_fd_destroy as a release function thereby doing
a unref on fd too.

Functionally, there is no problem with how everything works when as
described above. However, it is a little non-intuitive that we need to
perform a fd_unref as a consequence of a implicit fd_ref that happens
within glfs_resolve_fd. As we perform a GF_REF_GET(glfd) at the start of
every operation, it would be worthwhile to remove the fd_ref that
glfs_resovle_fd takes and do away with explicit fd_unref()s at the end
of every operation. This is the same reason why we don't need the fd_ref
in glfs_close. This is however not in the scope of this patch.

Change-Id: I86b1d3b2ad846b16ea527d541dc82b5e90b0ba85
BUG: 1391086
Signed-off-by: Raghavendra Talur 
Reviewed-on: http://review.gluster.org/15768
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Rajesh Joseph 
Reviewed-by: Xavier Hernandez 
Reviewed-by: soumya k 
Reviewed-by: Prasanna Kumar Kalever 
CentOS-regression: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan

gfapi: warn when glfs_realpath() returned malloc'd memory

2016-10-11T07:14:00+00:00

glfs_realpath() may return memory allocated with malloc(). Depending on
the memory allocator that the application uses, calling free() on the
returned string can cause segmentation faults or other problems.

Functions that allocate memory, need to match the free'ing of the same
memory allocator and memory accounting. glibc/malloc and jemalloc/free
do not match together (other allocators could probably trigger these
problems as well).

Applications need to provide a pre-allocated buffer, or in case
glfs_realpath() allocates the memory, glfs_free() should be used to free
it.

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

gfapi: Fix few fd ref leaks

2016-09-27T06:43:33+00:00

From the code inspection, have observed that there are fd ref
leaks for few fd-based gfapi fops. 'glfs_resolve_fd' returns
a fd (either existing or migrated) with an extra ref taken.
This needs to be unref'ed at the end of the operation.

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

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

2016-08-25T20:35:43+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.

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

gfapi: add missing glfs_truncate

2016-08-11T13:19:33+00:00

Change-Id: I80b016090a4d9d86278a0a5144dd58c0cbfe9bb2
BUG: 1365489
Signed-off-by: Jeff Darcy 
Signed-off-by: Oleksandr Natalenko 
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

gfapi: use const qualifier for glfs_*timens()

2016-08-10T11:26:47+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.

Change-Id: Iea2a1018de7dce67f67a8229671a5978246de800
BUG: 1365506
Signed-off-by: Oleksandr Natalenko 
Reviewed-on: http://review.gluster.org/15119
Smoke: Gluster Build System 
Reviewed-by: Niels de Vos 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System

glfs/upcall: entries should be removed under mutex lock

2016-07-22T15:13:29+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.

Change-Id: I468183f961eb6faed9a0a1bcb783705f711641fc
BUG: 1358608
Signed-off-by: Soumya Koduri 
Reviewed-on: http://review.gluster.org/14972
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Shyamsundar Ranganathan 
CentOS-regression: Gluster Build System 
Reviewed-by: Jeff Darcy

gfapi: update count when glfs_buf_copy is used

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

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: 1352634
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/14854
Reviewed-by: Prashanth Pai 
Reviewed-by: Kaushal M 
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Tested-by: Niels de Vos 
CentOS-regression: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan 
Reviewed-by: Niels de Vos

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

2016-06-28T11:21:56+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.

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

libglusterfs/gfapi: set appropriate errno for inode_link failures

2016-05-10T16:10:25+00:00

We do not seem to be setting errno appropriately in case
of inode_link failures. This errno may be used by any application
(for eg., nfs-ganesha) to determine the error encountered. This
patch addresses the same.

Change-Id: I674f747c73369d0597a9c463e6ea4c85b9091355
BUG: 1334621
Signed-off-by: Soumya Koduri 
Reviewed-on: http://review.gluster.org/14278
Smoke: Gluster Build System 
Reviewed-by: Niels de Vos 
NetBSD-regression: NetBSD Build System 
Reviewed-by: jiffin tony Thottan 
Reviewed-by: Kaleb KEITHLEY 
CentOS-regression: Gluster Build System