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 <manu@xxxxxxxxxx> 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 <manu@xxxxxxxxxx> 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
manu@xxxxxxxxxx
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
