Thread (16 messages) 16 messages, 6 authors, 2012-06-17

Re: [PATCH 2/5] drivers/net/ethernet/dec/tulip: Use standard __set_bit_le() function

From: Akinobu Mita <akinobu.mita@gmail.com>
Date: 2012-06-14 09:36:46
Also in: kvm, lkml, netdev

2012/6/14 Takuya Yoshikawa [off-list ref]:
On Wed, 13 Jun 2012 08:21:18 -0700
Grant Grundler [off-list ref] wrote:
quoted
quoted
quoted
quoted
quoted
Should this hash_table be converted from u16 hash_table[32] to
DECLARE_BITMAP(hash_table, 16 * 32) to ensure that it is aligned
on long-word boundary?
I think hash_table is already long-word aligned because it is placed
right after a pointer.
I recommend converting to proper bitmap.  Because such an implicit
assumption is easily broken by someone touching this function.
Do you mean something like:
       DECLARE_BITMAP(__hash_table, 16 * 32);
       u16 *hash_table = (u16 *)__hash_table;
?

Grant, what do you think about this?
Hi Takuya,
two thoughts:
1) while I agree with Akinobu and thank him for pointing out a
_potential_ alignment problem, this is a separate issue and your
existing patch should go in anyway. There are probably other drivers
with _potential_ alignment issues. Akinobu could get credit for
finding them by submitting patches after reviewing calls to set_bit
and set_bit_le() - similar to what you are doing now.
I prefer approach 1.

hash_table is local in build_setup_frame_hash(), so if further
improvement is also required, we can do that locally there later.
This potential alignment problem is introduced by this patch.  Because
the original set_bit_le() in tulip driver can handle unaligned bitmap.
This is why I recommended it should be fixed in this patch.

But please just ignore me if I'm too much paranoid.  And I'll handle
this issue if no one wants to do it.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help