Sebastian Andrzej Siewior wrote:
* Artem Bityutskiy | 2008-11-21 19:19:24 [+0200]:index 9ee6508..3f1f16b 100644 --- a/fs/ubifs/key.h +++ b/fs/ubifs/key.h @@ -345,7 +345,7 @@ static inline int key_type_flash(const struct ubifs_info *c, const void *k) { const union ubifs_key *key = k; - return le32_to_cpu(key->u32[1]) >> UBIFS_S_KEY_BLOCK_BITS; + return le32_to_cpu(key->j32[1]) >> UBIFS_S_KEY_BLOCK_BITS;If you would change such references to something like |return le32_to_cpup(&key->j32[1]) >> UBIFS_S_KEY_BLOCK_BITS; then on powerpc text data bss dec hex filename 155384 1284 24 156692 26414 ubifs-b4.ko 155372 1284 24 156680 26408 ubifs-after.ko because now it is possible to load the value as LE from memory instead of loading it BE and swapping it afterwads.
Wouldn't that be true for every le32_to_cpu of an lvalue? Shame you can't do: is_lvalue(x) ? le32_to_cpup(&(x)) : le32_to_cpu(x)
} /** @@ -416,7 +416,7 @@ static inline unsigned int key_block_flash(const struct ubifs_info *c, { const union ubifs_key *key = k; - return le32_to_cpu(key->u32[1]) & UBIFS_S_KEY_BLOCK_MASK; + return le32_to_cpu(key->j32[1]) & UBIFS_S_KEY_BLOCK_MASK; }This and the previous change look like a bugfix for something that should trigger during recovery or something? Shouldn't I fail in ubifs_validate_entry() during recovery?
This is just about casting. key->u32[1] and key->j32[1] are the same object. There is no "real" bug in these two cases - just compilation warnings.
/** diff --git a/fs/ubifs/recovery.c b/fs/ubifs/recovery.c index 77d26c1..bed9742 100644 --- a/fs/ubifs/recovery.c +++ b/fs/ubifs/recovery.c @@ -168,12 +168,12 @@ static int write_rcvrd_mst_node(struct ubifs_info *c, struct ubifs_mst_node *mst) { int err = 0, lnum = UBIFS_MST_LNUM, sz = c->mst_node_alsz; - uint32_t save_flags; + __le32 save_flags; dbg_rcvry("recovery"); save_flags = mst->flags; - mst->flags = cpu_to_le32(le32_to_cpu(mst->flags) | UBIFS_MST_RCVRY); + mst->flags |= cpu_to_le32(UBIFS_MST_RCVRY);another micro optimisation would be to use __constant_cpu_to_le32()
As per Harvey's reply. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
