[Gluster-devel] pthread_mutex misusage in glusterd_op_sm

[Anand Avati]

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 <manu at 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 <manu at 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
> manu at netbsd.org
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20141126/7e2eeef3/attachment-0001.html>