Re: [PATCH 2/2] Fix compile error of pgtable-ppc64.h

["Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>]

Greg KH <greg@kroah.com> writes:

> On Thu, Jan 30, 2014 at 11:08:52PM +0530, Aneesh Kumar K.V wrote:
>> Greg KH <greg@kroah.com> writes:
>> 
>> > On Thu, Jan 30, 2014 at 09:57:36AM +1100, Benjamin Herrenschmidt wrote:
>> >> On Wed, 2014-01-29 at 10:45 -0800, Greg KH wrote:
>> >> > On Tue, Jan 28, 2014 at 05:52:42PM +0530, Aneesh Kumar K.V wrote:
>> >> > > From: Li Zhong <zhong@linux.vnet.ibm.com>
>> >> > > 
>> >> > > It seems that forward declaration couldn't work well with typedef, use
>> >> > > struct spinlock directly to avoiding following build errors:
>> >> > > 
>> >> > > In file included from include/linux/spinlock.h:81,
>> >> > >                  from include/linux/seqlock.h:35,
>> >> > >                  from include/linux/time.h:5,
>> >> > >                  from include/uapi/linux/timex.h:56,
>> >> > >                  from include/linux/timex.h:56,
>> >> > >                  from include/linux/sched.h:17,
>> >> > >                  from arch/powerpc/kernel/asm-offsets.c:17:
>> >> > > include/linux/spinlock_types.h:76: error: redefinition of typedef 'spinlock_t'
>> >> > > /root/linux-next/arch/powerpc/include/asm/pgtable-ppc64.h:563: note: previous declaration of 'spinlock_t' was here
>> >> > > 
>> >> > > build fix for upstream SHA1: b3084f4db3aeb991c507ca774337c7e7893ed04f
>> >> > > for 3.13 stable series
>> >> > 
>> >> > I don't understand, why is this needed?  Is there a corrisponding patch
>> >> > upstream that already does this?  What went wrong with a "normal"
>> >> > backport of the patch to 3.13?
>> >> 
>> >> There's a corresponding patch in powerpc-next that I'm about to send to
>> >> Linus today, but for the backport, the "fix" could be folded into the
>> >> original offending patch.
>> >
>> > Oh come on, you know better than to try to send me a patch that isn't in
>> > Linus's tree already.  Crap, I can't take that at all.
>> >
>> > Send me the git commit id when it is in Linus's tree, otherwise I'm not
>> > taking it.
>> >
>> > And no, don't "fold in" anything, that's not ok either.  I'll just go
>> > drop this patch entirely from all of my -stable trees for now.  Feel
>> > free to resend them when all of the needed stuff is upstream.
>> 
>> The fix for mremap crash is already in Linus tree.
>
> What is the git commit id?

upstream SHA1: b3084f4db3aeb991c507ca774337c7e7893ed04f

That is patch 1 in this series.


>
>> It is the build failure for older gcc compiler version that is not in
>> linus tree.
>
> That is what I can not take.
>
>> We missed that in the first pull request. Do we really need to drop
>> the patch from 3.11 and 3.12 trees ?
>
> I already did.
>
>> The patch their is a variant, and don't require this build fix.
>
> Don't give me a "variant", give me the exact same patch, only changed to
> handle the fuzz/differences of older kernels, don't make different
> changes to the original patch to make up for things you found out later
> on, otherwise everyone is confused as to why the fix for the fix is not
> in the tree.

In this specific case it may be difficult. 3.13 have other changes
around the code path. It has split pmd locks etc which result in us
doing a withdraw and deposit even on x86. For 3.11 and 3.12, we need to
do that extra withdraw and deposit only for ppc64. Hence the variant
which used #ifdef around that code. 

>
> So, when both patches get in Linus's tree, please send me the properly
> backported patches and I'll be glad to apply them.
>

-aneesh