From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756053AbaIICdB (ORCPT ); Mon, 8 Sep 2014 22:33:01 -0400 Received: from terminus.zytor.com ([198.137.202.10]:34464 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754730AbaIICc7 (ORCPT ); Mon, 8 Sep 2014 22:32:59 -0400 Message-ID: <540E6582.9020403@zytor.com> Date: Mon, 08 Sep 2014 19:27:14 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: James Bottomley , Chris Metcalf CC: Peter Hurley , paulmck@linux.vnet.ibm.com, One Thousand Gnomes , Jakub Jelinek , Mikael Pettersson , Benjamin Herrenschmidt , Richard Henderson , Oleg Nesterov , Miroslav Franc , Paul Mackerras , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Tony Luck , linux-ia64@vger.kernel.org Subject: Re: bit fields && data tearing References: <21512.10628.412205.873477@gargle.gargle.HOWL> <20140904090952.GW17454@tucnak.redhat.com> <540859EC.5000407@hurleysoftware.com> <20140904175044.4697aee4@alan.etchedpixels.co.uk> <5408C0AB.6050801@hurleysoftware.com> <20140905001751.GL5001@linux.vnet.ibm.com> <1409883098.5078.14.camel@jarvis.lan> <5409243C.4080704@hurleysoftware.com> <20140905040645.GO5001@linux.vnet.ibm.com> <1410066442.12512.13.camel@jarvis.lan> <20140907162146.GK5001@linux.vnet.ibm.com> <1410116687.2027.19.camel@jarvis.lan> <540CC305.8010407@hurleysoftware.com> <1410155407.2027.29.camel@jarvis.lan> <540E1587.3060108@tilera.com> <1410216228.2027.88.camel@jarvis.lan> In-Reply-To: <1410216228.2027.88.camel@jarvis.lan> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/08/2014 03:43 PM, James Bottomley wrote: > > 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 > Well, ARM doesn't trap, it just silently gives garbage on unaligned memory references. -hpa