From: Omar Sandoval <osandov@osandov.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
kernel-team <kernel-team@fb.com>,
Matthew Wilcox <mawilcox@microsoft.com>,
Andrew Morton <akpm@linux-foundation.org>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>
Subject: Re: [PATCH] bitmap: fix memset optimization on big-endian systems
Date: Tue, 3 Apr 2018 11:08:54 -0700 [thread overview]
Message-ID: <20180403180854.GA17679@vader> (raw)
In-Reply-To: <CA+55aFxQdzZjQ__dX6AVZfoA_=Uqu+rvidVT6YtJO15RS307Ew@mail.gmail.com>
On Mon, Apr 02, 2018 at 04:49:39PM -0700, Linus Torvalds wrote:
> On Mon, Apr 2, 2018 at 4:37 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > We should probably have at least switched it to "unsigned long int"
>
> I meant just "unsigned int", of course.
>
> Right now we occasionally have a silly 64-bit field just for a couple of flags.
Not to mention the mix of bit fields, macros, and enums, some of which
are bit masks, some of which are the bit number :)
> Of course, we do have cases where 64-bit architectures happily end up
> using more than 32 bits too, so the "unsigned long" is occasionally
> useful. But it's rare enough that it probably wasn't the right thing
> to do.
>
> Water under the bridge. Part of it is due to another historical
> accident: the alpha port was one of the early ports, and it didn't do
> atomic byte accesses at all.
>
> So we had multiple issues that all conspired to "unsigned long arrays
> are the natural for atomic bit operations" even though they have this
> really annoying byte order issue.
Thanks for the historical context, this is exactly what I was wondering
when I spotted this bug and fixed a similar one in Btrfs a couple of
years back.
next prev parent reply other threads:[~2018-04-03 18:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-02 22:58 [PATCH] bitmap: fix memset optimization on big-endian systems Omar Sandoval
2018-04-02 23:00 ` Omar Sandoval
2018-04-02 23:37 ` Linus Torvalds
2018-04-02 23:49 ` Linus Torvalds
2018-04-03 18:08 ` Omar Sandoval [this message]
2018-04-03 18:14 ` Please add 21035965f60b ("bitmap: fix memset optimization on big-endian systems") to the stable tree Omar Sandoval
2018-04-03 18:57 ` Linus Torvalds
2018-04-04 6:12 ` Greg KH
2018-04-06 20:05 ` [PATCH] bitmap: fix memset optimization on big-endian systems Sasha Levin
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=20180403180854.GA17679@vader \
--to=osandov@osandov.com \
--cc=akpm@linux-foundation.org \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=mawilcox@microsoft.com \
--cc=torvalds@linux-foundation.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 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.