summaryrefslogtreecommitdiffstats
path: root/api/src/glfs-fops.c
Commit message (Collapse)AuthorAgeFilesLines
* gfapi: dict_unref() xattr_req in fop finish instead of dict_destroy()Anand Avati2013-03-071-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | The current way of calling dict_destroy() at the end of an API fop assumes that xattr_req is not stored/ref'd by any translators in the stack. However when translators like DHT store xattr_req in dht_local_t with a dict_ref() and perform dict_unref() in the unwind path, things get subject to a race. The race is between the woken up thread (by syncop_wake) i.e, the gfapi invoking thread and the thread where the FOP was unwound. As the C stack of STACK_UNWIND unwinds back, dht_local_unref() gets invoked within the DHT_STACK_UNWIND macro. This thread attempts dict_unref, which would be "safe" if it wins the race against the gfapi invoking thread. However if the gfapi invoking thread wins the race, it will perform dict_destroy() first and therefore make dict_unref() within dht_local_unref perform a double free. This is the embarrassing on-screen bug which showed up in a roomful of people during the gluster dev summit demo of qemu/libgfapi integration. Change-Id: I284c93de87cdc128d5801f42c84aa87f753090d4 BUG: 839950 Signed-off-by: Anand Avati <avati@redhat.com> Reviewed-on: http://review.gluster.org/4645 Tested-by: Gluster Build System <jenkins@build.gluster.com>
* core: remove all the 'inner' functions in codebaseAmar Tumballi2012-12-191-22/+2
| | | | | | | | | | | | | | | | * move 'dict_keys_join()' from api/glfs_fops.c to libglusterfs/dict.c - also added an argument which is treated as a filter function if required, currently useful for fuse. * now 'make CFLAGS="-std=gnu99 -pedantic" 2>&1 | grep nested' gives no output. Change-Id: I4e18496fbd93ae1d3942026ef4931889cba015e8 Signed-off-by: Amar Tumballi <amarts@redhat.com> BUG: 875913 Reviewed-on: http://review.gluster.org/4187 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Anand Avati <avati@redhat.com>
* gfapi: added more API callsAnand Avati2012-10-081-0/+1331
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - stat - lstat - access - readlink - mknod - mkdir - rmdir - symlink - rename - link - opendir - closedir - seekdir - telldir - readdir_r - statvfs - chmod - fchmod - chown - lchown - fchown - utimens - lutimens - futimens - getxattr - lgetxattr - fgetxattr - setxattr - lsetxattr - fsetxattr - listxattr - llistxattr - flistxattr - removexattr - lremovexattr - fremovexattr Change-Id: Ic2467293ddfbcefaa9b41c82cec61a5602636833 BUG: 839950 Signed-off-by: Anand Avati <avati@redhat.com> Reviewed-on: http://review.gluster.org/4022 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Amar Tumballi <amarts@redhat.com>
* gfapi: add symlink (auto resolution) support in resolverAnand Avati2012-09-171-1/+1
| | | | | | | | | | | | - new internal API glfs_lresolve() for usage with APIs like glfs_lXXXX() (e.g. glfs_lstat()) Change-Id: I61c60af6bda3072f189684ad8ac9815d59f455fc BUG: 839950 Signed-off-by: Anand Avati <avati@redhat.com> Reviewed-on: http://review.gluster.org/3866 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Amar Tumballi <amarts@redhat.com>
* syncop: handle 'dataonly' flag in syncop_fsync()Amar Tumballi2012-08-201-4/+2
| | | | | | | | | | | | * and also in syncop_readv(), don't look at _cbk args if op_ret is < 0. Change-Id: I3ab2982bc6d186e75b6adb74c8981e4ff7058bbe Signed-off-by: Amar Tumballi <amarts@redhat.com> BUG: 839950 Reviewed-on: http://review.gluster.org/3828 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Anand Avati <avati@redhat.com>
* gfapi: API/library for accessing gluster volumesAnand Avati2012-07-181-0/+829
Change-Id: Ie4cbcf91b58218bebf23cf951c313aceeb29f311 BUG: 839950 Signed-off-by: Anand Avati <avati@redhat.com> Reviewed-on: http://review.gluster.com/3664 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Jeff Darcy <jdarcy@redhat.com> Reviewed-by: Kaleb KEITHLEY <kkeithle@redhat.com> Reviewed-by: Bharata B Rao <bharata.rao@gmail.com>