Bug 1163822

Summary:	Current timer implementation has no way to avoid some races
Product:	[Community] GlusterFS	Reporter:	Xavi Hernandez <jahernan>
Component:	core	Assignee:	bugs <bugs>
Status:	CLOSED NEXTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.6.0	CC:	bugs, pkarampu
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	1163821	Environment:
Last Closed:	2016-08-23 12:30:03 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1163821
Bug Blocks:	1184460

Description Xavi Hernandez 2014-11-13 14:33:58 UTC

+++ This bug was initially created as a clone of Bug #1163821 +++

Description of problem:

With the current implementation of timers in gluster, there are some situations that cannot be handled in a safe way. This could lead to race conditions, causing crashes or other unexpected side effects.

Version-Release number of selected component (if applicable): master

Additional info:

A clear example is the release of resources after cancelling a timer (the timer could have not been really cancelled and the callback will run anyway but the caller of gf_timer_call_cancel() has no way to know it).

Additionally, it's not possible to determine if a timer callback has been executed or not, or synchronize with it and know if it has been executed successfully.

Comment 1 Pranith Kumar K 2016-08-23 12:30:03 UTC

This is fixed as part of 1243187