linux-ext4 - Re: [PATCH V2] fix mballoc oopses on mkdir

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:	Wed, 29 Aug 2007 14:01:47 -0700
From:	Mingming Cao <cmm@...ibm.com>
To:	Eric Sandeen <sandeen@...hat.com>, alex@...sterfs.com
Cc:	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH V2] fix mballoc oopses on mkdir

On Tue, 2007-08-28 at 00:25 -0500, Eric Sandeen wrote:
> Ugh. brain clearly not fully engaged... here we go:
> 
> ------------------
> 
> Tried out Ted's git tree + all pending patches today, and 
> immediately oopsed on a mkdir thanks to this in 
> ext4_mb_new_group_pa()
> 
> 	BUG_ON(!S_ISREG(ac->ac_inode->i_mode));
> 
> (there are 54 BUGs and BUG_ONs in this file...!)
> 
> I think something like this patch is needed?
> 

Thanks for catching this and the fix.  I saw the same kernel oops today
when rum mballoc on fsstress (mkdir). I just added this fix to the patch
queue with some comments.

> Signed-off-by: Eric Sandeen <sandeen@...hat.com>
> 
> 
> Index: ext4.git/fs/ext4/extents.c
> ===================================================================
> --- ext4.git.orig/fs/ext4/extents.c
> +++ ext4.git/fs/ext4/extents.c
> @@ -2535,7 +2535,10 @@ int ext4_ext_get_blocks(handle_t *handle
>  	ar.goal = ext4_ext_find_goal(inode, path, iblock);
>  	ar.logical = iblock;
>  	ar.len = allocated;
> -	ar.flags = EXT4_MB_HINT_DATA;
> +	if (S_ISREG(inode->i_mode))
> +		ar.flags = EXT4_MB_HINT_DATA;
> +	else
> +		ar.flags = 0;

I see. We set the flags to zero here to avoid doing in-core
preallocation for directory files later. 

Well, I am not sure whether it's worth the effort to support in-core
preallocation for directory files. But I don't see hard reason we cannot
do this. My understanding is: this is the new in-core preallocation
which does a should not depend on extents or any on-disk format changes.

Alex, any comments?


Mingming

>  	newblock = ext4_mb_new_blocks(handle, &ar, &err);
>  	if (!newblock)
>  		goto out2;
> 
> -
> 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

-
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