* Russell King <[email protected]> wrote:
> In which case isn't the real regression that it does IO?
>
> Nevertheless, I give you two options:
>
> 1. Abort all IO do inserted floppy disk after resume.
> 2. Corrupt replaced floppy disk after resume.
>
> You have to pick one and exactly one. Which is inherently less risky
> to the end user?
this isnt about in-flight IO (suspend doesnt succeed if IO is in flight
anyway). The bug is this:
1) you use the floppy and then stop using it
2) 1 hour passes. Nothing uses the floppy.
3) you suspend and later resume
4) another hour passes. Nothing uses the floppy.
5) you try to use the floppy: you get a bunch of IO errors!
6) you try to use the floppy again: this time it works
that's the regression. For some reason suspend/resume puts the floppy
hardware into a state that confuses the floppy driver.
my patch adds all the right suspend/resume hooks for this, without
reintroducing the bug that was noticed by lockdep and which was fixed by
my patch that introduced this regression - we just have to figure out
what to do upon resume to get the floppy driver and the hardware match
up each other, without passing spurious IO errors to the user.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
