linux-ext4 - Re: Test ext4/001

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:	Thu, 22 Oct 2015 22:23:09 +0200
From:	Jan Kara <jack@...e.cz>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org,
	fstests@...r.kernel.org
Subject: Re: Test ext4/001

On Thu 22-10-15 15:22:13, Ted Tso wrote:
> On Thu, Oct 22, 2015 at 11:10:17AM +0200, Jan Kara wrote:
> > 
> > I've checked why test ext4/001 fails for me with DAX and after some
> > investigation I've realized that the test assumes that
> > extent_max_zeroout_kb is 32 KB and thus unwritten extent will get converted
> > to written as a whole and not split. With DAX that doesn't happen (because
> > of difference between EXT4_GET_BLOCKS_ flags passed in writeback path and
> > DAX write path) and so the result differs.
> 
> Out of curiosity, how much memory are you using to test ext4 with DAX?
> I assume you're doing something like what Matthew Wilcox documented
> at: http://patchwork.ozlabs.org/patch/491107/
> 
> I should really figure out a way to automate doing DAX regression
> testing using my scripts.

Well, I took a machine with 128GB of RAM and use 2x16GB for test disks. I
have used the trick Matthew described but setting up plain ramdisk works as
well AFAICT.

> > So I was wondering how to best fix this. Either we could switch
> > extent_max_zeroout_kb to 0 to make the result same (but that has a slight
> > disadvantage that we would lose testing of the zeroout logic) or we could
> > increase file size so that zeroout doesn't trigger or something else?
> > Anyone has some idea?
> 
> The approach I would suggest is to fork 001.out to 001.out.zeroout and
> 001.out.nozerrout, and then test to see if our output file matches
> either file.  That means we'll redirect the output to our own 001.tmp2
> file and do the check against the two possible 001.out files in the
> ext4/001 script, but the advantage of doing things that way is that is
> that will also solve a false positive we're seeing when ext4
> encryption is enabled, and for a similar reason (extent zero-out is
> disabled when encryption is enabled).

Yeah, that's an interesting idea. I'll see how to make that work in the
cleanest possible way.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR
--
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