From: Theodore Tso <tytso@mit.edu>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: cmm@us.ibm.com, sandeen@redhat.com, frederic.bohe@bull.net,
linux-ext4@vger.kernel.org
Subject: Re: [PATCH] ext4: sparse fixes
Date: Sun, 2 Nov 2008 21:59:12 -0500 [thread overview]
Message-ID: <20081103025911.GA29102@mit.edu> (raw)
In-Reply-To: <1225472135-20297-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Fri, Oct 31, 2008 at 10:25:35PM +0530, Aneesh Kumar K.V wrote:
> There are some locking fixes also in this patch.
Can we move the one real locking fix into a separate patch, and push
that to Linus ASAP, while leaving the cleanups to later?
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index bdddea1..a725a5c 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -1455,9 +1455,8 @@ static int ext4_fill_flex_info(struct super_block *sb)
>
> /* We allocate both existing and potentially added groups */
> flex_group_count = ((sbi->s_groups_count + groups_per_flex - 1) +
> - ((sbi->s_es->s_reserved_gdt_blocks +1 ) <<
> - EXT4_DESC_PER_BLOCK_BITS(sb))) /
> - groups_per_flex;
> + ((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);
> if (sbi->s_flex_groups == NULL) {
This looks like a real bug fix which we should get to Linus quickly,
since could cause problems on Big Endian systems.
> @@ -2014,8 +2013,8 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
> sb->s_id, le32_to_cpu(features));
> goto failed_mount;
> }
> - has_huge_files = EXT4_HAS_RO_COMPAT_FEATURE(sb,
> - EXT4_FEATURE_RO_COMPAT_HUGE_FILE);
> + has_huge_files = le32_to_cpu(EXT4_HAS_RO_COMPAT_FEATURE(sb,
> + EXT4_FEATURE_RO_COMPAT_HUGE_FILE));
> if (has_huge_files) {
> /*
> * Large file size enabled file system can only be
This, on the other hand is a pointless sparse fixup that actually ends
up causing code bloat. EXT4_HAS_RO_COMPAT() is a macro which
returns a boolean. So we don't need to call le32_to_cpu() to it just
to shut up sparse. Better to simply give a sparse anotation that this
returns an int and not a le32.
- Ted
next prev parent reply other threads:[~2008-11-03 2:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-31 16:55 [PATCH] ext4: sparse fixes Aneesh Kumar K.V
2008-11-03 2:59 ` Theodore Tso [this message]
-- strict thread matches above, loose matches on Subject: below --
2007-10-04 5:50 [PATCH, RFC] Ext4 patches planned for submission upstream Theodore Ts'o
2007-10-04 5:50 ` [PATCH] jbd/jbd2: JBD memory allocation cleanups Theodore Ts'o
2007-10-04 5:50 ` [PATCH] jbd/jbd2: Journal initialization doesn't need __GFP_NOFAIL Theodore Ts'o
2007-10-04 5:50 ` [PATCH] JBD2/Ext4: Convert kmalloc to kzalloc in jbd2/ext4 Theodore Ts'o
[not found] ` <1191477059-5357-5-git-send-email-tytso@mit.edu>
2007-10-04 5:50 ` [PATCH] jbd2: fix commit code to properly abort journal Theodore Ts'o
2007-10-04 5:50 ` [PATCH] JBD2: debug code cleanup Theodore Ts'o
2007-10-04 5:50 ` [PATCH] Once ext4 will not implement fragment, it is believed it will never be Theodore Ts'o
2007-10-04 5:50 ` [PATCH] ext4: remove #ifdef CONFIG_EXT4_INDEX Theodore Ts'o
2007-10-04 5:50 ` [PATCH] Ext4: Uninitialized Block Groups Theodore Ts'o
2007-10-04 5:50 ` [PATCH] ext4: Fix sparse warnings Theodore Ts'o
2007-10-04 5:50 ` [PATCH] This feature relaxes check restrictions on where each block groups meta Theodore Ts'o
2007-10-04 5:50 ` [PATCH] Support large blocksize up to PAGESIZE (max 64KB) for ext4 Theodore Ts'o
2007-10-04 5:50 ` [PATCH] ext4: Avoid rec_len overflow with 64KB block size Theodore Ts'o
2007-10-04 5:50 ` [PATCH] Support large blocksize up to PAGESIZE (max 64KB) for ext2 Theodore Ts'o
2007-10-04 5:50 ` [PATCH] Support large blocksize up to PAGESIZE (max 64KB) for ext3 Theodore Ts'o
2007-10-04 5:50 ` [PATCH] ext2: Avoid rec_len overflow with 64KB block size Theodore Ts'o
2007-10-04 5:50 ` [PATCH] ext3: " Theodore Ts'o
2007-10-04 5:50 ` [PATCH] ext4: Convert bg_block_bitmap to bg_block_bitmap_lo Theodore Ts'o
2007-10-04 5:50 ` [PATCH] ext4: Convert bg_inode_bitmap and bg_inode_table Theodore Ts'o
2007-10-04 5:50 ` [PATCH] ext4: Convert s_blocks_count to s_blocks_count_lo Theodore Ts'o
2007-10-04 5:50 ` [PATCH] ext4: Convert s_r_blocks_count and s_free_blocks_count Theodore Ts'o
2007-10-04 5:50 ` [PATCH] ext4: Convert ext4_extent.ee_start to ext4_extent.ee_start_lo Theodore Ts'o
2007-10-04 5:50 ` [PATCH] ext4: Convert ext4_extent_idx.ei_leaf to ext4_extent_idx.ei_leaf_lo Theodore Ts'o
2007-10-04 5:50 ` [PATCH] ext4: sparse fixes Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081103025911.GA29102@mit.edu \
--to=tytso@mit.edu \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=cmm@us.ibm.com \
--cc=frederic.bohe@bull.net \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.