linux-ext4 - flex_bg information initialization and question on resize/bad inodes with 48 bits filesystem

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-next>] [day] [month] [year] [list]

Date:	Fri, 11 Sep 2009 19:57:00 +0200
From:	Damien Guibouret <damien.guibouret@...tition-saving.com>
To:	linux-ext4@...r.kernel.org
Subject: flex_bg information initialization and question on resize/bad inodes
 with 48 bits filesystem

Hello,

I have looked at the new features provided by ext4 and have a question 
on flex_bg information initialization:
into ext4_fill_flex_info function of fs/ext4/super.c (lines 1698, 1700 
and 1702 for kernel 2.6.31) doesn't the atomic_set calls be atomic_add 
to sum statistics of each group composing a flex group, or do I 
misunderstand something ?

For the extension to manage 48 bits blocks number, I do not see anything 
to treat this for resize and bad inodes into kernel or e2fsprogs. For 
the resize inode, it is perhaps an incompatibility of this feature with 
48 bits blocks number, but for the bad inode ?

For information, I did not subscribe to the list, so could you please 
CC-me in your answer ?

Thanks,

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