* Re: linux-next: manual merge of the kvms390 tree with the kvm-mips tree
From: James Hogan @ 2017-03-29 9:21 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Christian Borntraeger, Cornelia Huck, linux-next, linux-kernel,
Fan Zhang, Paolo Bonzini, Radim Krčmář
In-Reply-To: <20170329140832.5cbfb6ce@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 2277 bytes --]
On Wed, Mar 29, 2017 at 02:08:32PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the kvms390 tree got a conflict in:
>
> include/uapi/linux/kvm.h
>
> between commits:
>
> a8a3c426772e ("KVM: MIPS: Add VZ & TE capabilities")
> 578fd61d2d21 ("KVM: MIPS: Add 64BIT capability")
>
> from the kvm-mips tree and commit:
>
> 4e0b1ab72b8a ("KVM: s390: gs support for kvm guests")
>
> from the kvms390 tree.
>
> It looks like someone needs to arbitrate on these KVM_CAP_ numbers ...
>
> 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 include/uapi/linux/kvm.h
> index 1e1a6c728a18,c9d522765f8f..000000000000
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@@ -887,9 -883,7 +887,10 @@@ struct kvm_ppc_resize_hpt
> #define KVM_CAP_PPC_MMU_RADIX 134
> #define KVM_CAP_PPC_MMU_HASH_V3 135
> #define KVM_CAP_IMMEDIATE_EXIT 136
> -#define KVM_CAP_S390_GS 137
> +#define KVM_CAP_MIPS_VZ 137
> +#define KVM_CAP_MIPS_TE 138
> +#define KVM_CAP_MIPS_64BIT 139
> ++#define KVM_CAP_S390_GS 140
>
> #ifdef KVM_CAP_IRQ_ROUTING
Thanks Stephen,
Cc'ing Paulo and Radim.
This does seem a bit of a conflict magnet, and they're part of the user
ABI so when the values change upon merge, the intermediate versions
before and after require different userland builds.
Should the numbering be decided in advance somehow (i.e. in response to
conflicts in linux-next)? I don't particularly want to change the
numbering again as others would need rebuilds again, but I only just
pushed the MIPS changes, so if I change the MIPS numbering to 138-140,
can we expect other branches to continue at 141 so I don't need to
change them again?
Alternatively does it make sense to have different ranges reserved for
different architectures (like the get one reg numbers)?
Cheers
James
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the xen-tip tree with the tip tree
From: Juergen Gross @ 2017-03-29 9:28 UTC (permalink / raw)
To: Ingo Molnar, Boris Ostrovsky
Cc: Stephen Rothwell, Konrad Rzeszutek Wilk, Stefano Stabellini,
Xen Devel, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, linux-next, linux-kernel, Vitaly Kuznetsov,
Andy Lutomirski, Mathias Krause, Thomas Garnier
In-Reply-To: <20170329085945.GA11382@gmail.com>
On 29/03/17 10:59, Ingo Molnar wrote:
>
> * Juergen Gross <jgross@suse.com> wrote:
>
>> On 29/03/17 05:35, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Today's linux-next merge of the xen-tip tree got a conflict in:
>>>
>>> arch/x86/xen/enlighten.c
>>>
>>> between commits:
>>>
>>> 6415813bae75 ("x86/cpu: Drop wp_works_ok member of struct cpuinfo_x86")
>>> 69218e47994d ("x86: Remap GDT tables in the fixmap section")
>>> b23adb7d3f7d ("x86/xen/gdt: Use X86_FEATURE_XENPV instead of globals for the GDT fixup")
>>>
>>> from the tip tree and commits:
>>>
>>> 75cd32d6093e ("x86/xen: split off enlighten_pv.c")
>>>
>>> from the xen-tip tree.
>>>
>>> I dropped the xen-tip tree for today (see other conflict reports),
>>> please get together and sort these out, thanks.
>>>
>>
>> Hmm, seems to be a rather bad timing for the series of Vitaly.
>>
>> What is the best way to resolve those conflicts? A rebase of Vitaly's
>> patches seems to be required in any case.
>>
>> Should I rebase the Xen tree on current tip? This seems to be rather
>> easy, but I think this will work only if I can be sure the current tip
>> tree contents will all be merged by Linus before the Xen tree.
>
> That's certainly very likely, -tip trees all go in very early in the merge window.
>
>> I could try to cherry pick the patches from tip where Vitaly's patches
>> have conflicts with, but I think this could lead to a lot of patches
>> to take.
>
> Nor is it desirable as a workflow.
>
> I'd suggest the following: in about a week I can guarantee a working tip:x86/mm
> base with most of the 5-level paging patches applied that you could base Xen
> patches on.
>
> Unfortunately, right now there's at least one regression with those changes that
> needs to be properly fixed before it's a suitable base tree. The fix already
> exists, it just needs to be tested and the whole tree needs to cook for a few days
> to be dependable for Xen as a base.
>
>> Or we could delay Vitaly's series until tip has been merged, but this
>> will either delay some other Xen patches depending on (or conflicting
>> with) Vitaly's patches or would make the rebase for Vitaly more
>> difficult.
>
> So my suggestion would be: could you delay 75cd32d6093e for a week, and then merge
> it on top of a pulled in tip:x86/mm? I'll send that tree to Linus on the first day
> of the merge window so there shouldn't be any ordering problems.
Okay, that's rather easy to do.
Boris, I renamed the current Xen for-linus-4.12 branch for easy
development of other Xen patches to for-linus-4.12-pre.
I'll create another branch for-linus-4.12 based on the tip tree next
week which will be subject to the pull request for Linus. As soon as
for-linus-4.12 is ready the for-linus-4.12-pre branch shouldn't be used
any longer.
Juergen
^ permalink raw reply
* Re: linux-next: manual merge of the kvms390 tree with the kvm-mips tree
From: Christian Borntraeger @ 2017-03-29 9:29 UTC (permalink / raw)
To: James Hogan, Stephen Rothwell
Cc: Cornelia Huck, linux-next, linux-kernel, Fan Zhang, Paolo Bonzini,
Radim Krčmář
In-Reply-To: <20170329092112.GV31606@jhogan-linux.le.imgtec.org>
On 03/29/2017 11:21 AM, James Hogan wrote:
> On Wed, Mar 29, 2017 at 02:08:32PM +1100, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the kvms390 tree got a conflict in:
>>
>> include/uapi/linux/kvm.h
>>
>> between commits:
>>
>> a8a3c426772e ("KVM: MIPS: Add VZ & TE capabilities")
>> 578fd61d2d21 ("KVM: MIPS: Add 64BIT capability")
>>
>> from the kvm-mips tree and commit:
>>
>> 4e0b1ab72b8a ("KVM: s390: gs support for kvm guests")
>>
>> from the kvms390 tree.
>>
>> It looks like someone needs to arbitrate on these KVM_CAP_ numbers ...
>>
>> 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 include/uapi/linux/kvm.h
>> index 1e1a6c728a18,c9d522765f8f..000000000000
>> --- a/include/uapi/linux/kvm.h
>> +++ b/include/uapi/linux/kvm.h
>> @@@ -887,9 -883,7 +887,10 @@@ struct kvm_ppc_resize_hpt
>> #define KVM_CAP_PPC_MMU_RADIX 134
>> #define KVM_CAP_PPC_MMU_HASH_V3 135
>> #define KVM_CAP_IMMEDIATE_EXIT 136
>> -#define KVM_CAP_S390_GS 137
>> +#define KVM_CAP_MIPS_VZ 137
>> +#define KVM_CAP_MIPS_TE 138
>> +#define KVM_CAP_MIPS_64BIT 139
>> ++#define KVM_CAP_S390_GS 140
>>
>> #ifdef KVM_CAP_IRQ_ROUTING
>
> Thanks Stephen,
>
> Cc'ing Paulo and Radim.
>
> This does seem a bit of a conflict magnet, and they're part of the user
> ABI so when the values change upon merge, the intermediate versions
> before and after require different userland builds.
>
> Should the numbering be decided in advance somehow (i.e. in response to
> conflicts in linux-next)? I don't particularly want to change the
> numbering again as others would need rebuilds again, but I only just
> pushed the MIPS changes, so if I change the MIPS numbering to 138-140,
> can we expect other branches to continue at 141 so I don't need to
> change them again?
>
> Alternatively does it make sense to have different ranges reserved for
> different architectures (like the get one reg numbers)?
I can live with a changing GS capability number, so keep your number.
In the end I think Radim/Paolo will do the assigment when merging.
And no userspace should rely on this before this is at least in kvm/next
Yes, this will be a bit of pain for internal QA, but this worked ok
for the last 3 or 4 years on our side
^ permalink raw reply
* Re: linux-next: manual merge of the kvms390 tree with the kvm-mips tree
From: Paolo Bonzini @ 2017-03-29 9:47 UTC (permalink / raw)
To: Christian Borntraeger, James Hogan, Stephen Rothwell
Cc: Cornelia Huck, linux-next, linux-kernel, Fan Zhang,
Radim Krčmář
In-Reply-To: <7115ff68-df06-10e0-6fff-e040a222a5e8@de.ibm.com>
On 29/03/2017 11:29, Christian Borntraeger wrote:
>>> -#define KVM_CAP_S390_GS 137
>>> +#define KVM_CAP_MIPS_VZ 137
>>> +#define KVM_CAP_MIPS_TE 138
>>> +#define KVM_CAP_MIPS_64BIT 139
>>> ++#define KVM_CAP_S390_GS 140
>>>
>>> #ifdef KVM_CAP_IRQ_ROUTING
>> Thanks Stephen,
>>
>> Cc'ing Paulo and Radim.
>>
>> This does seem a bit of a conflict magnet, and they're part of the user
>> ABI so when the values change upon merge, the intermediate versions
>> before and after require different userland builds.
>>
>> Should the numbering be decided in advance somehow (i.e. in response to
>> conflicts in linux-next)? I don't particularly want to change the
>> numbering again as others would need rebuilds again, but I only just
>> pushed the MIPS changes, so if I change the MIPS numbering to 138-140,
>> can we expect other branches to continue at 141 so I don't need to
>> change them again?
Yes, that can be expected. If you don't do it, I'll bump the capability
number as soon as I get the conflict.
If it's an issue, the solution is topic branches: as soon as you need a
capability, fire a pull request so that it gets in kvm/next. But it
doesn't happen too often, the last times were in 4.1, 4.6 and 4.8 (three
times in 2 years).
>> Alternatively does it make sense to have different ranges reserved for
>> different architectures (like the get one reg numbers)?
>
> I can live with a changing GS capability number, so keep your number.
> In the end I think Radim/Paolo will do the assigment when merging.
Yes---and in that case it's first come first served.
Same for ioctls, though those change even more rarely.
Paolo
> And no userspace should rely on this before this is at least in kvm/next
> Yes, this will be a bit of pain for internal QA, but this worked ok
> for the last 3 or 4 years on our side
^ permalink raw reply
* Re: linux-next: manual merge of the xen-tip tree with the tip tree
From: Juergen Gross @ 2017-03-29 9:54 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Ingo Molnar, Konrad Rzeszutek Wilk, Stefano Stabellini,
Boris Ostrovsky, Xen Devel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel,
Vitaly Kuznetsov, Andy Lutomirski, Mathias Krause, Thomas Garnier
In-Reply-To: <20170329085945.GA11382@gmail.com>
On 29/03/17 10:59, Ingo Molnar wrote:
>
> * Juergen Gross <jgross@suse.com> wrote:
>
>> On 29/03/17 05:35, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Today's linux-next merge of the xen-tip tree got a conflict in:
>>>
>>> arch/x86/xen/enlighten.c
>>>
>>> between commits:
>>>
>>> 6415813bae75 ("x86/cpu: Drop wp_works_ok member of struct cpuinfo_x86")
>>> 69218e47994d ("x86: Remap GDT tables in the fixmap section")
>>> b23adb7d3f7d ("x86/xen/gdt: Use X86_FEATURE_XENPV instead of globals for the GDT fixup")
>>>
>>> from the tip tree and commits:
>>>
>>> 75cd32d6093e ("x86/xen: split off enlighten_pv.c")
>>>
>>> from the xen-tip tree.
>>>
>>> I dropped the xen-tip tree for today (see other conflict reports),
>>> please get together and sort these out, thanks.
Stephen, I have rewound the linux-next branch of xen-tip to its previous
position. You can re-enable xen-tip.
Juergen
^ permalink raw reply
* Re: linux-next: manual merge of the xen-tip tree with the tip tree
From: Vitaly Kuznetsov @ 2017-03-29 10:06 UTC (permalink / raw)
To: Juergen Gross
Cc: Ingo Molnar, Boris Ostrovsky, Stephen Rothwell,
Konrad Rzeszutek Wilk, Stefano Stabellini, Xen Devel,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
linux-next, linux-kernel, Andy Lutomirski, Mathias Krause,
Thomas Garnier
In-Reply-To: <26fb88f9-dd20-c56b-e87d-6d454b4f7c71@suse.com>
Juergen Gross <jgross@suse.com> writes:
> On 29/03/17 10:59, Ingo Molnar wrote:
>>
>> * Juergen Gross <jgross@suse.com> wrote:
>>
>>> On 29/03/17 05:35, Stephen Rothwell wrote:
>>>> Hi all,
>>>>
>>>> Today's linux-next merge of the xen-tip tree got a conflict in:
>>>>
>>>> arch/x86/xen/enlighten.c
>>>>
>>>> between commits:
>>>>
>>>> 6415813bae75 ("x86/cpu: Drop wp_works_ok member of struct cpuinfo_x86")
>>>> 69218e47994d ("x86: Remap GDT tables in the fixmap section")
>>>> b23adb7d3f7d ("x86/xen/gdt: Use X86_FEATURE_XENPV instead of globals for the GDT fixup")
>>>>
>>>> from the tip tree and commits:
>>>>
>>>> 75cd32d6093e ("x86/xen: split off enlighten_pv.c")
>>>>
>>>> from the xen-tip tree.
>>>>
>>>> I dropped the xen-tip tree for today (see other conflict reports),
>>>> please get together and sort these out, thanks.
>>>>
>>>
>>> Hmm, seems to be a rather bad timing for the series of Vitaly.
>>>
>>> What is the best way to resolve those conflicts? A rebase of Vitaly's
>>> patches seems to be required in any case.
>>>
>>> Should I rebase the Xen tree on current tip? This seems to be rather
>>> easy, but I think this will work only if I can be sure the current tip
>>> tree contents will all be merged by Linus before the Xen tree.
>>
>> That's certainly very likely, -tip trees all go in very early in the merge window.
>>
>>> I could try to cherry pick the patches from tip where Vitaly's patches
>>> have conflicts with, but I think this could lead to a lot of patches
>>> to take.
>>
>> Nor is it desirable as a workflow.
>>
>> I'd suggest the following: in about a week I can guarantee a working tip:x86/mm
>> base with most of the 5-level paging patches applied that you could base Xen
>> patches on.
>>
>> Unfortunately, right now there's at least one regression with those changes that
>> needs to be properly fixed before it's a suitable base tree. The fix already
>> exists, it just needs to be tested and the whole tree needs to cook for a few days
>> to be dependable for Xen as a base.
>>
>>> Or we could delay Vitaly's series until tip has been merged, but this
>>> will either delay some other Xen patches depending on (or conflicting
>>> with) Vitaly's patches or would make the rebase for Vitaly more
>>> difficult.
>>
>> So my suggestion would be: could you delay 75cd32d6093e for a week, and then merge
>> it on top of a pulled in tip:x86/mm? I'll send that tree to Linus on the first day
>> of the merge window so there shouldn't be any ordering problems.
>
> Okay, that's rather easy to do.
>
> Boris, I renamed the current Xen for-linus-4.12 branch for easy
> development of other Xen patches to for-linus-4.12-pre.
>
> I'll create another branch for-linus-4.12 based on the tip tree next
> week which will be subject to the pull request for Linus. As soon as
> for-linus-4.12 is ready the for-linus-4.12-pre branch shouldn't be used
> any longer.
Please let me know if/when I need to rebase my series. I'll rebase, test
and re-send.
Thanks!
--
Vitaly
^ permalink raw reply
* next-20170329 build: 0 failures 6 warnings (next-20170329)
From: Build bot for Mark Brown @ 2017-03-29 10:14 UTC (permalink / raw)
To: kernel-build-reports, linaro-kernel, linux-next
Tree/Branch: next-20170329
Git describe: next-20170329
Commit: 8f8ab14f44 Add linux-next specific files for 20170329
Build Time: 114 min 50 sec
Passed: 10 / 10 (100.00 %)
Failed: 0 / 10 ( 0.00 %)
Errors: 0
Warnings: 6
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
2 warnings 0 mismatches : arm64-allmodconfig
4 warnings 0 mismatches : arm-multi_v7_defconfig
-------------------------------------------------------------------------------
Warnings Summary: 6
1 arch/arm/configs/multi_v7_defconfig:600:warning: symbol value 'm' invalid for ROCKCHIP_INNO_HDMI
1 arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' invalid for ROCKCHIP_DW_MIPI_DSI
1 arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' invalid for ROCKCHIP_DW_HDMI
1 arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' invalid for ROCKCHIP_ANALOGIX_DP
1 ../include/uapi/linux/byteorder/big_endian.h:32:26: warning: large integer implicitly truncated to unsigned type [-Woverflow]
1 ../drivers/misc/aspeed-lpc-ctrl.c:232:17: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t {aka long long unsigned int}' [-Wformat=]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allmodconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
../include/uapi/linux/byteorder/big_endian.h:32:26: warning: large integer implicitly truncated to unsigned type [-Woverflow]
../drivers/misc/aspeed-lpc-ctrl.c:232:17: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t {aka long long unsigned int}' [-Wformat=]
-------------------------------------------------------------------------------
arm-multi_v7_defconfig : PASS, 0 errors, 4 warnings, 0 section mismatches
Warnings:
arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' invalid for ROCKCHIP_ANALOGIX_DP
arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' invalid for ROCKCHIP_DW_HDMI
arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' invalid for ROCKCHIP_DW_MIPI_DSI
arch/arm/configs/multi_v7_defconfig:600:warning: symbol value 'm' invalid for ROCKCHIP_INNO_HDMI
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
arm64-allnoconfig
arm-multi_v5_defconfig
x86_64-defconfig
arm-allmodconfig
arm-allnoconfig
x86_64-allnoconfig
arm-multi_v4t_defconfig
arm64-defconfig
^ permalink raw reply
* Re: linux-next: manual merge of the xen-tip tree with the tip tree
From: Ingo Molnar @ 2017-03-29 10:41 UTC (permalink / raw)
To: Juergen Gross
Cc: Stephen Rothwell, Konrad Rzeszutek Wilk, Stefano Stabellini,
Boris Ostrovsky, Xen Devel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel,
Vitaly Kuznetsov, Andy Lutomirski, Mathias Krause, Thomas Garnier
In-Reply-To: <04988941-7db8-1579-ce77-a1be25a55eb4@suse.com>
* Juergen Gross <jgross@suse.com> wrote:
> On 29/03/17 10:59, Ingo Molnar wrote:
> >
> > * Juergen Gross <jgross@suse.com> wrote:
> >
> >> On 29/03/17 05:35, Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>> Today's linux-next merge of the xen-tip tree got a conflict in:
> >>>
> >>> arch/x86/xen/enlighten.c
> >>>
> >>> between commits:
> >>>
> >>> 6415813bae75 ("x86/cpu: Drop wp_works_ok member of struct cpuinfo_x86")
> >>> 69218e47994d ("x86: Remap GDT tables in the fixmap section")
> >>> b23adb7d3f7d ("x86/xen/gdt: Use X86_FEATURE_XENPV instead of globals for the GDT fixup")
> >>>
> >>> from the tip tree and commits:
> >>>
> >>> 75cd32d6093e ("x86/xen: split off enlighten_pv.c")
> >>>
> >>> from the xen-tip tree.
> >>>
> >>> I dropped the xen-tip tree for today (see other conflict reports),
> >>> please get together and sort these out, thanks.
>
> Stephen, I have rewound the linux-next branch of xen-tip to its previous
> position. You can re-enable xen-tip.
Thank you!
Ingo
^ permalink raw reply
* Re: linux-next: manual merge of the xen-tip tree with the tip tree
From: Stephen Rothwell @ 2017-03-29 11:13 UTC (permalink / raw)
To: Juergen Gross
Cc: Ingo Molnar, Konrad Rzeszutek Wilk, Stefano Stabellini,
Boris Ostrovsky, Xen Devel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel,
Vitaly Kuznetsov, Andy Lutomirski, Mathias Krause, Thomas Garnier
In-Reply-To: <04988941-7db8-1579-ce77-a1be25a55eb4@suse.com>
Hi Juergen,
On Wed, 29 Mar 2017 11:54:57 +0200 Juergen Gross <jgross@suse.com> wrote:
>
> Stephen, I have rewound the linux-next branch of xen-tip to its previous
> position. You can re-enable xen-tip.
Thanks, it should be all good tomorrow.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: linux-next: manual merge of the kvms390 tree with the kvm-mips tree
From: James Hogan @ 2017-03-29 11:25 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Stephen Rothwell, Cornelia Huck, linux-next, linux-kernel,
Fan Zhang, Paolo Bonzini, Radim Krčmář
In-Reply-To: <7115ff68-df06-10e0-6fff-e040a222a5e8@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3072 bytes --]
On Wed, Mar 29, 2017 at 11:29:00AM +0200, Christian Borntraeger wrote:
> On 03/29/2017 11:21 AM, James Hogan wrote:
> > On Wed, Mar 29, 2017 at 02:08:32PM +1100, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> Today's linux-next merge of the kvms390 tree got a conflict in:
> >>
> >> include/uapi/linux/kvm.h
> >>
> >> between commits:
> >>
> >> a8a3c426772e ("KVM: MIPS: Add VZ & TE capabilities")
> >> 578fd61d2d21 ("KVM: MIPS: Add 64BIT capability")
> >>
> >> from the kvm-mips tree and commit:
> >>
> >> 4e0b1ab72b8a ("KVM: s390: gs support for kvm guests")
> >>
> >> from the kvms390 tree.
> >>
> >> It looks like someone needs to arbitrate on these KVM_CAP_ numbers ...
> >>
> >> 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 include/uapi/linux/kvm.h
> >> index 1e1a6c728a18,c9d522765f8f..000000000000
> >> --- a/include/uapi/linux/kvm.h
> >> +++ b/include/uapi/linux/kvm.h
> >> @@@ -887,9 -883,7 +887,10 @@@ struct kvm_ppc_resize_hpt
> >> #define KVM_CAP_PPC_MMU_RADIX 134
> >> #define KVM_CAP_PPC_MMU_HASH_V3 135
> >> #define KVM_CAP_IMMEDIATE_EXIT 136
> >> -#define KVM_CAP_S390_GS 137
> >> +#define KVM_CAP_MIPS_VZ 137
> >> +#define KVM_CAP_MIPS_TE 138
> >> +#define KVM_CAP_MIPS_64BIT 139
> >> ++#define KVM_CAP_S390_GS 140
> >>
> >> #ifdef KVM_CAP_IRQ_ROUTING
> >
> > Thanks Stephen,
> >
> > Cc'ing Paulo and Radim.
> >
> > This does seem a bit of a conflict magnet, and they're part of the user
> > ABI so when the values change upon merge, the intermediate versions
> > before and after require different userland builds.
> >
> > Should the numbering be decided in advance somehow (i.e. in response to
> > conflicts in linux-next)? I don't particularly want to change the
> > numbering again as others would need rebuilds again, but I only just
> > pushed the MIPS changes, so if I change the MIPS numbering to 138-140,
> > can we expect other branches to continue at 141 so I don't need to
> > change them again?
> >
> > Alternatively does it make sense to have different ranges reserved for
> > different architectures (like the get one reg numbers)?
>
> I can live with a changing GS capability number, so keep your number.
Okay, thanks
> In the end I think Radim/Paolo will do the assigment when merging.
> And no userspace should rely on this before this is at least in kvm/next
> Yes, this will be a bit of pain for internal QA, but this worked ok
> for the last 3 or 4 years on our side
Yeh, thats all it is, a bit of a pain, and probably just deserts for
having stuff out of tree for any length of time :)
Cheers
James
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* 35950 linux-next
From: t2dnature @ 2017-03-29 21:12 UTC (permalink / raw)
To: linux-next
[-- Attachment #1: 9907257.zip --]
[-- Type: application/zip, Size: 2605 bytes --]
^ permalink raw reply
* linux-next: unsigned commits in the kvm tree
From: Stephen Rothwell @ 2017-03-29 22:21 UTC (permalink / raw)
To: Marcelo Tosatti, Gleb Natapov, KVM
Cc: linux-next, linux-kernel, Paolo Bonzini
Hi all,
I noticed that several commits in the kvm tree
(git://git.kernel.org/pub/scm/virt/kvm/kvm.git#linux-next) today have
no Signed-off-by for their committer :-(
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: manual merge of the vfs tree with Linus' tree
From: Stephen Rothwell @ 2017-03-30 0:07 UTC (permalink / raw)
To: Al Viro
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Josef Bacik,
Jens Axboe
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in:
drivers/block/nbd.c
between commit:
9dd5d3ab49f7 ("nbd: handle ERESTARTSYS properly")
from Linus' tree and commit:
7c09d0a53c27 ("backmerge of nbd.c changes, resolving conflicts")
from the vfs tree.
I fixed it up (I used the former change) 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.
Its probably time that the vfs tree was cleaned up after the last merge
window.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: manual merge of the drm tree with the drm-intel-fixes tree
From: Stephen Rothwell @ 2017-03-30 1:08 UTC (permalink / raw)
To: Dave Airlie, Daniel Vetter, Intel Graphics, DRI
Cc: Jani Nikula, Linux-Next Mailing List, Linux Kernel Mailing List
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/intel_lrc.c
between commit:
dd68f2ba0720 ("drm/i915/execlists: Wrap tail pointer after reset tweaking")
from the drm-intel-fixes tree and commit:
944a36d472be ("drm/i915: Assert that the request->tail is always qword aligned")
from the drm 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/gpu/drm/i915/intel_lrc.c
index 91555d4e9129,77168e673e0a..000000000000
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@@ -1440,9 -1268,8 +1268,10 @@@ static void reset_common_ring(struct in
GEM_BUG_ON(request->ctx != port[0].request->ctx);
/* Reset WaIdleLiteRestore:bdw,skl as well */
- request->tail = request->wa_tail - WA_TAIL_DWORDS * sizeof(u32);
+ request->tail =
+ intel_ring_wrap(request->ring,
+ request->wa_tail - WA_TAIL_DWORDS*sizeof(u32));
+ GEM_BUG_ON(!IS_ALIGNED(request->tail, 8));
}
static int intel_logical_ring_emit_pdps(struct drm_i915_gem_request *req)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* linux-next: manual merge of the drm tree with the drm-intel-fixes tree
From: Stephen Rothwell @ 2017-03-30 1:14 UTC (permalink / raw)
To: Dave Airlie, Daniel Vetter, Intel Graphics, DRI
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Chris Wilson,
Jani Nikula, Tvrtko Ursulin
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/intel_ringbuffer.h
between commit:
dd68f2ba0720 ("drm/i915/execlists: Wrap tail pointer after reset tweaking")
from the drm-intel-fixes tree and commit:
73dec95e6ba3 ("drm/i915: Emit to ringbuffer directly")
from the drm 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/gpu/drm/i915/intel_ringbuffer.h
index 8cb2078c5bfc,847aea554464..000000000000
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@@ -522,19 -525,14 +525,20 @@@ intel_ring_advance(struct drm_i915_gem_
}
static inline u32
+intel_ring_wrap(const struct intel_ring *ring, u32 pos)
+{
+ return pos & (ring->size - 1);
+}
+
- static inline u32 intel_ring_offset(struct intel_ring *ring, void *addr)
++static inline u32
+ intel_ring_offset(struct drm_i915_gem_request *req, void *addr)
{
/* Don't write ring->size (equivalent to 0) as that hangs some GPUs. */
- u32 offset = addr - ring->vaddr;
- return intel_ring_wrap(ring, offset);
+ u32 offset = addr - req->ring->vaddr;
+ GEM_BUG_ON(offset > req->ring->size);
- return offset & (req->ring->size - 1);
++ return intel_ring_wrap(req->ring, offset);
}
- int __intel_ring_space(int head, int tail, int size);
void intel_ring_update_space(struct intel_ring *ring);
void intel_engine_init_global_seqno(struct intel_engine_cs *engine, u32 seqno);
^ permalink raw reply
* Re: linux-next: manual merge of the tty tree with the tty.current tree
From: Michael Neuling @ 2017-03-30 3:46 UTC (permalink / raw)
To: Dmitry Vyukov; +Cc: Greg KH, linux-next, LKML, Peter Hurley, Stephen Rothwell
In-Reply-To: <CACT4Y+YvkT0dVhM3fG_cnaMA_guNAt28dvzhbgyXtowDD7oBaw@mail.gmail.com>
On Mon, 2017-03-20 at 10:26 +0100, Dmitry Vyukov wrote:
> On Mon, Mar 20, 2017 at 10:21 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> > On Mon, Mar 20, 2017 at 3:28 AM, Stephen Rothwell <sfr@canb.auug.org.au>
> > wrote:
> > > Hi Greg,
> > >
> > > Today's linux-next merge of the tty tree got a conflict in:
> > >
> > > drivers/tty/tty_ldisc.c
> > >
> > > between commit:
> > >
> > > 5362544bebe8 ("tty: don't panic on OOM in tty_set_ldisc()")
> > >
> > > from the tty.current tree and commit:
> > >
> > > 71472fa9c52b ("tty: Fix ldisc crash on reopened tty")
> > >
> > > from the tty 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/tty/tty_ldisc.c
> > > index b0500a0a87b8,4ee7742dced3..000000000000
> > > --- a/drivers/tty/tty_ldisc.c
> > > +++ b/drivers/tty/tty_ldisc.c
> > > @@@ -621,14 -669,17 +621,15 @@@ int tty_ldisc_reinit(struct tty_struct
> > > tty_ldisc_put(tty->ldisc);
> > > }
> > >
> > > - /* switch the line discipline */
> > > - tty->ldisc = ld;
> > > tty_set_termios_ldisc(tty, disc);
> > > - retval = tty_ldisc_open(tty, tty->ldisc);
> > > + retval = tty_ldisc_open(tty, ld);
> > > if (retval) {
> > > - tty_ldisc_put(tty->ldisc);
> > > - tty->ldisc = NULL;
> > > - if (!WARN_ON(disc == N_TTY)) {
> > > - tty_ldisc_put(ld);
> > > - ld = NULL;
> > > - }
> > > ++ tty_ldisc_put(ld);
> > > ++ ld = NULL;
> > > }
> > > +
> > > + /* switch the line discipline */
> > > + smp_store_release(&tty->ldisc, ld);
> > > return retval;
> > > }
> > >
> >
> >
> > Peter,
> >
> > Looking at your patch "tty: Fix ldisc crash on reopened tty", I think
> > there is a missed barrier in tty_ldisc_ref. A single barrier does not
> > have any effect, they always need to be in pairs. So I think we also
> > need at least:
> >
> > @@ -295,7 +295,8 @@ struct tty_ldisc *tty_ldisc_ref(struct tty_struct *tty)
> > struct tty_ldisc *ld = NULL;
> >
> > if (ldsem_down_read_trylock(&tty->ldisc_sem)) {
> > - ld = tty->ldisc;
> > + ld = READ_ONCE(tty->ldisc);
> > + read_barrier_depends();
> > if (!ld)
> > ldsem_up_read(&tty->ldisc_sem);
> > }
> >
> >
> > Or simply:
> >
> > @@ -295,7 +295,8 @@ struct tty_ldisc *tty_ldisc_ref(struct tty_struct *tty)
> > struct tty_ldisc *ld = NULL;
> >
> > if (ldsem_down_read_trylock(&tty->ldisc_sem)) {
> > - ld = tty->ldisc;
> > + /* pairs with smp_store_release in tty_ldisc_reinit */
> > + ld = smp_load_acquire(&tty->ldisc);
> > if (!ld)
> > ldsem_up_read(&tty->ldisc_sem);
> > }
>
>
>
>
> I am also surprised that callers of tty_ldisc_reinit don't hold
> ldisc_sem. I thought that ldisc_sem is what's supposed to protect
> changes to ldisc. That would also auto fix the crash without any
> tricky barriers as flush_to_ldisc uses tty_ldisc_ref.
Dmitry,
Thanks for the help. Peter doesn't seem to be responding to email any more.
I'm not familiar with the tty layer, but the issue that patch was suppose to fix
had a similar signature to the below oops we are seeing on powerpc on boot.
(sorry I don't have a repro on mainline or linux-next). Hence why I pushed on
it.
In the below crash the call to tty_ldisc_reinit is coming from a workqueue, so
requiring the callers to hold the ldisc_sem is more tricky.
Could we just hold the ldisc_sem inside tty_ldisc_reinit()?
Regards,
Mikey
[ 9.021567] Unable to handle kernel paging request for data at address 0x00002260
[ 9.022501] Faulting instruction address: 0xc0000000006c7770
[ 9.023105] Oops: Kernel access of bad area, sig: 11 [#1]
[ 9.023674] SMP NR_CPUS=2048
[ 9.023676] NUMA
[ 9.023970] PowerNV
[ 9.024372] Modules linked in: ofpart cmdlinepart ipmi_powernv powernv_flash ipmi_devintf mtd ipmi_msghandler ibmpowernv opal_prd uio_pdrv_genirq uio vmx_crypto ip_tables x_tables autofs4 ast i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt crc32c_vpmsum fb_sys_fops drm ahci libahci tg3
[ 9.027146] CPU: 15 PID: 354 Comm: kworker/u64:2 Not tainted 4.10.0-8-generic #10-Ubuntu
[ 9.027978] Workqueue: events_unbound flush_to_ldisc
[ 9.028468] task: c0000016a7758c00 task.stack: c0000000fd084000
[ 9.029055] NIP: c0000000006c7770 LR: c0000000006c7758 CTR: c0000000006c84b0
[ 9.029767] REGS: c0000000fd0878c0 TRAP: 0300 Not tainted (4.10.0-8-generic)
[ 9.030520] MSR: 900000000280b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE>
[ 9.030537] CR: 28002888 XER: 00000000
[ 9.031579] CFAR: c000000000b3e20c DAR: 0000000000002260 DSISR: 40000000 SOFTE: 1
[ 9.031579] GPR04: c000000002ac8c20 c000000002ac8d20 0000000000000100 0000000000000001
[ 9.031579] GPR12: 0000000028002888 c00000000fb88700 c0000000000f6668 c0000016b4b7e3c0
[ 9.031579] GPR20: 0000000000000000 0000000000000000 c000000001335ce9 0000000100000000
[ 9.031579] GPR28: c000000002ac8d20 0000000000000100 c0000016a8dca608 c0000016ae0ebc00
[ 9.031579] GPR00: c0000000006c7758 c0000000fd087b40 c00000000143c900 0000000000000000
[ 9.031579] GPR08: c0000016ae0ebcc0 0000000000000001 c00000000139a5a0 c0000016a7758ca8
[ 9.031579] GPR16: c0000016c90322d8 c0000016c9032090 c0000016c9032020 0000000000000001
[ 9.031579] GPR24: 0000000000000000 0000000000000000 c000000002ac8c20 c0000016b4f932a0
[ 9.038511] NIP [c0000000006c7770] n_tty_receive_buf_common+0xb0/0xdf0
[ 9.039139] LR [c0000000006c7758] n_tty_receive_buf_common+0x98/0xdf0
[ 9.039766] Call Trace:
[ 9.040009] [c0000000fd087b40] [c0000000006c7758] n_tty_receive_buf_common+0x98/0xdf0 (unreliable)
[ 9.040868] [c0000000fd087c10] [c0000000006cc524] tty_ldisc_receive_buf+0x44/0xe0
[ 9.041595] [c0000000fd087c40] [c0000000006ccd9c] flush_to_ldisc+0x13c/0x160
[ 9.042265] [c0000000fd087c90] [c0000000000ed8c0] process_one_work+0x2b0/0x5a0
[ 9.042955] [c0000000fd087d20] [c0000000000edc58] worker_thread+0xa8/0x650
[ 9.043625] [c0000000fd087dc0] [c0000000000f67b4] kthread+0x154/0x1a0
[ 9.044245] [c0000000fd087e30] [c00000000000b4e8] ret_from_kernel_thread+0x5c/0x74
[ 9.044964] Instruction dump:
[ 9.045281] eb3f0260 7c9a2378 7cbc2b78 7cdd3378 f8e10030 48476a55 60000000 3b000000
[ 9.046128] 7af783e4 60000000 60000000 60420000 7c2004ac e8d90000 80ff0110
[ 9.047044] ---[ end trace 6b3bf4b72485f95c ]---
[ 9.047485]
^ permalink raw reply
* linux-next: build failure after merge of the phy-next tree
From: Stephen Rothwell @ 2017-03-30 3:47 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Meng Dongyang
Hi Kishon,
After merging the phy-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/phy/phy-rockchip-inno-usb2.c:1148:3: error: unknown field 'phy_tuning' specified in initializer
.phy_tuning = rk3328_usb2phy_tuning,
^
drivers/phy/phy-rockchip-inno-usb2.c:1148:17: error: 'rk3328_usb2phy_tuning' undeclared here (not in a function)
.phy_tuning = rk3328_usb2phy_tuning,
^
Caused by commit
ffa0c278e89c ("phy: rockchip-inno-usb2: add support of u2phy for rk3328")
I have used the phy-next tree from next-20170329 for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: build failure after merge of the vhost tree
From: Stephen Rothwell @ 2017-03-30 4:25 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List
Hi Michael,
After merging the vhost tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/remoteproc/remoteproc_virtio.c: In function 'rproc_virtio_find_vqs':
drivers/remoteproc/remoteproc_virtio.c:148:9: error: 'ctx' undeclared (first use in this function)
ctx ? ctx[i] : false);
^
Caused by commit
a965e977a103 ("virtio: add context flag to find vqs")
I have used the vhost tree from next-20170329 for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: linux-next: build failure after merge of the phy-next tree
From: Kishon Vijay Abraham I @ 2017-03-30 5:39 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Meng Dongyang
In-Reply-To: <20170330144735.534101e7@canb.auug.org.au>
Hi,
On Thursday 30 March 2017 09:17 AM, Stephen Rothwell wrote:
> Hi Kishon,
>
> After merging the phy-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/phy/phy-rockchip-inno-usb2.c:1148:3: error: unknown field 'phy_tuning' specified in initializer
> .phy_tuning = rk3328_usb2phy_tuning,
> ^
> drivers/phy/phy-rockchip-inno-usb2.c:1148:17: error: 'rk3328_usb2phy_tuning' undeclared here (not in a function)
> .phy_tuning = rk3328_usb2phy_tuning,
> ^
>
> Caused by commit
>
> ffa0c278e89c ("phy: rockchip-inno-usb2: add support of u2phy for rk3328")
>
> I have used the phy-next tree from next-20170329 for today.
Thanks for reporting this. Will fix it in my tree.
-Kishon
^ permalink raw reply
* linux-next: Tree for Mar 30
From: Stephen Rothwell @ 2017-03-30 5:55 UTC (permalink / raw)
To: Linux-Next Mailing List; +Cc: Linux Kernel Mailing List
Hi all,
Changes since 20170329:
Undropped tree: xen-tip
The vfs tree gained a conflict against Linus' tree.
The drm tree gained conflicts against the drm-intel-fixes tree.
The mailbox tree lost its build failure.
The phy-next tree gained a build failure, so I used the version from
next-20170329.
The vhost tree gained a build failure, so I used the version from
next-20170329.
Non-merge commits (relative to Linus' tree): 5728
6122 files changed, 441716 insertions(+), 108564 deletions(-)
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.
Below is a summary of the state of the merge.
I am currently merging 255 trees (counting Linus' and 37 trees of bug
fix patches pending for the current merge release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (806276b7f07a Merge branch 'for-linus' of git://git.kernel.dk/linux-block)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (9be3213b14d4 gconfig: remove misleading parentheses around a condition)
Merging arc-current/for-curr (ae9955aeb8e4 ARC: vdk: Fix support of UIO)
Merging arm-current/fixes (a1016e94cce9 ARM: wire up statx syscall)
Merging m68k-current/for-linus (e3b1ebd67387 m68k: Wire up statx)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (cc638a488a52 gcc-plugins: update architecture list in documentation)
Merging sparc/master (0ae2d26ffe70 arch/sparc: Avoid DCTI Couples)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and linking special files)
Merging net/master (8f1f7eeb22c1 Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf)
Merging ipsec/master (72ef9c4125c7 dccp: fix memory leak during tear-down of unsuccessful connection request)
Merging netfilter/master (77c1c03c5b8e netfilter: nfnetlink_queue: fix secctx memory leak)
Merging ipvs/master (5371bbf4b295 net: bcmgenet: Do not suspend PHY if Wake-on-LAN is enabled)
Merging wireless-drivers/master (6be3b6cce1e2 ath10k: fix incorrect wlan_mac_base in qca6174_regs)
Merging mac80211/master (7d65f82954da mac80211: unconditionally start new netdev queues with iTXQ support)
Merging sound-current/for-linus (2d7d54002e39 ALSA: seq: Fix race during FIFO resize)
Merging pci-current/for-linus (9abb27c7594a PCI: thunder-pem: Add legacy firmware support for Cavium ThunderX host controller)
Merging driver-core.current/driver-core-linus (c02ed2e75ef4 Linux 4.11-rc4)
Merging tty.current/tty-linus (c02ed2e75ef4 Linux 4.11-rc4)
Merging usb.current/usb-linus (a7f12a21f6b3 usb: phy: isp1301: Fix build warning when CONFIG_OF is disabled)
Merging usb-gadget-fixes/fixes (25cd9721c2b1 usb: gadget: f_hid: fix: Don't access hidg->req without spinlock held)
Merging usb-serial-fixes/usb-linus (c02ed2e75ef4 Linux 4.11-rc4)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move the lock initialization to core file)
Merging phy/fixes (1a09b6a7c10e phy: qcom-usb-hs: Add depends on EXTCON)
Merging staging.current/staging-linus (c02ed2e75ef4 Linux 4.11-rc4)
Merging char-misc.current/char-misc-linus (c02ed2e75ef4 Linux 4.11-rc4)
Merging input-current/for-linus (5659495a7a14 uapi: add missing install of userio.h)
Merging crypto-current/master (9df0eb180c20 crypto: xts,lrw - fix out-of-bounds write after kmalloc failure)
Merging ide/master (96297aee8bce ide: palm_bk3710: add __initdata to palm_bk3710_port_info)
Merging vfio-fixes/for-linus (65b1adebfe43 vfio: Rework group release notifier warning)
Merging kselftest-fixes/fixes (c1ae3cfa0e89 Linux 4.11-rc1)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: Handle EPROBE_DEFER while requesting the PWM)
Merging ftrace-fixes/for-next-urgent (6224beb12e19 tracing: Have branch tracer use recursive field of task struct)
Merging mfd-fixes/for-mfd-fixes (1a41741fd60b mfd: wm8994-core: Don't use managed regulator bulk get API)
Merging v4l-dvb-fixes/fixes (24a47426066c [media] exynos-gsc: Do not swap cb/cr for semi planar formats)
Merging drm-intel-fixes/for-linux-next-fixes (dd68f2ba0720 drm/i915/execlists: Wrap tail pointer after reset tweaking)
Merging drm-misc-fixes/for-linux-next-fixes (c02ed2e75ef4 Linux 4.11-rc4)
Merging kbuild/for-next (e68966e4f52e Merge branch 'uapi' into for-next)
CONFLICT (content): Merge conflict in include/uapi/linux/Kbuild
Merging asm-generic/master (de4be6b87b6b asm-generic: page.h: fix comment typo)
CONFLICT (content): Merge conflict in include/asm-generic/percpu.h
Merging arc/for-next (d5adbfcd5f7b Linux 4.10-rc7)
Merging arm/for-next (2bc6cdda1e32 Merge branches 'fixes' and 'misc' into for-next)
Merging arm-perf/for-next/perf (0c744ea4f77d Linux 4.10-rc2)
Merging arm-soc/for-next (d0c2152bb96e Merge branch 'fixes' into for-next)
CONFLICT (content): Merge conflict in arch/arm/boot/dts/r7s72100.dtsi
Merging alpine/alpine/for-next (a1144b2b1ec4 ARM: dts: alpine: add valid clock-frequency values)
Merging amlogic/for-next (585bfd0195cc Merge branch 'v4.12/drivers' into tmp/aml-rebuild)
Merging aspeed/for-next (ab15e12960f1 Merge branches 'defconfig-for-v4.11', 'soc-for-v4.11' and 'dt-for-v4.11' into for-next)
Merging at91/at91-next (7e9d7a321996 Merge branch 'at91-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux into at91-next)
Merging bcm2835/for-next (7ea6e490ba7f Merge branch anholt/bcm2835-defconfig-64-next into for-next)
Merging berlin/berlin/for-next (5153351425c9 Merge branch 'berlin/dt' into berlin/for-next)
Merging cortex-m/for-next (f719a0d6a854 ARM: efm32: switch to vendor,device compatible strings)
Merging imx-mxs/for-next (00c0ffa8545a Merge branch 'zte/dt64' into for-next)
Merging keystone/next (9e07c85a01ec Merge branch 'for_4.11/keystone_dts' into next)
Merging mvebu/for-next (69cbc9086459 Merge branch 'mvebu/dt64' into mvebu/for-next)
Merging omap/for-next (272f590cf2cd Merge branch 'omap-for-v4.12/defconfig' into for-next)
Merging omap-pending/for-next (c20c8f750d9f ARM: OMAP2+: hwmod: fix _idle() hwmod state sanity check sequence)
Merging qcom/for-next (9f514b0f9cf3 Merge branch 'drivers-for-4.12' into all-for-4.12)
Merging renesas/next (a1aca88887e6 Merge branch 'dt-for-v4.12' into next)
Merging rockchip/for-next (db2636b14ef1 Merge branch 'v4.12-armsoc/dts32' into for-next)
Merging rpi/for-rpi-next (bc0195aad0da Linux 4.2-rc2)
Merging samsung/for-next (1001354ca341 Linux 4.9-rc1)
Merging samsung-krzk/for-next (ece32e531453 Merge branch 'next/dt' into for-next)
Merging tegra/for-next (cc516494e180 Merge branch for-4.12/clk into for-next)
Merging arm64/for-next/core (29d981217a5d arm64: drop unnecessary newlines in show_regs())
Merging clk/clk-next (6b265e5eec86 Merge branch 'clk-meson' into clk-next)
Merging c6x/for-linux-next (ca3060d39ae7 c6x: Use generic clkdev.h header)
Merging cris/for-next (8f50f2a1b46a cris: No need to append -O2 and $(LINUXINCLUDE))
Merging h8300/h8300-next (58c57526711f h8300: Add missing include file to asm/io.h)
Merging hexagon/linux-next (02cc2ccfe771 Revert "Hexagon: fix signal.c compile error")
Merging ia64/next (fbb0e4da96f4 ia64: salinfo: use a waitqueue instead a sema down/up combo)
Merging m68k/for-next (3dfe33020ca8 m68k/sun3: Remove dead code in paging_init())
Merging m68knommu/for-next (c02ed2e75ef4 Linux 4.11-rc4)
Merging metag/for-next (f5d163aad31e metag: perf: fix build on Meta1)
Merging microblaze/next (3400606d8ffd microblaze: Add new fpga families)
Merging mips/mips-for-linux-next (d72c4a87e3df Merge branch 'linus' into mips-for-linux-next)
Merging nios2/for-next (744606c76c4a nios2: add screen_info)
Merging openrisc/for-next (a4d442663580 openrisc: head: Init r0 to 0 on start)
Merging parisc-hd/for-next (476e75a44b56 parisc: Avoid stalled CPU warnings after system shutdown)
Merging powerpc/next (c7e790c5f4c3 powerpc/64s: POWER8 add missing machine check definitions)
Merging fsl/next (75b824727680 powerpc/8xx: Perf events on PPC 8xx)
Merging mpc5xxx/next (39e69f55f857 powerpc: Introduce the use of the managed version of kzalloc)
Merging s390/features (ed849015a1a8 s390/uaccess: get_user() should zero on failure (again))
CONFLICT (content): Merge conflict in arch/s390/include/uapi/asm/Kbuild
Merging sparc-next/master (9f935675d41a Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
Merging sh/for-next (e61c10e468a4 sh: add device tree source for J2 FPGA on Mimas v2 board)
Merging tile/master (34649f72b628 tile: prefer <arch/intreg.h> to __need_int_reg_t)
Merging uml/linux-next (f88f0bdfc32f um: UBD Improvements)
Merging unicore32/unicore32 (bc27113620ca unicore32-oldabi: add oldabi syscall interface)
Merging xtensa/xtensa-for-next (ec59c4ad070d Merge branch 'xtensa-boot' into xtensa-for-next)
Merging fscrypt/master (94840e3c802d fscrypt: eliminate ->prepare_context() operation)
Merging befs/for-next (0bbabf98dd76 befs: make export work with cold dcache)
Merging btrfs/next (8b8b08cbfb90 Btrfs: fix delalloc accounting after copy_from_user faults)
Merging btrfs-kdave/for-next (17f4309ad30e Merge branch 'for-next-next-v4.12-20170328' into for-next-20170328)
Merging ceph/master (633ee407b9d1 libceph: force GFP_NOIO for socket allocations)
Merging cifs/for-next (70c1da060b51 cifs: remove unused code)
Merging configfs/for-next (e16769d4bca6 fs: configfs: don't return anything from drop_link)
Merging ecryptfs/next (be280b25c328 ecryptfs: remove private bin2hex implementation)
Merging ext3/for_next (ab4949640d66 reiserfs: avoid a -Wmaybe-uninitialized warning)
Merging ext4/dev (d67d64f42314 ext4: fix two spelling nits)
Merging f2fs/dev (0d675a968bf9 f2fs: avoid IO split due to mixed WB_SYNC_ALL and WB_SYNC_NONE)
Merging freevxfs/for-next (bf1bb4b460c8 freevxfs: update Kconfig information)
Merging fscache/fscache (d52bd54db8be Merge branch 'akpm' (patches from Andrew))
Merging fuse/for-next (9a87ad3da905 fuse: release: private_data cannot be NULL)
Merging gfs2/for-next (307c3320a929 Revert "GFS2: Wait for iopen glock dequeues")
CONFLICT (content): Merge conflict in net/core/secure_seq.c
CONFLICT (content): Merge conflict in drivers/net/usb/r8152.c
CONFLICT (content): Merge conflict in drivers/net/hyperv/netvsc.c
CONFLICT (content): Merge conflict in drivers/net/ethernet/broadcom/genet/bcmmii.c
Merging jfs/jfs-next (684666e51585 jfs: atomically read inode size)
Merging nfs/linux-next (97da3854c526 Linux 4.11-rc3)
Merging nfsd/nfsd-next (4544f5d6f165 uapi: fix linux/nfsd/cld.h userspace compilation errors)
Merging orangefs/for-next (e98bdb3059cb Merge tag 'v4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into for-next)
Merging overlayfs/overlayfs-next (b1eaa950f7e9 ovl: lockdep annotate of nested stacked overlayfs inode lock)
Merging v9fs/for-next (a333e4bf2556 fs/9p: use fscache mutex rather than spinlock)
Merging ubifs/linux-next (1cb51a15b576 ubifs: Fix journal replay wrt. xattr nodes)
Merging xfs/for-next (8d242e932fb7 xfs: remove XFS_ALLOCTYPE_ANY_AG and XFS_ALLOCTYPE_START_AG)
Merging file-locks/linux-next (07d9a380680d Linux 4.9-rc2)
Merging vfs/for-next (9e9c5ba8bd70 Merge branch 'work.statx' into for-next)
CONFLICT (content): Merge conflict in samples/Kconfig
CONFLICT (content): Merge conflict in fs/proc/base.c
CONFLICT (content): Merge conflict in fs/f2fs/f2fs.h
CONFLICT (content): Merge conflict in drivers/block/nbd.c
Applying: smc: merge fix for "switch socket ->splice_read() to struct file *"
Merging vfs-jk/vfs (030b533c4fd4 fs: Avoid premature clearing of capabilities)
Merging vfs-miklos/next (0eb8af4916a5 vfs: use helper for calling f_op->fsync())
Merging printk/for-next (64ca752dcbc0 printk: use console_trylock() in console_cpu_notify())
Merging pci/next (d0ec4e67c924 Merge branch 'pci/switchtec' into next)
Merging pstore/for-next/pstore (eec50d76a6ee pstore: Drop needless inode lock during population)
Merging hid/for-next (04e2e78ca134 Merge branch 'for-4.11/upstream-fixes' into for-next)
Merging i2c/i2c/for-next (346e400cfceb i2c: thunderx: ACPI support for clock settings)
Merging jdelvare-hwmon/master (08d27eb20666 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging dmi/master (0c744ea4f77d Linux 4.10-rc2)
Merging hwmon-staging/hwmon-next (95e15d573eaa hwmon: (dell-smm) Add Dell XPS 15 9560 into DMI list)
Merging jc_docs/docs-next (97e4e959c928 pci-error-recovery: doc cleanup)
Merging v4l-dvb/master (c3d4fb0fb41f [media] rc: sunxi-cir: simplify optional reset handling)
Merging v4l-dvb-next/master (432ac2d4acef Merge branch 'v4l_for_linus' into to_next)
Merging fbdev/fbdev-for-next (6f9655b1b81f drivers/video: Convert remaining uses of pr_warning to pr_warn)
Merging pm/linux-next (d80f9e89239b Merge branches 'acpi-hotplug-fixes', 'acpi-build-fixes' and 'acpi-apei-fixes' into linux-next)
Merging idle/next (306899f94804 x86 tsc: Add the Intel Denverton Processor to native_calibrate_tsc())
Merging thermal/next (f7b553c688c3 Merge branches 'for-rc' and 'thermal-core' into next)
Merging thermal-soc/next (c02ed2e75ef4 Linux 4.11-rc4)
Merging ieee1394/for-next (72f3c27aa646 firewire: net: max MTU off by one)
Merging dlm/next (c0ae14857677 dlm: Fix kernel memory disclosure)
Merging swiotlb/linux-next (69369f52d28a swiotlb-xen: implement xen_swiotlb_get_sgtable callback)
Merging net-next/master (397df7092a15 Merge branch '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue)
Merging ipsec-next/master (6c786bcb29dd xfrm: branchless addr4_match() on 64-bit)
Merging netfilter-next/master (592d42ac7fd3 Merge branch 'qed-IOV-cleanups')
Merging ipvs-next/master (3c679cba588a ipvs: Document sysctl pmtu_disc)
Merging wireless-drivers-next/master (41977e86c984 rt2x00: add support for MT7620)
Merging bluetooth/master (39e9fd07e8d1 Bluetooth: hci_intel: add missing tty-device sanity check)
Merging mac80211-next/master (667a2e6bfeaf mac80211-hwsim: remove dmesg spam about get-survey.)
Merging rdma/for-next (9294000d6d89 IB/srp: Drain the send queue before destroying a QP)
Merging mtd/master (d91f6cee98b6 mtd: aspeed: remove redundant dev_err call in aspeed_smc_probe())
Merging l2-mtd/master (d91f6cee98b6 mtd: aspeed: remove redundant dev_err call in aspeed_smc_probe())
Merging nand/nand/next (cf733602f143 mtd: nand: Remove unused chip->write_page() hook)
Merging spi-nor/next (9f3cd4537da0 drivers mtd: spi-nor: add Macronix MX25Ux033E and MX25Ux035 variants)
Merging crypto/master (796b40c61714 crypto: ixp4xx - Use sg_virt())
Merging drm/drm-next (8bcad07a4563 drm/i915/gvt: fix error return check for copy_gma_to_hva())
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_ringbuffer.h
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_lrc.c
Merging drm-panel/drm/panel/for-next (eaeebffa90f3 drm/panel: simple: Specify bus width and flags for EDT displays)
Merging drm-intel/for-linux-next (2f075565e32b drm/i915: Use LINEAR modifier instead of NONE)
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_ringbuffer.h
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_lrc.c
Merging drm-tegra/drm/tegra/for-next (0725ed651da1 drm/tegra: Add tiling FB modifiers)
CONFLICT (content): Merge conflict in drivers/gpu/drm/tegra/drm.c
Merging drm-misc/for-linux-next (b33b02707ba3 drm: Peek at the current counter/timestamp for vblank queries)
Merging drm-exynos/exynos-drm/for-next (7d1e04231461 Merge tag 'usercopy-v4.8-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux)
Merging drm-msm/msm-next (849f0512efc9 msm/drm: gpu: Dynamically locate the clocks from the device tree)
Merging hdlcd/for-upstream/hdlcd (1de3cd4fb49f drm: hdlcd: Fix the calculation of the scanout start address)
Merging mali-dp/for-upstream/mali-dp (cda0c3ce3297 drm: mali-dp: remove unused variable)
Merging sunxi/sunxi/for-next (99d98d1b3e3d Merge branches 'sunxi/clk-fixes-for-4.11', 'sunxi/clk-for-4.12', 'sunxi/config64-for-4.12', 'sunxi/core-for-4.12', 'sunxi/defconfig-for-4.12', 'sunxi/drm-for-4.12', 'sunxi/dt-for-4.12', 'sunxi/fixes-for-4.11', 'sunxi/dt-split-h3-for-4.12' and 'sunxi/dt-split-h5-for-4.12' into sunxi/for-next)
Merging kspp/for-next/kspp (9b5e50a16f07 security/Kconfig: further restrict HARDENED_USERCOPY)
CONFLICT (content): Merge conflict in include/drm/drm_drv.h
Merging kconfig/for-next (5bcba792bb30 localmodconfig: Fix whitespace repeat count after "tristate")
Merging regmap/for-next (bbbed1951704 Merge remote-tracking branches 'regmap/topic/doc' and 'regmap/topic/rbtree' into regmap-next)
Merging sound/for-next (5992e30034c4 ALSA: firewire-motu: add support for MOTU 828mk3 (FireWire/Hybrid) as a model with protocol version 3)
Merging sound-asoc/for-next (ae21fa3c8662 Merge remote-tracking branch 'asoc/topic/zte-tdm' into asoc-next)
Merging modules/modules-next (5bd933fe4481 module: set .init_array alignment to 8)
Merging input/next (7e7113f77ef2 dt-bindings: input: touchscreen: add max11801-ts binding)
Merging block/for-next (bab5db7c9133 Merge branch 'for-4.12/block' into for-next)
Merging lightnvm/for-next (e57ef816cf77 Merge branch 'for-4.11/block' into for-next)
Merging device-mapper/for-next (1e2d2e22d47c Merge branch 'dm-4.11' into dm-next)
Merging pcmcia/master (e8e68fd86d22 pcmcia: do not break rsrc_nonstatic when handling anonymous cards)
Merging mmc/next (a645cc1df4ff mmc: bcm2835: Fix possible NULL ptr dereference in bcm2835_request)
Merging kgdb/kgdb-next (7a6653fca500 kdb: Fix handling of kallsyms_symbol_next() return value)
Merging md/for-next (8fc04e6ea02d md: raid1: kill warning on powerpc_pseries)
CONFLICT (content): Merge conflict in drivers/md/raid5.h
Merging mfd/for-mfd-next (7ca7babfd27f mfd: palmas: Reset the POWERHOLD mux during power off)
Merging backlight/for-backlight-next (80e5d455339a MAINTAINERS: Rework entry for Backlight)
Merging battery/for-next (5782dcb20370 power: supply: bq24190_charger: Don't spam the logs on charger plug / unplug)
Merging omap_dss2/for-next (c456a2f30de5 video: smscufx: remove unused variable)
Merging regulator/for-next (a130241de244 Merge remote-tracking branches 'regulator/topic/notifier', 'regulator/topic/pfuze100' and 'regulator/topic/twl6030' into regulator-next)
Merging security/next (e4e55b47ed9a LSM: Revive security_task_alloc() hook and per "struct task_struct" security blob.)
Merging integrity/next (3dd0c8d06511 ima: provide ">" and "<" operators for fowner/uid/euid rules.)
Merging keys/keys-next (ed51e44e914c Merge branch 'keys-asym-keyctl' into keys-next)
Merging selinux/next (342e91578eb6 selinux: Remove unnecessary check of array base in selinux_set_mapping())
Merging tpmdd/next (8c76c41d0700 tpm/tpm_crb: Enable TPM CRB interface for ARM64)
Merging watchdog/master (00ea1ceebe0d ipv6: release dst on error in ip6_dst_lookup_tail)
Merging iommu/next (41346dad4de0 Merge branches 'x86/vt-d', 'arm/core', 'core' and 'iommu/fixes' into next)
Merging dwmw2-iommu/master (910170442944 iommu/vt-d: Fix PASID table allocation)
Merging vfio/next (d9d84780f17c vfio: fix a typo in comment of function vfio_pin_pages)
Merging trivial/for-next (4f6cce39105e Fix dead URLs to ftp.kernel.org)
Merging audit/next (36fe46d172e5 audit: normalize NETFILTER_PKT)
CONFLICT (content): Merge conflict in net/netfilter/xt_AUDIT.c
Merging devicetree/for-next (8654cb8d0371 dtc: update warning settings for new bus and node/property name checks)
Merging mailbox/mailbox-for-next (73874913d504 mailbox: Remove depends on COMPILE_TEST for BCM_FLEXRM_MBOX)
Merging spi/for-next (782c67e1885d Merge remote-tracking branches 'spi/topic/test', 'spi/topic/ti-qspi' and 'spi/topic/xlp' into spi-next)
Merging tip/auto-latest (ea532dfc5423 Merge branch 'x86/vdso')
Merging clockevents/clockevents/next (f947ee147e08 clocksource/drivers/arm_arch_timer: Map frame with of_io_request_and_map())
Merging edac/linux_next (345fb0a9a634 Merge tag 'edac_for_4.11' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp)
Merging edac-amd/for-next (41003396f932 EDAC, thunderx: Add Cavium ThunderX EDAC driver)
Merging irqchip/irqchip/for-next (c1ae3cfa0e89 Linux 4.11-rc1)
Merging ftrace/for-next (65a50c656276 ftrace/graph: Add ftrace_graph_max_depth kernel parameter)
Merging rcu/rcu/next (fd6f7b882ba7 srcu: Introduce CLASSIC_SRCU Kconfig option)
Applying: drm/i915: merge fix for "mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU"
Merging kvm/linux-next (e55fe3ccccc1 tools/kvm_stat: add '%Total' column)
Merging kvm-arm/next (255905e4ff0f KVM: arm/arm64: vgic: Improve sync_hwstate performance)
Merging kvm-mips/next (dc44abd6aad2 KVM: MIPS/Emulate: Properly implement TLBR for T&E)
Merging kvm-ppc/kvm-ppc-next (bcd3bb63dbc8 KVM: PPC: Book3S HV: Disable HPT resizing on POWER9 for now)
Merging kvms390/next (4e0b1ab72b8a KVM: s390: gs support for kvm guests)
CONFLICT (content): Merge conflict in include/uapi/linux/kvm.h
Merging xen-tip/linux-next (d825adb48cf9 xenbus: Remove duplicate inclusion of linux/init.h)
Merging percpu/for-next (8a1df543de8a percpu: remove unused chunk_alloc parameter from pcpu_get_pages())
Merging workqueues/for-next (bacb71fc9187 Merge branch 'for-4.12' into for-next)
Merging drivers-x86/for-next (b68049014a82 platform/x86: silead_dmi: Add entry for Insyde 7W tablets)
Merging chrome-platform/for-next (31b764171cb5 Revert "platform/chrome: chromeos_laptop: Add Leon Touch")
Merging hsi/for-next (7ac5d7b1a125 HSI: hsi_char.h: use __u32 from linux/types.h)
Merging leds/for-next (cd3b0b05328e leds: cpcap: new driver)
CONFLICT (content): Merge conflict in drivers/platform/x86/dell-laptop.c
Merging ipmi/for-next (31151bf07a52 ipmi: bt-bmc: Add ast2500 compatible string)
Merging driver-core/driver-core-next (96fb7e256a06 Merge 4.11-rc4 into driver-core-next)
Merging usb/usb-next (2f86a96be0cc USB: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously)
Merging usb-gadget/next (c02ed2e75ef4 Linux 4.11-rc4)
Merging usb-serial/usb-next (bc242fc107c7 USB: serial: drop termios-flag debugging)
Merging usb-chipidea-next/ci-for-usb-next (4f4555cfe704 usb: chipidea: udc: update gadget state after bus resume)
Merging phy-next/next (ffa0c278e89c phy: rockchip-inno-usb2: add support of u2phy for rk3328)
$ git reset --hard HEAD^
Merging next-20170329 version of phy-next
Merging tty/tty-next (53c1cf428178 Merge 4.11-rc4 into tty-next)
Merging char-misc/char-misc-next (57c0eabbd57e Merge 4.11-rc4 into char-misc-next)
CONFLICT (content): Merge conflict in drivers/char/tpm/tpm-chip.c
Merging extcon/extcon-next (8e45fd9e7326 extcon: Remove porting compatibility of swich class)
Merging staging/staging-next (a2e99e973931 Staging: lustre: lnet: code style fix)
Merging mux/for-next (5238347fea92 mux: adg792a: add mux controller driver for ADG792A/G)
Merging slave-dma/next (12366c3e2345 Merge branch 'topic/pl330' into next)
Merging cgroup/for-next (2b29fbe02b78 Merge branch 'for-4.12' into for-next)
Merging scsi/for-next (b945f543b2a0 Merge branch 'misc' into for-next)
Merging scsi-mkp/for-next (dbd34a61c343 Revert "scsi: ufs: add queries retry mechanism")
Merging target-updates/for-next (98fec7793703 iscsi-target: Propigate queue_data_in + queue_status errors)
Merging target-merge/for-next-merge (2994a7518317 cxgb4: update Kconfig and Makefile)
Merging target-bva/for-next (762b6f00a995 uapi: fix linux/target_core_user.h userspace compilation errors)
Merging libata/for-next (0a7d2635b8cf Merge branch 'for-4.12' into for-next)
Merging binfmt_misc/for-next (4af75df6a410 binfmt_misc: add F option description to documentation)
Merging vhost/linux-next (d01047cb281d virtio_console: fix uninitialized variable use)
$ git reset --hard HEAD^
Merging next-20170329 version of vhost
Merging rpmsg/for-next (5e78de7eee74 Merge branches 'hwspinlock-next', 'rpmsg-next' and 'rproc-next' into for-next)
Merging gpio/for-next (a1d5fab14d42 Merge branch 'devel' into for-next)
CONFLICT (content): Merge conflict in drivers/input/misc/soc_button_array.c
Merging pinctrl/for-next (7c795e971856 Merge branch 'devel' into for-next)
Merging pinctrl-samsung/for-next (786b1f7c95d7 Merge branch 'pinctrl-next' into for-next)
Merging dma-mapping/dma-mapping-next (1001354ca341 Linux 4.9-rc1)
Merging pwm/for-next (38b0a526ec33 Merge branch 'for-4.11/drivers' into for-next)
Merging dma-buf/for-next (194cad44c4e1 dma-buf/sync_file: improve Kconfig description for Sync Files)
CONFLICT (content): Merge conflict in drivers/dma-buf/Kconfig
Merging userns/for-next (040757f738e1 ucount: Remove the atomicity from ucount->count)
Merging ktest/for-next (f7c6401ff84a ktest: Make sure wait_for_input does honor the timeout)
Merging random/dev (db61ffe3a71c random: move random_min_urandom_seed into CONFIG_SYSCTL ifdef block)
Merging aio/master (b562e44f507e Linux 4.5)
Merging kselftest/next (c1ae3cfa0e89 Linux 4.11-rc1)
Merging y2038/y2038 (69973b830859 Linux 4.9)
Merging luto-misc/next (2dcd0af568b0 Linux 4.6)
Merging borntraeger/linux-next (e76d21c40bd6 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging livepatching/for-next (10517429b5ac livepatch: make klp_mutex proper part of API)
CONFLICT (content): Merge conflict in include/linux/sched.h
CONFLICT (content): Merge conflict in include/linux/init_task.h
CONFLICT (content): Merge conflict in arch/x86/include/asm/thread_info.h
CONFLICT (content): Merge conflict in arch/s390/kernel/entry.S
CONFLICT (content): Merge conflict in arch/s390/include/asm/thread_info.h
Merging coresight/next (6de8ad2f92ea coresight: Fixes coresight DT parse to get correct output port ID.)
Merging rtc/rtc-next (65e9e65cebbe rtc: cpcap: kfreeing devm allocated memory)
Merging hwspinlock/for-next (bd5717a4632c hwspinlock: qcom: Correct msb in regmap_field)
Merging nvdimm/libnvdimm-for-next (52084f89b38c device-dax: fix debug output typo)
Merging dax-misc/dax-misc (4d9a2c874667 dax: Remove i_mmap_lock protection)
Merging idr/idr-4.11 (f0f3f2d0a3e0 radix tree test suite: Specify -m32 in LDFLAGS too)
Merging akpm-current/current (ab94daa758e2 initramfs: use vfs_stat/lstat directly)
CONFLICT (content): Merge conflict in arch/x86/include/asm/atomic64_64.h
CONFLICT (content): Merge conflict in arch/x86/include/asm/atomic.h
CONFLICT (content): Merge conflict in arch/sparc/lib/NG4memset.S
Applying: linux-next-rejects
$ git checkout -b akpm remotes/origin/akpm/master
Applying: mm: introduce kv[mz]alloc helpers
Applying: mm: introduce kv[mz]alloc helpers - f2fs fix up
Applying: mm: support __GFP_REPEAT in kvmalloc_node for >32kB
Applying: lib/rhashtable.c: simplify a strange allocation pattern
Applying: net/ipv6/ila/ila_xlat.c: simplify a strange allocation pattern
Applying: fs/xattr.c: zero out memory copied to userspace in getxattr
Applying: treewide: use kv[mz]alloc* rather than opencoded variants
Applying: net: use kvmalloc with __GFP_REPEAT rather than open coded variant
Applying: drivers/md/dm-ioctl.c: use kvmalloc rather than opencoded variant
Applying: drivers/md/bcache/super.c: use kvmalloc
Applying: mm, vmalloc: use __GFP_HIGHMEM implicitly
Applying: scripts/spelling.txt: add "memory" pattern and fix typos
Applying: scripts/spelling.txt: Add regsiter -> register spelling mistake
Applying: scripts/spelling.txt: add "intialise(d)" pattern and fix typo instances
Applying: treewide: move set_memory_* functions away from cacheflush.h
Applying: arm: use set_memory.h header
Applying: arm64: use set_memory.h header
Applying: s390: use set_memory.h header
Applying: x86: use set_memory.h header
Applying: agp: use set_memory.h header
Applying: drm: use set_memory.h header
Applying: drm-use-set_memoryh-header-fix
Applying: drivers/hwtracing/intel_th/msu.c: use set_memory.h header
Applying: drivers/watchdog/hpwdt.c: use set_memory.h header
Applying: include/linux/filter.h: use set_memory.h header
Applying: kernel/module.c: use set_memory.h header
Applying: kernel/power/snapshot.c: use set_memory.h header
Applying: alsa: use set_memory.h header
Applying: drivers/misc/sram-exec.c: use set_memory.h header
Applying: drivers/video/fbdev/vermilion/vermilion.c: use set_memory.h header
Applying: drivers/staging/media/atomisp/pci/atomisp2: use set_memory.h
Applying: treewide: decouple cacheflush.h and set_memory.h
Applying: x86/atomic: move __arch_atomic_add_unless out of line
Applying: x86-atomic-move-__atomic_add_unless-out-of-line-fix
Applying: kernel/sched/fair.c: uninline __update_load_avg()
Applying: kref: remove WARN_ON for NULL release functions
Applying: drivers/scsi/megaraid: remove expensive inline from megasas_return_cmd
Applying: include/linux/uaccess.h: remove expensive WARN_ON in pagefault_disabled_dec
Applying: tracing: move trace_handle_return() out of line
Merging akpm/master (991da316c1c2 tracing: move trace_handle_return() out of line)
^ permalink raw reply
* Re: linux-next: unsigned commits in the kvm tree
From: Paolo Bonzini @ 2017-03-30 9:40 UTC (permalink / raw)
To: Stephen Rothwell, Marcelo Tosatti, Gleb Natapov, KVM
Cc: linux-next, linux-kernel, Radim Krčmář
In-Reply-To: <20170330092142.4ec22c6a@canb.auug.org.au>
On 30/03/2017 00:21, Stephen Rothwell wrote:
>
> I noticed that several commits in the kvm tree
> (git://git.kernel.org/pub/scm/virt/kvm/kvm.git#linux-next) today have
> no Signed-off-by for their committer :-(
Hmm, that must have happened because I rebased them before (testing and)
pushing to kvm/next; kvm/next does not rebase but kvm/queue does.
Still, it's weird because I have done that many times and it's the first
time you noticed. Do you have scripts for that or did you just happen
to notice? Or maybe there is a difference in what "git rebase" vs. "git
rebase -i" does to the committer email, or something obscure like that.
Paolo
^ permalink raw reply
* Re: linux-next: unsigned commits in the kvm tree
From: Stephen Rothwell @ 2017-03-30 11:01 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Marcelo Tosatti, Gleb Natapov, KVM, linux-next, linux-kernel,
Radim Krčmář
In-Reply-To: <e118215b-0a44-e1d7-c665-41112a44df0a@redhat.com>
Hi Paolo,
On Thu, 30 Mar 2017 11:40:41 +0200 Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 30/03/2017 00:21, Stephen Rothwell wrote:
> >
> > I noticed that several commits in the kvm tree
> > (git://git.kernel.org/pub/scm/virt/kvm/kvm.git#linux-next) today have
> > no Signed-off-by for their committer :-(
>
> Hmm, that must have happened because I rebased them before (testing and)
> pushing to kvm/next; kvm/next does not rebase but kvm/queue does.
>
> Still, it's weird because I have done that many times and it's the first
> time you noticed. Do you have scripts for that or did you just happen
> to notice? Or maybe there is a difference in what "git rebase" vs. "git
> rebase -i" does to the committer email, or something obscure like that.
I should write a script, but at the moment I just notice sometimes. I
have a quick look at what is new in each tree each morning and
sometimes things stick out :-)
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: linux-next: manual merge of the tty tree with the tty.current tree
From: Dmitry Vyukov @ 2017-03-30 12:17 UTC (permalink / raw)
To: Michael Neuling; +Cc: Greg KH, linux-next, LKML, Peter Hurley, Stephen Rothwell
In-Reply-To: <1490845566.27519.30.camel@neuling.org>
On Thu, Mar 30, 2017 at 5:46 AM, Michael Neuling <mikey@neuling.org> wrote:
>> > wrote:
>> > > Hi Greg,
>> > >
>> > > Today's linux-next merge of the tty tree got a conflict in:
>> > >
>> > > drivers/tty/tty_ldisc.c
>> > >
>> > > between commit:
>> > >
>> > > 5362544bebe8 ("tty: don't panic on OOM in tty_set_ldisc()")
>> > >
>> > > from the tty.current tree and commit:
>> > >
>> > > 71472fa9c52b ("tty: Fix ldisc crash on reopened tty")
>> > >
>> > > from the tty 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/tty/tty_ldisc.c
>> > > index b0500a0a87b8,4ee7742dced3..000000000000
>> > > --- a/drivers/tty/tty_ldisc.c
>> > > +++ b/drivers/tty/tty_ldisc.c
>> > > @@@ -621,14 -669,17 +621,15 @@@ int tty_ldisc_reinit(struct tty_struct
>> > > tty_ldisc_put(tty->ldisc);
>> > > }
>> > >
>> > > - /* switch the line discipline */
>> > > - tty->ldisc = ld;
>> > > tty_set_termios_ldisc(tty, disc);
>> > > - retval = tty_ldisc_open(tty, tty->ldisc);
>> > > + retval = tty_ldisc_open(tty, ld);
>> > > if (retval) {
>> > > - tty_ldisc_put(tty->ldisc);
>> > > - tty->ldisc = NULL;
>> > > - if (!WARN_ON(disc == N_TTY)) {
>> > > - tty_ldisc_put(ld);
>> > > - ld = NULL;
>> > > - }
>> > > ++ tty_ldisc_put(ld);
>> > > ++ ld = NULL;
>> > > }
>> > > +
>> > > + /* switch the line discipline */
>> > > + smp_store_release(&tty->ldisc, ld);
>> > > return retval;
>> > > }
>> > >
>> >
>> >
>> > Peter,
>> >
>> > Looking at your patch "tty: Fix ldisc crash on reopened tty", I think
>> > there is a missed barrier in tty_ldisc_ref. A single barrier does not
>> > have any effect, they always need to be in pairs. So I think we also
>> > need at least:
>> >
>> > @@ -295,7 +295,8 @@ struct tty_ldisc *tty_ldisc_ref(struct tty_struct *tty)
>> > struct tty_ldisc *ld = NULL;
>> >
>> > if (ldsem_down_read_trylock(&tty->ldisc_sem)) {
>> > - ld = tty->ldisc;
>> > + ld = READ_ONCE(tty->ldisc);
>> > + read_barrier_depends();
>> > if (!ld)
>> > ldsem_up_read(&tty->ldisc_sem);
>> > }
>> >
>> >
>> > Or simply:
>> >
>> > @@ -295,7 +295,8 @@ struct tty_ldisc *tty_ldisc_ref(struct tty_struct *tty)
>> > struct tty_ldisc *ld = NULL;
>> >
>> > if (ldsem_down_read_trylock(&tty->ldisc_sem)) {
>> > - ld = tty->ldisc;
>> > + /* pairs with smp_store_release in tty_ldisc_reinit */
>> > + ld = smp_load_acquire(&tty->ldisc);
>> > if (!ld)
>> > ldsem_up_read(&tty->ldisc_sem);
>> > }
>>
>>
>>
>>
>> I am also surprised that callers of tty_ldisc_reinit don't hold
>> ldisc_sem. I thought that ldisc_sem is what's supposed to protect
>> changes to ldisc. That would also auto fix the crash without any
>> tricky barriers as flush_to_ldisc uses tty_ldisc_ref.
>
> Dmitry,
>
> Thanks for the help. Peter doesn't seem to be responding to email any more.
>
> I'm not familiar with the tty layer, but the issue that patch was suppose to fix
> had a similar signature to the below oops we are seeing on powerpc on boot.
> (sorry I don't have a repro on mainline or linux-next). Hence why I pushed on
> it.
>
> In the below crash the call to tty_ldisc_reinit is coming from a workqueue, so
> requiring the callers to hold the ldisc_sem is more tricky.
>
> Could we just hold the ldisc_sem inside tty_ldisc_reinit()?
Hi,
I don't know.
At the very least we need a pairing smp_load_acquire().
Re ldisc_sem: I just noticed that most of the time ldisc filed is
protected with the semaphore and most code does not care about
races/lifetime issues. Maybe it's protected by some other means in
this particular place.
> Regards,
> Mikey
>
> [ 9.021567] Unable to handle kernel paging request for data at address 0x00002260
> [ 9.022501] Faulting instruction address: 0xc0000000006c7770
> [ 9.023105] Oops: Kernel access of bad area, sig: 11 [#1]
> [ 9.023674] SMP NR_CPUS=2048
> [ 9.023676] NUMA
> [ 9.023970] PowerNV
> [ 9.024372] Modules linked in: ofpart cmdlinepart ipmi_powernv powernv_flash ipmi_devintf mtd ipmi_msghandler ibmpowernv opal_prd uio_pdrv_genirq uio vmx_crypto ip_tables x_tables autofs4 ast i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt crc32c_vpmsum fb_sys_fops drm ahci libahci tg3
> [ 9.027146] CPU: 15 PID: 354 Comm: kworker/u64:2 Not tainted 4.10.0-8-generic #10-Ubuntu
> [ 9.027978] Workqueue: events_unbound flush_to_ldisc
> [ 9.028468] task: c0000016a7758c00 task.stack: c0000000fd084000
> [ 9.029055] NIP: c0000000006c7770 LR: c0000000006c7758 CTR: c0000000006c84b0
> [ 9.029767] REGS: c0000000fd0878c0 TRAP: 0300 Not tainted (4.10.0-8-generic)
> [ 9.030520] MSR: 900000000280b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE>
> [ 9.030537] CR: 28002888 XER: 00000000
> [ 9.031579] CFAR: c000000000b3e20c DAR: 0000000000002260 DSISR: 40000000 SOFTE: 1
> [ 9.031579] GPR04: c000000002ac8c20 c000000002ac8d20 0000000000000100 0000000000000001
> [ 9.031579] GPR12: 0000000028002888 c00000000fb88700 c0000000000f6668 c0000016b4b7e3c0
> [ 9.031579] GPR20: 0000000000000000 0000000000000000 c000000001335ce9 0000000100000000
> [ 9.031579] GPR28: c000000002ac8d20 0000000000000100 c0000016a8dca608 c0000016ae0ebc00
> [ 9.031579] GPR00: c0000000006c7758 c0000000fd087b40 c00000000143c900 0000000000000000
> [ 9.031579] GPR08: c0000016ae0ebcc0 0000000000000001 c00000000139a5a0 c0000016a7758ca8
> [ 9.031579] GPR16: c0000016c90322d8 c0000016c9032090 c0000016c9032020 0000000000000001
> [ 9.031579] GPR24: 0000000000000000 0000000000000000 c000000002ac8c20 c0000016b4f932a0
> [ 9.038511] NIP [c0000000006c7770] n_tty_receive_buf_common+0xb0/0xdf0
> [ 9.039139] LR [c0000000006c7758] n_tty_receive_buf_common+0x98/0xdf0
> [ 9.039766] Call Trace:
> [ 9.040009] [c0000000fd087b40] [c0000000006c7758] n_tty_receive_buf_common+0x98/0xdf0 (unreliable)
> [ 9.040868] [c0000000fd087c10] [c0000000006cc524] tty_ldisc_receive_buf+0x44/0xe0
> [ 9.041595] [c0000000fd087c40] [c0000000006ccd9c] flush_to_ldisc+0x13c/0x160
> [ 9.042265] [c0000000fd087c90] [c0000000000ed8c0] process_one_work+0x2b0/0x5a0
> [ 9.042955] [c0000000fd087d20] [c0000000000edc58] worker_thread+0xa8/0x650
> [ 9.043625] [c0000000fd087dc0] [c0000000000f67b4] kthread+0x154/0x1a0
> [ 9.044245] [c0000000fd087e30] [c00000000000b4e8] ret_from_kernel_thread+0x5c/0x74
> [ 9.044964] Instruction dump:
> [ 9.045281] eb3f0260 7c9a2378 7cbc2b78 7cdd3378 f8e10030 48476a55 60000000 3b000000
> [ 9.046128] 7af783e4 60000000 60000000 60420000 7c2004ac e8d90000 80ff0110
> [ 9.047044] ---[ end trace 6b3bf4b72485f95c ]---
> [ 9.047485]
>
>
>
^ permalink raw reply
* next-20170330 build: 2 failures 8 warnings (next-20170330)
From: Build bot for Mark Brown @ 2017-03-30 12:50 UTC (permalink / raw)
To: kernel-build-reports, linaro-kernel, linux-next
Tree/Branch: next-20170330
Git describe: next-20170330
Commit: 6fd3fc13b3 Add linux-next specific files for 20170330
Build Time: 213 min 40 sec
Passed: 8 / 10 ( 80.00 %)
Failed: 2 / 10 ( 20.00 %)
Errors: 7
Warnings: 8
Section Mismatches: 0
Failed defconfigs:
arm64-allmodconfig
arm-allmodconfig
Errors:
arm64-allmodconfig
../drivers/infiniband/hw/hns/hns_roce_hw_v1.c:1384:15: error: implicit declaration of function 'of_parse_phandle' [-Werror=implicit-function-declaration]
../drivers/infiniband/hw/hns/hns_roce_hw_v1.c:1389:22: error: dereferencing pointer to incomplete type 'struct device_node'
arm-allmodconfig
../drivers/mtd/nand/atmel/nand-controller.c:2126:25: error: 'atmel_nc_id_table' undeclared here (not in a function)
../include/linux/module.h:212:27: error: '__mod_of__atmel_nc_id_table_device_table' aliased to undefined symbol 'atmel_nc_id_table'
../drivers/net/ethernet/faraday/ftgmac100.c:153:9: error: implicit declaration of function 'device_get_mac_address' [-Werror=implicit-function-declaration]
../drivers/net/ethernet/faraday/ftgmac100.c:1262:6: error: implicit declaration of function 'of_machine_is_compatible' [-Werror=implicit-function-declaration]
../drivers/net/ethernet/faraday/ftgmac100.c:1406:6: error: implicit declaration of function 'of_get_property' [-Werror=implicit-function-declaration]
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
3 warnings 0 mismatches : arm64-allmodconfig
4 warnings 0 mismatches : arm-multi_v7_defconfig
1 warnings 0 mismatches : arm-allmodconfig
-------------------------------------------------------------------------------
Errors summary: 7
1 ../include/linux/module.h:212:27: error: '__mod_of__atmel_nc_id_table_device_table' aliased to undefined symbol 'atmel_nc_id_table'
1 ../drivers/net/ethernet/faraday/ftgmac100.c:153:9: error: implicit declaration of function 'device_get_mac_address' [-Werror=implicit-function-declaration]
1 ../drivers/net/ethernet/faraday/ftgmac100.c:1406:6: error: implicit declaration of function 'of_get_property' [-Werror=implicit-function-declaration]
1 ../drivers/net/ethernet/faraday/ftgmac100.c:1262:6: error: implicit declaration of function 'of_machine_is_compatible' [-Werror=implicit-function-declaration]
1 ../drivers/mtd/nand/atmel/nand-controller.c:2126:25: error: 'atmel_nc_id_table' undeclared here (not in a function)
1 ../drivers/infiniband/hw/hns/hns_roce_hw_v1.c:1389:22: error: dereferencing pointer to incomplete type 'struct device_node'
1 ../drivers/infiniband/hw/hns/hns_roce_hw_v1.c:1384:15: error: implicit declaration of function 'of_parse_phandle' [-Werror=implicit-function-declaration]
Warnings Summary: 8
1 arch/arm/configs/multi_v7_defconfig:600:warning: symbol value 'm' invalid for ROCKCHIP_INNO_HDMI
1 arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' invalid for ROCKCHIP_DW_MIPI_DSI
1 arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' invalid for ROCKCHIP_DW_HDMI
1 arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' invalid for ROCKCHIP_ANALOGIX_DP
1 ../include/uapi/linux/byteorder/big_endian.h:32:26: warning: large integer implicitly truncated to unsigned type [-Woverflow]
1 ../drivers/net/ethernet/faraday/ftgmac100.c:153:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
1 ../drivers/misc/aspeed-lpc-ctrl.c:232:17: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t {aka long long unsigned int}' [-Wformat=]
1 ../drivers/infiniband/hw/hns/hns_roce_hw_v1.c:1384:13: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allmodconfig : FAIL, 2 errors, 3 warnings, 0 section mismatches
Errors:
../drivers/infiniband/hw/hns/hns_roce_hw_v1.c:1384:15: error: implicit declaration of function 'of_parse_phandle' [-Werror=implicit-function-declaration]
../drivers/infiniband/hw/hns/hns_roce_hw_v1.c:1389:22: error: dereferencing pointer to incomplete type 'struct device_node'
Warnings:
../include/uapi/linux/byteorder/big_endian.h:32:26: warning: large integer implicitly truncated to unsigned type [-Woverflow]
../drivers/infiniband/hw/hns/hns_roce_hw_v1.c:1384:13: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
../drivers/misc/aspeed-lpc-ctrl.c:232:17: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t {aka long long unsigned int}' [-Wformat=]
-------------------------------------------------------------------------------
arm-multi_v7_defconfig : PASS, 0 errors, 4 warnings, 0 section mismatches
Warnings:
arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' invalid for ROCKCHIP_ANALOGIX_DP
arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' invalid for ROCKCHIP_DW_HDMI
arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' invalid for ROCKCHIP_DW_MIPI_DSI
arch/arm/configs/multi_v7_defconfig:600:warning: symbol value 'm' invalid for ROCKCHIP_INNO_HDMI
-------------------------------------------------------------------------------
arm-allmodconfig : FAIL, 5 errors, 1 warnings, 0 section mismatches
Errors:
../drivers/mtd/nand/atmel/nand-controller.c:2126:25: error: 'atmel_nc_id_table' undeclared here (not in a function)
../include/linux/module.h:212:27: error: '__mod_of__atmel_nc_id_table_device_table' aliased to undefined symbol 'atmel_nc_id_table'
../drivers/net/ethernet/faraday/ftgmac100.c:153:9: error: implicit declaration of function 'device_get_mac_address' [-Werror=implicit-function-declaration]
../drivers/net/ethernet/faraday/ftgmac100.c:1262:6: error: implicit declaration of function 'of_machine_is_compatible' [-Werror=implicit-function-declaration]
../drivers/net/ethernet/faraday/ftgmac100.c:1406:6: error: implicit declaration of function 'of_get_property' [-Werror=implicit-function-declaration]
Warnings:
../drivers/net/ethernet/faraday/ftgmac100.c:153:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
arm64-allnoconfig
arm-multi_v5_defconfig
x86_64-defconfig
arm-allnoconfig
x86_64-allnoconfig
arm-multi_v4t_defconfig
arm64-defconfig
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
^ permalink raw reply
* Re: linux-next: Tree for Mar 30
From: Leonard Crestez @ 2017-03-30 13:39 UTC (permalink / raw)
To: Stephen Rothwell, Linux-Next Mailing List, Chris Wilson,
Shawn Guo
Cc: Linux Kernel Mailing List, dri-devel, Octavian Purdila
In-Reply-To: <20170330165537.603eed3d@canb.auug.org.au>
On Thu, 2017-03-30 at 16:55 +1100, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20170329:
>
> Undropped tree: xen-tip
>
> The vfs tree gained a conflict against Linus' tree.
>
> The drm tree gained conflicts against the drm-intel-fixes tree.
>
> The mailbox tree lost its build failure.
>
> The phy-next tree gained a build failure, so I used the version from
> next-20170329.
>
> The vhost tree gained a build failure, so I used the version from
> next-20170329.
>
> Non-merge commits (relative to Linus' tree): 5728
> 6122 files changed, 441716 insertions(+), 108564 deletions(-)
>
> ----------------------------------------------------------------------------
>
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
> are tracking the linux-next tree using git, you should not use "git pull"
> to do so as that will try to merge the new linux-next release with the
> old one. You should use "git fetch" and checkout or reset to the new
> master.
>
> You can see which trees have been included by looking in the Next/Trees
> file in the source. There are also quilt-import.log and merge.log
> files in the Next directory. Between each merge, the tree was built
> with a ppc64_defconfig for powerpc and an allmodconfig (with
> CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
> native build of tools/perf. After the final fixups (if any), I do an
> x86_64 modules_install followed by builds for x86_64 allnoconfig,
> powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
> and pseries_le_defconfig and i386, sparc and sparc64 defconfig.
>
> Below is a summary of the state of the merge.
>
> I am currently merging 255 trees (counting Linus' and 37 trees of bug
> fix patches pending for the current merge release).
>
> Stats about the size of the tree over time can be seen at
> http://neuling.org/linux-next-size.html .
>
> Status of my local build tests will be at
> http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
> advice about cross compilers/configs that work, we are always open to add
> more builds.
It seems there is a build error for imx_v6_v7_defconfig.
Link: http://kisskb.ellerman.id.au/kisskb/buildresult/12980252/
Error:
drivers/built-in.o: In function `vblank_disable_and_save':
imx-ocotp.c:(.text+0xb45e8): undefined reference to `__bad_cmpxchg'
Makefile:986: recipe for target 'vmlinux' failed
This seems to be caused by something from drm:
commit 43dc7fe2b211 ("drm: Mark up accesses of vblank->enabled outside of its spinlock")
It introduces a cmpxchg on a bool which is apparently not supported on
ARM v6 (it only supports 32-bit values). The error looks legit to me
(not caused by an infrastructure bug).
It seems the kbuild test robot also found a similar breakage on tilegx:
https://lists.freedesktop.org/archives/dri-devel/2017-March/137322.html
--
Regards,
Leonard
^ 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