Thanks. I had another look, and think I may be able to see the
problem. If I'm right, it is a problem with this patch.
I think the "!buffer_update(bh)" test is not safe at this point as,
after the wait_on_buffer which could cause a schedule, the bh may
no longer exist, or be for the same block. There doesn't seem to be
any locking or refcounting that would keep it valid.
Note the comment "the journal_head may have been removed now".
If the journal_head is gone, the associated buffer_head is likely gone
I'm not certain that this is right, but it seems possible and would
explain the symptoms. Maybe Stephen or Andrew could comments?
As an aside, this looks extremely dubious to me.
There is a loop earlier in this routine (do_generic_file_write) that
passes a piece-at-a-time of the write request to prepare_write /
Successes are counted in 'written'. A failure causes the loop to
abort with a status in 'status'.
If some of the write succeeded and some failed, then I believe the
correct behaviour is to return the number of bytes that succeeded.
However this change to the return status (remember the above patch is
a reversal) causes any failure to over-ride any success. This, I
think, is wrong.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/