This is indeed a misuse. A very similar bug used to be there in io-threads, but we have moved to using pthread_cond over there since a while.
To fix this problem we could use a pthread_mutex/pthread_cond pair + a boolean flag in place of the misused mutex. Or, we could just declare gd_op_sm_lock as a synclock_t to achieve the same result. Thanks On Tue Nov 25 2014 at 10:26:34 AM Emmanuel Dreyfus <m...@netbsd.org> wrote: > I made a simple fix that address the problem: > http://review.gluster.org/9197 > > Are there other places where the same bug could exist? Anyone familiar > with the code would tell? > > Emmanuel Dreyfus <m...@netbsd.org> wrote: > > > in glusterd_op_sm(), we lock and unlock the gd_op_sm_lock mutex. > > Unfortunately, locking and unlocking can happen in different threads > > (task swap will occur in handelr call). > > > > This case is explictely covered by POSIX: the behavior is undefined. > > http://pubs.opengroup.org/onlinepubs/9699919799/ > functions/pthread_mutex_lo > > ck.html > > > > When unlocking from a thread that is not owner, Linux seems to be fine > > (though you never know with unspecified operation), while NetBSD returns > > EPERM, causing a spurious error in tests/basic/pump.t . It can be > observed > > in a few failed tests here: > > http://build.gluster.org/job/rackspace-netbsd7-regression-triggered/ > > > > Fixing it seems far from being obvious. I guess it needs to use syncop, > > but the change would be intrusive. Do we have another option? Is it > > possible to switch a task to a given thread? > > > -- > Emmanuel Dreyfus > http://hcpnet.free.fr/pubz > m...@netbsd.org > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-devel >
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
