On Thu, Jan 13, 2011 at 12:48:40PM +0100, Sebastian Ott wrote: > On Wed, 12 Jan 2011, Theodore Tso wrote: > > It looks like somehow the pages were left marked as dirty, so the > > writeback daemons attempted writing back a page to an inode which was > > never opened read/write (and in fact as a text page for > > /usr/bin/killall, was mapped read/only). > > Given that ext4 initializes jinode only when the file is opened > > read/write, the fact that it is null, and the fact that it makes no > > sense that a program would be modifying /usr/bin/killall as part of a > > suspend/resume, it looks very much like we just unmasked a software > > suspend bug.... > Ah, ok. Thanks for the explanation! Eeeek... this seems to be an architecture specific bug that is only present on s390. The dirty bit for user space pages on all architectures but s390 are stored into the PTE's. On s390 however they are stored into the storage key that exists per _physical_ page. So, what we should have done, when implementing suspend/resume on s390, is to save the storage key for each page and write that to the suspend device and upon resume restore the storage key contents for each physical page. The code that would do that is missing... Hence _all_ pages of the resumed image are dirty after they have been copied to their location. *ouch* Will fix. -- 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
