warning: ‘%s’ directive argument is null [-Wformat-overflow=] Change-Id: I69b8d47f0002c58b00d1cc947fac6f1c64e0b295 updates: bz#1193929 Signed-off-by: SheetalPamecha <spamecha@redhat.com>
There are many include statements that are not needed. A previous more ambitious attempt failed because of *BSD plafrom (see https://review.gluster.org/#/c/glusterfs/+/21929/ ) Now trying a more conservative reduction. It does not solve all circular deps that we have, but it does reduce some of them. There is just too much to handle reasonably (dht-common.h includes dht-lock.h which includes dht-common.h ...), but it does reduce the overall number of lines of include we need to look at in the future to understand and fix the mess later one. Change-Id: I550cd001bdefb8be0fe67632f783c0ef6bee3f9f updates: bz#1193929 Signed-off-by: Yaniv Kaul <ykaul@redhat.com>
* Also some logging enhancements in snapview-server Change-Id: I6a7646771cedf4bd1c62806eea69d720bbaf0c83 fixes: bz#1715921 Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com>
while creating rpc_tranpsort object, we store a dictionary without taking a ref on dict but it does an unref during the cleaning of the transport object. So the rpc layer expect the caller to take a ref on the dictionary before passing dict to rpc layer. This leads to a lot of confusion across the code base and leads to ref leaks. Semantically, this is not correct. It is the rpc layer responsibility to take a ref when storing it, and free during the cleanup. I'm listing down the total issues or leaks across the code base because of this confusion. These issues are currently present in the upstream master. 1) changelog_rpc_client_init 2) quota_enforcer_init 3) rpcsvc_create_listeners : when there are two transport, like tcp,rdma. 4) quotad_aggregator_init 5) glusterd: init 6) nfs3_init_state 7) server: init 8) client:init This patch does the cleanup according to the semantics. Change-Id: I46373af9630373eb375ee6de0e6f2bbe2a677425 updates: bz#1659708 Signed-off-by: Mohammed Rafi KC <rkavunga@redhat.com>
This patch helps enable IPv6 connections in the cluster. The default address-family is IPv4 without using this option explicitly. When address-family is set to "inet6" in the /etc/glusterfs/glusterd.vol file, the mount command-line also needs to have -o xlator-option="transport.address-family=inet6" added to it. This option also gets added to the brick command-line. Snapshot and gfapi use-cases should also use this option to pass in the inet6 address-family. Change-Id: I97db91021af27bacb6d7578e33ea4817f66d7270 fixes: bz#1635863 Signed-off-by: Milind Changire <mchangir@redhat.com>
Change-Id: Ie0fe971e694101aa011d66aa496d0644669c2c5a Updates: #389 Signed-off-by: Kinglong Mee <mijinlong@open-fs.com> Signed-off-by: ShyamsundarR <srangana@redhat.com>
* Remove the options to load old symbol. * keep only 'xlator_api' symbol from being exported using xlator.sym * add xlator_api to all the xlators where its missing NOTE: This covers all the xlators which has at least a test case to validate its loading. If there is a translator, which doesn't have any test, then we should probably remove that from codebase. fixes: #164 Change-Id: Ibcdc8c9844cda6b4463d907a15813745d14c1ebb Signed-off-by: Amar Tumballi <amarts@redhat.com>
libglusterfs devel package headers are referenced in code using include semantics for a program, this while it works can be better especially when dealing with out of tree xlator builds or in general out of tree devel package usage. Towards this, the following changes are done, - moved all devel headers under a glusterfs directory - Included these headers using system header notation <> in all code outside of libglusterfs - Included these headers using own program notation "" within libglusterfs This change although big, is just moving around the headers and making it correct when including these headers from other sources. This helps us correctly include libglusterfs includes without namespace conflicts. Change-Id: Id2a98854e671a7ee5d73be44da5ba1a74252423b Updates: bz#1193929 Signed-off-by: ShyamsundarR <srangana@redhat.com>
The warning by clang is due to the fact that we check for frame->root to be NULL, but in stack unwind, we ignore the same. If frame is non-NULL then frame->root is non-NULL as frame creation ensures this. Further, across the code we do not check both frame and frame->root for validity. Hence to fix these clang issues, removing the check for frame->root in the various functions. NOTE: Initially clang reported 14 issues in the file, but post commit 6eabefe6 the number reduced to 4, unsure why as that commit does not address this issue. Change-Id: I04b63f2d006a1f95773aae9f904b4bd3d5118e62 Updates: bz#1622665 Signed-off-by: ShyamsundarR <srangana@redhat.com>
Currently, the snapdaemon can reach the lru limit of the inode table and start sending forgets on the inodes that are least recently used. snapview-server maintains the mapping between the domain of the snapdaemon and the gfapi instance which it uses to access the snapshots via a handle that is stored in the inode context of snapdaemon's inode. The handle is glfs_h_object structure which itself points to the actual inode present in the gfapi world. But, when snapview-server receives forget on a inode, it deleted the inode context without actually closing the handle it had obtained to map the inode from snapdaemon to the inode in gfapi world. So, this change makes sure that, the handle is closed as part of the inode forget. And this closure of the handle will result in gfapi world receiving forget and unref on its corresponding inode. But care must be taken to ensure before the closure to ensure that the gfapi instance from which the handle came from, is still valid and not destroyed. Otherwise, sending a forget downward to the gfapi world might result in the access of freed pointers. Hence, the snapview-server xlator first checks whether that gfapi instance is still there or not and then proceeds with closure of the handle. Change-Id: Ia7bb45112d0c651cc95f2e54d33d925dbd6955b0 fixes: bz#1646728 Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com>