summaryrefslogtreecommitdiffstats
path: root/COPYING-GPLV2
diff options
context:
space:
mode:
authorKrishnan Parthasarathi <kparthas@redhat.com>2015-06-05 10:33:11 +0530
committerNiels de Vos <ndevos@redhat.com>2015-06-22 00:41:43 -0700
commit79e4c7b2fad6db15863efb4e979525b1bd4862ea (patch)
tree5bcf810a74536b5751213661ebf90370b02d6ff3 /COPYING-GPLV2
parent6b4add6b3f54b6d3202535a492eaf906d619ad75 (diff)
stack: use list_head for managing frames
PROBLEM -------- statedump requests that traverse call frames of all call stacks in execution may race with a STACK_RESET on a stack. This could crash the corresponding glusterfs process. For e.g, recently we observed this in a regression test case tests/basic/afr/sparse-self-heal.t. FIX --- gf_proc_dump_pending_frames takes a (TRY_LOCK) call_pool->lock before iterating through call frames of all call stacks in progress. With this fix, STACK_RESET removes its call frames under the same lock. Additional info ---------------- This fix makes call_stack_t to use struct list_head in place of custom doubly-linked list implementation. This makes call_frame_t manipulation easier to maintain in the context of STACK_WIND et al. BUG: 1229658 Change-Id: I7e43bccd3994cd9184ab982dba3dbc10618f0d94 Signed-off-by: Krishnan Parthasarathi <kparthas@redhat.com> Reviewed-on: http://review.gluster.org/11095 Reviewed-by: Niels de Vos <ndevos@redhat.com> Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Pranith Kumar Karampuri <pkarampu@redhat.com> Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Diffstat (limited to 'COPYING-GPLV2')
0 files changed, 0 insertions, 0 deletions