linux-kernel - Re: 3.9.4 Oops running xfstests (WAS Re: 3.9.3: Oops running xfstests)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 3 Jun 2013 14:00:38 +1000
From:	Dave Chinner <david@...morbit.com>
To:	CAI Qian <caiqian@...hat.com>
Cc:	xfs@....sgi.com, stable@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>,
	linux-mm <linux-mm@...ck.org>
Subject: Re: 3.9.4 Oops running xfstests (WAS Re: 3.9.3: Oops running
 xfstests)

On Sun, Jun 02, 2013 at 11:04:11PM -0400, CAI Qian wrote:
> 
> > There's memory corruption all over the place.  It is most likely
> > that trinity is causing this - it's purpose is to trigger corruption
> > issues, but they aren't always immediately seen.  If you can trigger
> > this xfs trace without trinity having been run and without all the
> > RCU/idle/scheduler/cgroup issues occuring at the same time, then
> > it's likely to be caused by XFS. But right now, I'd say XFS is just
> > an innocent bystander caught in the crossfire. There's nothing I can
> > do from an XFS persepctive to track this down...
> OK, this can be reproduced by just running LTP and then xfstests without
> trinity at all...

Cai, can you be more precise about what is triggering it?  LTP and
xfstests do a large amount of stuff, and stack traces do not do not
help narrow down the cause at all.  Can you provide the follwoing
information and perform the follwoing steps:

	1. What xfstest is tripping over it? 
	2. Can you reproduce it just by running that one specific test
	  on a pristine system (i.e. freshly mkfs'd filesystems,
	  immediately after boot)
	3. if you can't reproduce it like that, does it reproduce on
	  an xfstest run on a pristine system? If so, what command
	  line are you running, and what are the filesystem
	  configurations?
	4. if you cannot reproduce it just with xfstests and you need
	  to run LTP first, then can you just run the xfstest that
	  is failing after running LTP and see if that triggers the
	  problem. If it does, please take a metadump of the
	  filesystems after LTP has run, save them, and if the
	  single test then fails send me the metadumps and your
	  xfstests command line.
	5. If all else fails, bisect the kernel to identify the
	  commit that introduces the problem....

Cheers,

Dave.

-- 
Dave Chinner
david@...morbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/