On Wed, Nov 22, 2017 at 06:00:23PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Nov 22, 2017 at 04:06:42PM +0000, Ben Hutchings wrote:
> > 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.
>
> Ok, so, suggestions? Is this actually a real issue that anyone is
> hitting? If they are, is it just a test-build, or a
> real-world-I-need-this-driver situation?
>
Long term it would be beneficial to have generic support for
cmpxchg_u64 for all architectures, but I have no real idea
(nor strong opinion) if that would be useful to backport.
Big question here is if anyone uses the i40e driver in v4.14 on
any of the affected systems, and/or if anyone does regular test
builds which now fail (and if there is interest in keeping those
test builds going). I'd guess no one uses the driver on an affected
system, or at least no one cared enough to fix the problem while
v4.14 was in rc.
This leaves the testing question, which I can't really answer.
Are people still interested in test image build results ?
Guenter