From: Ted Ts'o <tytso@mit.edu>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 5/6] ext4: Drop i_state_flags on architectures with 64-bit longs
Date: Wed, 5 Jan 2011 15:29:52 -0500 [thread overview]
Message-ID: <20110105202952.GO2959@thunk.org> (raw)
In-Reply-To: <5A9C7BCF-AA25-494F-9C64-8A6553B44395@dilger.ca>
On Wed, Jan 05, 2011 at 11:43:08AM -0700, Andreas Dilger wrote:
>
> It looks like you have compensated for the above by changing the
> code here, but I think it is risky/confusing if clearing the state
> flags has a side-effect on 64-bit arches, that doesn't exist on
> 32-bit arches. It looks like a bug waiting to happen...
Yeah, I did think of this, but it seemed like extra/needless work that
I was trying to optimize away. It's still not safe to do:
#define EXT4_CLEAR_STATE_FLAGS(ei) (ei)->i_flags &= 0xffffffffULL;
... since we're not atomically updating i_flags. So if anyone tries
using EXT4_CLEAR_STATE_FLAGS() aside from the two allocation contexts,
they need to be careful anyway.
I did think about putting the #ifdef BITS_PER_LONG < 64 inline in the
code, but that's ugly.
Maybe the best thing to do is to clearly document this pitfall, and
then leave things as-is? There aren't a lot of great solutions.
- Ted
next prev parent reply other threads:[~2011-01-05 20:29 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-05 1:01 [PATCH 0/6] Shrinking the size of ext4_inode_info Theodore Ts'o
2011-01-05 1:01 ` [PATCH 1/6] ext4: replace i_delalloc_reserved_flag with EXT4_STATE_DELALLOC_RESERVED Theodore Ts'o
2011-01-05 1:01 ` [PATCH 2/6] ext4: Use ext4_lblk_t instead of sector_t for logical blocks Theodore Ts'o
2011-01-05 1:01 ` [PATCH 3/6] ext4: Drop ec_type from the ext4_ext_cache structure Theodore Ts'o
2011-01-05 1:01 ` [PATCH 4/6] ext4: reorder ext4_inode_info structure elements to remove unneeded padding Theodore Ts'o
2011-01-05 1:01 ` [PATCH 5/6] ext4: Drop i_state_flags on architectures with 64-bit longs Theodore Ts'o
2011-01-05 18:43 ` Andreas Dilger
2011-01-05 20:29 ` Ted Ts'o [this message]
2011-01-06 7:23 ` Andreas Dilger
2011-01-06 17:55 ` Ted Ts'o
2011-01-06 21:15 ` [PATCH] " Theodore Ts'o
2011-01-05 1:01 ` [PATCH 6/6] ext4: Dynamically allocate the jbd2_inode in ext4_inode_info as necessary Theodore Ts'o
2011-01-05 9:26 ` Amir Goldstein
2011-01-05 20:21 ` Ted Ts'o
2011-01-05 19:26 ` Andreas Dilger
2011-01-05 20:21 ` Ted Ts'o
2011-01-06 22:14 ` Ted Ts'o
2011-01-07 2:36 ` [PATCH -v2] " Theodore Ts'o
2011-01-07 20:46 ` Amir Goldstein
2011-01-07 22:40 ` Ted Ts'o
2011-01-11 21:50 ` [PATCH 6/6] " Ted 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=20110105202952.GO2959@thunk.org \
--to=tytso@mit.edu \
--cc=adilger@dilger.ca \
--cc=linux-ext4@vger.kernel.org \
/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.