linux-ext4 - Re: How were some of the lustre e2fsprogs test cases generated?

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: <20080219114032.GL3029@webber.adilger.int>
Date:	Tue, 19 Feb 2008 04:40:32 -0700
From:	Andreas Dilger <adilger@....com>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: How were some of the lustre e2fsprogs test cases generated?

On Feb 18, 2008  19:06 -0500, Theodore Ts'o wrote:
> Anyway, no big deal, I'll just regenerate test cases as necessary, or
> just use them as they with different expect logs.  But this just brings
> up one question --- are we 100% sure that for all deployed versions of
> the clusterfs extents code, that the kernel-side implementation was
> always careful to clear the ee_start_hi and ee_leaf_hi fields?

No, it hasn't always been true that we cleared the _hi fields in the
kernel code.  But, it has been a year or more since we found this bug,
and all CFS e2fsprogs releases since then have cleared the _hi fields,
and there has not been any other e2fsprogs that supports extents, so
we expect that there are no filesystems left in the field with this
issue, and even then the current code will prefer to clear the _hi
bits instead of considering the whole extent corrupt.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

-
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