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@xxxxxxxxx> 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@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
