[PATCH] fix for bug#515

[PATCH] fix for bug#515

[Harry Butterworth]

[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]

# HG changeset patch
# User harry@localhost.localdomain
# Node ID 78704d769fb2f758bc9c05b0911081375fae018d
# Parent  8c21c8ea5fff320d1cc4abd18d11c648cdca322e
Fix bug 515 by adding a global lock around the hotplug scripts in the
non-udev hotplug case only.

There are two possible root causes for 515, both of which are only
problems in the non-udev hotplug case because udev uses udevsend which
already implements the required serialisation.

1) Script concurrency.
2) Kernel reordering hotplug events.

This changeset fixes (1) but not (2).  Since (1) is the problem that
seems to be happening this is probably OK.

A fix for (2) for the hotplug case might be to add extra serialisation
using state changes in the store but this would impact all the drivers
and the code and extra complexity would be redundant once everyone had
moved to udev.  This doesn't seem worthwhile unless we actually start to
see (2) happening.

diff -r 8c21c8ea5fff -r 78704d769fb2 tools/examples/xen-backend.agent
--- a/tools/examples/xen-backend.agent	Fri Mar 24 09:47:48 2006
+++ b/tools/examples/xen-backend.agent	Fri Mar 24 12:58:04 2006
@@ -1,6 +1,10 @@
 #! /bin/sh
 
 PATH=/etc/xen/scripts:$PATH
+
+. /etc/xen/scripts/locking.sh
+
+claim_lock xenbus_hotplug_global
 
 case "$XENBUS_TYPE" in
   vbd)
@@ -25,3 +29,5 @@
   offline)
     ;;
 esac
+
+release_lock xenbus_hotplug_global

Signed-off-by: Harry Butterworth <butterwo@uk.ibm.com>

[-- Attachment #2: 515.patch --]
[-- Type: text/x-patch, Size: 1366 bytes --]

# HG changeset patch
# User harry@localhost.localdomain
# Node ID 78704d769fb2f758bc9c05b0911081375fae018d
# Parent  8c21c8ea5fff320d1cc4abd18d11c648cdca322e
Fix bug 515 by adding a global lock around the hotplug scripts in the non-udev hotplug case only.

There are two possible root causes for 515, both of which are only problems in the non-udev hotplug case because udev uses udevsend which already implements the required serialisation.

1) Script concurrency.
2) Kernel reordering hotplug events.

This changeset fixes (1) but not (2).  Since (1) is the problem that seems to be happening this is probably OK.

A fix for (2) for the hotplug case might be to add extra serialisation using state changes in the store but this would impact all the drivers and the code and extra complexity would be redundant once everyone had moved to udev.  This doesn't seem worthwhile unless we actually start to see (2) happening.

diff -r 8c21c8ea5fff -r 78704d769fb2 tools/examples/xen-backend.agent
--- a/tools/examples/xen-backend.agent	Fri Mar 24 09:47:48 2006
+++ b/tools/examples/xen-backend.agent	Fri Mar 24 12:58:04 2006
@@ -1,6 +1,10 @@
 #! /bin/sh
 
 PATH=/etc/xen/scripts:$PATH
+
+. /etc/xen/scripts/locking.sh
+
+claim_lock xenbus_hotplug_global
 
 case "$XENBUS_TYPE" in
   vbd)
@@ -25,3 +29,5 @@
   offline)
     ;;
 esac
+
+release_lock xenbus_hotplug_global

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCH] fix for bug#515

[Ewan Mellor]

On Fri, Mar 24, 2006 at 01:05:24PM +0000, Harry Butterworth wrote:

> # HG changeset patch
> # User harry@localhost.localdomain
> # Node ID 78704d769fb2f758bc9c05b0911081375fae018d
> # Parent  8c21c8ea5fff320d1cc4abd18d11c648cdca322e
> Fix bug 515 by adding a global lock around the hotplug scripts in the
> non-udev hotplug case only.
> 
> There are two possible root causes for 515, both of which are only
> problems in the non-udev hotplug case because udev uses udevsend which
> already implements the required serialisation.
> 
> 1) Script concurrency.
> 2) Kernel reordering hotplug events.
> 
> This changeset fixes (1) but not (2).  Since (1) is the problem that
> seems to be happening this is probably OK.
> 
> A fix for (2) for the hotplug case might be to add extra serialisation
> using state changes in the store but this would impact all the drivers
> and the code and extra complexity would be redundant once everyone had
> moved to udev.  This doesn't seem worthwhile unless we actually start to
> see (2) happening.

Applied, thanks Harry.

Ewan.