On Fri, Jan 14, 2011 at 08:30:12AM +1100, Bojan Smojver wrote: > On Thu, 2011-01-13 at 13:46 -0500, Ted Ts'o wrote: > > I'm still a bit concerned with the call to set the pages' PTE to be > > dirty that I found in the hibernate code, but I accept the fact that > > removing it doesn't solve the s390 crash. It still seems wrong to me, > > and hopefully someone from linux-pm can look at that more closely. > > If I'm understanding things correctly, this should affect only the > situation when compression is not used. Otherwise, pages that are read > into by block I/O are decompressed first and copied into different > pages. No? When the pages get copied to their final resting place the dirty bits of the corresponding physical pages get set automatically by the hardware. If there would be some code that would clear the dirty bit after the copy operation then we would have some underindication and as a result the possibility of data corruption, but we've never seen this. However since s390 is the only architecture which has dirty bits for physical pages I doubt that there is any such code present. So the bug should happen independently of image compression. What is missing is code that restores the original storage keys after the pages have been copied to their final place. I need to read the suspend/resume code and figure out how to fix this. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
