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