* Re: linux-next: build failure after merge of the wireless-drivers-next tree
From: David Miller @ 2017-06-15 16:08 UTC (permalink / raw)
To: sfr
Cc: netdev, kvalo, linux-wireless, linux-next, linux-kernel,
igor.mitsyanko.os, dlebed, smaksimenko, smatyukevich, btherthala,
hwang, krath, avinashp
In-Reply-To: <20170613120024.2a1ce31b@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 13 Jun 2017 12:00:24 +1000
> Hi Dave,
>
> On Thu, 8 Jun 2017 12:27:59 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> After merging the wireless-drivers-next tree, today's linux-next build
>> (x86_64 allmodconfig) failed like this:
>>
>> drivers/net/wireless/quantenna/qtnfmac/core.c: In function 'qtnf_core_net_attach':
>> drivers/net/wireless/quantenna/qtnfmac/core.c:319:5: error: 'struct net_device' has no member named 'destructor'
>> dev->destructor = free_netdev;
>> ^
>>
>> Caused by commit
>>
>> 98f44cb0655c ("qtnfmac: introduce new FullMAC driver for Quantenna chipsets")
>
> This commit is now in the net-next tree ...
>
>> interacting with commit
>>
>> cf124db566e6 ("net: Fix inconsistent teardown and release of private netdev state.")
>>
>> from the net tree.
>>
>> I applied this merge fix patch for today.
>
> So this merge fix patch is needed when the net and net-next trees are merged.
This is now all resolved, thanks!
^ permalink raw reply
* RE: [Oops][next-20170614][] powerpc boot fails with WARNING: CPU: 12 PID: 0 at mm/memblock.c
From: Rowand, Frank @ 2017-06-15 17:06 UTC (permalink / raw)
To: Abdul Haleem
Cc: sachinp, linux-next, linux-kernel, Stephen Rothwell, linuxppc-dev,
mpe
In-Reply-To: <1497518696.15415.68.camel@abdul.in.ibm.com>
On Thursday, June 15, 2017 2:25 AM, Abdul Haleem [mailto:abdhalee@linux.vnet.ibm.com] wrote:
>
> On Thu, 2017-06-15 at 11:30 +0530, Abdul Haleem wrote:
>> Hi,
>>
>> linux-next fails to boot on powerpc Bare-metal with these warnings.
>>
>> machine booted fine on next-20170613
>
> Thanks Michael, Yes it is (75fe04e59 of: remove *phandle properties from
> expanded device tree)
>
> Frank, would you please take a look at the trace.
>
> Thanks
< snip >
My patch series 'of: remove *phandle properties from expanded device tree'
in -next seems to have broken boot for a significant number of powerpc
systems. I am actively working on understanding and fixing the problem.
-Frank
^ permalink raw reply
* Re: linux-next: build failure after merge of the wireless-drivers-next tree
From: Stephen Rothwell @ 2017-06-15 18:25 UTC (permalink / raw)
To: David Miller
Cc: netdev, kvalo, linux-wireless, linux-next, linux-kernel,
igor.mitsyanko.os, dlebed, smaksimenko, smatyukevich, btherthala,
hwang, krath, avinashp
In-Reply-To: <20170615.120808.1402317729827497353.davem@davemloft.net>
Hi Dave,
On Thu, 15 Jun 2017 12:08:08 -0400 (EDT) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 13 Jun 2017 12:00:24 +1000
>
> > On Thu, 8 Jun 2017 12:27:59 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>
> >> After merging the wireless-drivers-next tree, today's linux-next build
> >> (x86_64 allmodconfig) failed like this:
> >>
> >> drivers/net/wireless/quantenna/qtnfmac/core.c: In function 'qtnf_core_net_attach':
> >> drivers/net/wireless/quantenna/qtnfmac/core.c:319:5: error: 'struct net_device' has no member named 'destructor'
> >> dev->destructor = free_netdev;
> >> ^
> >>
> >> Caused by commit
> >>
> >> 98f44cb0655c ("qtnfmac: introduce new FullMAC driver for Quantenna chipsets")
> >
> > This commit is now in the net-next tree ...
> >
> >> interacting with commit
> >>
> >> cf124db566e6 ("net: Fix inconsistent teardown and release of private netdev state.")
> >>
> >> from the net tree.
> >>
> >> I applied this merge fix patch for today.
> >
> > So this merge fix patch is needed when the net and net-next trees are merged.
>
> This is now all resolved, thanks!
Thanks for letting me know.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: linux-next: build failure after merge of the akpm-current tree
From: Andrew Morton @ 2017-06-15 19:12 UTC (permalink / raw)
To: Kees Cook
Cc: Stephen Rothwell, Linux-Next Mailing List,
Linux Kernel Mailing List, Daniel Micay
In-Reply-To: <CAGXu5jJyjymPfRNcKrRruYzZFUR-W8H7EWUnYR-6PJi3HcQ+-A@mail.gmail.com>
On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <keescook@chromium.org> wrote:
> >> Caused by commit
> >>
> >> 088a5ecf7581 ("include/linux/string.h: add the option of fortified string.h functions")
> >>
> >> We really need to fix all the known problems it detects *before*
> >> merging this commit ...
> >>
> >> I have reverted it for today.
> >
> > I am still needing to revert this every day ...
>
> I sent a series for -mm (or maintainers) to merge that should catch
> everything. Do you want me to carry it in my kspp tree instead? (My
> original intention was to carry all the fixes and the fortify patch in
> kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
> complaining.)
This is all getting a bit foggy in my mind. Can we please have a full
resend of everything? Sufficient to hopefully produce a tree which has
no build-time or run-time regressions? Including the buildbot's
recently-reported alpha and xtensa issues?
^ permalink raw reply
* linux-next: bad commit in the mvebu tree
From: Stephen Rothwell @ 2017-06-15 19:57 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Gregory Clement, ARM
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
Hi all,
I noticed that commit
c6f4e66bd0f4 ("arm64: marvell: dts: add xmdio nodes for 7k/8k")
has no Signed-off-by for its comitter.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: build warning after merge of the wireless-drivers tree
From: Stephen Rothwell @ 2017-06-15 22:25 UTC (permalink / raw)
To: Kalle Valo, Wireless
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Arend Van Spriel
Hi all,
After merging the wireless-drivers tree, today's linux-next build
(x86_64 allmodconfig) produced this warning:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c: In function 'brcmf_usb_probe_phase2':
drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c:1198:2: warning: 'devinfo' may be used uninitialized in this function [-Wmaybe-uninitialized]
mutex_unlock(&devinfo->dev_init_lock);
^
Introduced by commit
6d0507a777fb ("brcmfmac: add parameter to pass error code in firmware callback")
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: manual merge of the clk tree with the reset tree
From: Stephen Rothwell @ 2017-06-15 23:15 UTC (permalink / raw)
To: Mike Turquette, Stephen Boyd, Philipp Zabel
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Andrew F. Davis, Tero Kristo
Hi all,
Today's linux-next merge of the clk tree got a conflict in:
MAINTAINERS
between commits:
18a006203b88 ("dt-bindings: reset: Add TI SCI reset binding")
28df169b9afa ("reset: Add the TI SCI reset driver")
from the reset tree and commits:
8f306cfe4383 ("Documentation: dt: Add TI SCI clock driver")
b745c0794e2f ("clk: keystone: Add sci-clk driver support")
from the clk tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc MAINTAINERS
index 003e0e302d46,1ba72e6d8254..000000000000
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -12638,8 -12630,8 +12638,10 @@@ F: include/linux/soc/ti/ti_sci_protocol
F: Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
F: include/dt-bindings/genpd/k2g.h
F: drivers/soc/ti/ti_sci_pm_domains.c
+F: Documentation/devicetree/bindings/reset/ti,sci-reset.txt
+F: drivers/reset/reset-ti-sci.c
+ F: Documentation/devicetree/bindings/clock/ti,sci-clk.txt
+ F: drivers/clk/keystone/sci-clk.c
THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
M: Hans Verkuil <hverkuil@xs4all.nl>
^ permalink raw reply
* Re: linux-next: build failure after merge of the akpm-current tree
From: Kees Cook @ 2017-06-15 23:46 UTC (permalink / raw)
To: Andrew Morton
Cc: Stephen Rothwell, Linux-Next Mailing List,
Linux Kernel Mailing List, Daniel Micay
In-Reply-To: <20170615121220.4331a37b0fb736ec9da4e423@linux-foundation.org>
On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <keescook@chromium.org> wrote:
>
>> >> Caused by commit
>> >>
>> >> 088a5ecf7581 ("include/linux/string.h: add the option of fortified string.h functions")
>> >>
>> >> We really need to fix all the known problems it detects *before*
>> >> merging this commit ...
>> >>
>> >> I have reverted it for today.
>> >
>> > I am still needing to revert this every day ...
>>
>> I sent a series for -mm (or maintainers) to merge that should catch
>> everything. Do you want me to carry it in my kspp tree instead? (My
>> original intention was to carry all the fixes and the fortify patch in
>> kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
>> complaining.)
>
> This is all getting a bit foggy in my mind. Can we please have a full
> resend of everything? Sufficient to hopefully produce a tree which has
> no build-time or run-time regressions? Including the buildbot's
> recently-reported alpha and xtensa issues?
It's been sent a few times (and a few fixes have been collected in
other trees already). What I've got in my for-next/kspp tree right now
is all the fixes that haven't already been picked up by other tree
maintainers, and I added the fortify patch itself to the end of the
tree too now since sfr asked for that a few hours ago.
Merged with latest -next, this passes x86_64, i386, arm64, and powerpc
allmodconfig builds for me. It doesn't pass arm, though. Perhaps we
need to add an ARCH_HAS_FORTIFY_SOURCE to gate the all*config builds?
Should we let the dust settle first? I'm happy to do whatever makes
the most sense, I'm just following what (I understand) sfr suggested
most recently. :)
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* Re: [Oops][next-20170614][] powerpc boot fails with WARNING: CPU: 12 PID: 0 at mm/memblock.c
From: Benjamin Herrenschmidt @ 2017-06-16 0:04 UTC (permalink / raw)
To: Rowand, Frank, Abdul Haleem
Cc: sachinp, Stephen Rothwell, linux-kernel, linux-next, linuxppc-dev
In-Reply-To: <ED290C750E1B324E972B0017C9D4BAB02E5A7EAF@USCULXMSG03.am.sony.com>
On Thu, 2017-06-15 at 17:06 +0000, Rowand, Frank wrote:
> On Thursday, June 15, 2017 2:25 AM, Abdul Haleem [mailto:abdhalee@linux.vnet.ibm.com] wrote:
> >
> > On Thu, 2017-06-15 at 11:30 +0530, Abdul Haleem wrote:
> > > Hi,
> > >
> > > linux-next fails to boot on powerpc Bare-metal with these warnings.
> > >
> > > machine booted fine on next-20170613
> >
> > Thanks Michael, Yes it is (75fe04e59 of: remove *phandle properties from
> > expanded device tree)
> >
> > Frank, would you please take a look at the trace.
> >
> > Thanks
>
> < snip >
>
> My patch series 'of: remove *phandle properties from expanded device tree'
> in -next seems to have broken boot for a significant number of powerpc
> systems. I am actively working on understanding and fixing the problem.
I think kexec needs them in sysfs (or /proc) when building the fdt
for the target kernel.
Cheers,
Ben.
^ permalink raw reply
* Re: linux-next: build failure after merge of the akpm-current tree
From: Daniel Micay @ 2017-06-16 0:05 UTC (permalink / raw)
To: Kees Cook, Andrew Morton
Cc: Stephen Rothwell, Linux-Next Mailing List,
Linux Kernel Mailing List
In-Reply-To: <CAGXu5jJJPZYnhcubfWrjj8XROAycEYsgK_AhBF-rQydeZyCwCg@mail.gmail.com>
On Thu, 2017-06-15 at 16:46 -0700, Kees Cook wrote:
> On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <keescook@chromium.org>
> > wrote:
> >
> > > > > Caused by commit
> > > > >
> > > > > 088a5ecf7581 ("include/linux/string.h: add the option of
> > > > > fortified string.h functions")
> > > > >
> > > > > We really need to fix all the known problems it detects
> > > > > *before*
> > > > > merging this commit ...
> > > > >
> > > > > I have reverted it for today.
> > > >
> > > > I am still needing to revert this every day ...
> > >
> > > I sent a series for -mm (or maintainers) to merge that should
> > > catch
> > > everything. Do you want me to carry it in my kspp tree instead?
> > > (My
> > > original intention was to carry all the fixes and the fortify
> > > patch in
> > > kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
> > > complaining.)
> >
> > This is all getting a bit foggy in my mind. Can we please have a
> > full
> > resend of everything? Sufficient to hopefully produce a tree which
> > has
> > no build-time or run-time regressions? Including the buildbot's
> > recently-reported alpha and xtensa issues?
>
> It's been sent a few times (and a few fixes have been collected in
> other trees already). What I've got in my for-next/kspp tree right now
> is all the fixes that haven't already been picked up by other tree
> maintainers, and I added the fortify patch itself to the end of the
> tree too now since sfr asked for that a few hours ago.
>
> Merged with latest -next, this passes x86_64, i386, arm64, and powerpc
> allmodconfig builds for me. It doesn't pass arm, though. Perhaps we
> need to add an ARCH_HAS_FORTIFY_SOURCE to gate the all*config builds?
>
> Should we let the dust settle first? I'm happy to do whatever makes
> the most sense, I'm just following what (I understand) sfr suggested
> most recently. :)
>
> -Kees
>
If it needs to build and boot on every architecture, I think we should
gate it on i386, x86_64, arm64 or powerpc where it has been tested.
I think I know what has to be fixed for alpha and xtensa but there might
be more problems. It's better to wait for someone willing / able to do
it properly by building it themselves and doing basic runtime testing.
^ permalink raw reply
* Re: linux-next: build failure after merge of the akpm-current tree
From: Kees Cook @ 2017-06-16 0:35 UTC (permalink / raw)
To: Daniel Micay
Cc: Andrew Morton, Stephen Rothwell, Linux-Next Mailing List,
Linux Kernel Mailing List
In-Reply-To: <1497571513.17727.2.camel@gmail.com>
On Thu, Jun 15, 2017 at 5:05 PM, Daniel Micay <danielmicay@gmail.com> wrote:
> On Thu, 2017-06-15 at 16:46 -0700, Kees Cook wrote:
>> On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton
>> <akpm@linux-foundation.org> wrote:
>> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <keescook@chromium.org>
>> > wrote:
>> >
>> > > > > Caused by commit
>> > > > >
>> > > > > 088a5ecf7581 ("include/linux/string.h: add the option of
>> > > > > fortified string.h functions")
>> > > > >
>> > > > > We really need to fix all the known problems it detects
>> > > > > *before*
>> > > > > merging this commit ...
>> > > > >
>> > > > > I have reverted it for today.
>> > > >
>> > > > I am still needing to revert this every day ...
>> > >
>> > > I sent a series for -mm (or maintainers) to merge that should
>> > > catch
>> > > everything. Do you want me to carry it in my kspp tree instead?
>> > > (My
>> > > original intention was to carry all the fixes and the fortify
>> > > patch in
>> > > kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
>> > > complaining.)
>> >
>> > This is all getting a bit foggy in my mind. Can we please have a
>> > full
>> > resend of everything? Sufficient to hopefully produce a tree which
>> > has
>> > no build-time or run-time regressions? Including the buildbot's
>> > recently-reported alpha and xtensa issues?
>>
>> It's been sent a few times (and a few fixes have been collected in
>> other trees already). What I've got in my for-next/kspp tree right now
>> is all the fixes that haven't already been picked up by other tree
>> maintainers, and I added the fortify patch itself to the end of the
>> tree too now since sfr asked for that a few hours ago.
>>
>> Merged with latest -next, this passes x86_64, i386, arm64, and powerpc
>> allmodconfig builds for me. It doesn't pass arm, though. Perhaps we
>> need to add an ARCH_HAS_FORTIFY_SOURCE to gate the all*config builds?
>>
>> Should we let the dust settle first? I'm happy to do whatever makes
>> the most sense, I'm just following what (I understand) sfr suggested
>> most recently. :)
>>
>> -Kees
>>
>
> If it needs to build and boot on every architecture, I think we should
> gate it on i386, x86_64, arm64 or powerpc where it has been tested.
>
> I think I know what has to be fixed for alpha and xtensa but there might
> be more problems. It's better to wait for someone willing / able to do
> it properly by building it themselves and doing basic runtime testing.
Sounds good. I've added ARCH_HAS_FORTIFY_SOURCE to the patch (and noted it).
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* RE: [Oops][next-20170614][] powerpc boot fails with WARNING: CPU: 12 PID: 0 at mm/memblock.c
From: Michael Ellerman @ 2017-06-16 0:57 UTC (permalink / raw)
To: Rowand, Frank, Abdul Haleem
Cc: sachinp, linux-next, linux-kernel, Stephen Rothwell, linuxppc-dev,
Rob Herring
In-Reply-To: <ED290C750E1B324E972B0017C9D4BAB02E5A7EAF@USCULXMSG03.am.sony.com>
"Rowand, Frank" <Frank.Rowand@sony.com> writes:
> On Thursday, June 15, 2017 2:25 AM, Abdul Haleem [mailto:abdhalee@linux.vnet.ibm.com] wrote:
>>
>> On Thu, 2017-06-15 at 11:30 +0530, Abdul Haleem wrote:
>>> Hi,
>>>
>>> linux-next fails to boot on powerpc Bare-metal with these warnings.
>>>
>>> machine booted fine on next-20170613
>>
>> Thanks Michael, Yes it is (75fe04e59 of: remove *phandle properties from
>> expanded device tree)
>>
>> Frank, would you please take a look at the trace.
>>
>> Thanks
>
> < snip >
>
> My patch series 'of: remove *phandle properties from expanded device tree'
> in -next seems to have broken boot for a significant number of powerpc
> systems. I am actively working on understanding and fixing the problem.
Thanks.
At least for me reverting that patch on top of linux-next gets things
booting again.
Stephen can you revert that patch in linux-next today?
cheers
^ permalink raw reply
* linux-next: manual merge of the drm-tegra tree with the drm tree
From: Stephen Rothwell @ 2017-06-16 1:12 UTC (permalink / raw)
To: Thierry Reding
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Tom Cooksey,
Eric Anholt
Hi Thierry,
Today's linux-next merge of the drm-tegra tree got a conflict in:
Documentation/gpu/index.rst
between commit:
bed41005e617 ("drm/pl111: Initial drm/kms driver for pl111")
from the drm tree and commit:
fa6d095eb23a ("drm/tegra: Add driver documentation")
from the drm-tegra tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/gpu/index.rst
index 037a39ac1807,feae37fa7ca3..000000000000
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@@ -12,7 -12,7 +12,8 @@@ Linux GPU Driver Developer's Guid
drm-uapi
i915
meson
+ pl111
+ tegra
tinydrm
vc4
vga-switcheroo
^ permalink raw reply
* Re: [Oops][next-20170614][] powerpc boot fails with WARNING: CPU: 12 PID: 0 at mm/memblock.c
From: Stephen Rothwell @ 2017-06-16 1:13 UTC (permalink / raw)
To: Michael Ellerman
Cc: Rowand, Frank, Abdul Haleem, sachinp, linux-next, linux-kernel,
linuxppc-dev, Rob Herring
In-Reply-To: <87injwwxzh.fsf@concordia.ellerman.id.au>
Hi Michael,
On Fri, 16 Jun 2017 10:57:22 +1000 Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> "Rowand, Frank" <Frank.Rowand@sony.com> writes:
>
> > On Thursday, June 15, 2017 2:25 AM, Abdul Haleem [mailto:abdhalee@linux.vnet.ibm.com] wrote:
> >>
> >> On Thu, 2017-06-15 at 11:30 +0530, Abdul Haleem wrote:
> >>>
> >>> linux-next fails to boot on powerpc Bare-metal with these warnings.
> >>>
> >>> machine booted fine on next-20170613
> >>
> >> Thanks Michael, Yes it is (75fe04e59 of: remove *phandle properties from
> >> expanded device tree)
> >>
> >> Frank, would you please take a look at the trace.
> >>
> >> Thanks
> >
> > < snip >
> >
> > My patch series 'of: remove *phandle properties from expanded device tree'
> > in -next seems to have broken boot for a significant number of powerpc
> > systems. I am actively working on understanding and fixing the problem.
>
> Thanks.
>
> At least for me reverting that patch on top of linux-next gets things
> booting again.
>
> Stephen can you revert that patch in linux-next today?
OK.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: linux-next: build failure after merge of the akpm-current tree
From: Stephen Rothwell @ 2017-06-16 1:20 UTC (permalink / raw)
To: Kees Cook
Cc: Daniel Micay, Andrew Morton, Linux-Next Mailing List,
Linux Kernel Mailing List
In-Reply-To: <CAGXu5jKXNuZOqWB6pa+1L6x0k6qwXyFzba0nECCpvb07XcW+zg@mail.gmail.com>
Hi Kees,
On Thu, 15 Jun 2017 17:35:43 -0700 Kees Cook <keescook@chromium.org> wrote:
>
> Sounds good. I've added ARCH_HAS_FORTIFY_SOURCE to the patch (and noted it).
And that just made it in time for today's linux-next. I have removed
the patches from Andrew's tree.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: build failure after merge of the kspp tree
From: Stephen Rothwell @ 2017-06-16 1:30 UTC (permalink / raw)
To: Kees Cook
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Daniel Micay,
Andrew Morton
Hi Kees,
After merging the kspp tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from include/linux/bitmap.h:8:0,
from include/linux/cpumask.h:11,
from arch/x86/include/asm/cpumask.h:4,
from arch/x86/include/asm/msr.h:10,
from arch/x86/include/asm/processor.h:20,
from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:37,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:80,
from include/linux/spinlock.h:50,
from include/linux/mmzone.h:7,
from include/linux/gfp.h:5,
from include/linux/slab.h:14,
from drivers/scsi/csiostor/csio_lnode.c:37:
In function 'memcpy',
inlined from 'csio_append_attrib' at drivers/scsi/csiostor/csio_lnode.c:248:2,
inlined from 'csio_ln_fdmi_dprt_cbfn' at drivers/scsi/csiostor/csio_lnode.c:471:2:
include/linux/string.h:309:4: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter
__read_overflow2();
^
In function 'memcpy',
inlined from 'csio_append_attrib' at drivers/scsi/csiostor/csio_lnode.c:248:2,
inlined from 'csio_ln_fdmi_rhba_cbfn' at drivers/scsi/csiostor/csio_lnode.c:337:2:
include/linux/string.h:309:4: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter
__read_overflow2();
^
Caused by commit
b90d6eba50d7 ("include/linux/string.h: add the option of fortified string.h functions")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: build failure after merge of the sound-asoc tree
From: Stephen Rothwell @ 2017-06-16 2:04 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Christophe Jaillet
Hi all,
After merging the sound-asoc tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
sound/soc/rockchip/rockchip_i2s.c: In function 'rockchip_i2s_probe':
sound/soc/rockchip/rockchip_i2s.c:649:3: error: 'err' undeclared (first use in this function)
err = -ENOMEM;
^
Caused by commit
c3a3d3c41b74 ("ASoC: rockchip: Fix an error handling in 'rockchip_i2s_probe'")
I have used the sound-asoc tree from next-20170615 for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: linux-next: build failure after merge of the kspp tree
From: Daniel Micay @ 2017-06-16 2:51 UTC (permalink / raw)
To: Stephen Rothwell, Kees Cook
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Andrew Morton
In-Reply-To: <20170616113032.306720bf@canb.auug.org.au>
On Fri, 2017-06-16 at 11:30 +1000, Stephen Rothwell wrote:
> Hi Kees,
>
> After merging the kspp tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from include/linux/bitmap.h:8:0,
> from include/linux/cpumask.h:11,
> from arch/x86/include/asm/cpumask.h:4,
> from arch/x86/include/asm/msr.h:10,
> from arch/x86/include/asm/processor.h:20,
> from arch/x86/include/asm/cpufeature.h:4,
> from arch/x86/include/asm/thread_info.h:52,
> from include/linux/thread_info.h:37,
> from arch/x86/include/asm/preempt.h:6,
> from include/linux/preempt.h:80,
> from include/linux/spinlock.h:50,
> from include/linux/mmzone.h:7,
> from include/linux/gfp.h:5,
> from include/linux/slab.h:14,
> from drivers/scsi/csiostor/csio_lnode.c:37:
> In function 'memcpy',
> inlined from 'csio_append_attrib' at
> drivers/scsi/csiostor/csio_lnode.c:248:2,
> inlined from 'csio_ln_fdmi_dprt_cbfn' at
> drivers/scsi/csiostor/csio_lnode.c:471:2:
> include/linux/string.h:309:4: error: call to '__read_overflow2'
> declared with attribute error: detected read beyond size of object
> passed as 2nd parameter
> __read_overflow2();
> ^
> In function 'memcpy',
> inlined from 'csio_append_attrib' at
> drivers/scsi/csiostor/csio_lnode.c:248:2,
> inlined from 'csio_ln_fdmi_rhba_cbfn' at
> drivers/scsi/csiostor/csio_lnode.c:337:2:
> include/linux/string.h:309:4: error: call to '__read_overflow2'
> declared with attribute error: detected read beyond size of object
> passed as 2nd parameter
> __read_overflow2();
> ^
>
> Caused by commit
>
> b90d6eba50d7 ("include/linux/string.h: add the option of fortified
> string.h functions")
>
> I have reverted that commit for today.
That's this one: https://lkml.org/lkml/2017/5/9/613, which is in
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/ in the
4.13/scsi-queue and for-next branches. I think that's why Kees didn't
include it but I get he needs to add that.
^ permalink raw reply
* Re: linux-next: build failure after merge of the kspp tree
From: Daniel Micay @ 2017-06-16 2:52 UTC (permalink / raw)
To: Stephen Rothwell, Kees Cook
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Andrew Morton
In-Reply-To: <1497581467.17727.7.camel@gmail.com>
> https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/ in the
> 4.13/scsi-queue and for-next branches. I think that's why Kees didn't
> include it but I get he needs to add that.
s/get/guess/
Or is that repo supposed to get pulled into next?
^ permalink raw reply
* Re: linux-next: build failure after merge of the kspp tree
From: Kees Cook @ 2017-06-16 3:20 UTC (permalink / raw)
To: Daniel Micay
Cc: Stephen Rothwell, Linux-Next Mailing List,
Linux Kernel Mailing List, Andrew Morton
In-Reply-To: <1497581467.17727.7.camel@gmail.com>
On Thu, Jun 15, 2017 at 7:51 PM, Daniel Micay <danielmicay@gmail.com> wrote:
> On Fri, 2017-06-16 at 11:30 +1000, Stephen Rothwell wrote:
>> Hi Kees,
>>
>> After merging the kspp tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> In file included from include/linux/bitmap.h:8:0,
>> from include/linux/cpumask.h:11,
>> from arch/x86/include/asm/cpumask.h:4,
>> from arch/x86/include/asm/msr.h:10,
>> from arch/x86/include/asm/processor.h:20,
>> from arch/x86/include/asm/cpufeature.h:4,
>> from arch/x86/include/asm/thread_info.h:52,
>> from include/linux/thread_info.h:37,
>> from arch/x86/include/asm/preempt.h:6,
>> from include/linux/preempt.h:80,
>> from include/linux/spinlock.h:50,
>> from include/linux/mmzone.h:7,
>> from include/linux/gfp.h:5,
>> from include/linux/slab.h:14,
>> from drivers/scsi/csiostor/csio_lnode.c:37:
>> In function 'memcpy',
>> inlined from 'csio_append_attrib' at
>> drivers/scsi/csiostor/csio_lnode.c:248:2,
>> inlined from 'csio_ln_fdmi_dprt_cbfn' at
>> drivers/scsi/csiostor/csio_lnode.c:471:2:
>> include/linux/string.h:309:4: error: call to '__read_overflow2'
>> declared with attribute error: detected read beyond size of object
>> passed as 2nd parameter
>> __read_overflow2();
>> ^
>> In function 'memcpy',
>> inlined from 'csio_append_attrib' at
>> drivers/scsi/csiostor/csio_lnode.c:248:2,
>> inlined from 'csio_ln_fdmi_rhba_cbfn' at
>> drivers/scsi/csiostor/csio_lnode.c:337:2:
>> include/linux/string.h:309:4: error: call to '__read_overflow2'
>> declared with attribute error: detected read beyond size of object
>> passed as 2nd parameter
>> __read_overflow2();
>> ^
>>
>> Caused by commit
>>
>> b90d6eba50d7 ("include/linux/string.h: add the option of fortified
>> string.h functions")
>>
>> I have reverted that commit for today.
>
> That's this one: https://lkml.org/lkml/2017/5/9/613, which is in
> https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/ in the
> 4.13/scsi-queue and for-next branches. I think that's why Kees didn't
> include it but I get he needs to add that.
I'm so confused -- isn't this in next? All the build tests I did were
against yesterday's -next which includes this from what I can see...
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* linux-next: manual merge of the tip tree with the arm64 tree
From: Stephen Rothwell @ 2017-06-16 3:25 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Catalin Marinas
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Shiju Jose,
James Morse, Borislav Petkov, Tyler Baicar
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
drivers/acpi/apei/ghes.c
between commit:
d0189b2eef2e ("acpi: apei: handle SEA notification type for ARMv8")
from the arm64 tree and commit:
7bf130e4a065 ("ACPI/APEI: Handle GSIV and GPIO notification types")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/acpi/apei/ghes.c
index dfdb33f09f0a,d2c8a9286fa8..000000000000
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@@ -810,59 -718,10 +810,59 @@@ static int ghes_notify_hed(struct notif
return ret;
}
- static struct notifier_block ghes_notifier_sci = {
- .notifier_call = ghes_notify_sci,
+ static struct notifier_block ghes_notifier_hed = {
+ .notifier_call = ghes_notify_hed,
};
+#ifdef CONFIG_ACPI_APEI_SEA
+static LIST_HEAD(ghes_sea);
+
+/*
+ * Return 0 only if one of the SEA error sources successfully reported an error
+ * record sent from the firmware.
+ */
+int ghes_notify_sea(void)
+{
+ struct ghes *ghes;
+ int ret = -ENOENT;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(ghes, &ghes_sea, list) {
+ if (!ghes_proc(ghes))
+ ret = 0;
+ }
+ rcu_read_unlock();
+ return ret;
+}
+
+static void ghes_sea_add(struct ghes *ghes)
+{
+ mutex_lock(&ghes_list_mutex);
+ list_add_rcu(&ghes->list, &ghes_sea);
+ mutex_unlock(&ghes_list_mutex);
+}
+
+static void ghes_sea_remove(struct ghes *ghes)
+{
+ mutex_lock(&ghes_list_mutex);
+ list_del_rcu(&ghes->list);
+ mutex_unlock(&ghes_list_mutex);
+ synchronize_rcu();
+}
+#else /* CONFIG_ACPI_APEI_SEA */
+static inline void ghes_sea_add(struct ghes *ghes)
+{
+ pr_err(GHES_PFX "ID: %d, trying to add SEA notification which is not supported\n",
+ ghes->generic->header.source_id);
+}
+
+static inline void ghes_sea_remove(struct ghes *ghes)
+{
+ pr_err(GHES_PFX "ID: %d, trying to remove SEA notification which is not supported\n",
+ ghes->generic->header.source_id);
+}
+#endif /* CONFIG_ACPI_APEI_SEA */
+
#ifdef CONFIG_HAVE_ACPI_APEI_NMI
/*
* printk is not safe in NMI context. So in NMI handler, we allocate
@@@ -1096,15 -966,10 +1096,18 @@@ static int ghes_probe(struct platform_d
case ACPI_HEST_NOTIFY_POLLED:
case ACPI_HEST_NOTIFY_EXTERNAL:
case ACPI_HEST_NOTIFY_SCI:
+ case ACPI_HEST_NOTIFY_GSIV:
+ case ACPI_HEST_NOTIFY_GPIO:
break;
+ case ACPI_HEST_NOTIFY_SEA:
+ if (!IS_ENABLED(CONFIG_ACPI_APEI_SEA)) {
+ pr_warn(GHES_PFX "Generic hardware error source: %d notified via SEA is not supported\n",
+ generic->header.source_id);
+ rc = -ENOTSUPP;
+ goto err;
+ }
+ break;
+
case ACPI_HEST_NOTIFY_NMI:
if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_NMI)) {
pr_warn(GHES_PFX "Generic hardware error source: %d notified via NMI interrupt is not supported!\n",
@@@ -1162,16 -1027,17 +1165,20 @@@
goto err_edac_unreg;
}
break;
+
case ACPI_HEST_NOTIFY_SCI:
+ case ACPI_HEST_NOTIFY_GSIV:
+ case ACPI_HEST_NOTIFY_GPIO:
mutex_lock(&ghes_list_mutex);
- if (list_empty(&ghes_sci))
- register_acpi_hed_notifier(&ghes_notifier_sci);
- list_add_rcu(&ghes->list, &ghes_sci);
+ if (list_empty(&ghes_hed))
+ register_acpi_hed_notifier(&ghes_notifier_hed);
+ list_add_rcu(&ghes->list, &ghes_hed);
mutex_unlock(&ghes_list_mutex);
break;
+ case ACPI_HEST_NOTIFY_SEA:
+ ghes_sea_add(ghes);
+ break;
+
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_add(ghes);
break;
@@@ -1218,9 -1084,7 +1228,10 @@@ static int ghes_remove(struct platform_
mutex_unlock(&ghes_list_mutex);
synchronize_rcu();
break;
+ case ACPI_HEST_NOTIFY_SEA:
+ ghes_sea_remove(ghes);
+ break;
+
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_remove(ghes);
break;
^ permalink raw reply
* Re: linux-next: build failure after merge of the kspp tree
From: Stephen Rothwell @ 2017-06-16 3:31 UTC (permalink / raw)
To: Kees Cook
Cc: Daniel Micay, Linux-Next Mailing List, Linux Kernel Mailing List,
Andrew Morton
In-Reply-To: <CAGXu5j+gcoqVT6sA-_Eu-Nm5P+58FuVfW=yof1ufpXaZeXC8zA@mail.gmail.com>
Hi Kees,
On Thu, 15 Jun 2017 20:20:47 -0700 Kees Cook <keescook@google.com> wrote:
>
> I'm so confused -- isn't this in next? All the build tests I did were
> against yesterday's -next which includes this from what I can see...
It is in next, but gets merged after the kspp tree ... so, this is when
inter-tree dependencies are a pain - I can merge the kspp tree later,
but then you have to remember which trees Linus must merge before you
send your pull request. That's why we like to have all trees be
effectively stand alone (as much as possible).
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: [Oops][next-20170614][] powerpc boot fails with WARNING: CPU: 12 PID: 0 at mm/memblock.c
From: Stephen Rothwell @ 2017-06-16 3:32 UTC (permalink / raw)
To: Michael Ellerman
Cc: Rowand, Frank, Abdul Haleem, sachinp, linux-next, linux-kernel,
linuxppc-dev, Rob Herring
In-Reply-To: <20170616111335.4e1a818a@canb.auug.org.au>
Hi all,
On Fri, 16 Jun 2017 11:13:35 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Fri, 16 Jun 2017 10:57:22 +1000 Michael Ellerman <mpe@ellerman.id.au> wrote:
> >
> > "Rowand, Frank" <Frank.Rowand@sony.com> writes:
> >
> > > On Thursday, June 15, 2017 2:25 AM, Abdul Haleem [mailto:abdhalee@linux.vnet.ibm.com] wrote:
> > >>
> > >> On Thu, 2017-06-15 at 11:30 +0530, Abdul Haleem wrote:
> > >>>
> > >>> linux-next fails to boot on powerpc Bare-metal with these warnings.
> > >>>
> > >>> machine booted fine on next-20170613
> > >>
> > >> Thanks Michael, Yes it is (75fe04e59 of: remove *phandle properties from
> > >> expanded device tree)
> > >>
> > >> Frank, would you please take a look at the trace.
> > >>
> > >> Thanks
> > >
> > > < snip >
> > >
> > > My patch series 'of: remove *phandle properties from expanded device tree'
> > > in -next seems to have broken boot for a significant number of powerpc
> > > systems. I am actively working on understanding and fixing the problem.
> >
> > Thanks.
> >
> > At least for me reverting that patch on top of linux-next gets things
> > booting again.
> >
> > Stephen can you revert that patch in linux-next today?
>
> OK.
Actually, Rob removed it from his tree before I merged it.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: linux-next: build warning after merge of the wireless-drivers tree
From: Kalle Valo @ 2017-06-16 5:07 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Wireless, Linux-Next Mailing List, Linux Kernel Mailing List,
Arend Van Spriel
In-Reply-To: <20170616082507.1e824796@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> After merging the wireless-drivers tree, today's linux-next build
> (x86_64 allmodconfig) produced this warning:
>
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c: In function
> 'brcmf_usb_probe_phase2':
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c:1198:2:
> warning: 'devinfo' may be used uninitialized in this function
> [-Wmaybe-uninitialized]
> mutex_unlock(&devinfo->dev_init_lock);
> ^
>
> Introduced by commit
>
> 6d0507a777fb ("brcmfmac: add parameter to pass error code in firmware callback")
Thanks, for the report. I also noticed this, only after I had applied
the patch, but hopefully Arend sends a patch to fix this soon.
--
Kalle Valo
^ permalink raw reply
* linux-next: manual merge of the uuid tree with the arm64 tree
From: Stephen Rothwell @ 2017-06-16 5:21 UTC (permalink / raw)
To: Christoph Hellwig, Catalin Marinas
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Andy Shevchenko, Tyler Baicar, Will Deacon
Hi all,
Today's linux-next merge of the uuid tree got conflicts in:
drivers/acpi/apei/ghes.c
include/uapi/linux/uuid.h
between commits:
f4dccde3f9b9 ("ras: acpi/apei: cper: add support for generic data v3 structure")
476e4940c251 ("ras: acpi / apei: generate trace event for unrecognized CPER section")
8a0456ea3dec ("trace, ras: add ARM processor error trace event")
from the arm64 tree and commit:
60927bc31436 ("uuid: remove uuid_be defintions from the uapi header")
f9727a17db9b ("uuid: rename uuid types")
5b53696a30d5 ("ACPI / APEI: Switch to use new generic UUID API")
from the uuid tree.
I really can't fix this up, so can you guys get together and sort this
out, please.
For today, I have just dropped the uuid tree, sorry.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox