| Message ID | 1240628459-25582-1-git-send-email-tytso@mit.edu |
|---|---|
| State | Superseded, archived |
| Headers | show |
Theodore Ts'o wrote: > For very large filesystems, the s_flex_groups array can get quite big. > For example, a 16TB filesystem will have 8192 flex groups by default, > so the array is 96k, which is marginal for kmalloc(). On the other > hand, a 160GB filesystem will have 80 flex groups, so the array will > be 960 bytes. So we try to allocate the array first using kmalloc(), > and if that fails, we'll try to use vmalloc() instead. > > Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> > --- > fs/ext4/super.c | 15 ++++++++++++--- > 1 files changed, 12 insertions(+), 3 deletions(-) > ... > @@ -2849,7 +2855,10 @@ failed_mount3: > failed_mount2: > for (i = 0; i < db_count; i++) > brelse(sbi->s_group_desc[i]); > - kfree(sbi->s_group_desc); > + if (is_vmalloc_addr(sbi->s_group_desc)) > + vfree(sbi->s_group_desc); > + else > + kfree(sbi->s_group_desc); > failed_mount: > if (sbi->s_proc) { > remove_proc_entry(sb->s_id, ext4_proc_root); er, won't you need the same vfree/kfree treatment in ext4_put_super? :) -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 2958f4e..0682fe0 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -1620,6 +1620,7 @@ static int ext4_fill_flex_info(struct super_block *sb) ext4_group_t flex_group_count; ext4_group_t flex_group; int groups_per_flex = 0; + size_t size; int i; if (!sbi->s_es->s_log_groups_per_flex) { @@ -1634,8 +1635,13 @@ static int ext4_fill_flex_info(struct super_block *sb) flex_group_count = ((sbi->s_groups_count + groups_per_flex - 1) + ((le16_to_cpu(sbi->s_es->s_reserved_gdt_blocks) + 1) << EXT4_DESC_PER_BLOCK_BITS(sb))) / groups_per_flex; - sbi->s_flex_groups = kzalloc(flex_group_count * - sizeof(struct flex_groups), GFP_KERNEL); + size = flex_group_count * sizeof(struct flex_groups); + sbi->s_flex_groups = kzalloc(size, GFP_KERNEL); + if (sbi->s_flex_groups == NULL) { + sbi->s_flex_groups = vmalloc(size); + if (sbi->s_flex_groups) + memset(sbi->s_flex_groups, 0, size); + } if (sbi->s_flex_groups == NULL) { printk(KERN_ERR "EXT4-fs: not enough memory for " "%u flex groups\n", flex_group_count); @@ -2849,7 +2855,10 @@ failed_mount3: failed_mount2: for (i = 0; i < db_count; i++) brelse(sbi->s_group_desc[i]); - kfree(sbi->s_group_desc); + if (is_vmalloc_addr(sbi->s_group_desc)) + vfree(sbi->s_group_desc); + else + kfree(sbi->s_group_desc); failed_mount: if (sbi->s_proc) { remove_proc_entry(sb->s_id, ext4_proc_root);
For very large filesystems, the s_flex_groups array can get quite big. For example, a 16TB filesystem will have 8192 flex groups by default, so the array is 96k, which is marginal for kmalloc(). On the other hand, a 160GB filesystem will have 80 flex groups, so the array will be 960 bytes. So we try to allocate the array first using kmalloc(), and if that fails, we'll try to use vmalloc() instead. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> --- fs/ext4/super.c | 15 ++++++++++++--- 1 files changed, 12 insertions(+), 3 deletions(-)