blkfront driver race, can not attach new volumes
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux-ec2 (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Lucid |
Fix Released
|
Medium
|
Stefan Bader |
Bug Description
[Impact]
* If a user detaches a volume before unmount a race is hit (kernel stuck detaching the volume) and new volumes are not recognized
* Stefan Bader suggested the following patch set to resolve the issue:
* 0e34582699392d6
blkfront: fixes for 'xm block-detach ... --force'
* 5d7ed20e822ef82
blkfront: don't access freed struct xenbus_device
* a66b5aebb7dc9e6
blkfront: Clean up vbd release
* b70f5fa043b3186
blkfront: Lock blkfront_info when closing
[Test Case]
The was originally seen with AMI ami-bffa6fd6[0] doing the following:
1. Launch an instance.
2. Attach a new volume to the instance using the API.
3. Mount the volume on the instance.
4. Detach the volume using the API.
5. Wait a few seconds (30 seconds? 60 seconds?).
6. Unmount the volume on the instance.
7. Wait for volume to become available.
8. Delete the volume once it is available and go to step 2.
With about 135 iterations of these steps this problem can be reproduced.
[0] That AMI is "lucid server release 20130124 instance-store amd64 us-east-1 ami-bffa6fd6 aki-88aa75e1 paravirtual"
bffa6fd6
In the ubuntu instance with a self-compiled 2.6.32 kernel with these patches applied the behavior of the kernel is as expected even with the user error.
[Regression Potential]
* Since EC2 images in Lucid are based on a separate branch,
we can rule out regressions on the generic/server images.
* Code changes are limited to the xen-blkfront driver and
to hot-adding/
using PV disks can be affected.
* So there is potential for introducing new bugs into the
process but then should be detected while testing for
verification.
* I would consider the risk of regressions as low.
[Other Info]
Root cause of the problem are:
1. User error: The user first does force detach then unmount.
Correct usage is: first unmount then detach.
2. This 2.6.32 kernel has a race bug in the blkfront driver.
When the race bug is hit then the instance kernel is stuck in the detaching code and hence does not recognize the new attached volume.
In the ubuntu instance with a self-compiled 2.6.32 kernel with these patches applied the behavior of the kernel is as expected even with the user error.
$ lsb_release -rd
Description: Ubuntu 10.04.4 LTS
Release: 10.04
$ apt-cache policy linux-ec2
linux-ec2:
Installed: 2.6.32.350.31
Candidate: 2.6.32.364.45
Version table:
2.6.32.364.45 0
500 http://
500 http://
*** 2.6.32.350.31 0
100 /var/lib/
2.6.32.305.6 0
500 http://
Changed in linux-ec2 (Ubuntu): | |
assignee: | nobody → Stefan Bader (smb) |
Changed in linux-ec2 (Ubuntu Lucid): | |
assignee: | nobody → Stefan Bader (smb) |
Changed in linux-ec2 (Ubuntu): | |
assignee: | Stefan Bader (smb) → nobody |
Changed in linux-ec2 (Ubuntu Lucid): | |
importance: | Undecided → Medium |
Changed in linux-ec2 (Ubuntu Lucid): | |
status: | New → Confirmed |
Changed in linux-ec2 (Ubuntu): | |
status: | Confirmed → Fix Released |
description: | updated |
Changed in linux-ec2 (Ubuntu Lucid): | |
status: | Confirmed → Fix Committed |
Stefan, could you help me outline the regression potential for these patches? Thank you.