lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 22 Nov 2017 16:06:42 +0000 From: Ben Hutchings <ben.hutchings@...ethink.co.uk> To: Guenter Roeck <linux@...ck-us.net> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org, akpm@...ux-foundation.org, shuahkh@....samsung.com, patches@...nelci.org, stable@...r.kernel.org Subject: Re: [PATCH 4.14 00/31] 4.14.1-stable review 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. -- Ben Hutchings Software Developer, Codethink Ltd.
Powered by blists - more mailing lists