Re: pthread_mutex misusage in glusterd_op_sm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Emmanuel,

Could you explain which sequence of function calls lead to
mutex lock and mutex unlock being called by different threads?
Meanwhile, I am trying to find one such sequence to understand
the problem better.

FWIW, glusterd_do_replace_brick is injecting an event into
the state machine queue and invoking the state machine from
a different thread. But this execution interleaved with another
thread executing the state machine (glusterd_op_sm()) doesn't seem to cause the misusage you observe. That leads me to wonder why we see the EPERM in pthread_mutex_unlock.

----- Original Message -----
> Hello
> 
> 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_lock.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
> 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




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux