linux-ext4 - Re: What's cooking in e2fsprogs.git (topics)

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:	Fri, 29 Feb 2008 11:59:48 -0800
From:	Andreas Dilger <adilger@....com>
To:	Theodore Tso <tytso@....EDU>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: What's cooking in e2fsprogs.git (topics)

On Feb 29, 2008  10:43 -0500, Theodore Ts'o wrote:
> * ad/nlinks-dir (Sat Feb 2 01:25:03 2008 -0700) 1 commit
>  - e2fsprogs-nlinks.patch
> 
> 	I'm really not sure about this change in e2fsck/pass4.c:
> 
> -			if (fix_problem(ctx, PR_4_BAD_REF_COUNT, &pctx)) {
> +			/* i_link_count was previously exceeded, but no longer
> +			 * is, fix this but don't consider it an error */
> +			if ((LINUX_S_ISDIR(inode->i_mode) && link_counted > 1 &&
> +			     (inode->i_flags & EXT2_INDEX_FL) &&
> +			     link_count == 1 && !(ctx->options & E2F_OPT_NO)) ||
> +			     (fix_problem(ctx, PR_4_BAD_REF_COUNT, &pctx))) {
>  				inode->i_links_count = link_counted;
>  				e2fsck_write_inode(ctx, i, inode, "pass4");
>  			}
> 
> 	Why do we require EXT2_INDEX_FL to be set before deciding that
> 	it's OK if the i_link_count is 1 but we now have less than
> 	EXT2_LINK_MAX links?

The reason that INDEX_FL is important here is because only indexed
directories are allowed to exceed 65000 entries in the kernel.  This is a
"save users from themselves" measure, because of the O(n^2) operations
needed to create/delete entries in unindexed directories.  It also helps
detect the difference between corruption and expected behaviour.

> 	As a result of the "make check" failures which I mentioned at
> 	the beginning of this note, I noticed the following
> 	unfortunate problem in how errors are getting reported in
> 	e2fsck pass 5.  As a sample:
> 
> Block bitmap differences:  +8195Group 3 block(s) in use but group is marked BLO
> CK_UNINIT
> Fix? yes
> 
> 	This mangling is happening because error reporting for
> 	PR_5_INODE_UNINIT is getting intermingled with the
> 	PR_5_INODE_USED/PR_5_INODE_UNUSED reporting, which isn't a
> 	good idea.  The comment around the code says:
> 
> 		/* 
> 		 * We should never hit this, because it means that
> 		 * inodes were marked in use that weren't noticed
> 		 * in pass1 or pass 2. It is easier to fix the problem
> 		 * than to kill e2fsck and leave the user stuck.
> 		 */
> 
> 	So I'm guessing there's something else wrong going on here....

Does this test case have both flexbg and uninit_groups?  Alternately,
maybe some part of the e2fsck fixup code is allocating blocks in the
group, but doesn't know that the UNINIT flag needs to be cleared.

Instead of burning a lot of time on diagnosing this, I'd suggest to
try using the original uninit_groups patchset + Jose's patch on top of
that series to see if that works better?

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

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