Re: [PATCH] MMC: Add 400ms to CAFE SD controller resume path

[Deepak Saxena]

On May 28 2009, at 10:48, Pierre Ossman was caught saying:
> On Thu, 28 May 2009 01:36:29 -0700
> Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> > On Fri, 22 May 2009 13:51:50 +0200 Pierre Ossman <pierre@xxxxxxxxx> wrote:
> > 
> > > 
> > > Reading through that report, I don't believe you properly worked around
> > > the bug. You only avoid bug 1339, but that's only mildly related.
> > > 
> > > What this workaround does is to make sure that MMC_UNSAFE_RESUME
> > > actually works. But if you change cards during suspend, the VFS bug
> > > should reappear and you'll corrupt the partition table.
> > 
> > What do you think the VFS did wrong here?
> > 
> 
> Might be the block layer as well. Somehow requests associated with an
> old block device end up on the queue of a new block device. I don't
> see how this can happen given Linux' device model, but somehow it does.

The request is not ending up in the queue of the new device.  If I 
recall correctyl What is happening is that userspace does an unmount on the 
old device when it receives the notification that it is gone (since it is not 
redected and a new entry is created). By the time that unmount is called, the 
various data structures for the device has been zeroed out but the various 
operation pointers are !NULL, so when we go back to write the superblock for 
the mounted partition, we overwrite the device's partition table as the
partition offset is now 0. The main issue here is that the kernel is allowing 
an I/O to a device that is technically still there but not from the kernel's
POV.
 
~Deepak

-- 
In the end, they will not say, "those were dark times,"  they will ask
"why were their poets silent?" - Bertold Brecht

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/