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]
Message-Id: <1228258056.6378.20.camel@mingming-laptop>
Date:	Tue, 02 Dec 2008 14:47:36 -0800
From:	Mingming Cao <cmm@...ibm.com>
To:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Cc:	tytso@....edu, sandeen@...hat.com, linux-ext4@...r.kernel.org
Subject: Re: [PATCH -V5] ext4: fix BUG when calling ext4_error with locked
	block group


在 2008-12-02二的 11:39 +0530,Aneesh Kumar K.V写道:
> The mballoc code likes to call ext4_error while it is holding locked
> block groups.  This can causes a scheduling in atomic context BUG.  We
> can't just unlock the block group and relock it after/if ext4_error
> returns since that might result in race conditions in the case where
> the filesystem is set to continue after finding errors.
> 
> -V5 changes:
> update ext4_commit_super to use the percpu free blocks and free inodes
> counter values.
> 
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@...ux.vnet.ibm.com>
> Signed-off-by: "Theodore Ts'o" <tytso@....edu>
> ---
>  fs/ext4/ext4.h    |   47 +++++++++++++++++++++++++++++++++++++++++++++++
>  fs/ext4/mballoc.c |   30 +++++++++++++++---------------
>  fs/ext4/mballoc.h |   47 -----------------------------------------------
>  fs/ext4/super.c   |   45 +++++++++++++++++++++++++++++++++++++++++++--
>  4 files changed, 105 insertions(+), 64 deletions(-)



>  void ext4_update_dynamic_rev(struct super_block *sb)
>  {
>  	struct ext4_super_block *es = EXT4_SB(sb)->s_es;
> @@ -2820,8 +2858,11 @@ static void ext4_commit_super(struct super_block *sb,
>  		set_buffer_uptodate(sbh);
>  	}
>  	es->s_wtime = cpu_to_le32(get_seconds());
> -	ext4_free_blocks_count_set(es, ext4_count_free_blocks(sb));
> -	es->s_free_inodes_count = cpu_to_le32(ext4_count_free_inodes(sb));
> +	ext4_free_blocks_count_set(es, percpu_counter_sum_positive(
> +					&EXT4_SB(sb)->s_freeblocks_counter));
> +	es->s_free_inodes_count = cpu_to_le32(percpu_counter_sum_positive(
> +					&EXT4_SB(sb)->s_freeinodes_counter));
> +
>  	BUFFER_TRACE(sbh, "marking dirty");
>  	mark_buffer_dirty(sbh);
>  	if (sync) {

I thought the per cpu s_freeblocks_counter is not as accurate as the sum
of group free blocks counters, we are depending on
ext4_count_free_blocks() to gets the accurate free blocks counter
flushed to disk...

Mingming

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ