linux-ext4 - Re: [PATCH] e2fsprogs: remove fragment support which will never be implemented [modified format]

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

Message-ID: <46BC65F0.5070107@suse.de>
Date:	Fri, 10 Aug 2007 21:19:44 +0800
From:	Coly Li <coyli@...e.de>
To:	Andreas Dilger <adilger@...sterfs.com>
CC:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH] e2fsprogs: remove fragment support which will never be
 implemented [modified format]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andreas Dilger wrote:
> On Aug 10, 2007  11:37 +0800, Coly Li wrote:
>> - --- a/e2fsck/problem.h
>> +++ b/e2fsck/problem.h
>> @@ -558,8 +558,8 @@ struct problem_context {
>> +/* Duplicate directory entry found */
>> +#define PR_2_REPORT_DUP_DIRENT	0x02000D
>>
>> - -/* i_frag should be zero */
>> - -#define PR_2_FRAG_ZERO		0x020010
>> +/* Non-unique filename found */
>> +#define PR_2_NON_UNIQUE_FILE	0x020010
>>
>> - -/* i_fsize should be zero */
>> - -#define PR_2_FSIZE_ZERO		0x020011
>> +/* i_blocks_hi should be zero */
>> +#define PR_2_BLOCKS_HI_ZERO	0x020011
> 
> Please don't do this.  This makes other patches fail to apply, and I don't
> think we need to have sequential error numbers?
Yes, I should only remove the obsoleted macro. BTW, why not use enum type to declare the error number ?



>>  		struct {
>> - -			__u8	m_i_frag;	/* Fragment number */
>> - -			__u8	m_i_fsize;	/* Fragment size */
>> - -			__u16	m_pad1;
>> - -			__u32	m_i_reserved2[2];
>> +			__u32	m_i_reserved2[3];
> 
> It is a bad idea to declare on-disk fields "reserved[{num}]", because
> if some code is ever using e.g. "reserved[0]" for something and then
> one of the fields is "unreserved" then the other code will silently
> continue to work, but it will be using some other field on disk...
> 
> That said, while we are removing junk you could also remove the "masix"
> parts of the code, because I don't think they have been used for 10 years.

Sure, it seems that it will be better to remove all this structure. Isn't it ?

> 
> Cheers, Andreas
> --
> Andreas Dilger
> Principal Software Engineer
> Cluster File Systems, Inc.
> 

Andreas, thanks for your comments.


- --
Coly Li
SuSE PRC Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGvGXwuTp8cyZ5lTERAqu9AJwIkWMO/2OjxD2teOh76d6wQ3M6nACeN1rU
sy8hm6ugCJTB4z+D/0foTsU=
=/ZXl
-----END PGP SIGNATURE-----
-
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