On Thu, 2014-01-30 at 09:55 -0800, Greg KH wrote:

On Thu, Jan 30, 2014 at 11:08:52PM +0530, Aneesh Kumar K.V wrote:

quoted

Greg KH [off-list ref] writes:

quoted

On Thu, Jan 30, 2014 at 09:57:36AM +1100, Benjamin Herrenschmidt wrote:

quoted

On Wed, 2014-01-29 at 10:45 -0800, Greg KH wrote:

quoted

On Tue, Jan 28, 2014 at 05:52:42PM +0530, Aneesh Kumar K.V wrote:

quoted

From: Li Zhong <redacted>

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?

Relax Greg :-) The submissions all had the commit ID of the original
patch upsteam: b3084f4db3aeb991c507ca774337c7e7893ed04f

The only *thing* here is due to churn upstream in 3.13, the backport
is a bit different for 3.13 vs. earlier versions.

The earlier ones are perfectly kosher and you should have no reason
not to take them.

The 3.13, well, Mahesh was a bit quick here, he sent you the actual
patch that went upstream ... and a second patch to fix a problem
with older gcc's that it introduces. Because it's a simple build fix of
the previous patch, I suggested folding it in instead.

That build fix is what is not yet upstream, it's in my -next branch
which Linus hasn't pulled just yet.

If that's an issue for you, just drop the 3.13 variant of the patch and
we'll send it again with the build fix as soon as Linus has pulled the
latter.

quoted

It is the build failure for older gcc compiler version that is not in
linus tree.

That is what I can not take.

quoted

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.

quoted

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.

The backport patch is a "variant" because of changes in the affected
function that went into 3.13.

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

Ben.