[Gluster-devel] Issue with THIS and libgfapi

Jeff Darcy jdarcy at redhat.com
Wed May 13 07:09:29 UTC 2015


> Before the master xlator (fuse/libgfapi) is created, all the code that access
> THIS will be using global_xlator object,
> defined globally for the whole of the process.
> The problem is when multiple threads start modifying THIS, and overwrite thr
> global_xlators' ctx eg: glfs_new:
> glfs_new () {
> ...
> ctx = glusterfs_ctx_new();
> glusterfs_globals_inti();
> THIS = NULL; /* implies THIS = &global_xlator */
> THIS->ctx = ctx;
> ...
> }
> The issue is more severe than it appears, as the other threads like epoll,
> timer, sigwaiter, when not executing in
> fop context will always refer to the global_xlator and global_xlator->ctx.
> Because of the probable race condition
> explained above we may be referring to the stale ctxs and could lead to
> crashes.

Is it not true that we *want* multiple threads to share some of these data
structures?  For example, it seems like multiple epoll threads should be
operating on the same set of file descriptors and so on; they just need to
do so in a controlled way.  If that's the case, then it's not clear that
having per-thread global_xlator objects will really work.  Am I not
correctly understanding the nature of the problem?


More information about the Gluster-devel mailing list