From: David Laight <David.Laight@ACULAB.COM>
To: "'Martin K. Petersen'" <martin.petersen@oracle.com>,
Arnd Bergmann <arnd@kernel.org>
Cc: "Don.Brace@microchip.com" <Don.Brace@microchip.com>,
Sergei Trofimovich <slyfox@gentoo.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
"storagedev@microchip.com" <storagedev@microchip.com>,
linux-scsi <linux-scsi@vger.kernel.org>,
"jszczype@redhat.com" <jszczype@redhat.com>,
"Scott.Benesh@microchip.com" <Scott.Benesh@microchip.com>,
"Scott.Teel@microchip.com" <Scott.Teel@microchip.com>,
"thenzl@redhat.com" <thenzl@redhat.com>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Subject: RE: [PATCH] hpsa: fix boot on ia64 (atomic_t alignment)
Date: Wed, 17 Mar 2021 13:19:23 +0000 [thread overview]
Message-ID: <4b2a64d91c4c478f881d9713cac5001b@AcuMS.aculab.com> (raw)
In-Reply-To: <yq1zgz21rkz.fsf@ca-mkp.ca.oracle.com>
From: Martin K. Petersen
> Sent: 17 March 2021 02:26
>
> Arnd,
>
> > Actually that still feels wrong: the annotation of the struct is to
> > pack every member, which causes the access to be done in byte units on
> > architectures that do not have hardware unaligned load/store
> > instructions, at least for things like atomic_read() that does not go
> > through a cmpxchg() or ll/sc cycle.
>
> > This change may fix itanium, but it's still not correct. Other
> > architectures would have already been broken before the recent change,
> > but that's not a reason against fixing them now.
>
> I agree. I understand why there are restrictions on fields consumed by
> the hardware. But for fields internal to the driver the packing doesn't
> make sense to me.
Jeepers -- that global #pragma pack(1) is bollocks.
I think there are a couple of __u64 that are 32bit aligned.
Just marking those field __packed __aligned(4) should have
the desired effect.
Or use a typedef for '__u64 with 32bit alignment'.
(There probably ought to be one in types.h)
Then add compile-time asserts that any non-trivial structures
the hardware accesses are the right size.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2021-03-17 13:19 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210222230519.73f3e239@sf>
2021-02-22 23:34 ` 5.11 regression: "ia64: add support for TIF_NOTIFY_SIGNAL" breaks ia64 boot Jens Axboe
2021-02-22 23:55 ` John Paul Adrian Glaubitz
[not found] ` <20210223083507.43b5a6dd@sf>
[not found] ` <51cbf584-07ef-1e62-7a3b-81494a04faa6@physik.fu-berlin.de>
2021-02-23 12:36 ` John Paul Adrian Glaubitz
[not found] ` <20210223192743.0198d4a9@sf>
[not found] ` <20210302222630.5056f243@sf>
2021-03-02 22:31 ` John Paul Adrian Glaubitz
2021-03-03 0:22 ` [bisected] 5.12-rc1 hpsa regression: "scsi: hpsa: Correct dev cmds outstanding for retried cmds" bre Sergei Trofimovich
2021-03-03 8:55 ` [bisected] 5.12-rc1 hpsa regression: "scsi: hpsa: Correct dev cmds outstanding for retried cmds" Sergei Trofimovich
2021-03-03 17:33 ` Don.Brace
[not found] ` <20210303220401.501449e5@sf>
2021-03-04 17:00 ` Don.Brace
2021-03-05 13:26 ` Tomas Henzl
2021-03-12 22:27 ` [PATCH] hpsa: fix boot on ia64 (atomic_t alignment) Sergei Trofimovich
2021-03-16 16:30 ` Don.Brace
2021-03-16 18:28 ` Arnd Bergmann
2021-03-17 2:25 ` Martin K. Petersen
2021-03-17 13:19 ` David Laight [this message]
2021-03-17 19:06 ` Don.Brace
2021-03-17 17:28 ` John Paul Adrian Glaubitz
2021-03-27 10:24 ` Sergei Trofimovich
2021-03-24 7:08 ` John Paul Adrian Glaubitz
2021-03-24 18:37 ` Don.Brace
2021-03-29 11:25 ` John Paul Adrian Glaubitz
2021-03-29 14:22 ` Arnd Bergmann
2021-03-30 3:02 ` Martin K. Petersen
2021-03-30 7:19 ` [PATCH v2 1/3] hpsa: use __packed on individual structs, not header-wide Sergei Trofimovich
2021-03-30 7:19 ` [PATCH v2 2/3] hpsa: fix boot on ia64 (atomic_t alignment) Sergei Trofimovich
2021-03-30 7:19 ` [PATCH v2 3/3] hpsa: add an assert to prevent from __packed reintroduction Sergei Trofimovich
2021-03-30 7:34 ` Arnd Bergmann
2021-04-02 14:40 ` Elliott, Robert (Servers)
2021-04-03 14:51 ` Sergei Trofimovich
2021-03-30 7:30 ` [PATCH v2 1/3] hpsa: use __packed on individual structs, not header-wide Arnd Bergmann
2021-03-30 7:43 ` Arnd Bergmann
2021-04-02 3:54 ` Martin K. Petersen
2021-04-15 18:41 ` Don.Brace
2021-03-05 9:22 ` [bisected] 5.12-rc1 hpsa regression: "scsi: hpsa: Correct dev cmds outstanding for retried cmds" Geert Uytterhoeven
2021-03-05 13:31 ` Arnd Bergmann
2021-03-05 20:45 ` Don.Brace
2021-03-03 15:42 ` Don.Brace
2021-03-17 17:42 ` 5.11 regression: "ia64: add support for TIF_NOTIFY_SIGNAL" breaks ia64 boot John Paul Adrian Glaubitz
2021-03-17 17:53 ` John Paul Adrian Glaubitz
[not found] ` <20210222235359.75d1a912@sf>
2021-02-23 0:34 ` Jens Axboe
2021-02-23 0:41 ` Jens Axboe
2021-02-23 0:43 ` Jens Axboe
[not found] ` <20210223080830.23bccdbf@sf>
2021-03-02 22:07 ` Sergei Trofimovich
2021-03-02 22:31 ` Jens Axboe
[not found] ` <20210302232716.353ed49b@sf>
2021-03-03 0:34 ` Jens Axboe
2021-03-03 3:51 ` Jens Axboe
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=4b2a64d91c4c478f881d9713cac5001b@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=Don.Brace@microchip.com \
--cc=Scott.Benesh@microchip.com \
--cc=Scott.Teel@microchip.com \
--cc=arnd@kernel.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=jszczype@redhat.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=slyfox@gentoo.org \
--cc=storagedev@microchip.com \
--cc=thenzl@redhat.com \
/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