On Wed, 12 Jan 2011, Theodore Tso wrote:

That looks really bogus.  /usr/bin/killall is a system binary, and there's
no good reason that hibernation should be trying to write pages to that
binary.

You said originally that the oops was happening "while going into
hibernation right after resuming with...".   So that means you did a
successful suspend/resume, and then the second suspend caused the oops?

Yes. I basically did a
echo reboot > /sys/power/disk
for i in {1..5} ;do echo disk > /sys/power/state ;done
and it crashed very early in the second suspend.

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!

Regards,
Sebastian