From: Dave Chinner <david@fromorbit.com>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Dave Chinner <dchinner@redhat.com>,
darrick.wong@oracle.com, linux-xfs@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
Christoph Hellwig <hch@lst.de>, Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: xfs: list corruption in xfs_setup_inode()
Date: Tue, 20 Mar 2018 10:39:13 +1100 [thread overview]
Message-ID: <20180319233913.GA1150@dastard> (raw)
In-Reply-To: <CAM_iQpVBmhiN05ZpxEZ2cNLSJpczc7z=Sz7a1tnUGeQimtDTYA@mail.gmail.com>
On Mon, Mar 19, 2018 at 02:37:22PM -0700, Cong Wang wrote:
> On Mon, Oct 30, 2017 at 2:55 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> > Hello,
> >
> > We triggered a list corruption (double add) warning below on our 4.9
> > kernel (the 4.9 kernel we use is based on -stable release, with only a
> > few unrelated networking backports):
>
> We still keep getting this warning on 4.9 kernel. Looking into this again,
> it seems xfs_setup_inode() could be called twice if an XFS inode is gotten
> from disk? Once in xfs_iget() => xfs_setup_existing_inode(), and once
> in xfs_ialloc().
AFAICT, the only way this can happen is that if the inode ->i_mode
has been corrupted in some way. i.e. there is either on-disk or
in-memory corruption occurring.
> Does the following patch (compile-only) make any sense? Again, I don't
> want to pretend to understand XFS...
No, it doesn't make sense because a newly allocated inode should
always have a zero i_mode.
Have you turned on memory poisoning to try to identify where the
corruption is coming from?
And given that it might actually be on-disk corruption that is
causing this, have you run xfs_repair on these filesystems to
determine if they are free from on-disk corruption?
Indeed, that makes me wonder format are you running on these
filesystems, because on the more recent v5 format we don't read
newly allocated inodes from disk. Can you provide the info listed
here:
http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F
as that will tell us what code paths are executing on inode
allocation.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2018-03-19 23:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-30 21:55 xfs: list corruption in xfs_setup_inode() Cong Wang
2017-10-31 0:33 ` Dave Chinner
2017-11-01 1:51 ` Cong Wang
2017-11-01 3:05 ` Dave Chinner
2017-11-01 4:43 ` Cong Wang
2017-11-01 5:07 ` Dave Chinner
2017-11-01 15:01 ` Christoph Hellwig
2017-11-01 21:32 ` Dave Chinner
2017-11-01 21:55 ` Cong Wang
2018-03-19 21:37 ` Cong Wang
2018-03-19 23:39 ` Dave Chinner [this message]
2018-03-20 17:52 ` Cong Wang
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=20180319233913.GA1150@dastard \
--to=david@fromorbit.com \
--cc=darrick.wong@oracle.com \
--cc=dchinner@redhat.com \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=xiyou.wangcong@gmail.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;
as well as URLs for NNTP newsgroup(s).