Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1234248

Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

From James Bottomley <James.Bottomley@HansenPartnership.com>
Newsgroups linux.kernel
Subject Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
Date 2015-09-28 17:20 +0200
Message-ID <qdInE-3bi-5@gated-at.bofh.it> (permalink)
References (2 earlier) <qd3Nv-1lI-7@gated-at.bofh.it> <qdkuZ-kt-5@gated-at.bofh.it> <qdCrU-Qy-9@gated-at.bofh.it> <qdHBg-21o-13@gated-at.bofh.it> <qdI4j-2z9-25@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Mon, 2015-09-28 at 14:50 +0000, David Laight wrote:
> From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com]
> > Sent: 28 September 2015 15:27
> > On Mon, 2015-09-28 at 08:58 +0000, David Laight wrote:
> > > From: Rafael J. Wysocki
> > > > Sent: 27 September 2015 15:09
> > > ...
> > > > > > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > > > > > Initially, all of them are equal to 0.
> > > > > >
> > > > > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > > > > >
> > > > > > What's the result?
> > > > >
> > > > > I think every CPU's  cache architecure guarantees adjacent store
> > > > > integrity, even in the face of SMP, so it's x==1 and y==2.  If you're
> > > > > thinking of old alpha SMP system where the lowest store width is 32 bits
> > > > > and thus you have to do RMW to update a byte, this was usually fixed by
> > > > > padding (assuming the structure is not packed).  However, it was such a
> > > > > problem that even the later alpha chips had byte extensions.
> > >
> > > Does linux still support those old Alphas?
> > >
> > > The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
> > 
> > That's different: it's an atomic RMW operation.  The problem with the
> > alpha was that the operation wasn't atomic (meaning that it can't be
> > interrupted and no intermediate output states are visible).
> 
> It is only atomic if prefixed by the 'lock' prefix.
> Normally the read and write are separate bus cycles.

The essential point is that x86 has atomic bit ops and byte writes.
Early alpha did not.

> > > You still have to ensure the compiler doesn't do wider rmw cycles.
> > > I believe the recent versions of gcc won't do wider accesses for volatile data.
> > 
> > I don't understand this comment.  You seem to be implying gcc would do a
> > 64 bit RMW for a 32 bit store ... that would be daft when a single
> > instruction exists to perform the operation on all architectures.
> 
> Read the object code and weep...
> It is most likely to happen for operations that are rmw (eg bit set).
> For instance the arm cpu has limited offsets for 16bit accesses, for
> normal structures the compiler is likely to use a 32bit rmw sequence
> for a 16bit field that has a large offset.
> The C language allows the compiler to do it for any access (IIRC including
> volatiles).

I think you might be confusing different things.  Most RISC CPUs can't
do 32 bit store immediates because there aren't enough bits in their
arsenal, so they tend to split 32 bit loads into a left and right part
(first the top then the offset).  This (and other things) are mostly
what you see in code.  However, 32 bit register stores are still atomic,
which is all we require.  It's not really the compiler's fault, it's
mostly an architectural limitation.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock' Viresh Kumar <viresh.kumar@linaro.org> - 2015-09-25 18:50 +0200
  [PATCH V4 2/2] debugfs: Pass bool pointer to debugfs_create_bool() Viresh Kumar <viresh.kumar@linaro.org> - 2015-09-25 18:50 +0200
  Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of  'global_lock' Johannes Berg <johannes@sipsolutions.net> - 2015-09-25 19:50 +0200
    Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of  'global_lock' Viresh Kumar <viresh.kumar@linaro.org> - 2015-09-25 20:50 +0200
      Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of  'global_lock' Johannes Berg <johannes@sipsolutions.net> - 2015-09-25 20:50 +0200
        Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of  'global_lock' Viresh Kumar <viresh.kumar@linaro.org> - 2015-09-25 21:00 +0200
          Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock' "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-25 22:00 +0200
            Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock' "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-25 22:10 +0200
              Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock' Viresh Kumar <viresh.kumar@linaro.org> - 2015-09-25 22:30 +0200
                Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock' "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-25 22:40 +0200
                Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of  'global_lock' Viresh Kumar <viresh.kumar@linaro.org> - 2015-09-25 23:50 +0200
                Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock' "Rafael J. Wysocki" <rafael@kernel.org> - 2015-09-26 00:30 +0200
                Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock' Viresh Kumar <viresh.kumar@linaro.org> - 2015-09-26 20:50 +0200
                Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock' Arnd Bergmann <arnd@arndb.de> - 2015-09-26 21:40 +0200
                Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock' "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-27 15:50 +0200
                Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock' Arnd Bergmann <arnd@arndb.de> - 2015-09-28 10:30 +0200
                Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock' "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-28 14:40 +0200
                Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of  'global_lock' James Bottomley <James.Bottomley@HansenPartnership.com> - 2015-09-26 22:00 +0200
                Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock' "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-27 15:50 +0200
                RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of  'global_lock' David Laight <David.Laight@ACULAB.COM> - 2015-09-28 11:00 +0200
                Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of  'global_lock' James Bottomley <James.Bottomley@HansenPartnership.com> - 2015-09-28 16:30 +0200
                RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of  'global_lock' David Laight <David.Laight@ACULAB.COM> - 2015-09-28 17:00 +0200
                Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of  'global_lock' James Bottomley <James.Bottomley@HansenPartnership.com> - 2015-09-28 17:20 +0200
                RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of  'global_lock' David Laight <David.Laight@ACULAB.COM> - 2015-09-28 17:40 +0200
  Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock' "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-25 22:00 +0200
    Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock' "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-25 22:00 +0200
  Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock' Viresh Kumar <viresh.kumar@linaro.org> - 2015-09-27 16:40 +0200

csiph-web