[Top] [All Lists]

Re: group for tests that are dangerous for verifiers?

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: group for tests that are dangerous for verifiers?
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Sun, 23 Jun 2013 17:57:49 -0500
Cc: Mark Tinguely <tinguely@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130623225053.GA29376@dastard>
References: <51C341E1.8000302@xxxxxxx> <51C49F5A.3020907@xxxxxxxxxxx> <20130623225053.GA29376@dastard>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
On 6/23/13 5:50 PM, Dave Chinner wrote:
> On Fri, Jun 21, 2013 at 01:45:46PM -0500, Eric Sandeen wrote:
>> On 6/20/13 12:54 PM, Mark Tinguely wrote:
>>> Do we need a xfstest verifier dangerous group?
>>> xfstest 111 purposely damages inodes. In hindsight it make sense
>>> that it asserts when running with verifiers.
>> But it only asserts on a debug kernel... 
> Right, and it has done so for years - blaming verifiers for
> triggering the assert failure is simply shooting the messenger.

But this test *intentionally* corrupts, right?  So it's prudent
to not run a test which you *know* will explode if it runs
as designed.

>> This isn't the only place where corruption could ASSERT on debug;
>> see xlog_recover_add_to_trans() for example.
>> But if the test intentionally corrupts it and that leads to
>> an ASSERT that does seem problematic for anyone testing w/ debug
>> enabled.
> Yup, it runs src/itrash.c which corrupts every inode it can find.
> That's the reason this test is not part of the auto group - it's
> a test that will cause the system to stop. We've got other tests
> that are not part of the auto group for exactly the same reason -
> they cause some kind of terminal failure and so aren't candidates
> for regression testing.

Then maybe just part of the normal dangerous group would be enough.
Except this isn't transient (today) - it's not a case where old kernels
may oops, it's where it's *designed* to oops on this test, with a debug

So I guess I could see a debug-dangerous group ;)

>> I guess I'd vote for removing the ASSERT unless there's
>> some reason it should be there - Dave?
> I'm fine with it being removed - we catch the failure just fine. If
> that then makes 111 work as a regression test (i.e. doesn't trigger
> the bad-inode bulkstat loop it was designed to test) then perhaps we
> can consider making that part of the auto group, too...

Removing it sounds like the best option then.


> Cheers,
> Dave.

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