xen-close_lockfd_after_lock_attempt.patch

   1
   2 # HG changeset patch
   3 # User Olaf Hering <olaf@aepfle.de>
   4 # Date 1350549301 -3600
   5 # Node ID b3b03536789abbf2c4b7d62377034c1f14c6340c
   6 # Parent  019ca95dfa34efc71b1707f785b5112573e7d02e
   7 hotplug/Linux: close lockfd after lock attempt
   8
   9 When a HVM guest is shutdown some of the 'remove' events can not claim
  10 the lock for some reason. Instead they try to grab the lock in a busy
  11 loop, until udev reaps the xen-hotplug-cleanup helper.
  12 After analyzing the resulting logfile its not obvious what the cause is.
  13 The only explanation is that bash (?) gets confused if the same lockfd
  14 is opened again and again. Closing it in each iteration seem to fix the
  15 issue.
  16
  17 This was observed with sles11sp2 (bash 3.2) and 4.2 xend.
  18
  19 Signed-off-by: Olaf Hering <olaf@aepfle.de>
  20 Acked-by: Ian Campbell <Ian.campbell@citrix.com>
  21 [ ijc -- added the comment ]
  22 Committed-by: Ian Campbell <ian.campbell@citrix.com>
  23
  24 diff -r 019ca95dfa34 -r b3b03536789a tools/hotplug/Linux/locking.sh
  25 --- a/tools/hotplug/Linux/locking.sh    Thu Oct 18 09:35:00 2012 +0100
  26 +++ b/tools/hotplug/Linux/locking.sh    Thu Oct 18 09:35:01 2012 +0100
  27 @@ -59,6 +59,9 @@ claim_lock()
  28              print "y\n" if $fd_inum eq $file_inum;
  29                               ' "$_lockfile" )
  30          if [ x$rightfile = xy ]; then break; fi
  31 +       # Some versions of bash appear to be buggy if the same
  32 +       # $_lockfile is opened repeatedly. Close the current fd here.
  33 +        eval "exec $_lockfd<&-"
  34      done
  35  }
  36
  37