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, 27 Jun 2008 17:54:28 -0600
From:	Andreas Dilger <>
To:	Frdric Boh <>
Subject: Re: [PATCH] ext4: fix online resize with mballoc

On Jun 27, 2008  16:36 +0200, Fr�d�ric Boh� wrote:
> Le jeudi 26 juin 2008 à 17:26 -0600, Andreas Dilger a écrit :
> > On Jun 26, 2008  16:58 +0200, Fr�d�ric Boh� wrote:
> > > From: Frederic Bohe <>
> > > +	num_meta_group_infos_max = num_meta_group_infos +
> > > +				le16_to_cpu(es->s_reserved_gdt_blocks);
> > 
> > The only drawback of NOT handling this properly is that once (eventually)
> > we allow resizing with META_BG this code will be broken again.  It at
> > least deserves a comment like "Need to handle this properly when META_BG
> > resizing is allowed" so that it will show up on any grep for META_BG.
> > 
> > It probably also makes sense to round this up to the next power-of-two
> > value, since kmalloc will do that internally anyways, and it gives us
> > some resizing headroom for no cost.
> Do you have any idea of how this headroom could be used in the future ?

For e.g. resize with META_BG, which does not need new reserved blocks
to be added.  Since the space is already allocated because of kmalloc
use of 2^n slab size, we may as well make it "available" even if it isn't

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
More majordomo info at

Powered by blists - more mailing lists