xfs
[Top] [All Lists]

Re: [xfs] Calltrace in 2.6.27 kernel]

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [xfs] Calltrace in 2.6.27 kernel]
From: aluno3 <aluno3@xxxxxxxxxxxxxx>
Date: Tue, 18 Nov 2008 21:58:14 +0100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20081114163056.GA22691@xxxxxxxxxxxxx>
References: <491C9687.6040305@xxxxxxxxxxxxxx> <491D3BAB.2090207@xxxxxxxxxxxxxx> <20081114163056.GA22691@xxxxxxxxxxxxx>
User-agent: Thunderbird 2.0.0.17 (X11/20080914)
Hi

I tested this patch through a few days and I did not get call trace from
kernel.Will this patch be included to official kernel? Thanks and best


Christoph Hellwig wrote:
> On Fri, Nov 14, 2008 at 09:49:47AM +0100, aluno3@xxxxxxxxxxxxxx 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
>
>   

<Prev in Thread] Current Thread [Next in Thread>