[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1410216228.2027.88.camel@jarvis.lan>
Date: Mon, 08 Sep 2014 15:43:48 -0700
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Chris Metcalf <cmetcalf@...era.com>
Cc: Peter Hurley <peter@...leysoftware.com>,
paulmck@...ux.vnet.ibm.com, "H. Peter Anvin" <hpa@...or.com>,
One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
Jakub Jelinek <jakub@...hat.com>,
Mikael Pettersson <mikpelinux@...il.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Richard Henderson <rth@...ddle.net>,
Oleg Nesterov <oleg@...hat.com>,
Miroslav Franc <mfranc@...hat.com>,
Paul Mackerras <paulus@...ba.org>,
linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
linux-arch@...r.kernel.org, Tony Luck <tony.luck@...el.com>,
linux-ia64@...r.kernel.org
Subject: Re: bit fields && data tearing
On Mon, 2014-09-08 at 16:45 -0400, Chris Metcalf wrote:
> On 9/8/2014 1:50 AM, James Bottomley wrote:
> > Actual alignment is pretty irrelevant. That's why all architectures
> > which require alignment also have to implement misaligned traps ... this
> > is a fundamental requirement of the networking code, for instance.
>
> Can you clarify what you think the requirement is? The tile architecture
> doesn't support misaligned load/store in general, but we do support it for
> userspace (using a nifty JIT approach with a direct-map hash table kept
> in userspace), and also for get_user/put_user. But that's it, and,
> the networking subsystem works fine for us.
This was years ago (possibly decades). We had to implement in-kernel
unaligned traps for the networking layer because it could access short
and int fields that weren't of the correct alignment when processing
packets. It that's all corrected now, we wouldn't really notice (except
a bit of a speed up since an unaligned trap effectively places the
broken out instructions into the bit stream).
James
> Occasionally we report bugs for driver code that doesn't use the
> get_unaligned_xxx() macros and friends, and our fixes are generally taken
> upstream.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists