Suspending with mounted ext3 formatted SD card erases partition table (karmic regression)
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| linux (Ubuntu) |
Fix Released
|
High
|
Stefan Bader | ||
Bug Description
Kernel: 2.6.30-rc7 based
Worked in Jaunty (probably only because things went at a different speed)
Testcase: Use ext3/ext4 on a SD card partitioned with one primary DOS partition and leave it mounted while suspend/resume.
Result: After resume the partition table of the SD card has been erased.
In more detail: This is my assumption based on some debugging done.
On suspend the mmc block device gets thrown away. Parts of that is mmc_blk_remove which calls mmc_cleanup_queue. There blk_cleanup_queue is called which should end the lifetime of the queue object (which seems to be done).
The bad part is that gendisk struct holds a reference to that queue object which is never accounted for. And the gendisk struct is kept together with the mmc device structure as long as that is opened (done on mount).
As the device triggers the removal it seems to take a bit of time until the old mount is thrown away. In fact it looks like this is spread between suspend and resume.
What makes the whole thing a disaster is the fact that the block device queue objects are taken from a slub cache. Which means on resume, the newly created block device will get the same queue object as the old one, initializes it and
after the tasks have been resumed, ext3 feels obliged to write out the invalidated superblocks (still not sure why it goes for sector 0) which will happily migrate to the new block device and cause confusion.
| Stefan Bader (smb) wrote | #1 |
| Changed in linux (Ubuntu): | |
| assignee: | nobody → Stefan Bader (stefan-bader-canonical) |
| importance: | Undecided → High |
| status: | New → In Progress |
| Stefan Bader (smb) wrote | #2 |
| Stefan Bader (smb) wrote | #3 |
| Changed in linux (Ubuntu): | |
| status: | In Progress → Fix Committed |
| Launchpad Janitor (janitor) wrote | #4 |
| Changed in linux (Ubuntu): | |
| status: | Fix Committed → Fix Released |
The first log is a debugging long of the state before. The block device request queue gets set up twice then there is a WARNING at the point when sector 0 gets overwritten by a request coming from the old device.