How does GD_SYNCOP work?

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

 



Hi

I am tracking a bug that appear when running self_heald.t on NetBSD.
The test will hang on:
    EXPECT "$HEAL_FILES" afr_get_pending_heal_count $V0

The problem inside afr_get_pending_heal_count is when  calling
   gluster volume heal $vol info

The command will never return. By adding a lot of printf, I 
tracked down the problem to GD_SYNCOP() when called throigh
gd_syncop_mgmt_brick_op()

In GD_SYNCOP(), once gd_syncop_submit_request() is called 
with success, we call synctask_yield() to wait for the
reply. It will never come: _gd_syncop_brick_op_cbk() is not called.

I suspect this is a synctask_wake() problem somewhere. If I 
add synctask_wake() before synctask_yiel() in GD_SYNCOP(), 
the currrent task is scheduled immediatly, gd_syncop_mgmt_brick_op()
exits, then later _gd_syncop_brick_op_cbk() is invoked. Of course
it will crash, because the context (args) was allocated on the
stack in gd_syncop_mgmt_brick_op(),

Anyone has an idea of what is going on?


-- 
Emmanuel Dreyfus
manu@xxxxxxxxxx
_______________________________________________
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