All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Hunter <ext-adrian.hunter@nokia.com>
To: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Cc: Artem Bityutskiy <dedekind@infradead.org>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] UBIFS: endian handling fixes and annotations
Date: Mon, 24 Nov 2008 16:19:31 +0200	[thread overview]
Message-ID: <492AB7F3.5020406@nokia.com> (raw)
In-Reply-To: <20081122192747.GB21433@Chamillionaire.breakpoint.cc>

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.


  parent reply	other threads:[~2008-11-24 14:11 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-21 17:19 UBIFS updates for 2.6.28 Artem Bityutskiy
2008-11-21 17:19 ` Artem Bityutskiy
2008-11-21 17:19 ` [PATCH] UBIFS: remove printk Artem Bityutskiy
2008-11-21 17:19 ` [PATCH] UBIFS: endian handling fixes and annotations Artem Bityutskiy
2008-11-22 19:27   ` Sebastian Andrzej Siewior
2008-11-23  3:21     ` Harvey Harrison
2008-11-23  9:28       ` Sebastian Andrzej Siewior
2008-11-23 10:05     ` Jamie Lokier
2008-11-24 14:19     ` Adrian Hunter [this message]
2008-11-24 16:46       ` Harvey Harrison
2008-12-02  9:12     ` Artem Bityutskiy
2008-11-21 17:19 ` [PATCH] MAINTAINERS: change UBI/UBIFS git tree URLs Artem Bityutskiy
2008-11-21 17:19 ` [PATCH] UBIFS: fix compilation warnings Artem Bityutskiy
2008-11-22 18:54   ` Sebastian Andrzej Siewior
2008-11-24 10:03     ` Adrian Hunter
2008-11-24 10:03       ` Adrian Hunter
2008-11-30 18:58       ` Sebastian Andrzej Siewior
2008-11-21 17:19 ` [PATCH] UBIFS: allow for gaps when dirtying the LPT Artem Bityutskiy
2008-11-21 17:19 ` [PATCH] UBIFS: do not print scary memory allocation warnings Artem Bityutskiy
2008-11-21 17:19 ` [PATCH] UBIFS: do not allocate too much Artem Bityutskiy
2008-11-21 17:19 ` [PATCH] UBIFS: pre-allocate bulk-read buffer Artem Bityutskiy
  -- strict thread matches above, loose matches on Subject: below --
2008-10-24 17:52 [PATCH] ubifs: endian handling fixes and annotations Harvey Harrison
2008-10-25 10:57 ` Artem Bityutskiy
2008-10-25 18:52   ` Harvey Harrison
2008-10-26 10:12     ` Artem Bityutskiy
2008-10-26 13:22     ` Artem Bityutskiy
2008-10-26 18:44       ` Harvey Harrison

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=492AB7F3.5020406@nokia.com \
    --to=ext-adrian.hunter@nokia.com \
    --cc=dedekind@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sebastian@breakpoint.cc \
    /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.