public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@redhat.com>
To: ak@suse.de
Cc: jeffm@suse.com, linux-kernel@vger.kernel.org
Subject: Re: [SOLVED + PATCH]: documented Oops running big-endian reiserfs on parisc architecture
Date: Tue, 04 Sep 2001 03:04:54 -0700 (PDT)	[thread overview]
Message-ID: <20010904.030454.85412225.davem@redhat.com> (raw)
In-Reply-To: <oupoforxpc1.fsf@pigdrop.muc.suse.de>
In-Reply-To: <20010903003437.A385@linux-m68k.org.suse.lists.linux.kernel> <20010903213835.A13887@fury.csh.rit.edu.suse.lists.linux.kernel> <oupoforxpc1.fsf@pigdrop.muc.suse.de>

   From: Andi Kleen <ak@suse.de>
   Date: 04 Sep 2001 11:44:30 +0200

   Jeff Mahoney <jeffm@suse.com> writes:
   
   >     I did kick around the idea of making those macros the default accessors for
   >     the deh_state member (which is the only place they're used), but it unfairly
   >     penalizes arches that don't need them.
   
   On archs that don't need them {get,put}_unaligned should be just normal
   assignments. They are certainly on i386.

I can also almost guarentee you that the x86 will sometimes not
execute these bitops atomically on SMP.

We had some obscure bug on SMP/x86 years ago, and Linus discovered
that removing an unaligned spinlock or bitop made the problem go away.

Reiserfs is broken and needs to be fixed.

If you make the unaligned accessors there the default for everyone,
you solve the problem _AND_ there is no penalization.  Look at what
the compiler makes of the code generated, it is going to be almost
entirely identical.  The compiler should be able to compute it all
via constants.  If not, oh you get 1 or 2 instructions here or
there, and that is MINISCULE compared to the cost of the atomic
operation itself.

What's more, you will have less QA'ing to do, since this code will
always be in use and thus tested.

FACT: Doing bitops on something not "long" aligned is a bug and
      will always be a bug.  You must fix it.

Later,
David S. Miller
davem@redhat.com


  reply	other threads:[~2001-09-04 10:05 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20010902105538.A15344@middle.of.nowhere.suse.lists.linux.kernel>
     [not found] ` <20010902150023.U5126@parcelfarce.linux.theplanet.co.uk.suse.lists.linux.kernel>
     [not found]   ` <20010902195717.A21209@middle.of.nowhere.suse.lists.linux.kernel>
     [not found]     ` <20010903003437.A385@linux-m68k.org.suse.lists.linux.kernel>
     [not found]       ` <20010903213835.A13887@fury.csh.rit.edu.suse.lists.linux.kernel>
2001-09-04  9:44         ` [SOLVED + PATCH]: documented Oops running big-endian reiserfs on parisc architecture Andi Kleen
2001-09-04 10:04           ` David S. Miller [this message]
2001-09-04 10:25             ` Andi Kleen
2001-09-04 10:29               ` David S. Miller
2001-09-04 10:52             ` [SOLVED + PATCH]: documented Oops running big-endian reiserfs Alan Cox
2001-09-04 12:50           ` [SOLVED + PATCH]: documented Oops running big-endian reiserfs on parisc architecture Jeff Mahoney
2001-09-04 22:55 Ulrich Weigand
  -- strict thread matches above, loose matches on Subject: below --
2001-09-04 17:04 Ulrich Weigand
2001-09-04 14:34 Ulrich Weigand
2001-09-04 15:02 ` Richard B. Johnson
2001-09-04 16:09 ` John Alvord
2001-09-03 12:08 Ulrich Weigand
2001-09-03 13:14 ` Ralf Baechle
2001-09-03 22:24 ` David S. Miller
2001-09-08  1:41   ` Linus Torvalds
2001-09-02  8:55 thunder7
2001-09-02 14:00 ` [parisc-linux] " Matthew Wilcox
2001-09-02 17:57   ` [SOLVED + PATCH]: " thunder7
2001-09-02 22:34     ` Richard Zidlicky
2001-09-02 23:08       ` David S. Miller
2001-09-04  1:38       ` Jeff Mahoney

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=20010904.030454.85412225.davem@redhat.com \
    --to=davem@redhat.com \
    --cc=ak@suse.de \
    --cc=jeffm@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    /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