public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
* Re: NULL pointer dereference in ext4_ext_remove_space on 3.5.1
       [not found]           ` <20120817174841.GA4519@infradead.org>
@ 2012-08-17 20:34             ` Theodore Ts'o
  2012-08-17 21:05               ` Christoph Hellwig
  0 siblings, 1 reply; 4+ messages in thread
From: Theodore Ts'o @ 2012-08-17 20:34 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: ext4 hackers, xfs

On Fri, Aug 17, 2012 at 01:48:41PM -0400, Christoph Hellwig wrote:
> 
> Can you submit this for xfstests?
> 

This is actually something I wanted to ask you guys about.  There are
a series of ext4-specific tests that I could potentially add, but I
wasn't sure how welcome they would be in xfstests.  Assuming that
ext4-specific tests would be welcome, is there a number range for
these ext4-specific tests that I should use?

BTW, we have an extension to xfstests that we've been using inside
Google where Google-internal tests have a "g" prefix (i.e., g001,
g002, etc.).  That way we didn't need to worry about conflicts between
newly added upstream xfstests, and ones which were added internally.
Would it make sense to start using some kind of prefix such as "e001"
for ext2/3/4 specific tests?

Regards,

						- Ted

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: NULL pointer dereference in ext4_ext_remove_space on 3.5.1
  2012-08-17 20:34             ` NULL pointer dereference in ext4_ext_remove_space on 3.5.1 Theodore Ts'o
@ 2012-08-17 21:05               ` Christoph Hellwig
  2012-08-17 22:55                 ` Dave Chinner
  0 siblings, 1 reply; 4+ messages in thread
From: Christoph Hellwig @ 2012-08-17 21:05 UTC (permalink / raw)
  To: Theodore Ts'o; +Cc: Christoph Hellwig, ext4 hackers, xfs

On Fri, Aug 17, 2012 at 04:34:38PM -0400, Theodore Ts'o wrote:
> On Fri, Aug 17, 2012 at 01:48:41PM -0400, Christoph Hellwig wrote:
> > 
> > Can you submit this for xfstests?
> > 
> 
> This is actually something I wanted to ask you guys about.  There are
> a series of ext4-specific tests that I could potentially add, but I
> wasn't sure how welcome they would be in xfstests.  Assuming that
> ext4-specific tests would be welcome, is there a number range for
> these ext4-specific tests that I should use?

Dave actually has an outstanding series to move tests from the toplevel
directory to directories for categories.  We already have a lot of
btrfs-specific tests that have a separate directory, as well as xfs
specific ones, ext4 would just follow this model.  For this specific
test it actually seems fairly generic except for the commit interval,
so I'd love to run it for all filesystems, just setting the interval for
ext4.

> BTW, we have an extension to xfstests that we've been using inside
> Google where Google-internal tests have a "g" prefix (i.e., g001,
> g002, etc.).  That way we didn't need to worry about conflicts between
> newly added upstream xfstests, and ones which were added internally.
> Would it make sense to start using some kind of prefix such as "e001"
> for ext2/3/4 specific tests?

Can you take a look at Dave's series if that helps you?  I haven't
really reviewed it much myself yet, but I'll try to get to it ASAP.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: NULL pointer dereference in ext4_ext_remove_space on 3.5.1
  2012-08-17 21:05               ` Christoph Hellwig
@ 2012-08-17 22:55                 ` Dave Chinner
  2012-08-17 23:11                   ` Theodore Ts'o
  0 siblings, 1 reply; 4+ messages in thread
From: Dave Chinner @ 2012-08-17 22:55 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: ext4 hackers, Theodore Ts'o, xfs

On Fri, Aug 17, 2012 at 05:05:27PM -0400, Christoph Hellwig wrote:
> On Fri, Aug 17, 2012 at 04:34:38PM -0400, Theodore Ts'o wrote:
> > On Fri, Aug 17, 2012 at 01:48:41PM -0400, Christoph Hellwig wrote:
> > > 
> > > Can you submit this for xfstests?
> > > 
> > 
> > This is actually something I wanted to ask you guys about.  There are
> > a series of ext4-specific tests that I could potentially add, but I
> > wasn't sure how welcome they would be in xfstests.  Assuming that
> > ext4-specific tests would be welcome, is there a number range for
> > these ext4-specific tests that I should use?
> 
> Dave actually has an outstanding series to move tests from the toplevel
> directory to directories for categories.

And a whole lot more stuff, like a separate results directory, being
able to run just a directory of tests rather than a group (e.g. just
run ext4 specific tests), being able to use names rather than
numbers for tests (not quite there yet), being able to exclude
different tests (e.g. for older distro testing with wont-fix bugs),
etc.

Basically, all those things I talked about at the LSF/MM conference
about making xfstests easier to use, develop and deploy for the wider
filesystem community are started in the patchsets here:

http://oss.sgi.com/archives/xfs/2012-07/msg00361.html
http://oss.sgi.com/archives/xfs/2012-07/msg00373.html

"This moves all the tests into a ./tests subdirectory, and sorts them into
classes of related tests. Those are:

        tests/generic:  valid for all filesystems
        tests/shared:   valid for a limited number of filesystems
        tests/xfs:      xfs specific tests
        tests/btrfs     btrfs specific tests
        tests/ext4      ext4 specific tests
        tests/udf       udf specific tests

Each directory has it's own group file to determine what groups the
tests are associated with. Tests are run in exactly the same was as
before, but when trying to run individual tests you need to specify
the class as well. e.g. the old way:

# ./check 001

The new way:

# ./check generic/001

...."

> We already have a lot of
> btrfs-specific tests that have a separate directory, as well as xfs
> specific ones, ext4 would just follow this model.  For this specific
> test it actually seems fairly generic except for the commit interval,
> so I'd love to run it for all filesystems, just setting the interval for
> ext4.

Yeah, anything that is not deeply fileystem specific should be
written as a generic test so that it can run on all filesystems. If
it's mostly generic, with a small fs specific extension, that
extension is easy to do under a 'if [ $FSTYP = "ext4" ]; then'
branch....

> > BTW, we have an extension to xfstests that we've been using inside
> > Google where Google-internal tests have a "g" prefix (i.e., g001,
> > g002, etc.).  That way we didn't need to worry about conflicts between
> > newly added upstream xfstests, and ones which were added internally.
> > Would it make sense to start using some kind of prefix such as "e001"
> > for ext2/3/4 specific tests?

No.  The whole point of moving to multiple directories is to allow
easy extension for domain specific tests without having to hack up
the check script or play other games with test naming. Duplicate
names in different test subdirectories are most certainly allowed.

> Can you take a look at Dave's series if that helps you?  I haven't
> really reviewed it much myself yet, but I'll try to get to it ASAP.

Well, I'd apprepciate it if somebody looked at it. It's been almost
a month since I posted it and all I've heard is crickets so far...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: NULL pointer dereference in ext4_ext_remove_space on 3.5.1
  2012-08-17 22:55                 ` Dave Chinner
@ 2012-08-17 23:11                   ` Theodore Ts'o
  0 siblings, 0 replies; 4+ messages in thread
From: Theodore Ts'o @ 2012-08-17 23:11 UTC (permalink / raw)
  To: Dave Chinner; +Cc: Christoph Hellwig, ext4 hackers, xfs

On Sat, Aug 18, 2012 at 08:55:24AM +1000, Dave Chinner wrote:
> 
> No.  The whole point of moving to multiple directories is to allow
> easy extension for domain specific tests without having to hack up
> the check script or play other games with test naming. Duplicate
> names in different test subdirectories are most certainly allowed.

Oh, I agree, using separate directories is *way* better than the hack
we're using internally.  The main benefit of what we did was the
patches were minimally intrusive....

> > Can you take a look at Dave's series if that helps you?  I haven't
> > really reviewed it much myself yet, but I'll try to get to it ASAP.
> 
> Well, I'd apprepciate it if somebody looked at it. It's been almost
> a month since I posted it and all I've heard is crickets so far...

I definitely want to look at it, but realistically, I probably won't
have time until after San Diego....  I've been crazy busy lately.

Cheers,

						- Ted

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2012-08-17 23:11 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <CABRT9RAOhaxcYdCxMn5neJ9WT85r=h=7WgZ2dmLaOs-MMqDW9A@mail.gmail.com>
     [not found] ` <20120816024654.GB3781@thunk.org>
     [not found]   ` <20120816111051.GA16036@localhost>
     [not found]     ` <20120816152513.GA31346@thunk.org>
     [not found]       ` <20120817060110.GA28786@localhost>
     [not found]         ` <20120817131558.GA11439@thunk.org>
     [not found]           ` <20120817174841.GA4519@infradead.org>
2012-08-17 20:34             ` NULL pointer dereference in ext4_ext_remove_space on 3.5.1 Theodore Ts'o
2012-08-17 21:05               ` Christoph Hellwig
2012-08-17 22:55                 ` Dave Chinner
2012-08-17 23:11                   ` Theodore Ts'o

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox