linux-ext4 - Increase xattr space by allocating contiguous xattr blocks

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:	Mon, 21 Nov 2011 20:22:26 +0800
From:	Yu Jian <yujian@...mcloud.com>
To:	tytso@....edu
CC:	Andreas Dilger <adilger@...mcloud.com>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
	Yu Jian <yujian@...mcloud.com>
Subject: Increase xattr space by allocating contiguous xattr blocks

Hello Ted,

I'm working on the patches for large xattrs support again based on the 
previous patch made by Kalpak Shah. There are some small issues in the 
previous patch, I'd fix them and rebase the patch on the latest ext4 codes.

Per the thread of 
http://kerneltrap.org/mailarchive/linux-ext4/2009/2/9/4931244, there are 
two features need to be implemented:
1) store large xattr value (with value_size > blocksize) in an external 
xattr inode
2) increase xattr space by allocating a single chunk of up to 64kB (in 
size) contiguous xattr blocks

The first one has been implemented in the previous patch, and I'm 
working on the second one, which would handle "medium-sized" xattrs more 
efficiently.

Now, I've the same question as that in the above thread:
In xattr.{h,c}, all of the macros and functions assume the xattr space 
is contiguous with entries growing downwards and values growing upwards 
(aligned to the end of the space). Especially, the create, replace, 
remove and shift operations of xattrs are all performed inside a 
contiguous buffer. This is no problem with in-inode xattr space and 
single external xattr block which is associated with one block buffer. 
But for multiple xattr blocks, since the data of them would be read into 
different block buffers, which are not contiguous, most of the existing 
macros and functions need to be changed. Is this way acceptable?

In order to make most of the codes remain as-is, we could allocate a 
contiguous large buffer (up to 64kB in size) to handle all of the data. 
However, we have to memcpy the data from block buffers to the large 
buffer, and after the data are changed, we need memcpy the data back to 
block buffers to make the data written into the block device. Is this 
way reasonable?

Could you please give me some suggestions on how to solve this issue?

Thanks!
-- 
Best regards,
Yu Jian
--
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