[zaptel-commits] tilghman: trunk r1469 - in /trunk: ./ zaptel.c
zaptel-commits at lists.digium.com
zaptel-commits at lists.digium.com
Sat Sep 16 00:48:33 MST 2006
Author: tilghman
Date: Sat Sep 16 02:48:33 2006
New Revision: 1469
URL: http://svn.digium.com/view/zaptel?rev=1469&view=rev
Log:
Merged revisions 1468 via svnmerge from
https://origsvn.digium.com/svn/zaptel/branches/1.2
........
r1468 | tilghman | 2006-09-16 02:45:04 -0500 (Sat, 16 Sep 2006) | 4 lines
Round two of the fix for "hard-safe -> hard-unsafe lock order detected" (Issue 7620)
Only difference is that the fix is only defined for kernel versions 2.6.11 and
above; older kernels keep the current (possible deadlocking) code.
........
Modified:
trunk/ (props changed)
trunk/zaptel.c
Propchange: trunk/
------------------------------------------------------------------------------
Binary property 'branch-1.2-merged' - no diff available.
Modified: trunk/zaptel.c
URL: http://svn.digium.com/view/zaptel/trunk/zaptel.c?rev=1469&r1=1468&r2=1469&view=diff
==============================================================================
--- trunk/zaptel.c (original)
+++ trunk/zaptel.c Sat Sep 16 02:48:33 2006
@@ -1154,8 +1154,21 @@
/* Assumes channel is already locked */
if ((zone >= ZT_TONE_ZONE_MAX) || (zone < -1))
return -EINVAL;
-
+
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,11)
+ /* Since this routine is called both from IRQ as well as from userspace,
+ * it is possible that we could be called during an IRQ while userspace
+ * has locked this. However unlikely, this could possibly cause a
+ * deadlock. */
+ if (! read_trylock(&zone_lock))
+ return -EWOULDBLOCK;
+#else
+ /* But there are no trylock macros for kernel versions before 2.6.11,
+ * so we do the unsafe thing anyway. Such is the problem for dealing
+ * with old, buggy kernels. */
read_lock(&zone_lock);
+#endif
+
if (zone == -1) {
zone = default_zone;
}
@@ -1166,7 +1179,7 @@
} else {
res = -ENODATA;
}
-
+
read_unlock(&zone_lock);
return res;
}
More information about the zaptel-commits
mailing list