Hi Dave,
After merging almost all the trees, today's linux-next build (sparc64
defconfig) failed like this:
arch/sparc/lib/hweight.o: In function `__arch_hweight8':
(.text+0x0): relocation truncated to fit: R_SPARC_WDISP19 against symbol `__sw_hweight8' defined in .text section in lib/hweight.o
arch/sparc/lib/hweight.o: In function `__arch_hweight16':
(.text+0xc): relocation truncated to fit: R_SPARC_WDISP19 against symbol `__sw_hweight16' defined in .text section in lib/hweight.o
arch/sparc/lib/hweight.o: In function `__arch_hweight32':
(.text+0x18): relocation truncated to fit: R_SPARC_WDISP19 against symbol `__sw_hweight32' defined in .text section in lib/hweight.o
arch/sparc/lib/hweight.o: In function `__arch_hweight64':
(.text+0x24): relocation truncated to fit: R_SPARC_WDISP19 against symbol `__sw_hweight64' defined in .text section in lib/hweight.o
I though it may have been caused by the thin archive changes, but
disabling CONFIG_THIN_ARCHIVE did not fix it. I have cc'd Nick and
Masahiro just in case.
I am using powerpc-le hosted cross compilers:
gcc 5.2.0
binutsila 2.25.2
I have left it broken for now.
32 bit sparc is not affected.
--
Cheers,
Stephen Rothwell
On Thu, 22 Jun 2017 15:24:41 +1000
Stephen Rothwell <[email protected]> wrote:
> Hi Dave,
>
> After merging almost all the trees, today's linux-next build (sparc64
> defconfig) failed like this:
>
> arch/sparc/lib/hweight.o: In function `__arch_hweight8':
> (.text+0x0): relocation truncated to fit: R_SPARC_WDISP19 against symbol `__sw_hweight8' defined in .text section in lib/hweight.o
> arch/sparc/lib/hweight.o: In function `__arch_hweight16':
> (.text+0xc): relocation truncated to fit: R_SPARC_WDISP19 against symbol `__sw_hweight16' defined in .text section in lib/hweight.o
> arch/sparc/lib/hweight.o: In function `__arch_hweight32':
> (.text+0x18): relocation truncated to fit: R_SPARC_WDISP19 against symbol `__sw_hweight32' defined in .text section in lib/hweight.o
> arch/sparc/lib/hweight.o: In function `__arch_hweight64':
> (.text+0x24): relocation truncated to fit: R_SPARC_WDISP19 against symbol `__sw_hweight64' defined in .text section in lib/hweight.o
>
> I though it may have been caused by the thin archive changes, but
> disabling CONFIG_THIN_ARCHIVE did not fix it. I have cc'd Nick and
> Masahiro just in case.
It could be this
https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=thin-ar&id=ec2c9c20f0efab37ae31de44fe0617aa61283905
kbuild: handle libs-y archives separately from built-in.o archives
That touches the lib linking code regardless of CONFIG_THIN_ARCHIVE.
You should be able to revert it by itself (which will break a few
other archs, so you would also have to revert the default y patch
for thin archives to repair your tree if this is the cause).
I'll try to get around to it after I fix up some other arch breakage
caused by the series :)
Thanks,
Nick
Hi Nicholas,
On Thu, 22 Jun 2017 15:49:52 +1000 Nicholas Piggin <[email protected]> wrote:
>
> It could be this
>
> https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=thin-ar&id=ec2c9c20f0efab37ae31de44fe0617aa61283905
>
> kbuild: handle libs-y archives separately from built-in.o archives
>
> That touches the lib linking code regardless of CONFIG_THIN_ARCHIVE.
> You should be able to revert it by itself (which will break a few
> other archs, so you would also have to revert the default y patch
> for thin archives to repair your tree if this is the cause).
Yeah, reverting that commit fixes the sparc64 build. (i have not done
that in today;s linux-next release, however).
> I'll try to get around to it after I fix up some other arch breakage
> caused by the series :)
Thanks.
--
Cheers,
Stephen Rothwell
Hi Nick,
On Thu, 22 Jun 2017 16:20:11 +1000 Stephen Rothwell <[email protected]> wrote:
>
> On Thu, 22 Jun 2017 15:49:52 +1000 Nicholas Piggin <[email protected]> wrote:
> >
> > It could be this
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=thin-ar&id=ec2c9c20f0efab37ae31de44fe0617aa61283905
> >
> > kbuild: handle libs-y archives separately from built-in.o archives
> >
> > That touches the lib linking code regardless of CONFIG_THIN_ARCHIVE.
> > You should be able to revert it by itself (which will break a few
> > other archs, so you would also have to revert the default y patch
> > for thin archives to repair your tree if this is the cause).
>
> Yeah, reverting that commit fixes the sparc64 build. (i have not done
> that in today;s linux-next release, however).
But it broke the 32 bit sparc defconfig:
arch/sparc/lib/strlen.o: In function `strlen':
(.text+0x0): multiple definition of `strlen'
lib/string.o:string.c:(.text+0x4b4): first defined here
No unexpected, I expect :-)
--
Cheers,
Stephen Rothwell
CC'ing Alan
On Thu, 22 Jun 2017 15:24:41 +1000
Stephen Rothwell <[email protected]> wrote:
> Hi Dave,
>
> After merging almost all the trees, today's linux-next build (sparc64
> defconfig) failed like this:
>
> arch/sparc/lib/hweight.o: In function `__arch_hweight8':
> (.text+0x0): relocation truncated to fit: R_SPARC_WDISP19 against symbol `__sw_hweight8' defined in .text section in lib/hweight.o
> arch/sparc/lib/hweight.o: In function `__arch_hweight16':
> (.text+0xc): relocation truncated to fit: R_SPARC_WDISP19 against symbol `__sw_hweight16' defined in .text section in lib/hweight.o
> arch/sparc/lib/hweight.o: In function `__arch_hweight32':
> (.text+0x18): relocation truncated to fit: R_SPARC_WDISP19 against symbol `__sw_hweight32' defined in .text section in lib/hweight.o
> arch/sparc/lib/hweight.o: In function `__arch_hweight64':
> (.text+0x24): relocation truncated to fit: R_SPARC_WDISP19 against symbol `__sw_hweight64' defined in .text section in lib/hweight.o
After a bit of digging, this is due to that thin archives patch, but only
because it changes the order of linker inputs around slightly. You can
reproduce it with upstream kernel:
This is the final link which succeeds:
sparc64-linux-gnu-ld -m elf64_sparc --build-id -o vmlinux -T ./arch/sparc/kernel/vmlinux.lds arch/sparc/kernel/head_64.o init/built-in.o --start-group usr/built-in.o arch/sparc/built-in.o kernel/built-in.o certs/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a arch/sparc/prom/lib.a arch/sparc/lib/lib.a lib/built-in.o arch/sparc/prom/built-in.o arch/sparc/lib/built-in.o drivers/built-in.o sound/built-in.o firmware/built-in.o net/built-in.o virt/built-in.o --end-group .tmp_kallsyms2.o
Moving the lib.a files to the end:
sparc64-linux-gnu-ld -m elf64_sparc --build-id -o vmlinux -T ./arch/sparc/kernel/vmlinux.lds arch/sparc/kernel/head_64.o init/built-in.o --start-group usr/built-in.o arch/sparc/built-in.o kernel/built-in.o certs/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o lib/built-in.o arch/sparc/prom/built-in.o arch/sparc/lib/built-in.o drivers/built-in.o sound/built-in.o firmware/built-in.o net/built-in.o virt/built-in.o lib/lib.a arch/sparc/prom/lib.a arch/sparc/lib/lib.a --end-group .tmp_kallsyms2.o
arch/sparc/lib/lib.a(hweight.o): In function `__arch_hweight8':
(.text+0x0): relocation truncated to fit: R_SPARC_WDISP19 against symbol `__sw_hweight8' defined in .text section in lib/built-in.o
If we also move lib/built-in.o to the end, then the error goes away.
Is there any way for the linker to place the inputs to avoid unresolvable
relocations where possible?
A way to work around this is to make arch/sparc/lib/hweight.o an obj-y
rather than lib-y. That's a hack because it just serves to move the
input location, but not really any more of a hack than the current code
that also only works because of input locations...
Any thoughts?
Thanks,
Nick
From: Nicholas Piggin <[email protected]>
Date: Thu, 22 Jun 2017 18:41:16 +1000
> Is there any way for the linker to place the inputs to avoid unresolvable
> relocations where possible?
I don't think so.
> A way to work around this is to make arch/sparc/lib/hweight.o an obj-y
> rather than lib-y. That's a hack because it just serves to move the
> input location, but not really any more of a hack than the current code
> that also only works because of input locations...
I could adjust those branches in the sparc code into indirect calls
but it's going to perform a bit poorly on older cpus.
Something like this:
diff --git a/arch/sparc/lib/hweight.S b/arch/sparc/lib/hweight.S
index f9985f1..d21cf20 100644
--- a/arch/sparc/lib/hweight.S
+++ b/arch/sparc/lib/hweight.S
@@ -4,9 +4,9 @@
.text
.align 32
ENTRY(__arch_hweight8)
- ba,pt %xcc, __sw_hweight8
+ sethi %hi(__sw_hweight8), %g1
+ jmpl %g1 + %lo(__sw_hweight8), %g0
nop
- nop
ENDPROC(__arch_hweight8)
EXPORT_SYMBOL(__arch_hweight8)
.section .popc_3insn_patch, "ax"
@@ -17,9 +17,9 @@ EXPORT_SYMBOL(__arch_hweight8)
.previous
ENTRY(__arch_hweight16)
- ba,pt %xcc, __sw_hweight16
+ sethi %hi(__sw_hweight16), %g1
+ jmpl %g1 + %lo(__sw_hweight16), %g0
nop
- nop
ENDPROC(__arch_hweight16)
EXPORT_SYMBOL(__arch_hweight16)
.section .popc_3insn_patch, "ax"
@@ -30,9 +30,9 @@ EXPORT_SYMBOL(__arch_hweight16)
.previous
ENTRY(__arch_hweight32)
- ba,pt %xcc, __sw_hweight32
+ sethi %hi(__sw_hweight32), %g1
+ jmpl %g1 + %lo(__sw_hweight32), %g0
nop
- nop
ENDPROC(__arch_hweight32)
EXPORT_SYMBOL(__arch_hweight32)
.section .popc_3insn_patch, "ax"
@@ -43,9 +43,9 @@ EXPORT_SYMBOL(__arch_hweight32)
.previous
ENTRY(__arch_hweight64)
- ba,pt %xcc, __sw_hweight64
+ sethi %hi(__sw_hweight16), %g1
+ jmpl %g1 + %lo(__sw_hweight16), %g0
nop
- nop
ENDPROC(__arch_hweight64)
EXPORT_SYMBOL(__arch_hweight64)
.section .popc_3insn_patch, "ax"
On Thu, Jun 22, 2017 at 06:41:16PM +1000, Nicholas Piggin wrote:
> Is there any way for the linker to place the inputs to avoid unresolvable
> relocations where possible?
Not without quite a lot of work writing support for that feature.
--
Alan Modra
Australia Development Lab, IBM
From: David Miller <[email protected]>
Date: Thu, 22 Jun 2017 10:13:06 -0400 (EDT)
> From: Nicholas Piggin <[email protected]>
> Date: Thu, 22 Jun 2017 18:41:16 +1000
>
>> Is there any way for the linker to place the inputs to avoid unresolvable
>> relocations where possible?
>
> I don't think so.
>
>> A way to work around this is to make arch/sparc/lib/hweight.o an obj-y
>> rather than lib-y. That's a hack because it just serves to move the
>> input location, but not really any more of a hack than the current code
>> that also only works because of input locations...
>
> I could adjust those branches in the sparc code into indirect calls
> but it's going to perform a bit poorly on older cpus.
>
> Something like this:
I just wanted to mention something in passing.
On sparc64 we patch the first two instructions of memcpy, memset,
bzero, etc. in order to vector them to cpu optimized routines.
And we use the same kind of branch there.
Now because the branches are to routines in the same directory it
should never exceed the relocation limits.
However, if the relocation limits were exceeded in this case, the
build would still succeed and the kernel would be simply broken and
not bootup properly.
On Thu, 22 Jun 2017 10:13:06 -0400 (EDT)
David Miller <[email protected]> wrote:
> From: Nicholas Piggin <[email protected]>
> Date: Thu, 22 Jun 2017 18:41:16 +1000
>
> > Is there any way for the linker to place the inputs to avoid unresolvable
> > relocations where possible?
>
> I don't think so.
>
> > A way to work around this is to make arch/sparc/lib/hweight.o an obj-y
> > rather than lib-y. That's a hack because it just serves to move the
> > input location, but not really any more of a hack than the current code
> > that also only works because of input locations...
>
> I could adjust those branches in the sparc code into indirect calls
> but it's going to perform a bit poorly on older cpus.
The build succeeds with your patch. That should solve it properly
so it won't come back to bite again.
If you can tolerate the slowdown on old CPUs I'd be grateful if
we could merge it for linux-next to get this thin archives tree
unblocked.
Thanks,
Nick
On Thu, 22 Jun 2017 23:43:10 +0930
Alan Modra <[email protected]> wrote:
> On Thu, Jun 22, 2017 at 06:41:16PM +1000, Nicholas Piggin wrote:
> > Is there any way for the linker to place the inputs to avoid unresolvable
> > relocations where possible?
>
> Not without quite a lot of work writing support for that feature.
>
Okay, just wondering if I'd missed something. It'd probably wouldn't
be enough benefit to justify a significant amount of work. We'd be
better off looking at link time optimisation if we wanted to go that
way.
Thanks,
Nick
From: Nicholas Piggin <[email protected]>
Date: Fri, 23 Jun 2017 00:33:39 +1000
> On Thu, 22 Jun 2017 10:13:06 -0400 (EDT)
> David Miller <[email protected]> wrote:
>
>> From: Nicholas Piggin <[email protected]>
>> Date: Thu, 22 Jun 2017 18:41:16 +1000
>>
>> > Is there any way for the linker to place the inputs to avoid unresolvable
>> > relocations where possible?
>>
>> I don't think so.
>>
>> > A way to work around this is to make arch/sparc/lib/hweight.o an obj-y
>> > rather than lib-y. That's a hack because it just serves to move the
>> > input location, but not really any more of a hack than the current code
>> > that also only works because of input locations...
>>
>> I could adjust those branches in the sparc code into indirect calls
>> but it's going to perform a bit poorly on older cpus.
>
> The build succeeds with your patch. That should solve it properly
> so it won't come back to bite again.
>
> If you can tolerate the slowdown on old CPUs I'd be grateful if
> we could merge it for linux-next to get this thin archives tree
> unblocked.
Feel free to merge it into your series:
====================
sparc64: Use indirect calls in hamming weight stubs.
Otherwise, depending upon link order, the branch relocation
limits could be exceeded.
Signed-off-by: David S. Miller <[email protected]>
diff --git a/arch/sparc/lib/hweight.S b/arch/sparc/lib/hweight.S
index f9985f1..d21cf20 100644
--- a/arch/sparc/lib/hweight.S
+++ b/arch/sparc/lib/hweight.S
@@ -4,9 +4,9 @@
.text
.align 32
ENTRY(__arch_hweight8)
- ba,pt %xcc, __sw_hweight8
+ sethi %hi(__sw_hweight8), %g1
+ jmpl %g1 + %lo(__sw_hweight8), %g0
nop
- nop
ENDPROC(__arch_hweight8)
EXPORT_SYMBOL(__arch_hweight8)
.section .popc_3insn_patch, "ax"
@@ -17,9 +17,9 @@ EXPORT_SYMBOL(__arch_hweight8)
.previous
ENTRY(__arch_hweight16)
- ba,pt %xcc, __sw_hweight16
+ sethi %hi(__sw_hweight16), %g1
+ jmpl %g1 + %lo(__sw_hweight16), %g0
nop
- nop
ENDPROC(__arch_hweight16)
EXPORT_SYMBOL(__arch_hweight16)
.section .popc_3insn_patch, "ax"
@@ -30,9 +30,9 @@ EXPORT_SYMBOL(__arch_hweight16)
.previous
ENTRY(__arch_hweight32)
- ba,pt %xcc, __sw_hweight32
+ sethi %hi(__sw_hweight32), %g1
+ jmpl %g1 + %lo(__sw_hweight32), %g0
nop
- nop
ENDPROC(__arch_hweight32)
EXPORT_SYMBOL(__arch_hweight32)
.section .popc_3insn_patch, "ax"
@@ -43,9 +43,9 @@ EXPORT_SYMBOL(__arch_hweight32)
.previous
ENTRY(__arch_hweight64)
- ba,pt %xcc, __sw_hweight64
+ sethi %hi(__sw_hweight16), %g1
+ jmpl %g1 + %lo(__sw_hweight16), %g0
nop
- nop
ENDPROC(__arch_hweight64)
EXPORT_SYMBOL(__arch_hweight64)
.section .popc_3insn_patch, "ax"
On Thu, 22 Jun 2017 10:56:48 -0400 (EDT)
David Miller <[email protected]> wrote:
> From: Nicholas Piggin <[email protected]>
> Date: Fri, 23 Jun 2017 00:33:39 +1000
>
> > On Thu, 22 Jun 2017 10:13:06 -0400 (EDT)
> > David Miller <[email protected]> wrote:
> >
> >> From: Nicholas Piggin <[email protected]>
> >> Date: Thu, 22 Jun 2017 18:41:16 +1000
> >>
> >> > Is there any way for the linker to place the inputs to avoid unresolvable
> >> > relocations where possible?
> >>
> >> I don't think so.
> >>
> >> > A way to work around this is to make arch/sparc/lib/hweight.o an obj-y
> >> > rather than lib-y. That's a hack because it just serves to move the
> >> > input location, but not really any more of a hack than the current code
> >> > that also only works because of input locations...
> >>
> >> I could adjust those branches in the sparc code into indirect calls
> >> but it's going to perform a bit poorly on older cpus.
> >
> > The build succeeds with your patch. That should solve it properly
> > so it won't come back to bite again.
> >
> > If you can tolerate the slowdown on old CPUs I'd be grateful if
> > we could merge it for linux-next to get this thin archives tree
> > unblocked.
>
> Feel free to merge it into your series:
>
> ====================
> sparc64: Use indirect calls in hamming weight stubs.
>
> Otherwise, depending upon link order, the branch relocation
> limits could be exceeded.
>
> Signed-off-by: David S. Miller <[email protected]>
Thanks for the patch, looks good to me.
On Thu, 22 Jun 2017 10:29:23 -0400 (EDT)
David Miller <[email protected]> wrote:
> From: David Miller <[email protected]>
> Date: Thu, 22 Jun 2017 10:13:06 -0400 (EDT)
>
> > From: Nicholas Piggin <[email protected]>
> > Date: Thu, 22 Jun 2017 18:41:16 +1000
> >
> >> Is there any way for the linker to place the inputs to avoid unresolvable
> >> relocations where possible?
> >
> > I don't think so.
> >
> >> A way to work around this is to make arch/sparc/lib/hweight.o an obj-y
> >> rather than lib-y. That's a hack because it just serves to move the
> >> input location, but not really any more of a hack than the current code
> >> that also only works because of input locations...
> >
> > I could adjust those branches in the sparc code into indirect calls
> > but it's going to perform a bit poorly on older cpus.
> >
> > Something like this:
>
> I just wanted to mention something in passing.
>
> On sparc64 we patch the first two instructions of memcpy, memset,
> bzero, etc. in order to vector them to cpu optimized routines.
>
> And we use the same kind of branch there.
>
> Now because the branches are to routines in the same directory it
> should never exceed the relocation limits.
>
> However, if the relocation limits were exceeded in this case, the
> build would still succeed and the kernel would be simply broken and
> not bootup properly.
Powerpc has similar problems with linking, particularly in patch
code. What it does is to actually link the patch code into the kernel
as well in another section, so the branch target is resolved by the
linker. When moving the patch code at runtime, the branch offset is
adjusted. So it does get a link error if things don't work there.
I guess the other thing you could do is a build-time check over your
patch code with a custom script or tool.
If you're in the same directory it should be okay, unless it is split
between obj-y/built-in.o and lib-y/lib.a then you might have a
problem.
Thanks,
Nick
Hi all,
On Thu, 22 Jun 2017 10:56:48 -0400 (EDT) David Miller <[email protected]> wrote:
>
> Feel free to merge it into your series:
>
> ====================
> sparc64: Use indirect calls in hamming weight stubs.
>
> Otherwise, depending upon link order, the branch relocation
> limits could be exceeded.
>
> Signed-off-by: David S. Miller <[email protected]>
>
> diff --git a/arch/sparc/lib/hweight.S b/arch/sparc/lib/hweight.S
> index f9985f1..d21cf20 100644
> --- a/arch/sparc/lib/hweight.S
> +++ b/arch/sparc/lib/hweight.S
> @@ -4,9 +4,9 @@
> .text
> .align 32
> ENTRY(__arch_hweight8)
> - ba,pt %xcc, __sw_hweight8
> + sethi %hi(__sw_hweight8), %g1
> + jmpl %g1 + %lo(__sw_hweight8), %g0
> nop
> - nop
> ENDPROC(__arch_hweight8)
> EXPORT_SYMBOL(__arch_hweight8)
> .section .popc_3insn_patch, "ax"
> @@ -17,9 +17,9 @@ EXPORT_SYMBOL(__arch_hweight8)
> .previous
>
> ENTRY(__arch_hweight16)
> - ba,pt %xcc, __sw_hweight16
> + sethi %hi(__sw_hweight16), %g1
> + jmpl %g1 + %lo(__sw_hweight16), %g0
> nop
> - nop
> ENDPROC(__arch_hweight16)
> EXPORT_SYMBOL(__arch_hweight16)
> .section .popc_3insn_patch, "ax"
> @@ -30,9 +30,9 @@ EXPORT_SYMBOL(__arch_hweight16)
> .previous
>
> ENTRY(__arch_hweight32)
> - ba,pt %xcc, __sw_hweight32
> + sethi %hi(__sw_hweight32), %g1
> + jmpl %g1 + %lo(__sw_hweight32), %g0
> nop
> - nop
> ENDPROC(__arch_hweight32)
> EXPORT_SYMBOL(__arch_hweight32)
> .section .popc_3insn_patch, "ax"
> @@ -43,9 +43,9 @@ EXPORT_SYMBOL(__arch_hweight32)
> .previous
>
> ENTRY(__arch_hweight64)
> - ba,pt %xcc, __sw_hweight64
> + sethi %hi(__sw_hweight16), %g1
> + jmpl %g1 + %lo(__sw_hweight16), %g0
> nop
> - nop
> ENDPROC(__arch_hweight64)
> EXPORT_SYMBOL(__arch_hweight64)
> .section .popc_3insn_patch, "ax"
I added that to linux-next today and it fixed the build problem.
--
Cheers,
Stephen Rothwell
Hi Stephen,
> -----Original Message-----
> From: Stephen Rothwell [mailto:[email protected]]
> Sent: Friday, June 23, 2017 3:43 PM
> To: David Miller <[email protected]>
> Cc: [email protected]; [email protected];
> [email protected]; Yamada, Masahiro/$B;3ED(B $B??90(B
> <[email protected]>; [email protected]
> Subject: Re: linux-next: build failure after merge of most trees
>
> Hi all,
>
> On Thu, 22 Jun 2017 10:56:48 -0400 (EDT) David Miller <[email protected]>
> wrote:
> >
> > Feel free to merge it into your series:
> >
> > ====================
[snip]
>
> I added that to linux-next today and it fixed the build problem.
Thanks for taking care of this.
Sorry, I missed to pick up this for today's release.
I will insert this before Nicholas' series.
Hi,
On Fri, 23 Jun 2017 06:46:53 +0000 <[email protected]> wrote:
>
> > -----Original Message-----
> > From: Stephen Rothwell [mailto:[email protected]]
> > Sent: Friday, June 23, 2017 3:43 PM
> > To: David Miller <[email protected]>
> > Cc: [email protected]; [email protected];
> > [email protected]; Yamada, Masahiro/山田 真弘
> > <[email protected]>; [email protected]
> > Subject: Re: linux-next: build failure after merge of most trees
> >
> > Hi all,
> >
> > On Thu, 22 Jun 2017 10:56:48 -0400 (EDT) David Miller <[email protected]>
> > wrote:
> > >
> > > Feel free to merge it into your series:
> > >
> > > ====================
> [snip]
> >
> > I added that to linux-next today and it fixed the build problem.
>
> Thanks for taking care of this.
No worries.
> Sorry, I missed to pick up this for today's release.
> I will insert this before Nicholas' series.
Thanks, I will drop it on Monday.
--
Cheers,
Stephen Rothwell
From: <[email protected]>
Date: Fri, 23 Jun 2017 06:46:53 +0000
> I will insert this before Nicholas' series.
Thank you.