From: Christoph Hellwig <hch@infradead.org>
To: "aluno3@poczta.onet.pl" <aluno3@poczta.onet.pl>
Cc: hch@infradead.org, xfs@oss.sgi.com
Subject: Re: [xfs] Calltrace in 2.6.27 kernel]
Date: Fri, 14 Nov 2008 11:30:56 -0500 [thread overview]
Message-ID: <20081114163056.GA22691@infradead.org> (raw)
In-Reply-To: <491D3BAB.2090207@poczta.onet.pl>
On Fri, Nov 14, 2008 at 09:49:47AM +0100, aluno3@poczta.onet.pl wrote:
> Hi
>
> I ran addr2line for both vmlinux and for first call trace (2.6.27)
> add2line returned:
>
> addr2line -e ./vmlinux c029553d
> fs/xfs/xfs_log.c:3528
>
> in source:
>
> /*
> * If this happens during log recovery, don't worry about
> * locking; the log isn't open for business yet.
> */
> if (!log ||
> log->l_flags & XLOG_ACTIVE_RECOVERY) {
> mp->m_flags |= XFS_MOUNT_FS_SHUTDOWN;
> XFS_BUF_DONE(mp->m_sb_bp);
> //3528 line
Thanks a lot. I think I figured out what happens:
- we fail the buffer read in xlog_recover_do_inode_trans, and thus
abort the mount.
- but before that log recovery has started delayed writeback of inode
buffers
- during the mount error handling we call xfs_freesb, which NULLs
mp->m_sb_bp after the inode has been unmounted
- but the device close tries to flush all delayed buffers after that,
and the inode buffer triggers the filesystem shutdown case because
it also had an I/O error.
- Now we try to mark the superblock buffer done, but it's not there
anymore.
The easy fix is to just check for a NULL mp->m_sb_bp before marking it
done. Note that this will only fix the XFS oops, but not the underling
DM issue, for which I'd ask on the device mapper list.
Index: xfs-2.6/fs/xfs/xfs_log.c
===================================================================
--- xfs-2.6.orig/fs/xfs/xfs_log.c 2008-11-14 17:28:55.000000000 +0100
+++ xfs-2.6/fs/xfs/xfs_log.c 2008-11-14 17:29:20.000000000 +0100
@@ -3525,7 +3525,8 @@ xfs_log_force_umount(
if (!log ||
log->l_flags & XLOG_ACTIVE_RECOVERY) {
mp->m_flags |= XFS_MOUNT_FS_SHUTDOWN;
- XFS_BUF_DONE(mp->m_sb_bp);
+ if (mp->m_sb_bp)
+ XFS_BUF_DONE(mp->m_sb_bp);
return 0;
}
@@ -3546,7 +3547,8 @@ xfs_log_force_umount(
spin_lock(&log->l_icloglock);
spin_lock(&log->l_grant_lock);
mp->m_flags |= XFS_MOUNT_FS_SHUTDOWN;
- XFS_BUF_DONE(mp->m_sb_bp);
+ if (mp->m_sb_bp)
+ XFS_BUF_DONE(mp->m_sb_bp);
/*
* This flag is sort of redundant because of the mount flag, but
* it's good to maintain the separation between the log and the rest
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2008-11-14 16:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <491C9687.6040305@poczta.onet.pl>
2008-11-14 8:49 ` [xfs] Calltrace in 2.6.27 kernel] aluno3
2008-11-14 16:30 ` Christoph Hellwig [this message]
2008-11-18 20:58 ` aluno3
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081114163056.GA22691@infradead.org \
--to=hch@infradead.org \
--cc=aluno3@poczta.onet.pl \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox