[PATCH] powerpc: don't re-issue spinlock typedef that breaks older gcc
paul.gortmaker at windriver.com
Wed Jan 29 06:07:11 EST 2014
On 14-01-28 01:49 PM, Aneesh Kumar K.V wrote:
> Paul Gortmaker <paul.gortmaker at windriver.com> writes:
>> On 14-01-28 12:28 PM, Aneesh Kumar K.V wrote:
>>> Paul Gortmaker <paul.gortmaker at windriver.com> writes:
>>>> Commit b3084f4db3aeb991c507ca774337c7e7893ed04f ("powerpc/thp: Fix
>>>> crash on mremap") added a "typedef struct spinlock spinlock_t;"
>>>> which on gcc 4.5.2 (and possibly other versions) causes many of:
>>>> include/linux/spinlock_types.h:76:3: error: redefinition of typedef 'spinlock_t'
>>>> arch/powerpc/include/asm/pgtable-ppc64.h:563:25: note: previous declaration of 'spinlock_t' was here
>>>> In file included from include/linux/mutex.h:15:0,
>>>> from include/linux/notifier.h:13,
>>>> from include/linux/pm_qos.h:8,
>>>> from include/linux/netdevice.h:28,
>>>> from drivers/net/wireless/ath/wil6210/wil6210.h:20,
>>>> from drivers/net/wireless/ath/wil6210/debug.c:17:
>>>> It appears that somewhere between gcc 4.5.2 and 4.6.3 this
>>>> redefinition restriction was lifted. Using the proper header
>>>> from within !ASSEMBLY seems to fix it up in an acceptable way.
>>>> Cc: Aneesh Kumar K.V <aneesh.kumar at linux.vnet.ibm.com>
>>>> Cc: Kirill A. Shutemov <kirill.shutemov at linux.intel.com>
>>>> Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
>>>> Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
>>> This was posted earlier.
>> I see. Well I guess Ben didn't use it since it is the same as the
>> temporary not-signed-off-by hack patch I posted earlier as well.
>> I believe what I've posted here below to be the proper fix.
> I had another variant which needed this
What config did you use to trigger that? I've not seen it in
allyes/allmodconfig. I'd like us to try and fix it an alternate
way, vs. fragmenting the header into smaller and smaller
specialized chunks, if possible.
> BTW I had added the above struct spinlock; patch as the backport to
> stable 3.13 series. So if we are picking another one, we may need to
> update stable also
The stable tree is self-correcting ; it won't take any patches that
don't have the same commit present in mainline. But yes, someone
will still have to _nominate_ one for stable tree consideration.
More information about the Linuxppc-dev