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: <20131204224314.GD19914@thunk.org>
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

Powered by blists - more mailing lists