linux-ext4 - Re: [PATCH] ext4: Unify inode flags bit and inode flags.

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:	Sun, 11 Dec 2011 21:40:00 -0500
From:	Ted Ts'o <tytso@....edu>
To:	Tao Ma <tm@....ma>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH] ext4: Unify inode flags bit and inode flags.

On Mon, Dec 12, 2011 at 09:59:49AM +0800, Tao Ma wrote:
> From: Tao Ma <boyu.mt@...bao.com>
> 
> In order to make atomic set/get of inode flags, we create a enum of
> different inode flags. Now when we add a new inode flag(e.g inline data),
> we have to add both the 'enum' and the 'define' and calculate the value
> of 'define' by ourselves. This is a bit boring and error-prune.
> So this patch just unify these 2 fields.

This was deliberate.  The problem is these flags also have to be in
sync with the hex values defined in include/linux/fs.h (and in some
other file systems' header files), not to mention the definitions in
e2fsprogs.

This is because the lsattr and chattr command was originally defined
originally for ext2/3, but then other file systems (reiserfs, xfs,
btrfs, etc) decided they would also use the same ioctls and userspace
commands.  So we have partial overlap of these flags, and when we
define new flags we have to be a little careful to make sure we
coordinate between all of the places where these flags are defined.

So the fact that this is also an ABI is why I don't want to use an
enum and to calculate the values from that.

					- 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