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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ