linux-ext4 - Re: [PATCH -V5] ext4: fix BUG when calling ext4

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: <20081203052731.GB9481@skywalker>
Date:	Wed, 3 Dec 2008 10:57:31 +0530
From:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	Mingming Cao <cmm@...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

On Tue, Dec 02, 2008 at 02:47:36PM -0800, Mingming Cao wrote:
> 
> 在 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...
> 

The super block values are not used in the kernel. A wrong value of
free_blocks/free_inode count in super block will be fixed by a
subsequent e2fsck. I guess we can afford to have less accurate value
of free_blocks/free_inodes in super block.

-aneesh


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