On Thu, Nov 7, 2024 at 2:37 PM Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > > On Thu, Nov 07, 2024 at 11:01:58AM +0100, Arnd Bergmann wrote: > > > >> and later: > > >> > > >> * Yes, this permits 64-bit accesses on 32-bit architectures. These will > > >> * actually be atomic in some cases (namely Armv7 + LPAE), but for others we > > >> * rely on the access being split into 2x32-bit accesses for a 32-bit quantity > > >> * (e.g. a virtual address) and a strong prevailing wind. > > >> > > >> This is the "strong prevailing wind", mentioned in the patch review at [1]. > > >> > > >> [1] https://lore.kernel.org/lkml/20241016130819.GJ3559746@xxxxxxxxxx/ > > > > I understand the special case for ARMv7VE. I think the more important > > comment in that file is > > > > * Use __READ_ONCE() instead of READ_ONCE() if you do not require any > > * atomicity. Note that this may result in tears! > > That makes sense, let's just use that and there is no need to change > anything here? > > Uros? Yes, preloading "old" value for try_cmpxchg loop does not need to be atomic (cmpxchg will fail in case teared value is preloaded and loop will be retried). So, __READ_ONCE() is perfectly OK to be used in this series. Please note that __READ_ONCE() uses __unqual_scalar_typeof() operator, so at least patch at [1] to teach __uqual_scalar_typeof() about __int128 is needed. [1] https://lore.kernel.org/lkml/CAFULd4Z86uiH+w+1N36kOuhYZ5_ZkQkaEN6nyPh8VNJth3WNhg@xxxxxxxxxxxxxx/ Uros.
