On Tue, 2017-11-21 at 11:38 -0800, Guenter Roeck wrote:
On Tue, Nov 21, 2017 at 07:07:14PM +0000, Ben Hutchings wrote:
On Tue, 2017-11-21 at 18:09 +0100, Greg Kroah-Hartman wrote:
On Tue, Nov 21, 2017 at 04:46:18PM +0000, Ben Hutchings wrote:
On Tue, 2017-11-21 at 17:35 +0100, Greg Kroah-Hartman wrote:
On Tue, Nov 21, 2017 at 03:26:10PM +0000, Ben Hutchings wrote:
[...]
Not all 32-bit configurations can provide cmpxchg64(). i40e's use of cmpxchg64() appears to be fixed by:
b74f571f59a8 i40e/i40evf: organize and re-number feature flags b48be9978e4b i40e: fix flags declaration
So without those patches, are any specific arches/configs broken for 4.14?
32-bit parisc is.
Ok, but that's a horrid hack on the i40e driver, it just happens to move the bitfield to a 32bit variable. Can't we just provide a "real" cmpxchg64() for 32-bit parisc?
No. There is a generic implementation of cmpxchg64() but it is only suitable for non-SMP configurations.
Dave implemented the following for sparc32 (in arch/sparc/lib/atomic32.c).
u64 __cmpxchg_u64(u64 *ptr, u64 old, u64 new) { unsigned long flags; u64 prev;
spin_lock_irqsave(ATOMIC_HASH(ptr), flags); if ((prev = *ptr) == old) *ptr = new; spin_unlock_irqrestore(ATOMIC_HASH(ptr), flags); return prev; } EXPORT_SYMBOL(__cmpxchg_u64);
Maybe something like this would work for other 32 bit architectures as well ?
Yes, you're right, and we even have generic code for this in lib/atomic64.c - but only for atomic64_t, not u64.
Ben.