Call trace with 2.6.27.39

[Dave Chinner]

On Tue, Dec 29, 2009 at 07:18:32PM +0100, aluno3 wrote:
> Hi
>  
> I have tested kernel 2.6.27.39 with fsstress, LVM, DD and snapshots and after a few hours I got call trace.I had 2 volumes and 10 snapshots for each volume.I created and deleted these snapshots from time to time and wrote to origin volumes with use DD from /dev/zero.Fsstress was run for 1 volume.
> 
> 
> Filesystem "dm-41": xfs_log_force: error 5 returned.

What were the errors in the log before this? i.e. why did
xfs_log_force() get an EIO error? It sounds like there's something
already gone wrong before this point.

> BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
> IP: [<ffffffff802e99c3>] bdevname+0x3/0x20
....
> Process xfslogd/0 (pid: 404, threadinfo ffff88021d956000, task ffff88021fafd890)
> Stack:  ffffffff803e7526 ffff880028046970 ffffffff80817020 ffff88021d957e38
>  00000000ffff8b92 ffff88021fafdac0 ffff88021fafd890 000000001d957eb8
>  ffff880207fe8800 ffff88007fbf6cc0 ffff88021d937bc8 ffff88021d937bc8
> Call Trace:
>  [<ffffffff803e7526>] ? xfs_ioerror_alert+0x56/0xc0
>  [<ffffffff803d5060>] ? xlog_recover_iodone+0x40/0x90
>  [<ffffffff803eaa60>] ? xfs_buf_iodone_work+0x0/0x80

This has died during log recovery (on a different filesytem?), which
implies that a buffer has not been set up properly with a buftarg or
mount stucture. I can't see how that would happen from the code
because each place that explicitly sets xlog_recover_iodone() as the
completion also sets the bp->b_mount correctly. Still, there's been
an IO error of some kind to get to xfs_ioerror_alert(), so it comes
back to whether there were errors reported before this failure?

Also, were you mounting a snapshot when this occurred? If so, you
shouldn't be doing log recovery on a snapshot because that writes to
the snapshot - you should mount them with the "ro,norecovery"
options to avoid this.

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com