linux-ext4 - Re: [PATCH v2 01/28] libext2fs: support modifying arbitrary extended attributes

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:	Wed, 4 Dec 2013 17:43:14 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	"Darrick J. Wong" <darrick.wong@...cle.com>
Cc:	Zheng Liu <gnehzuil.liu@...il.com>, linux-ext4@...r.kernel.org,
	Zheng Liu <wenqing.lz@...bao.com>
Subject: Re: [PATCH v2 01/28] libext2fs: support modifying arbitrary extended
 attributes

On Wed, Dec 04, 2013 at 12:30:28PM -0800, Darrick J. Wong wrote:
> It doesn't include all of them.  At the moment there are 83 of them(!) which I
> haven't figured out how to release in a reviewable manner.  Roughly speaking,
> the patches can be grouped:
> 
>  1. The unapplied patches from the October submission (fuse2fs, 64bit
>     conversion, xattr editing part 1, metadata checksumming tests)
>  2. The xattr-editing patches
>  3. Fixes for uninit extent handling
>  4. Patches to test and turn on block_validity
>  5. A bunch of coverity fixes
>  6. Fixes for bugs I found by running xfstests atop fuse2fs
>  7. Fixes for that thing about block_uninit groups that Akira Fujita and I were
>     discussing
>  8. Fixes for 1k block filesystems with meta_bg
>  9. Patches to prevent too-high lblk mapping
> 
> I could collapse all the post-October fuse2fs and xattr-editing patches into
> the original submissions, but that seems like it would be harder for people to
> review the new changes.

Can you send at least some of the fixes independent of patches that
have API/ABI or functionality impacts, or are dependent on patches
that will require more careful review?

In particular, if there are any fixes that might lead to data loss or
be significant in some way (potential security issues, etc.) sending
them independently, preferably against the maint branch, would be a
good idea, so we can get that into a 1.42.x maintenance release.

Thanks,

					- Ted
--
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