linux-ext4 - Re: [PATCH] New testcase to check if fallocate respects RLIMIT

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]

Message-ID: <4BE08718.5040608@redhat.com>
Date:	Tue, 04 May 2010 15:44:08 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	"Amit K. Arora" <aarora@...ux.vnet.ibm.com>
CC:	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>, xfs@....sgi.com,
	Nikanth Karthikesan <knikanth@...e.de>, coly.li@...e.de,
	Nick Piggin <npiggin@...e.de>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel@...r.kernel.org, "Theodore Ts'o" <tytso@....edu>,
	Andreas Dilger <adilger@....com>, linux-ext4@...r.kernel.org,
	Eelis <opensuse.org@...tacts.eelis.net>,
	Amit Arora <aarora@...ibm.com>
Subject: Re: [PATCH] New testcase to check if fallocate respects RLIMIT_FSIZE
 or not

Amit K. Arora wrote:
> On Sat, May 01, 2010 at 06:18:46AM -0400, Christoph Hellwig wrote:
>> On Sat, May 01, 2010 at 12:34:26PM +0530, Amit K. Arora wrote:
>>> Agreed. How about doing this check in the filesystem specific fallocate
>>> inode routines instead ? For example, in ext4 we could do :
>> That looks okay - in fact XFS should already have this check because
>> it re-uses the setattr implementation to set the size.
>>
>> Can you submit an xfstests testcase to verify this behaviour on all
>> filesystems?
> 
> Here is the new testcase.

Thanks!  A few comments...

> I have run this test on a x86_64 box on XFS and ext4 on 2.6.34-rc6. It
> passes on XFS, but fails on ext4. Below is the snapshot of results
> followed by the testcase itself.
> 
> --
> Regards,
> Amit Arora
> 
> Test results:
> ------------
> # ./check 228
> FSTYP         -- xfs (non-debug)
> PLATFORM      -- Linux/x86_64 elm9m93 2.6.34-rc6
> 
> 228 0s ...
> Ran: 228
> Passed all 1 tests
> #
> # umount /mnt
> # mkfs.ext4 /dev/sda4 >/dev/null
> mke2fs 1.41.10 (10-Feb-2009)
> # ./check 228
> FSTYP         -- ext4
> PLATFORM      -- Linux/x86_64 elm9m93 2.6.34-rc6
> 
> 228 0s ... - output mismatch (see 228.out.bad)
> --- 228.out	2010-05-03 02:51:24.000000000 -0400
> +++ 228.out.bad	2010-05-03 04:27:33.000000000 -0400
> @@ -1,2 +1 @@
>  QA output created by 228
> -File size limit exceeded (core dumped)
> Ran: 228
> Failures: 228
> Failed 1 of 1 tests
> #

228.out is missing from the patch

Also on my fedora box I don't get a coredump by default; can
you either make that explicit, or filter out the core message?

> 
> Here is the test:
> ----------------
> Add a new testcase to the xfstests suite to check if fallocate respects
> the limit imposed by RLIMIT_FSIZE (can be set by "ulimit -f XXX") or
> not, on a particular filesystem.

...

> +# get standard environment, filters and checks
> +. ./common.rc
> +. ./common.filter

Nitpick, I don't think you need common.filter, doesn't look like you are 
using it.

> +# FSIZE limit is now set to 100 MB.
> +# Lets try to preallocate 101 MB. This should fail.
> +$XFS_IO_PROG -F -f -c 'falloc 0 101m' $TEST_DIR/ouch
> +rm -f $TEST_DIR/ouch
> +
> +# Lets now try to preallocate 50 MB. This should succeed.
> +$XFS_IO_PROG -F -f -c 'falloc 0 50m' $TEST_DIR/ouch
> +rm -f $TEST_DIR/ouch

Even more nitpicky, but sometimes I think it's nice to have the .out 
file be a bit more descriptive in and of itself so when you see a 
failing diff you have a better idea what's gone wrong.

Changing the comments to echos, like:

+# FSIZE limit is now set to 100 MB.
+# echo "Lets try to preallocate 101 MB. This should fail."
+$XFS_IO_PROG -F -f -c 'falloc 0 101m' $TEST_DIR/ouch
+rm -f $TEST_DIR/ouch

etc ... would make a failure look like:

--- 228.out	2010-05-04 15:42:31.924278768 -0500
+++ 228.out.bad	2010-05-04 15:42:36.961278392 -0500
@@ -1,3 +1,2 @@
 QA output created by 228
 Lets try to preallocate 101 MB. This should fail.
-File size limit exceeded
 Lets now try to preallocate 50 MB. This should succeed.

... just a thought.

Thanks,
-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html