netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Takuya Yoshikawa <takuya.yoshikawa@gmail.com>
To: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Grant Grundler <grantgrundler@gmail.com>,
	Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>,
	akpm@linux-foundation.org, bhutchings@solarflare.com,
	grundler@parisc-linux.org, arnd@arndb.de,
	benh@kernel.crashing.org, avi@redhat.com, mtosatti@redhat.com,
	linux-net-drivers@solarflare.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	kvm@vger.kernel.org
Subject: Re: [PATCH 2/5] drivers/net/ethernet/dec/tulip: Use standard __set_bit_le() function
Date: Thu, 14 Jun 2012 23:28:55 +0900	[thread overview]
Message-ID: <20120614232855.5cb16291d148340c19d01f04@gmail.com> (raw)
In-Reply-To: <CAC5umyjkdDqavCo3Dk+WOggCnH+_CZz5jrOr3SougS4HSgV3OA@mail.gmail.com>

On Thu, 14 Jun 2012 18:36:42 +0900
Akinobu Mita <akinobu.mita@gmail.com> wrote:

> >> 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.

The original set_bit_le() was used only in build_setup_frame_hash().

If it's clear that the table is aligned locally in the function, I do
not think the __potential__ problem is introduced by this patch.

As you can see from my response to Arnd in v1 thread, I knew the
alignment requirement at that time and checked the definition of
hash_table before using __set_bit_le().

> But please just ignore me if I'm too much paranoid.  And I'll handle
> this issue if no one wants to do it.

I'm open to suggestions.

But now that the maintainer who can test the driver on real hardware
has suggested this patch should go in, I won't change the patch without
any real issue.

I would thank you if you improve this driver later on top of that.

Thanks,
	Takuya

  reply	other threads:[~2012-06-14 14:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-13  4:00 [PATCH 0/5] Introduce generic set_bit_le() -v2 Takuya Yoshikawa
2012-06-13  4:02 ` [PATCH 1/5] sfc: Use standard __{clear,set}_bit_le() functions Takuya Yoshikawa
2012-06-13  4:03 ` [PATCH 2/5] drivers/net/ethernet/dec/tulip: Use standard __set_bit_le() function Takuya Yoshikawa
2012-06-13  9:43   ` Akinobu Mita
2012-06-13 12:41     ` Takuya Yoshikawa
2012-06-13 13:31       ` Akinobu Mita
2012-06-13 14:00         ` Takuya Yoshikawa
2012-06-13 15:14           ` Ben Hutchings
2012-06-13 15:21           ` Grant Grundler
2012-06-13 22:28             ` Takuya Yoshikawa
2012-06-14  9:36               ` Akinobu Mita
2012-06-14 14:28                 ` Takuya Yoshikawa [this message]
2012-06-13  4:03 ` [PATCH 3/5] bitops: Introduce generic {clear,set}_bit_le() Takuya Yoshikawa
2012-06-13  4:04 ` [PATCH 4/5] powerpc: bitops: Introduce {clear,set}_bit_le() Takuya Yoshikawa
2012-06-17 21:49   ` Benjamin Herrenschmidt
2012-06-13  4:05 ` [PATCH 5/5] KVM: Replace test_and_set_bit_le() in mark_page_dirty_in_slot() with set_bit_le() Takuya Yoshikawa

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=20120614232855.5cb16291d148340c19d01f04@gmail.com \
    --to=takuya.yoshikawa@gmail.com \
    --cc=akinobu.mita@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=avi@redhat.com \
    --cc=benh@kernel.crashing.org \
    --cc=bhutchings@solarflare.com \
    --cc=grantgrundler@gmail.com \
    --cc=grundler@parisc-linux.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-net-drivers@solarflare.com \
    --cc=mtosatti@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=yoshikawa.takuya@oss.ntt.co.jp \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).