linux-ext4 - Re: Incompat change: giving inline data four more bytes?

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <76A8C7EE-5066-43CB-B87E-007826C407C5@alibaba-inc.com>
Date:	Thu, 28 May 2015 10:48:21 +0800
From:	"刘峥(文卿)" <wenqing.lz@...baba-inc.com>
To:	"Darrick J. Wong" <darrick.wong@...cle.com>
Cc:	"linux-ext4" <linux-ext4@...r.kernel.org>, <tm@....ma>,
	<gnehzuil.liu@...il.com>,
	"刘峥(文卿)" <wenqing.lz@...bao.com>,
	"Theodore Ts'o" <tytso@....edu>
Subject: Re: Incompat change: giving inline data four more bytes?

Hi Darrick,

Yes, The Alibaba uses inline data feature in our system.  We are fine
with this incompatiable change, and we will handle this change by
ourselves.

Regards,
                                                - Zheng

> On May 27, 2015, at 8:25 AM, Darrick J. Wong <darrick.wong@...cle.com> wrote:
> 
> Hi all,
> 
> [echoing a conversation on today's concall]
> 
> I'm just curious -- is there a reason why the inline data feature stores the
> data with an xattr of [EXT4_XATTR_INDEX_SYSTEM, "data"] instead of creating a
> new index value to cover "system.data"?  That would allow us to set the namelen
> to zero, which fetches us an extra 4 bytes for inline data storage:
> 
> struct ext4_xattr_info i = {
> 	.name_index = EXT4_XATTR_INDEX_SYSTEM,
> 	.name = EXT4_XATTR_SYSTEM_DATA,
> };
> 
> becomes
> 
> struct ext4_xattr_info i = {
> 	.name_index = EXT4_XATTR_INDEX_SYSTEM_DATA,
> 	.name = "",
> };
> 
> The hard part, of course, is that inline.c is hardcoded to the xattr key that
> it uses (instead of using "system.data" and letting the key resolver figure it
> out), which makes it harder to switch to the optimized encoding.
> 
> On the other hand, since inline data isn't in a released e2fsprogs yet, there
> still aren't very many users of it, so if we're going to make the change we
> ought to do so now while it's still fairly inexpensive to do so.
> 
> The biggest problem of course is retrofitting anyone who's been using this
> feature, since old kernels require the larger encoding.  So, who are those
> users, and are you willing to trade some breakage for four more bytes?
> 
> It shouldn't be that hard to teach the kernel to look for either encoding of
> the xattr name.  e2fsprogs uses the full string and lets the xattr code
> figure out the encoding.
> 
> --D

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