Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Update REPORTING-BUGS #65

Open
wants to merge 1 commit into from

1 participant

@ngatnicdotmil

No description provided.

@swarren swarren referenced this pull request from a commit in swarren/linux-tegra
Andrew Morton acpi-numa-mem_hotplug-mark-hotpluggable-memory-in-memblock-checkpatch…
…-fixes

WARNING: line over 80 characters
#65: FILE: arch/x86/mm/srat.c:187:
+			(unsigned long long) start, (unsigned long long) end - 1);

total: 0 errors, 1 warnings, 19 lines checked

./patches/acpi-numa-mem_hotplug-mark-hotpluggable-memory-in-memblock.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
8953a1a
@tom3q tom3q referenced this pull request from a commit in tom3q/linux
Andrew Morton acpi-numa-mem_hotplug-mark-hotpluggable-memory-in-memblock-checkpatch…
…-fixes

WARNING: line over 80 characters
#65: FILE: arch/x86/mm/srat.c:187:
+			(unsigned long long) start, (unsigned long long) end - 1);

total: 0 errors, 1 warnings, 19 lines checked

./patches/acpi-numa-mem_hotplug-mark-hotpluggable-memory-in-memblock.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
6f412b5
@mitake mitake referenced this pull request from a commit in mitake/linux
Cong Wang rds: limit the size allocated by rds_message_alloc()
Dave Jones reported the following bug:

"When fed mangled socket data, rds will trust what userspace gives it,
and tries to allocate enormous amounts of memory larger than what
kmalloc can satisfy."

WARNING: at mm/page_alloc.c:2393 __alloc_pages_nodemask+0xa0d/0xbe0()
Hardware name: GA-MA78GM-S2H
Modules linked in: vmw_vsock_vmci_transport vmw_vmci vsock fuse bnep dlci bridge 8021q garp stp mrp binfmt_misc l2tp_ppp l2tp_core rfcomm s
Pid: 24652, comm: trinity-child2 Not tainted 3.8.0+ #65
Call Trace:
 [<ffffffff81044155>] warn_slowpath_common+0x75/0xa0
 [<ffffffff8104419a>] warn_slowpath_null+0x1a/0x20
 [<ffffffff811444ad>] __alloc_pages_nodemask+0xa0d/0xbe0
 [<ffffffff8100a196>] ? native_sched_clock+0x26/0x90
 [<ffffffff810b2128>] ? trace_hardirqs_off_caller+0x28/0xc0
 [<ffffffff810b21cd>] ? trace_hardirqs_off+0xd/0x10
 [<ffffffff811861f8>] alloc_pages_current+0xb8/0x180
 [<ffffffff8113eaaa>] __get_free_pages+0x2a/0x80
 [<ffffffff811934fe>] kmalloc_order_trace+0x3e/0x1a0
 [<ffffffff81193955>] __kmalloc+0x2f5/0x3a0
 [<ffffffff8104df0c>] ? local_bh_enable_ip+0x7c/0xf0
 [<ffffffffa0401ab3>] rds_message_alloc+0x23/0xb0 [rds]
 [<ffffffffa04043a1>] rds_sendmsg+0x2b1/0x990 [rds]
 [<ffffffff810b21cd>] ? trace_hardirqs_off+0xd/0x10
 [<ffffffff81564620>] sock_sendmsg+0xb0/0xe0
 [<ffffffff810b2052>] ? get_lock_stats+0x22/0x70
 [<ffffffff810b24be>] ? put_lock_stats.isra.23+0xe/0x40
 [<ffffffff81567f30>] sys_sendto+0x130/0x180
 [<ffffffff810b872d>] ? trace_hardirqs_on+0xd/0x10
 [<ffffffff816c547b>] ? _raw_spin_unlock_irq+0x3b/0x60
 [<ffffffff816cd767>] ? sysret_check+0x1b/0x56
 [<ffffffff810b8695>] ? trace_hardirqs_on_caller+0x115/0x1a0
 [<ffffffff81341d8e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [<ffffffff816cd742>] system_call_fastpath+0x16/0x1b
---[ end trace eed6ae990d018c8b ]---

Reported-by: Dave Jones <davej@redhat.com>
Cc: Dave Jones <davej@redhat.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
Signed-off-by: Cong Wang <amwang@redhat.com>
Acked-by: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
ece6b0a
@mitake mitake referenced this pull request from a commit in mitake/linux
Borislav Petkov x86/boot: Further compress CPUs bootup message
Turn it into (for example):

[    0.073380] x86: Booting SMP configuration:
[    0.074005] .... node   #0, CPUs:          #1   #2   #3   #4   #5   #6   #7
[    0.603005] .... node   #1, CPUs:     #8   #9  #10  #11  #12  #13  #14  #15
[    1.200005] .... node   #2, CPUs:    #16  #17  #18  #19  #20  #21  #22  #23
[    1.796005] .... node   #3, CPUs:    #24  #25  #26  #27  #28  #29  #30  #31
[    2.393005] .... node   #4, CPUs:    #32  #33  #34  #35  #36  #37  #38  #39
[    2.996005] .... node   #5, CPUs:    #40  #41  #42  #43  #44  #45  #46  #47
[    3.600005] .... node   #6, CPUs:    #48  #49  #50  #51  #52  #53  #54  #55
[    4.202005] .... node   #7, CPUs:    #56  #57  #58  #59  #60  #61  #62  #63
[    4.811005] .... node   #8, CPUs:    #64  #65  #66  #67  #68  #69  #70  #71
[    5.421006] .... node   #9, CPUs:    #72  #73  #74  #75  #76  #77  #78  #79
[    6.032005] .... node  #10, CPUs:    #80  #81  #82  #83  #84  #85  #86  #87
[    6.648006] .... node  #11, CPUs:    #88  #89  #90  #91  #92  #93  #94  #95
[    7.262005] .... node  #12, CPUs:    #96  #97  #98  #99 #100 #101 #102 #103
[    7.865005] .... node  #13, CPUs:   #104 #105 #106 #107 #108 #109 #110 #111
[    8.466005] .... node  #14, CPUs:   #112 #113 #114 #115 #116 #117 #118 #119
[    9.073006] .... node  #15, CPUs:   #120 #121 #122 #123 #124 #125 #126 #127
[    9.679901] x86: Booted up 16 nodes, 128 CPUs

and drop useless elements.

Change num_digits() to hpa's division-avoiding, cell-phone-typed
version which he went at great lengths and pains to submit on a
Saturday evening.

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: huawei.libin@huawei.com
Cc: wangyijing@huawei.com
Cc: fenghua.yu@intel.com
Cc: guohanjun@huawei.com
Cc: paul.gortmaker@windriver.com
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20130930095624.GB16383@pd.tnic
Signed-off-by: Ingo Molnar <mingo@kernel.org>
a17bce4
@Naoya-Horiguchi Naoya-Horiguchi referenced this pull request from a commit
Andrew Morton acpi-numa-mem_hotplug-mark-hotpluggable-memory-in-memblock-checkpatch…
…-fixes

WARNING: line over 80 characters
#65: FILE: arch/x86/mm/srat.c:187:
+			(unsigned long long) start, (unsigned long long) end - 1);

total: 0 errors, 1 warnings, 19 lines checked

./patches/acpi-numa-mem_hotplug-mark-hotpluggable-memory-in-memblock.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
22082a1
@hardkernel hardkernel referenced this pull request from a commit in hardkernel/linux
Andrew Morton acpi-numa-mem_hotplug-mark-hotpluggable-memory-in-memblock-checkpatch…
…-fixes

WARNING: line over 80 characters
#65: FILE: arch/x86/mm/srat.c:187:
+			(unsigned long long) start, (unsigned long long) end - 1);

total: 0 errors, 1 warnings, 19 lines checked

./patches/acpi-numa-mem_hotplug-mark-hotpluggable-memory-in-memblock.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0a81dee
@tobiasjakobi tobiasjakobi referenced this pull request from a commit in tobiasjakobi/linux-odroid
Cong Wang rds: limit the size allocated by rds_message_alloc()
[ Upstream commit ece6b0a ]

Dave Jones reported the following bug:

"When fed mangled socket data, rds will trust what userspace gives it,
and tries to allocate enormous amounts of memory larger than what
kmalloc can satisfy."

WARNING: at mm/page_alloc.c:2393 __alloc_pages_nodemask+0xa0d/0xbe0()
Hardware name: GA-MA78GM-S2H
Modules linked in: vmw_vsock_vmci_transport vmw_vmci vsock fuse bnep dlci bridge 8021q garp stp mrp binfmt_misc l2tp_ppp l2tp_core rfcomm s
Pid: 24652, comm: trinity-child2 Not tainted 3.8.0+ #65
Call Trace:
 [<ffffffff81044155>] warn_slowpath_common+0x75/0xa0
 [<ffffffff8104419a>] warn_slowpath_null+0x1a/0x20
 [<ffffffff811444ad>] __alloc_pages_nodemask+0xa0d/0xbe0
 [<ffffffff8100a196>] ? native_sched_clock+0x26/0x90
 [<ffffffff810b2128>] ? trace_hardirqs_off_caller+0x28/0xc0
 [<ffffffff810b21cd>] ? trace_hardirqs_off+0xd/0x10
 [<ffffffff811861f8>] alloc_pages_current+0xb8/0x180
 [<ffffffff8113eaaa>] __get_free_pages+0x2a/0x80
 [<ffffffff811934fe>] kmalloc_order_trace+0x3e/0x1a0
 [<ffffffff81193955>] __kmalloc+0x2f5/0x3a0
 [<ffffffff8104df0c>] ? local_bh_enable_ip+0x7c/0xf0
 [<ffffffffa0401ab3>] rds_message_alloc+0x23/0xb0 [rds]
 [<ffffffffa04043a1>] rds_sendmsg+0x2b1/0x990 [rds]
 [<ffffffff810b21cd>] ? trace_hardirqs_off+0xd/0x10
 [<ffffffff81564620>] sock_sendmsg+0xb0/0xe0
 [<ffffffff810b2052>] ? get_lock_stats+0x22/0x70
 [<ffffffff810b24be>] ? put_lock_stats.isra.23+0xe/0x40
 [<ffffffff81567f30>] sys_sendto+0x130/0x180
 [<ffffffff810b872d>] ? trace_hardirqs_on+0xd/0x10
 [<ffffffff816c547b>] ? _raw_spin_unlock_irq+0x3b/0x60
 [<ffffffff816cd767>] ? sysret_check+0x1b/0x56
 [<ffffffff810b8695>] ? trace_hardirqs_on_caller+0x115/0x1a0
 [<ffffffff81341d8e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [<ffffffff816cd742>] system_call_fastpath+0x16/0x1b
---[ end trace eed6ae990d018c8b ]---

Reported-by: Dave Jones <davej@redhat.com>
Cc: Dave Jones <davej@redhat.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
Signed-off-by: Cong Wang <amwang@redhat.com>
Acked-by: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
273402d
@niwamatsu niwamatsu referenced this pull request from a commit in renesas-devel/linux
Cong Wang rds: limit the size allocated by rds_message_alloc()
[ Upstream commit ece6b0a ]

Dave Jones reported the following bug:

"When fed mangled socket data, rds will trust what userspace gives it,
and tries to allocate enormous amounts of memory larger than what
kmalloc can satisfy."

WARNING: at mm/page_alloc.c:2393 __alloc_pages_nodemask+0xa0d/0xbe0()
Hardware name: GA-MA78GM-S2H
Modules linked in: vmw_vsock_vmci_transport vmw_vmci vsock fuse bnep dlci bridge 8021q garp stp mrp binfmt_misc l2tp_ppp l2tp_core rfcomm s
Pid: 24652, comm: trinity-child2 Not tainted 3.8.0+ #65
Call Trace:
 [<ffffffff81044155>] warn_slowpath_common+0x75/0xa0
 [<ffffffff8104419a>] warn_slowpath_null+0x1a/0x20
 [<ffffffff811444ad>] __alloc_pages_nodemask+0xa0d/0xbe0
 [<ffffffff8100a196>] ? native_sched_clock+0x26/0x90
 [<ffffffff810b2128>] ? trace_hardirqs_off_caller+0x28/0xc0
 [<ffffffff810b21cd>] ? trace_hardirqs_off+0xd/0x10
 [<ffffffff811861f8>] alloc_pages_current+0xb8/0x180
 [<ffffffff8113eaaa>] __get_free_pages+0x2a/0x80
 [<ffffffff811934fe>] kmalloc_order_trace+0x3e/0x1a0
 [<ffffffff81193955>] __kmalloc+0x2f5/0x3a0
 [<ffffffff8104df0c>] ? local_bh_enable_ip+0x7c/0xf0
 [<ffffffffa0401ab3>] rds_message_alloc+0x23/0xb0 [rds]
 [<ffffffffa04043a1>] rds_sendmsg+0x2b1/0x990 [rds]
 [<ffffffff810b21cd>] ? trace_hardirqs_off+0xd/0x10
 [<ffffffff81564620>] sock_sendmsg+0xb0/0xe0
 [<ffffffff810b2052>] ? get_lock_stats+0x22/0x70
 [<ffffffff810b24be>] ? put_lock_stats.isra.23+0xe/0x40
 [<ffffffff81567f30>] sys_sendto+0x130/0x180
 [<ffffffff810b872d>] ? trace_hardirqs_on+0xd/0x10
 [<ffffffff816c547b>] ? _raw_spin_unlock_irq+0x3b/0x60
 [<ffffffff816cd767>] ? sysret_check+0x1b/0x56
 [<ffffffff810b8695>] ? trace_hardirqs_on_caller+0x115/0x1a0
 [<ffffffff81341d8e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [<ffffffff816cd742>] system_call_fastpath+0x16/0x1b
---[ end trace eed6ae990d018c8b ]---

Reported-by: Dave Jones <davej@redhat.com>
Cc: Dave Jones <davej@redhat.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
Signed-off-by: Cong Wang <amwang@redhat.com>
Acked-by: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2b2066c
@torvalds torvalds referenced this pull request from a commit
@sorenb-xlnx sorenb-xlnx net: macb: DMA-unmap full rx-buffer
When allocating RX buffers a fixed size is used, while freeing is based
on actually received bytes, resulting in the following kernel warning
when CONFIG_DMA_API_DEBUG is enabled:
 WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:1051 check_unmap+0x258/0x894()
 macb e000b000.ethernet: DMA-API: device driver frees DMA memory with different size [device address=0x000000002d170040] [map size=1536 bytes] [unmap size=60 bytes]
 Modules linked in:
 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.0-rc3-xilinx-00220-g49f84081ce4f #65
 [<c001516c>] (unwind_backtrace) from [<c0011df8>] (show_stack+0x10/0x14)
 [<c0011df8>] (show_stack) from [<c03c775c>] (dump_stack+0x7c/0xc8)
 [<c03c775c>] (dump_stack) from [<c00245cc>] (warn_slowpath_common+0x60/0x84)
 [<c00245cc>] (warn_slowpath_common) from [<c0024670>] (warn_slowpath_fmt+0x2c/0x3c)
 [<c0024670>] (warn_slowpath_fmt) from [<c0227d44>] (check_unmap+0x258/0x894)
 [<c0227d44>] (check_unmap) from [<c0228588>] (debug_dma_unmap_page+0x64/0x70)
 [<c0228588>] (debug_dma_unmap_page) from [<c02ab78c>] (gem_rx+0x118/0x170)
 [<c02ab78c>] (gem_rx) from [<c02ac4d4>] (macb_poll+0x24/0x94)
 [<c02ac4d4>] (macb_poll) from [<c031222c>] (net_rx_action+0x6c/0x188)
 [<c031222c>] (net_rx_action) from [<c0028a28>] (__do_softirq+0x108/0x280)
 [<c0028a28>] (__do_softirq) from [<c0028e8c>] (irq_exit+0x84/0xf8)
 [<c0028e8c>] (irq_exit) from [<c000f360>] (handle_IRQ+0x68/0x8c)
 [<c000f360>] (handle_IRQ) from [<c0008528>] (gic_handle_irq+0x3c/0x60)
 [<c0008528>] (gic_handle_irq) from [<c0012904>] (__irq_svc+0x44/0x78)
 Exception stack(0xc056df20 to 0xc056df68)
 df20: 00000001 c0577430 00000000 c0577430 04ce8e0d 00000002 edfce238 00000000
 df40: 04e20f78 00000002 c05981f4 00000000 00000008 c056df68 c0064008 c02d7658
 df60: 20000013 ffffffff
 [<c0012904>] (__irq_svc) from [<c02d7658>] (cpuidle_enter_state+0x54/0xf8)
 [<c02d7658>] (cpuidle_enter_state) from [<c02d77dc>] (cpuidle_idle_call+0xe0/0x138)
 [<c02d77dc>] (cpuidle_idle_call) from [<c000f660>] (arch_cpu_idle+0x8/0x3c)
 [<c000f660>] (arch_cpu_idle) from [<c006bec4>] (cpu_startup_entry+0xbc/0x124)
 [<c006bec4>] (cpu_startup_entry) from [<c053daec>] (start_kernel+0x350/0x3b0)
 ---[ end trace d5fdc38641bd3a11 ]---
 Mapped at:
  [<c0227184>] debug_dma_map_page+0x48/0x11c
  [<c02ab32c>] gem_rx_refill+0x154/0x1f8
  [<c02ac7b4>] macb_open+0x270/0x3e0
  [<c03152e0>] __dev_open+0x7c/0xfc
  [<c031554c>] __dev_change_flags+0x8c/0x140

Fixing this by passing the same size which is passed during mapping the
memory to the unmap function as well.

Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
Reviewed-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
48330e0
@gregnietsky gregnietsky referenced this pull request from a commit in Distrotech/linux
Cong Wang rds: limit the size allocated by rds_message_alloc()
[ Upstream commit ece6b0a ]

Dave Jones reported the following bug:

"When fed mangled socket data, rds will trust what userspace gives it,
and tries to allocate enormous amounts of memory larger than what
kmalloc can satisfy."

WARNING: at mm/page_alloc.c:2393 __alloc_pages_nodemask+0xa0d/0xbe0()
Hardware name: GA-MA78GM-S2H
Modules linked in: vmw_vsock_vmci_transport vmw_vmci vsock fuse bnep dlci bridge 8021q garp stp mrp binfmt_misc l2tp_ppp l2tp_core rfcomm s
Pid: 24652, comm: trinity-child2 Not tainted 3.8.0+ #65
Call Trace:
 [<ffffffff81044155>] warn_slowpath_common+0x75/0xa0
 [<ffffffff8104419a>] warn_slowpath_null+0x1a/0x20
 [<ffffffff811444ad>] __alloc_pages_nodemask+0xa0d/0xbe0
 [<ffffffff8100a196>] ? native_sched_clock+0x26/0x90
 [<ffffffff810b2128>] ? trace_hardirqs_off_caller+0x28/0xc0
 [<ffffffff810b21cd>] ? trace_hardirqs_off+0xd/0x10
 [<ffffffff811861f8>] alloc_pages_current+0xb8/0x180
 [<ffffffff8113eaaa>] __get_free_pages+0x2a/0x80
 [<ffffffff811934fe>] kmalloc_order_trace+0x3e/0x1a0
 [<ffffffff81193955>] __kmalloc+0x2f5/0x3a0
 [<ffffffff8104df0c>] ? local_bh_enable_ip+0x7c/0xf0
 [<ffffffffa0401ab3>] rds_message_alloc+0x23/0xb0 [rds]
 [<ffffffffa04043a1>] rds_sendmsg+0x2b1/0x990 [rds]
 [<ffffffff810b21cd>] ? trace_hardirqs_off+0xd/0x10
 [<ffffffff81564620>] sock_sendmsg+0xb0/0xe0
 [<ffffffff810b2052>] ? get_lock_stats+0x22/0x70
 [<ffffffff810b24be>] ? put_lock_stats.isra.23+0xe/0x40
 [<ffffffff81567f30>] sys_sendto+0x130/0x180
 [<ffffffff810b872d>] ? trace_hardirqs_on+0xd/0x10
 [<ffffffff816c547b>] ? _raw_spin_unlock_irq+0x3b/0x60
 [<ffffffff816cd767>] ? sysret_check+0x1b/0x56
 [<ffffffff810b8695>] ? trace_hardirqs_on_caller+0x115/0x1a0
 [<ffffffff81341d8e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [<ffffffff816cd742>] system_call_fastpath+0x16/0x1b
---[ end trace eed6ae990d018c8b ]---

Reported-by: Dave Jones <davej@redhat.com>
Cc: Dave Jones <davej@redhat.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
Signed-off-by: Cong Wang <amwang@redhat.com>
Acked-by: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
7bdd7e6
@gregnietsky gregnietsky referenced this pull request from a commit in Distrotech/linux
Cong Wang rds: limit the size allocated by rds_message_alloc()
[ Upstream commit ece6b0a ]

Dave Jones reported the following bug:

"When fed mangled socket data, rds will trust what userspace gives it,
and tries to allocate enormous amounts of memory larger than what
kmalloc can satisfy."

WARNING: at mm/page_alloc.c:2393 __alloc_pages_nodemask+0xa0d/0xbe0()
Hardware name: GA-MA78GM-S2H
Modules linked in: vmw_vsock_vmci_transport vmw_vmci vsock fuse bnep dlci bridge 8021q garp stp mrp binfmt_misc l2tp_ppp l2tp_core rfcomm s
Pid: 24652, comm: trinity-child2 Not tainted 3.8.0+ #65
Call Trace:
 [<ffffffff81044155>] warn_slowpath_common+0x75/0xa0
 [<ffffffff8104419a>] warn_slowpath_null+0x1a/0x20
 [<ffffffff811444ad>] __alloc_pages_nodemask+0xa0d/0xbe0
 [<ffffffff8100a196>] ? native_sched_clock+0x26/0x90
 [<ffffffff810b2128>] ? trace_hardirqs_off_caller+0x28/0xc0
 [<ffffffff810b21cd>] ? trace_hardirqs_off+0xd/0x10
 [<ffffffff811861f8>] alloc_pages_current+0xb8/0x180
 [<ffffffff8113eaaa>] __get_free_pages+0x2a/0x80
 [<ffffffff811934fe>] kmalloc_order_trace+0x3e/0x1a0
 [<ffffffff81193955>] __kmalloc+0x2f5/0x3a0
 [<ffffffff8104df0c>] ? local_bh_enable_ip+0x7c/0xf0
 [<ffffffffa0401ab3>] rds_message_alloc+0x23/0xb0 [rds]
 [<ffffffffa04043a1>] rds_sendmsg+0x2b1/0x990 [rds]
 [<ffffffff810b21cd>] ? trace_hardirqs_off+0xd/0x10
 [<ffffffff81564620>] sock_sendmsg+0xb0/0xe0
 [<ffffffff810b2052>] ? get_lock_stats+0x22/0x70
 [<ffffffff810b24be>] ? put_lock_stats.isra.23+0xe/0x40
 [<ffffffff81567f30>] sys_sendto+0x130/0x180
 [<ffffffff810b872d>] ? trace_hardirqs_on+0xd/0x10
 [<ffffffff816c547b>] ? _raw_spin_unlock_irq+0x3b/0x60
 [<ffffffff816cd767>] ? sysret_check+0x1b/0x56
 [<ffffffff810b8695>] ? trace_hardirqs_on_caller+0x115/0x1a0
 [<ffffffff81341d8e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [<ffffffff816cd742>] system_call_fastpath+0x16/0x1b
---[ end trace eed6ae990d018c8b ]---

Reported-by: Dave Jones <davej@redhat.com>
Cc: Dave Jones <davej@redhat.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
Signed-off-by: Cong Wang <amwang@redhat.com>
Acked-by: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
36561fe
@swarren swarren referenced this pull request from a commit in swarren/linux-tegra
Andrew Morton hugetlb-fix-copy_hugetlb_page_range-to-handle-migration-hwpoisoned-en…
…try-checkpatch-fixes

WARNING: Missing a blank line after declarations
#65: FILE: mm/hugetlb.c:2593:
+			swp_entry_t swp_entry = pte_to_swp_entry(entry);
+			if (is_write_migration_entry(swp_entry) && cow) {

total: 0 errors, 1 warnings, 90 lines checked

./patches/hugetlb-fix-copy_hugetlb_page_range-to-handle-migration-hwpoisoned-entry.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
3bac03f
@Naoya-Horiguchi Naoya-Horiguchi referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@andy-shev andy-shev referenced this pull request from a commit in andy-shev/linux
Andrew Morton mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable-ch…
…eckpatch-fixes

WARNING: Missing a blank line after declarations
#65: FILE: arch/x86/mm/numa.c:480:
+		struct numa_memblk *mb = &numa_meminfo.blk[i];
+		memblock_set_node(mb->start, mb->end - mb->start,

total: 0 errors, 1 warnings, 112 lines checked

./patches/mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Xishi Qiu <qiuxishi@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
197cf54
@Naoya-Horiguchi Naoya-Horiguchi referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@aryabinin aryabinin referenced this pull request from a commit in aryabinin/linux
Andrew Morton mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable-ch…
…eckpatch-fixes

WARNING: Missing a blank line after declarations
#65: FILE: arch/x86/mm/numa.c:480:
+		struct numa_memblk *mb = &numa_meminfo.blk[i];
+		memblock_set_node(mb->start, mb->end - mb->start,

total: 0 errors, 1 warnings, 112 lines checked

./patches/mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Xishi Qiu <qiuxishi@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
36f97b9
@swarren swarren referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@andy-shev andy-shev referenced this pull request from a commit in andy-shev/linux
Andrew Morton mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable-ch…
…eckpatch-fixes

WARNING: Missing a blank line after declarations
#65: FILE: arch/x86/mm/numa.c:480:
+		struct numa_memblk *mb = &numa_meminfo.blk[i];
+		memblock_set_node(mb->start, mb->end - mb->start,

total: 0 errors, 1 warnings, 112 lines checked

./patches/mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Xishi Qiu <qiuxishi@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0a01a23
@aryabinin aryabinin referenced this pull request from a commit in aryabinin/linux
Andrew Morton mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable-ch…
…eckpatch-fixes

WARNING: Missing a blank line after declarations
#65: FILE: arch/x86/mm/numa.c:480:
+		struct numa_memblk *mb = &numa_meminfo.blk[i];
+		memblock_set_node(mb->start, mb->end - mb->start,

total: 0 errors, 1 warnings, 112 lines checked

./patches/mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Xishi Qiu <qiuxishi@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
78a0a72
@koct9i koct9i referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@aryabinin aryabinin referenced this pull request from a commit in aryabinin/linux
Andrew Morton mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable-ch…
…eckpatch-fixes

WARNING: Missing a blank line after declarations
#65: FILE: arch/x86/mm/numa.c:480:
+		struct numa_memblk *mb = &numa_meminfo.blk[i];
+		memblock_set_node(mb->start, mb->end - mb->start,

total: 0 errors, 1 warnings, 112 lines checked

./patches/mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Xishi Qiu <qiuxishi@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
299ac29
@ddstreet ddstreet referenced this pull request from a commit in ddstreet/linux
Andrew Morton mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable-ch…
…eckpatch-fixes

WARNING: Missing a blank line after declarations
#65: FILE: arch/x86/mm/numa.c:480:
+		struct numa_memblk *mb = &numa_meminfo.blk[i];
+		memblock_set_node(mb->start, mb->end - mb->start,

total: 0 errors, 1 warnings, 112 lines checked

./patches/mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Xishi Qiu <qiuxishi@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
a65d856
@rperier rperier referenced this pull request from a commit in rperier/linux-rockchip
Andrew Morton mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable-ch…
…eckpatch-fixes

WARNING: Missing a blank line after declarations
#65: FILE: arch/x86/mm/numa.c:480:
+		struct numa_memblk *mb = &numa_meminfo.blk[i];
+		memblock_set_node(mb->start, mb->end - mb->start,

total: 0 errors, 1 warnings, 112 lines checked

./patches/mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Xishi Qiu <qiuxishi@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
159a7f2
@koct9i koct9i referenced this pull request from a commit in koct9i/linux
Andrew Morton mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable-ch…
…eckpatch-fixes

WARNING: Missing a blank line after declarations
#65: FILE: arch/x86/mm/numa.c:480:
+		struct numa_memblk *mb = &numa_meminfo.blk[i];
+		memblock_set_node(mb->start, mb->end - mb->start,

total: 0 errors, 1 warnings, 112 lines checked

./patches/mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Xishi Qiu <qiuxishi@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
5863d07
@tom3q tom3q referenced this pull request from a commit in tom3q/linux
Andrew Morton mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable-ch…
…eckpatch-fixes

WARNING: Missing a blank line after declarations
#65: FILE: arch/x86/mm/numa.c:480:
+		struct numa_memblk *mb = &numa_meminfo.blk[i];
+		memblock_set_node(mb->start, mb->end - mb->start,

total: 0 errors, 1 warnings, 112 lines checked

./patches/mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Xishi Qiu <qiuxishi@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
f7a7f9a
@swarren swarren referenced this pull request from a commit in swarren/linux-tegra
Andrew Morton mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable-ch…
…eckpatch-fixes

WARNING: Missing a blank line after declarations
#65: FILE: arch/x86/mm/numa.c:480:
+		struct numa_memblk *mb = &numa_meminfo.blk[i];
+		memblock_set_node(mb->start, mb->end - mb->start,

total: 0 errors, 1 warnings, 112 lines checked

./patches/mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Xishi Qiu <qiuxishi@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
8d71cc4
@aryabinin aryabinin referenced this pull request from a commit in aryabinin/linux
Andrew Morton mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable-ch…
…eckpatch-fixes

WARNING: Missing a blank line after declarations
#65: FILE: arch/x86/mm/numa.c:480:
+		struct numa_memblk *mb = &numa_meminfo.blk[i];
+		memblock_set_node(mb->start, mb->end - mb->start,

total: 0 errors, 1 warnings, 112 lines checked

./patches/mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Xishi Qiu <qiuxishi@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
3d199b7
@bengal bengal referenced this pull request from a commit in bengal/linux
Andrew Morton mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable-ch…
…eckpatch-fixes

WARNING: Missing a blank line after declarations
#65: FILE: arch/x86/mm/numa.c:480:
+		struct numa_memblk *mb = &numa_meminfo.blk[i];
+		memblock_set_node(mb->start, mb->end - mb->start,

total: 0 errors, 1 warnings, 112 lines checked

./patches/mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Xishi Qiu <qiuxishi@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ad4119a
@tom3q tom3q referenced this pull request from a commit in tom3q/linux
Andrew Morton mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable-ch…
…eckpatch-fixes

WARNING: Missing a blank line after declarations
#65: FILE: arch/x86/mm/numa.c:480:
+		struct numa_memblk *mb = &numa_meminfo.blk[i];
+		memblock_set_node(mb->start, mb->end - mb->start,

total: 0 errors, 1 warnings, 112 lines checked

./patches/mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Xishi Qiu <qiuxishi@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
d4a7ca9
@Gnurou Gnurou referenced this pull request from a commit in Gnurou/linux
Andrew Morton mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable-ch…
…eckpatch-fixes

WARNING: Missing a blank line after declarations
#65: FILE: arch/x86/mm/numa.c:480:
+		struct numa_memblk *mb = &numa_meminfo.blk[i];
+		memblock_set_node(mb->start, mb->end - mb->start,

total: 0 errors, 1 warnings, 112 lines checked

./patches/mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Xishi Qiu <qiuxishi@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
9c7ab6c
@rperier rperier referenced this pull request from a commit in rperier/linux-rockchip
Andrew Morton mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable-ch…
…eckpatch-fixes

WARNING: Missing a blank line after declarations
#65: FILE: arch/x86/mm/numa.c:480:
+		struct numa_memblk *mb = &numa_meminfo.blk[i];
+		memblock_set_node(mb->start, mb->end - mb->start,

total: 0 errors, 1 warnings, 112 lines checked

./patches/mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Xishi Qiu <qiuxishi@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
7ca0160
@tom3q tom3q referenced this pull request from a commit in tom3q/linux
Andrew Morton mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable-ch…
…eckpatch-fixes

WARNING: Missing a blank line after declarations
#65: FILE: arch/x86/mm/numa.c:480:
+		struct numa_memblk *mb = &numa_meminfo.blk[i];
+		memblock_set_node(mb->start, mb->end - mb->start,

total: 0 errors, 1 warnings, 112 lines checked

./patches/mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Xishi Qiu <qiuxishi@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
7cdc322
@rperier rperier referenced this pull request from a commit in rperier/linux-rockchip
Andrew Morton mm-compaction-always-update-cached-scanner-positions-fix-checkpatch-f…
…ixes

WARNING: Missing a blank line after declarations
#65: FILE: mm/compaction.c:1243:
+		unsigned long free_pfn = release_freepages(&cc->freepages);
+		cc->nr_freepages = 0;

total: 0 errors, 1 warnings, 47 lines checked

./patches/mm-compaction-always-update-cached-scanner-positions-fix.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
a8856ad
@aryabinin aryabinin referenced this pull request from a commit in aryabinin/linux
Andrew Morton mm-compaction-always-update-cached-scanner-positions-fix-checkpatch-f…
…ixes

WARNING: Missing a blank line after declarations
#65: FILE: mm/compaction.c:1243:
+		unsigned long free_pfn = release_freepages(&cc->freepages);
+		cc->nr_freepages = 0;

total: 0 errors, 1 warnings, 47 lines checked

./patches/mm-compaction-always-update-cached-scanner-positions-fix.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
3cc4a34
@Naoya-Horiguchi Naoya-Horiguchi referenced this pull request from a commit
Andrew Morton mm-compaction-always-update-cached-scanner-positions-fix-checkpatch-f…
…ixes

WARNING: Missing a blank line after declarations
#65: FILE: mm/compaction.c:1243:
+		unsigned long free_pfn = release_freepages(&cc->freepages);
+		cc->nr_freepages = 0;

total: 0 errors, 1 warnings, 47 lines checked

./patches/mm-compaction-always-update-cached-scanner-positions-fix.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
7cc6dcb
@aryabinin aryabinin referenced this pull request from a commit in aryabinin/linux
Andrew Morton mm-compaction-always-update-cached-scanner-positions-fix-checkpatch-f…
…ixes

WARNING: Missing a blank line after declarations
#65: FILE: mm/compaction.c:1243:
+		unsigned long free_pfn = release_freepages(&cc->freepages);
+		cc->nr_freepages = 0;

total: 0 errors, 1 warnings, 47 lines checked

./patches/mm-compaction-always-update-cached-scanner-positions-fix.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
d540c8c
@rperier rperier referenced this pull request from a commit in rperier/linux-rockchip
Andrew Morton mm-compaction-always-update-cached-scanner-positions-fix-checkpatch-f…
…ixes

WARNING: Missing a blank line after declarations
#65: FILE: mm/compaction.c:1243:
+		unsigned long free_pfn = release_freepages(&cc->freepages);
+		cc->nr_freepages = 0;

total: 0 errors, 1 warnings, 47 lines checked

./patches/mm-compaction-always-update-cached-scanner-positions-fix.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
83a0094
@vineetgarc vineetgarc referenced this pull request from a commit in foss-for-synopsys-dwc-arc-processors/linux
@vineetgarc vineetgarc ARC: signal handling robustify
A malicious signal handler / restorer can DOS the system by fudging the
user regs saved on stack, causing weird things such as sigreturn returning
to user mode PC but cpu state still being kernel mode....

Ensure that in sigreturn path status32 always has U bit; any other bogosity
(gargbage PC etc) will be taken care of by normal user mode exceptions mechanisms.

Reproducer signal handler:

    void handle_sig(int signo, siginfo_t *info, void *context)
    {
	ucontext_t *uc = context;
	struct user_regs_struct *regs = &(uc->uc_mcontext.regs);

	regs->scratch.status32 = 0;
    }

Before the fix, kernel would go off to weeds like below:

    --------->8-----------
    [ARCLinux]$ ./signal-test
    Path: /signal-test
    CPU: 0 PID: 61 Comm: signal-test Not tainted 4.0.0-rc5+ #65
    task: 8f177880 ti: 5ffe6000 task.ti: 8f15c000

    [ECR   ]: 0x00220200 => Invalid Write @ 0x00000010 by insn @ 0x00010698
    [EFA   ]: 0x00000010
    [BLINK ]: 0x2007c1ee
    [ERET  ]: 0x10698
    [STAT32]: 0x00000000 :                                   <--------
    BTA: 0x00010680	 SP: 0x5ffe7e48	 FP: 0x00000000
    LPS: 0x20003c6c	LPE: 0x20003c70	LPC: 0x00000000
    ...
    --------->8-----------

Reported-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
4257f1b
@torvalds torvalds referenced this pull request from a commit
@vineetgarc vineetgarc ARC: signal handling robustify
A malicious signal handler / restorer can DOS the system by fudging the
user regs saved on stack, causing weird things such as sigreturn returning
to user mode PC but cpu state still being kernel mode....

Ensure that in sigreturn path status32 always has U bit; any other bogosity
(gargbage PC etc) will be taken care of by normal user mode exceptions mechanisms.

Reproducer signal handler:

    void handle_sig(int signo, siginfo_t *info, void *context)
    {
	ucontext_t *uc = context;
	struct user_regs_struct *regs = &(uc->uc_mcontext.regs);

	regs->scratch.status32 = 0;
    }

Before the fix, kernel would go off to weeds like below:

    --------->8-----------
    [ARCLinux]$ ./signal-test
    Path: /signal-test
    CPU: 0 PID: 61 Comm: signal-test Not tainted 4.0.0-rc5+ #65
    task: 8f177880 ti: 5ffe6000 task.ti: 8f15c000

    [ECR   ]: 0x00220200 => Invalid Write @ 0x00000010 by insn @ 0x00010698
    [EFA   ]: 0x00000010
    [BLINK ]: 0x2007c1ee
    [ERET  ]: 0x10698
    [STAT32]: 0x00000000 :                                   <--------
    BTA: 0x00010680	 SP: 0x5ffe7e48	 FP: 0x00000000
    LPS: 0x20003c6c	LPE: 0x20003c70	LPC: 0x00000000
    ...
    --------->8-----------

Reported-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
e414081
@pranith pranith referenced this pull request from a commit in pranith/linux
@vineetgarc vineetgarc ARC: signal handling robustify
A malicious signal handler / restorer can DOS the system by fudging the
user regs saved on stack, causing weird things such as sigreturn returning
to user mode PC but cpu state still being kernel mode....

Ensure that in sigreturn path status32 always has U bit; any other bogosity
(gargbage PC etc) will be taken care of by normal user mode exceptions mechanisms.

Reproducer signal handler:

    void handle_sig(int signo, siginfo_t *info, void *context)
    {
	ucontext_t *uc = context;
	struct user_regs_struct *regs = &(uc->uc_mcontext.regs);

	regs->scratch.status32 = 0;
    }

Before the fix, kernel would go off to weeds like below:

    --------->8-----------
    [ARCLinux]$ ./signal-test
    Path: /signal-test
    CPU: 0 PID: 61 Comm: signal-test Not tainted 4.0.0-rc5+ #65
    task: 8f177880 ti: 5ffe6000 task.ti: 8f15c000

    [ECR   ]: 0x00220200 => Invalid Write @ 0x00000010 by insn @ 0x00010698
    [EFA   ]: 0x00000010
    [BLINK ]: 0x2007c1ee
    [ERET  ]: 0x10698
    [STAT32]: 0x00000000 :                                   <--------
    BTA: 0x00010680	 SP: 0x5ffe7e48	 FP: 0x00000000
    LPS: 0x20003c6c	LPE: 0x20003c70	LPC: 0x00000000
    ...
    --------->8-----------

Reported-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
9fee087
@damentz damentz referenced this pull request from a commit in zen-kernel/zen-kernel
@vineetgarc vineetgarc ARC: signal handling robustify
commit e414081 upstream.

A malicious signal handler / restorer can DOS the system by fudging the
user regs saved on stack, causing weird things such as sigreturn returning
to user mode PC but cpu state still being kernel mode....

Ensure that in sigreturn path status32 always has U bit; any other bogosity
(gargbage PC etc) will be taken care of by normal user mode exceptions mechanisms.

Reproducer signal handler:

    void handle_sig(int signo, siginfo_t *info, void *context)
    {
	ucontext_t *uc = context;
	struct user_regs_struct *regs = &(uc->uc_mcontext.regs);

	regs->scratch.status32 = 0;
    }

Before the fix, kernel would go off to weeds like below:

    --------->8-----------
    [ARCLinux]$ ./signal-test
    Path: /signal-test
    CPU: 0 PID: 61 Comm: signal-test Not tainted 4.0.0-rc5+ #65
    task: 8f177880 ti: 5ffe6000 task.ti: 8f15c000

    [ECR   ]: 0x00220200 => Invalid Write @ 0x00000010 by insn @ 0x00010698
    [EFA   ]: 0x00000010
    [BLINK ]: 0x2007c1ee
    [ERET  ]: 0x10698
    [STAT32]: 0x00000000 :                                   <--------
    BTA: 0x00010680	 SP: 0x5ffe7e48	 FP: 0x00000000
    LPS: 0x20003c6c	LPE: 0x20003c70	LPC: 0x00000000
    ...
    --------->8-----------

Reported-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
b3a1f88
@sunny256 sunny256 referenced this pull request from a commit in sunny256/linux
@vineetgarc vineetgarc ARC: signal handling robustify
[ Upstream commit e414081 ]

A malicious signal handler / restorer can DOS the system by fudging the
user regs saved on stack, causing weird things such as sigreturn returning
to user mode PC but cpu state still being kernel mode....

Ensure that in sigreturn path status32 always has U bit; any other bogosity
(gargbage PC etc) will be taken care of by normal user mode exceptions mechanisms.

Reproducer signal handler:

    void handle_sig(int signo, siginfo_t *info, void *context)
    {
	ucontext_t *uc = context;
	struct user_regs_struct *regs = &(uc->uc_mcontext.regs);

	regs->scratch.status32 = 0;
    }

Before the fix, kernel would go off to weeds like below:

    --------->8-----------
    [ARCLinux]$ ./signal-test
    Path: /signal-test
    CPU: 0 PID: 61 Comm: signal-test Not tainted 4.0.0-rc5+ #65
    task: 8f177880 ti: 5ffe6000 task.ti: 8f15c000

    [ECR   ]: 0x00220200 => Invalid Write @ 0x00000010 by insn @ 0x00010698
    [EFA   ]: 0x00000010
    [BLINK ]: 0x2007c1ee
    [ERET  ]: 0x10698
    [STAT32]: 0x00000000 :                                   <--------
    BTA: 0x00010680	 SP: 0x5ffe7e48	 FP: 0x00000000
    LPS: 0x20003c6c	LPE: 0x20003c70	LPC: 0x00000000
    ...
    --------->8-----------

Reported-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
654acb3
@otavio otavio referenced this pull request from a commit in Freescale/linux-fslc
@vineetgarc vineetgarc ARC: signal handling robustify
commit e414081 upstream.

A malicious signal handler / restorer can DOS the system by fudging the
user regs saved on stack, causing weird things such as sigreturn returning
to user mode PC but cpu state still being kernel mode....

Ensure that in sigreturn path status32 always has U bit; any other bogosity
(gargbage PC etc) will be taken care of by normal user mode exceptions mechanisms.

Reproducer signal handler:

    void handle_sig(int signo, siginfo_t *info, void *context)
    {
	ucontext_t *uc = context;
	struct user_regs_struct *regs = &(uc->uc_mcontext.regs);

	regs->scratch.status32 = 0;
    }

Before the fix, kernel would go off to weeds like below:

    --------->8-----------
    [ARCLinux]$ ./signal-test
    Path: /signal-test
    CPU: 0 PID: 61 Comm: signal-test Not tainted 4.0.0-rc5+ #65
    task: 8f177880 ti: 5ffe6000 task.ti: 8f15c000

    [ECR   ]: 0x00220200 => Invalid Write @ 0x00000010 by insn @ 0x00010698
    [EFA   ]: 0x00000010
    [BLINK ]: 0x2007c1ee
    [ERET  ]: 0x10698
    [STAT32]: 0x00000000 :                                   <--------
    BTA: 0x00010680	 SP: 0x5ffe7e48	 FP: 0x00000000
    LPS: 0x20003c6c	LPE: 0x20003c70	LPC: 0x00000000
    ...
    --------->8-----------

Reported-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
eb7b216
@otavio otavio referenced this pull request from a commit in Freescale/linux-fslc
@vineetgarc vineetgarc ARC: signal handling robustify
commit e414081 upstream.

A malicious signal handler / restorer can DOS the system by fudging the
user regs saved on stack, causing weird things such as sigreturn returning
to user mode PC but cpu state still being kernel mode....

Ensure that in sigreturn path status32 always has U bit; any other bogosity
(gargbage PC etc) will be taken care of by normal user mode exceptions mechanisms.

Reproducer signal handler:

    void handle_sig(int signo, siginfo_t *info, void *context)
    {
	ucontext_t *uc = context;
	struct user_regs_struct *regs = &(uc->uc_mcontext.regs);

	regs->scratch.status32 = 0;
    }

Before the fix, kernel would go off to weeds like below:

    --------->8-----------
    [ARCLinux]$ ./signal-test
    Path: /signal-test
    CPU: 0 PID: 61 Comm: signal-test Not tainted 4.0.0-rc5+ #65
    task: 8f177880 ti: 5ffe6000 task.ti: 8f15c000

    [ECR   ]: 0x00220200 => Invalid Write @ 0x00000010 by insn @ 0x00010698
    [EFA   ]: 0x00000010
    [BLINK ]: 0x2007c1ee
    [ERET  ]: 0x10698
    [STAT32]: 0x00000000 :                                   <--------
    BTA: 0x00010680	 SP: 0x5ffe7e48	 FP: 0x00000000
    LPS: 0x20003c6c	LPE: 0x20003c70	LPC: 0x00000000
    ...
    --------->8-----------

Reported-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
73a0285
@vineetgarc vineetgarc referenced this pull request from a commit in foss-for-synopsys-dwc-arc-processors/linux
@vineetgarc vineetgarc ARC: signal handling robustify
[ Upstream commit e414081 ]

A malicious signal handler / restorer can DOS the system by fudging the
user regs saved on stack, causing weird things such as sigreturn returning
to user mode PC but cpu state still being kernel mode....

Ensure that in sigreturn path status32 always has U bit; any other bogosity
(gargbage PC etc) will be taken care of by normal user mode exceptions mechanisms.

Reproducer signal handler:

    void handle_sig(int signo, siginfo_t *info, void *context)
    {
	ucontext_t *uc = context;
	struct user_regs_struct *regs = &(uc->uc_mcontext.regs);

	regs->scratch.status32 = 0;
    }

Before the fix, kernel would go off to weeds like below:

    --------->8-----------
    [ARCLinux]$ ./signal-test
    Path: /signal-test
    CPU: 0 PID: 61 Comm: signal-test Not tainted 4.0.0-rc5+ #65
    task: 8f177880 ti: 5ffe6000 task.ti: 8f15c000

    [ECR   ]: 0x00220200 => Invalid Write @ 0x00000010 by insn @ 0x00010698
    [EFA   ]: 0x00000010
    [BLINK ]: 0x2007c1ee
    [ERET  ]: 0x10698
    [STAT32]: 0x00000000 :                                   <--------
    BTA: 0x00010680	 SP: 0x5ffe7e48	 FP: 0x00000000
    LPS: 0x20003c6c	LPE: 0x20003c70	LPC: 0x00000000
    ...
    --------->8-----------

Reported-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
0aa81e9
@ddstreet ddstreet referenced this pull request from a commit in ddstreet/linux
mmotm auto import linux-next
GIT c5901c20eb0341722035975a272a2a7b647fbb32

commit eeb64c14275e52740d6410632e62e0ad9b88ca70
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date:   Sat Jun 6 11:44:39 2015 -0700

    tty/vt/keyboard: define LED triggers for VT keyboard lock states
    
    In addition to defining triggers for VT LED states, let's define triggers
    for VT keyboard lock states, such as "kbd-shiftlock", "kbd-altgrlock", etc.
    
    This permits to fix #7063 from userland by using a modifier to implement
    proper CapsLock behavior and have the keyboard caps lock led show that
    modifier state.
    
    Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
    Tested-by: Pavel Machek <pavel@ucw.cz>
    Acked-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

commit 5235552273e6b68abbed3b3047af6344e2e60c2c
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date:   Mon Mar 16 21:19:44 2015 -0700

    tty/vt/keyboard: define LED triggers for VT LED states
    
    Now that input core allows controlling keyboards LEDs via standard LED
    subsystem triggers let's switch VT keyboard code to make use of this
    feature. We will define the following standard triggers: "kbd-scrollock",
    "kbd-numlock", "kbd-capslock", and "kbd-kanalock" which are default
    triggers for respective LEDs on keyboards.
    
    Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
    Tested-by: Pavel Machek <pavel@ucw.cz>
    Acked-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

commit 10e87dc42a086c256b25334b6c1c89214feba9a7
Author: Andrew Duggan <aduggan@synaptics.com>
Date:   Tue Jun 16 14:08:41 2015 -0700

    HID: rmi: Disable populating F30 when the touchpad has physical buttons
    
    Physical buttons do not use F30 to report their state and in some cases the
    data reported in F30 is incorrect and inconsistent with what is reported by
    the HID descriptor. When physical buttons are present, ignore F30 and let
    hid-input report buttons based on what is defined in the HID descriptor.
    
    Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit ba8d134e75deb1904b146a4decb0bc6a217333cd
Author: Nishanth Menon <nm@ti.com>
Date:   Mon Apr 20 19:51:34 2015 -0500

    rtc: ds1307: Enable the mcp794xx alarm after programming time
    
    Alarm interrupt enable register is at offset 0x7, while the time
    registers for the alarm follow that. When we program Alarm interrupt
    enable prior to programming the time, it is possible that previous
    time value could be close or match at the time of alarm enable
    resulting in interrupt trigger which is unexpected (and does not match
    the time we expect it to trigger).
    
    To prevent this scenario from occuring, program the ALM0_EN bit only
    after the alarm time is appropriately programmed.
    
    Ofcourse, I2C programming is non-atomic, so there are loopholes where
    the interrupt wont trigger if the time requested is in the past at
    the time of programming the ALM0_EN bit. However, we will not have
    unexpected interrupts while the time is programmed after the interrupt
    are enabled.
    
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Reviewed-by: Grygorii Strashko <grygorii.strashko@linaro.org>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>

commit b7ae128d728c42583dac9db48dce9a44bc0fb900
Author: Robert Richter <rrichter@cavium.com>
Date:   Fri Jun 5 19:49:26 2015 +0200

    ahci: Add support for Cavium's ThunderX host controller
    
    This patch adds support for Cavium's ThunderX host controller. The
    controller resides on the SoC and is a AHCI compatible SATA controller
    with one port, compliant with Serial ATA 3.1 and AHCI Revision 1.31.
    There can exists multiple SATA controllers on the SoC.
    
    The controller depends on MSI-X support since the PCI ECAM controller
    on the SoC does not implement MSI nor lagacy intx interrupt support.
    Thus, during device initialization, if MSI fails MSI-X will be used to
    enable the device's interrupts.
    
    The controller uses non-standard BAR0 for its register range. The
    already existing device lookup (vendor and device id) that is already
    implemented for other host controllers is used to change the PCI BAR.
    
    Signed-off-by: Robert Richter <rrichter@cavium.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>

commit ee2aad42e4b6eaa9721196f07f7d5d8d049e6530
Author: Robert Richter <rrichter@cavium.com>
Date:   Fri Jun 5 19:49:25 2015 +0200

    ahci: Add generic MSI-X support for single interrupts to SATA PCI driver
    
    This patch adds generic MSI-X support for single interrupts to the
    SATA PCI driver. MSI-X support is needed for host controller that only
    have MSI-X support implemented, but no MSI or intx. This patch only
    adds support for single interrupts, multiple per-port MSI-X interrupts
    are not yet implemented.
    
    The new implementation still initializes MSIs first. Only if that
    fails, the code tries to enable MSI-X. If that fails too, setup is
    continued with intx interrupts.
    
    To not break other chips by this generic code change, there are the
    following precautions:
    
     * Interrupt ranges are not enabled at all.
    
     * Only single interrupt mode is enabled for msix cap devices. Thus,
       only one interrupt will be setup.
    
     * During the discussion with Tejun we agreed to change the init
       sequence from msix-msi-intx to msi-msix-intx. Thus, if a device
       offers msi and init does not fail, the msix init code will not be
       executed. This is equivalent to current code.
    
    With this, the code only setups single mode msix as a last resort if
    msi fails. No interrupt range is enabled at all. Only one interrupt
    will be enabled.
    
    tj: comment edits.
    
    Changes of the patch series:
    
    v5:
     * updated patch subject that the patch only implements single IRQ
     * moved Cavium specific code to a separate patch
     * detect Cavium ThunderX device with PCI_CLASS_STORAGE_SATA_AHCI
       instead of vendor/dev id
     * added more comments to the code
     * enable single msix support for all kind of devices (removing strict
       check)
     * rebased onto update libata/for-4.2 with patch 1, 2 applied
    
    v4:
     * removed implementation of ahci_init_intx()
     * improved patch descriptions
     * rebased onto libata/for-4.2
    
    v3:
     * store irq number in struct ahci_host_priv
     * change initialization order from msix-msi-intx to msi-msix-intx
     * improve comments in ahci_init_msix()
     * improve error message in ahci_init_msix()
     * do not enable MSI-X if MSI is actively disabled for the device
    
    v2:
     * determine irq vector from pci_dev->msi_list
    
    Based on a patch from Sunil Goutham <sgoutham@cavium.com>.
    
    Signed-off-by: Robert Richter <rrichter@cavium.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>

commit e0dd268a2c983acf2b52130b489b3b5724e26b39
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Fri Jun 12 00:35:43 2015 -0700

    leds: aat1290: pass flags parameter to devm_gpiod_get
    
    Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
    which appeared in v3.17-rc1, the gpiod_get* functions take an additional
    parameter that allows to specify direction and initial value for output.
    
    In this case the driver cannot easily be simplified but as the flags
    parameter will become mandatory soon this change is necessary
    beforehand.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
    Signed-off-by: Bryan Wu <cooloney@gmail.com>

commit c8e27605c687d2d628217bef721e955d4baa1ce1
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Fri Jun 12 00:32:23 2015 -0700

    leds: ktd2692: pass flags parameter to devm_gpiod_get
    
    Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
    which appeared in v3.17-rc1, the gpiod_get* functions take an additional
    parameter that allows to specify direction and initial value for output.
    
    In this case the driver cannot easily be simplified but as the flags
    parameter will become mandatory soon this change is necessary
    beforehand.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
    Signed-off-by: Bryan Wu <cooloney@gmail.com>

commit bc3e452003d02b8ec21546490aaed36003a83864
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:13:42 2015 -0400

    module: relocate module_init from init.h to module.h
    
    Modular users will always be users of init functionality, but
    users of init functionality are not necessarily always modules.
    
    Hence any functionality like module_init and module_exit would
    be more at home in the module.h file.  And module.h should
    explicitly include init.h to make the dependency clear.
    
    We've already done all the legwork needed to ensure that this
    move does not cause any build regressions due to implicit
    header file include assumptions about where module_init lives.
    
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Acked-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit b0c6d93014c8f2f53b70e9362b9fbec13b8e3aa0
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Mon Jun 15 09:56:26 2015 -0400

    MIPS: don't use module_init in non-modular cobalt/mtd.c file
    
    As of commit 34b1252bd91851f77f89fbb6829a04efad900f41 ("MIPS:
    Cobalt: Do not build MTD platform device registration code as module.")
    this file became built-in instead of modular.  So we should also
    stop using module_init as an alias for __initcall as that can be
    rather misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Direct use of __initcall is discouraged, vs prioritized ones.
    Use of device_initcall is consistent with what __initcall
    maps onto, and hence does not change the init order, making the
    impact of this change zero.
    
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: linux-mips@linux-mips.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 33d69ca12b44ef3c7be8f948ffa5a35652e1f2ff
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Mon Jun 15 16:48:22 2015 -0500

    drivers/leds: don't use module_init in non-modular leds-cobalt-raq.c
    
    This file is built for a bool Kconfig variable, and hence this
    code is either present or absent.  It currently can never be
    modular, so using module_init as an alias for __initcall can be
    somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    And since it can't be modular, we remove all the __exitcall
    stuff related to module_exit() -- it is dead code that won't
    ever be executed.
    
    Cc: Bryan Wu <cooloney@gmail.com>
    Cc: Richard Purdie <rpurdie@rpsys.net>
    Cc: Jacek Anaszewski <j.anaszewski@samsung.com>
    Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
    Cc: linux-leds@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 32e805e7c6a343894c95a3431973e8ddad4aa2cf
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri Jun 5 09:37:19 2015 -0400

    tile: add init.h to usb.c to avoid compile failure
    
    Pending header cleanups will reveal this file is using the
    init.h content implicitly with the following fail:
    
    arch/tile/kernel/usb.c:69:1: warning: data definition has no type or storage class [enabled by default]
    arch/tile/kernel/usb.c:69:1: error: type defaults to 'int' in declaration of 'arch_initcall'
    arch/tile/kernel/usb.c:69:1: warning: parameter names (without types) in function declaration [enabled by default]
    arch/tile/kernel/usb.c:62:19: warning: 'tilegx_usb_init' defined but not used
    
    Explicitly add init.h to get arch_initcall and avoid this.
    
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Cc: Chris Metcalf <cmetcalf@ezchip.com>
    Acked-by: Chris Metcalf <cmetcalf@ezchip.com>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 9b9cf81a2d1f5336de2bebae71a9f2b8d5f1a8de
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:13:42 2015 -0400

    arm: fix implicit #include <linux/init.h> in entry asm.
    
    They use the "_INIT" macro and friends, and hence need to
    source this header file, vs. relying on getting it implicitly.
    
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 70c4f78b23c69013c908222d55a07c96fea4bba1
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:13:42 2015 -0400

    x86: replace __init_or_module with __init in non-modular vsmp_64.c
    
    The __init_or_module is from commit 05e12e1c4c09cd35ac9f4e6af1e
    ("x86: fix 27-rc crash on vsmp due to paravirt during module load").
    
    But as of commit 70511134f61bd6e5eed19f767381f9fb3e762d49
    ("Revert "x86: don't compile vsmp_64 for 32bit") this file became
    obj-y and hence is now only for built-in.  That makes any
    "_or_module" support no longer necessary.
    
    We need to distinguish between the two in order to do some header
    reorganization between init.h and module.h and we don't want to
    be including module.h in non-modular code.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: x86@kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 77459a0feca4ae8757a905fd1791f039479e8e1e
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Wed Jun 3 11:20:05 2015 -0400

    drivers/clk: convert sunxi/clk-mod0.c to use builtin_platform_driver
    
    This driver builds based on obj-y and hence will not ever be
    modular.  Change it to use the non-modular registration so that it
    won't suffer a compile fail once a header move places the modular
    registration within the module.h file.
    
    Cc: "Emilio López" <emilio@elopez.com.ar>
    Cc: Mike Turquette <mturquette@linaro.org>
    Cc: Stephen Boyd <sboyd@codeaurora.org>
    Acked-by: Stephen Boyd <sboyd@codeaurora.org>
    Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
    Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
    Cc: linux-clk@vger.kernel.org
    Cc: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit e35415e59f86d6b546a3681e2cda4f22b5b142c0
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:10:58 2015 -0400

    drivers/power: Convert non-modular syscon-reboot to use builtin_platform_driver
    
    This file depends on Kconfig options all of which are a bool, so
    we use the appropriate registration function, which avoids us
    relying on an implicit inclusion of <module.h> which we are
    doing currently.
    
    While this currently works, we really don't want to be including
    the module.h header in non-modular code, which we'd be forced
    to do, pending some upcoming code relocation from init.h into
    module.h.  So we fix it now by using the non-modular equivalent.
    
    Cc: Sebastian Reichel <sre@kernel.org>
    Acked-By: Sebastian Reichel <sre@kernel.org>
    Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
    Cc: David Woodhouse <dwmw2@infradead.org>
    Cc: linux-pm@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 0159ae95e6a923f565937f10518aa3c919527733
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:10:57 2015 -0400

    drivers/soc: Convert non-modular soc-realview to use builtin_platform_driver
    
    This file depends on Kconfig SOC_REALVIEW which is a bool, so
    we use the appropriate registration function, which avoids us
    relying on an implicit inclusion of <module.h> which we are
    doing currently.
    
    While this currently works, we really don't want to be including
    the module.h header in non-modular code, which we'd be forced
    to do, pending some upcoming code relocation from init.h into
    module.h.  So we fix it now by using the non-modular equivalent.
    
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Linus Walleij <linus.walleij@linaro.org>
    Acked-by: Linus Walleij <linus.walleij@linaro.org>
    Cc: Axel Lin <axel.lin@ingics.com>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 7d4d9ed6ef5219857865dd57d425f9729d0a39ff
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:10:57 2015 -0400

    drivers/soc: Convert non-modular tegra/pmc to use builtin_platform_driver
    
    This file depends on Kconfig ARCH_TEGRA which is a bool, so
    we use the appropriate registration function, which avoids us
    relying on an implicit inclusion of <module.h> which we are
    doing currently.
    
    While this currently works, we really don't want to be including
    the module.h header in non-modular code, which we'd be forced
    to do, pending some upcoming code relocation from init.h into
    module.h.  So we fix it now by using the non-modular equivalent.
    
    Cc: Stephen Warren <swarren@wwwdotorg.org>
    Cc: Thierry Reding <thierry.reding@gmail.com>
    Cc: Alexandre Courbot <gnurou@gmail.com>
    Cc: linux-tegra@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 5b64127e0529387d4538ecc3dfd49248baf619c5
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:10:57 2015 -0400

    drivers/cpufreq: Convert non-modular s5pv210-cpufreq.c to use builtin_platform_driver
    
    This file depends on a Kconfig option which is a bool, so
    we use the appropriate registration function, which avoids us
    relying on an implicit inclusion of <module.h> which we are
    doing currently.
    
    While this currently works, we really don't want to be including
    the module.h header in non-modular code, which we'd be forced
    to do, pending some upcoming code relocation from init.h into
    module.h.  So we fix it now by using the non-modular equivalent.
    
    Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
    Cc: Viresh Kumar <viresh.kumar@linaro.org>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Cc: Kukjin Kim <kgene@kernel.org>
    Cc: linux-pm@vger.kernel.org
    Cc: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 090d1cf103725f583b3f41fc3185698ae5a7aa64
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:10:57 2015 -0400

    drivers/cpuidle: Convert non-modular drivers to use builtin_platform_driver
    
    All these drivers are configured with Kconfig options that are
    declared as bool.  Hence it is not possible for the code
    to be built as modular.  However the code is currently using the
    module_platform_driver() macro for driver registration.
    
    While this currently works, we really don't want to be including
    the module.h header in non-modular code, which we'll be forced
    to do, pending some upcoming code relocation from init.h into
    module.h.  So we fix it now by using the non-modular equivalent.
    
    Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
    Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
    Cc: Michal Simek <michal.simek@xilinx.com>
    Cc: linux-pm@vger.kernel.org
    Cc: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 1dda2b42db1bbc788bf6de0a8141a305484f963b
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:10:57 2015 -0400

    drivers/platform: Convert non-modular pdev_bus to use builtin_platform_driver
    
    This driver is configured with a Kconfig option that is
    declared as a bool.  Hence it is not possible for the code
    to be built as modular.  However the code is currently using
    the module_platform_driver() macro for driver registration.
    
    While this currently works, we really don't want to be including
    the module.h header in non-modular code, which we'll be forced
    to do, pending some upcoming code relocation from init.h into
    module.h.  So we fix it now by using the non-modular equivalent.
    And since we've already established that the code is non-modular,
    we can completely drop any code relating to module_exit.
    
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit f309d4443130bf814e991f836e919dca22df37ae
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:10:57 2015 -0400

    platform_device: better support builtin boilerplate avoidance
    
    We have macros that help reduce the boilerplate for modules
    that register with no extra init/exit complexity other than the
    most standard use case.  However we see an increasing number of
    non-modular drivers using these modular_driver() type register
    functions.
    
    There are several downsides to this:
    1) The code can appear modular to a reader of the code, and they
       won't know if the code really is modular without checking the
       Makefile and Kconfig to see if compilation is governed by a
       bool or tristate.
    2) Coders of drivers may be tempted to code up an __exit function
       that is never used, just in order to satisfy the required three
       args of the modular registration function.
    3) Non-modular code ends up including the <module.h> which increases
       CPP overhead that they don't need.
    4) It hinders us from performing better separation of the module
       init code and the generic init code.
    
    Here we introduce similar macros, with the mapping from module_driver
    to builtin_driver and similar, so that simple changes of:
    
      module_platform_driver()       --->  builtin_platform_driver()
      module_platform_driver_probe() --->  builtin_platform_driver_probe().
    
    can help us avoid #3 above, without having to code up the same
    __init functions and device_initcall() boilerplate.
    
    For non modular code, module_init becomes __initcall.  But direct use
    of __initcall is discouraged, vs. one of the priority categorized
    subgroups.  As __initcall gets mapped onto device_initcall, our
    use of device_initcall directly in this change means that the
    runtime impact is zero -- drivers will remain at level 6 in the
    initcall ordering.
    
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 5b00c1eb94e5936e5bf5cdd9ad1ddfbed0c39159
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 21:57:34 2015 -0400

    x86: perf_event_intel_pt.c: use arch_initcall to hook in enabling
    
    This was using module_init, but the current Kconfig situation is
    as follows:
    
    In arch/x86/kernel/cpu/Makefile:
    
      obj-$(CONFIG_CPU_SUP_INTEL)    += perf_event_intel_pt.o perf_event_intel_bts.o
    
    and in arch/x86/Kconfig.cpu:
    
      config CPU_SUP_INTEL
            default y
            bool "Support Intel processors" if PROCESSOR_SELECT
    
    So currently, the end user can not build this code into a module.
    If in the future, there is desire for this to be modular, then
    it can be changed to include <linux/module.h> and use module_init.
    
    But currently, in the non-modular case, a module_init becomes a
    device_initcall.  But this really isn't a device, so we should
    choose a more appropriate initcall bucket to put it in.
    
    The obvious choice here seems to be arch_initcall, but that does
    make it earlier than it was currently through device_initcall.
    As long as perf_pmu_register() is functional, we should be OK.
    
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: x86@kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit ca41d24cf56458a699b44e918c5a19b7077df422
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 21:57:34 2015 -0400

    x86: perf_event_intel_bts.c: use arch_initcall to hook in enabling
    
    This was using module_init, but the current Kconfig situation is
    as follows:
    
    In arch/x86/kernel/cpu/Makefile:
    
      obj-$(CONFIG_CPU_SUP_INTEL)    += perf_event_intel_pt.o perf_event_intel_bts.o
    
    and in arch/x86/Kconfig.cpu:
    
      config CPU_SUP_INTEL
            default y
            bool "Support Intel processors" if PROCESSOR_SELECT
    
    So currently, the end user can not build this code into a module.
    If in the future, there is desire for this to be modular, then
    it can be changed to include <linux/module.h> and use module_init.
    
    But currently, in the non-modular case, a module_init becomes a
    device_initcall.  But this really isn't a device, so we should
    choose a more appropriate initcall bucket to put it in.
    
    The obvious choice here seems to be arch_initcall, but that does
    make it earlier than it was currently through device_initcall.
    As long as perf_pmu_register() is functional, we should be OK.
    
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: x86@kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 44c5af96de8230ff7268500f48995f9fea5cffe7
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 21:57:34 2015 -0400

    mm/page_owner.c: use late_initcall to hook in enabling
    
    This was using module_init, but there is no way this code can
    be modular.  In the non-modular case, a module_init becomes a
    device_initcall, but this really isn't a device.   So we should
    choose a more appropriate initcall bucket to put it in.
    
    In order of execution, our close choices are:
    
     fs_initcall(fn)
     rootfs_initcall(fn)
     device_initcall(fn)
     late_initcall(fn)
    
    ..and since the initcall here goes after debugfs, we really
    should be post-rootfs, which means late_initcall makes the
    most sense here.
    
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: linux-mm@kvack.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 4c7217f1f0fe70af7b9e213ef16f1d2f4a4bacaf
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 21:57:34 2015 -0400

    lib/list_sort: use late_initcall to hook in self tests
    
    This was using module_init, but there is no way this code can
    be modular.  In the non-modular case, a module_init becomes a
    device_initcall, but this really isn't a device.   So we should
    choose a more appropriate initcall bucket to put it in.
    
    Assuming boot time self tests need to be observed over a console
    to be useful, and that the console device could possibly not be
    fully functional until after device_initcall, we move this to the
    late_initcall bucket, which is immediately after device_initcall.
    
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 89f08f64408b630df7d559223f63e616d0814509
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:08:21 2015 -0400

    arm: use subsys_initcall in non-modular pl320 IPC code
    
    The drivers/mailbox/pl320-ipc.o is dependent on config PL320_MBOX
    which is declared as a bool.  Hence the code is never going to be
    modular.  So using module_init as an alias for __initcall can be
    somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.  Also add an inclusion of init.h, as
    that was previously implicit.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of subsys_initcall (which
    seems to make sense for IPC code) will thus change this
    registration from level 6-device to level 4-subsys (i.e. slightly
    earlier).  However no impact of that small difference is expected.
    
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 6f114281c4ad543392f5b7c8345e11e103675cee
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:08:21 2015 -0400

    powerpc: don't use module_init for non-modular core hugetlb code
    
    The hugetlbpage.o is obj-y (always built in).  It will never
    be modular, so using module_init as an alias for __initcall is
    somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of arch_initcall (which
    makes sense for arch code) will thus change this registration
    from level 6-device to level 3-arch (i.e. slightly earlier).
    However no observable impact of that small difference has
    been observed during testing, or is expected.
    
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: linuxppc-dev@lists.ozlabs.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 383d14a5365879bc193d29ad2ed17ac5299753c3
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:08:21 2015 -0400

    powerpc: use subsys_initcall for Freescale Local Bus
    
    The FSL_SOC option is bool, and hence this code is either
    present or absent.  It will never be modular, so using
    module_init as an alias for __initcall is rather misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of subsys_initcall (which
    makes sense for bus code) will thus change this registration
    from level 6-device to level 4-subsys (i.e. slightly earlier).
    However no observable impact of that small difference has
    been observed during testing, or is expected.
    
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Scott Wood <scottwood@freescale.com>
    Acked-by: Scott Wood <scottwood@freescale.com>
    Cc: linuxppc-dev@lists.ozlabs.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 1206f53589237b7e00b9b0a4e42815f14aedad2d
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:08:21 2015 -0400

    x86: don't use module_init for non-modular core bootflag code
    
    The bootflag.o is obj-y (always built in).  It will never be
    modular, so using module_init as an alias for __initcall is
    somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of arch_initcall (which
    makes sense for arch code) will thus change this registration
    from level 6-device to level 3-arch (i.e. slightly earlier).
    However no observable impact of that small difference has
    been observed during testing, or is expected.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: x86@kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 55331060096f0e9a57356ec36476a49e4bf22bc1
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:08:20 2015 -0400

    netfilter: don't use module_init/exit in core IPV4 code
    
    The file net/ipv4/netfilter.o is created based on whether
    CONFIG_NETFILTER is set.  However that is defined as a bool, and
    hence this file with the core netfilter hooks will never be
    modular.  So using module_init as an alias for __initcall can be
    somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.  Also add an inclusion of init.h, as
    that was previously implicit here in the netfilter.c file.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of subsys_initcall (which
    seems to make sense for netfilter code) will thus change this
    registration from level 6-device to level 4-subsys (i.e. slightly
    earlier).  However no observable impact of that small difference
    has been observed during testing, or is expected. (i.e. the
    location of the netfilter messages in dmesg remains unchanged
    with respect to all the other surrounding messages.)
    
    As for the module_exit, rather than replace it with __exitcall,
    we simply remove it, since it appears only UML does anything
    with those, and even for UML, there is no relevant cleanup
    to be done here.
    
    Cc: Pablo Neira Ayuso <pablo@netfilter.org>
    Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Cc: Patrick McHardy <kaber@trash.net>
    Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: netfilter-devel@vger.kernel.org
    Cc: netdev@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit c013d5a4581203e074a1065e17378984544fcaef
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:08:20 2015 -0400

    fs/notify: don't use module_init for non-modular inotify_user code
    
    The INOTIFY_USER option is bool, and hence this code is either
    present or absent.  It will never be modular, so using
    module_init as an alias for __initcall is rather misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of fs_initcall (which
    makes sense for fs code) will thus change this registration
    from level 6-device to level 5-fs (i.e. slightly earlier).
    However no observable impact of that small difference has
    been observed during testing, or is expected.
    
    Cc: John McCutchan <john@johnmccutchan.com>
    Cc: Robert Love <rlove@rlove.org>
    Cc: Eric Paris <eparis@parisplace.org>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit a4bc6fc79f94c5b4f850aabca9c5249adc597094
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:08:20 2015 -0400

    mm: replace module_init usages with subsys_initcall in nommu.c
    
    Compiling some arm/m68k configs with "# CONFIG_MMU is not set" reveals
    two more instances of module_init being used for code that can't
    possibly be modular, as CONFIG_MMU is either on or off.
    
    We replace them with subsys_initcall as per what was done in other
    mmu-enabled code.
    
    Note that direct use of __initcall is discouraged, vs.  one of the
    priority categorized subgroups.  As __initcall gets mapped onto
    device_initcall, our use of subsys_initcall (which makes sense for these
    files) will thus change this registration from level 6-device to level
    4-subsys (i.e.  slightly earlier).
    
    One might think that core_initcall (l2) or postcore_initcall (l3) would
    be more appropriate for anything in mm/ but if we look at the actual init
    functions themselves, we see they are just sysctl setup stuff, and
    hence the choice of subsys_initcall (l4) seems reasonable.  At the same
    time it minimizes the risk of changing the priority too drastically all
    at once.  We can adjust further in the future.
    
    Also, a couple instances of missing ";" at EOL are fixed.
    
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: linux-mm@kvack.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 84c3e5bf1defc035d63869bbb0f5f80d276c1fc7
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Sun Jun 14 16:55:25 2015 -0400

    cris: don't use module_init for non-modular core eeprom.c code
    
    The eeprom.c code is compiled based on the Kconfig setting
    ETRAX_I2C_EEPROM, which is bool.  So the code is either built in
    or absent.  It will never be modular, so using module_init as an
    alias for __initcall is rather misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Direct use of __initcall is discouraged, vs prioritized ones.
    Use of device_initcall is consistent with what __initcall
    maps onto, and hence does not change the init order, making the
    impact of this change zero.   Should someone with real hardware
    for boot testing want to change it later to arch_initcall or
    something different, they can do that at a later date.
    
    Cc: Mikael Starvik <starvik@axis.com>
    Cc: Jesper Nilsson <jesper.nilsson@axis.com>
    Cc: linux-cris-kernel@axis.com
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 4d38e5c48f4095be21343869ad741676ab4e518f
Author: James Hogan <james.hogan@imgtec.com>
Date:   Fri Jun 5 22:17:18 2015 +0100

    tty/metag_da: Avoid module_init/module_exit in non-modular code
    
    The metag_da TTY driver can't get built as a module at the moment, but
    it still uses module_init() and module_exit(). Those macros are moving
    to module.h which isn't included by metag_da.c, which will result in the
    following build warnings (remarkably no build errors) and an apparent
    failure to boot as the TTY driver won't be loaded.
    
    drivers/tty/metag_da.c:660: warning: data definition has no type or storage class
    drivers/tty/metag_da.c:660: warning: type defaults to ‘int’ in declaration of ‘module_init’
    drivers/tty/metag_da.c:660: warning: parameter names (without types) in function declaration
    drivers/tty/metag_da.c:661: warning: data definition has no type or storage class
    drivers/tty/metag_da.c:661: warning: type defaults to ‘int’ in declaration of ‘module_exit’
    drivers/tty/metag_da.c:661: warning: parameter names (without types) in function declaration
    drivers/tty/metag_da.c:572: warning: ‘dashtty_init’ defined but not used
    drivers/tty/metag_da.c:645: warning: ‘dashtty_exit’ defined but not used
    drivers/tty/metag_da.c In function ‘dash_console_write’:
    drivers/tty/metag_da.c:670 : warning: passing argument 4 of ‘chancall’ discards qualifiers from pointer target type
    
    Instead of just adding the module.h include, now would be a good time to
    remove the use of these macros, replacing the module_init with
    device_initcall, and removing the exit function altogether since it
    isn't needed. If module support is added later the code can always be
    resurrected.
    
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Jiri Slaby <jslaby@suse.cz>
    Cc: linux-metag@vger.kernel.org
    Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 791ed0bb5558dfdc4040563bd0b7dc24450fa732
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:51 2015 -0400

    drivers/clk: don't use module_init in clk-nomadik.c which is non-modular
    
    The clk-nomadik.o is built for ARCH_NOMADIK -- which is bool, and
    hence this code is either present or absent.  It will never be
    modular, so using module_init as an alias for __initcall can be
    somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    Cc: Mike Turquette <mturquette@linaro.org>
    Cc: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 30e3c6428f18b5b8e78602a5a7cc653aee3bfe99
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:50 2015 -0400

    xtensa: don't use module_init for non-modular core network.c code
    
    The network.c code is piggybacking off of the arch independent
    CONFIG_NET, which is bool.  So the code is either built in or
    absent.  It will never be modular, so using module_init as an
    alias for __initcall is rather misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Direct use of __initcall is discouraged, vs prioritized ones.
    Use of device_initcall is consistent with what __initcall
    maps onto, and hence does not change the init order, making the
    impact of this change zero.   Should someone with real hardware
    for boot testing want to change it later to arch_initcall or
    something different, they can do that at a later date.
    
    Cc: Chris Zankel <chris@zankel.net>
    Cc: Max Filippov <jcmvbkbc@gmail.com>
    Cc: Thomas Meyer <thomas@m3y3r.de>
    Cc: linux-xtensa@linux-xtensa.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit b205118bdb4b515b4b4f5058aa9f5a12668386c3
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:50 2015 -0400

    sh: don't use module_init in non-modular psw.c code
    
    The psw.o is built for obj-y -- and hence this code is always
    present.  It will never be modular, so using module_init as an alias
    for __initcall can be somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Cc: Paul Mundt <lethal@linux-sh.org>
    Cc: linux-sh@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 1b4d5beecbeb4608a0fdb77c3b8ba182f0cfb4b6
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:50 2015 -0400

    mn10300: don't use module_init in non-modular flash.c code
    
    The flash.o is built for obj-y -- and hence this code is always
    present.  It will never be modular, so using module_init as an alias
    for __initcall can be somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Cc: David Howells <dhowells@redhat.com>
    Acked-by: David Howells <dhowells@redhat.com>
    Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
    Cc: linux-am33-list@redhat.com
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 15becabd89fa3fec6aa864fbd1b50b5b1871eee2
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:50 2015 -0400

    parisc64: don't use module_init for non-modular core perf code
    
    The perf.c code depends on CONFIG_64BIT, so it is either built-in
    or absent.  It will never be modular, so using module_init as an
    alias for __initcall is rather misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.  Aside from it not making sense, it also
    causes a ~10% increase in CPP overhead due to module.h having a
    large list of headers itself -- for example compare line counts:
    
     device_initcall() and <linux/init.h>
    	20238 arch/parisc/kernel/perf.i
    
     module_init() and <linux/module.h>
    	22194 arch/parisc/kernel/perf.i
    
    Direct use of __initcall is discouraged, vs prioritized ones.
    Use of device_initcall is consistent with what __initcall
    maps onto, and hence does not change the init order, making the
    impact of this change zero.   Should someone with real hardware
    for boot testing want to change it later to arch_initcall or
    something different, they can do that at a later date.
    
    Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
    Cc: Helge Deller <deller@gmx.de>
    Cc: linux-parisc@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit aed6850a1390c2b208b91b2fae0199fc14b94a26
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:50 2015 -0400

    parisc: don't use module_init for non-modular core pdc_cons code
    
    The pdc_cons.c code is always built in.  It will never be modular,
    so using module_init as an alias for __initcall is rather
    misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Direct use of __initcall is discouraged, vs prioritized ones.
    Use of device_initcall is consistent with what __initcall
    maps onto, and hence does not change the init order, making the
    impact of this change zero.   Should someone with real hardware
    for boot testing want to change it later to arch_initcall or
    something different, they can do that at a later date.
    
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
    Cc: Helge Deller <deller@gmx.de>
    Cc: linux-parisc@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 73de14e8cdc733bbc8eda006f813d5aa51511139
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:50 2015 -0400

    cris: don't use module_init for non-modular core intmem.c code
    
    The intmem.c code is always built in.  It will never be modular,
    so using module_init as an alias for __initcall is rather
    misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Direct use of __initcall is discouraged, vs prioritized ones.
    Use of device_initcall is consistent with what __initcall
    maps onto, and hence does not change the init order, making the
    impact of this change zero.   Should someone with real hardware
    for boot testing want to change it later to arch_initcall or
    something different, they can do that at a later date.
    
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Cc: Mikael Starvik <starvik@axis.com>
    Cc: Jesper Nilsson <jesper.nilsson@axis.com>
    Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
    Cc: linux-cris-kernel@axis.com
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 2a177fd1d92f669f8f493a61e195ff4e3c50f95f
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:50 2015 -0400

    ia64: don't use module_init in non-modular sim/simscsi.c code
    
    The simscsi.o is built for HP_SIMSCSI -- which is bool, and hence
    this code is either present or absent.  It will never be modular,
    so using module_init as an alias for __initcall can be somewhat
    misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    And since it can't be modular, we remove all the __exitcall
    stuff related to module_exit() -- it is dead code that won't
    ever be executed.
    
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: linux-ia64@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 2e21fa2d11ab61e1827bd5bb1e0e2484931d68e1
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:49 2015 -0400

    ia64: don't use module_init for non-modular core kernel/mca.c code
    
    The mca.c code is always built in.  It will never be modular,
    so using module_init as an alias for __initcall is rather
    misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Direct use of __initcall is discouraged, vs prioritized ones.
    Use of device_initcall is consistent with what __initcall
    maps onto, and hence does not change the init order, making the
    impact of this change zero.   Should someone with real hardware
    for boot testing want to change it later to arch_initcall or
    something different, they can do that at a later date.
    
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: linux-ia64@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 4a0ece7ceceab251e92e7f98e7926642a065727b
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:49 2015 -0400

    arm: don't use module_init in non-modular mach-vexpress/spc.c code
    
    The spc.o is built for ARCH_VEXPRESS_SPC -- which is bool, and hence
    this code is either present or absent.  It will never be modular,
    so using module_init as an alias for __initcall can be somewhat
    misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit a390a2f18147533359d4e45cb13438d42580da84
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:49 2015 -0400

    powerpc: don't use module_init in non-modular 83xx suspend code
    
    The suspend.o is built for SUSPEND -- which is bool, and hence
    this code is either present or absent.  It will never be modular,
    so using module_init as an alias for __initcall can be somewhat
    misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    Cc: Scott Wood <scottwood@freescale.com>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: linuxppc-dev@lists.ozlabs.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 8f6b9512ceadc6bd52777c299111dc642b4c65b6
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:49 2015 -0400

    powerpc: use device_initcall for registering rtc devices
    
    Currently these two RTC devices are in core platform code
    where it is not possible for them to be modular.  It will
    never be modular, so using module_init as an alias for
    __initcall can be somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- they will remain at level 6 in initcall ordering.
    
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Geoff Levand <geoff@infradead.org>
    Acked-by: Geoff Levand <geoff@infradead.org>
    Cc: linuxppc-dev@lists.ozlabs.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit d54b675a6b0007422dc13acbecdb1ca2b1a53aeb
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:49 2015 -0400

    x86: don't use module_init in non-modular devicetree.c code
    
    The devicetree.o is built for "OF" -- which is bool, and hence
    this code is either present or absent.  It will never be modular,
    so using module_init as an alias for __initcall can be somewhat
    misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: x86@kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 4711e2f9caedaa07e7cdcb5e058a18762d6be9b1
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:49 2015 -0400

    x86: don't use module_init in non-modular intel_mid_vrtc.c
    
    The X86_INTEL_MID option is bool, and hence this code is either
    present or absent.  It will never be modular, so using
    module_init as an alias for __initcall is rather misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: x86@kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 7cac34370a4dde12e6430c2f0985926d4ef0f459
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri Jun 5 11:25:18 2015 -0400

    frv: add module.h to mb93090-mb00/flash.c to avoid compile fail
    
    This file is built off of a tristate Kconfig option and also contains
    modular function calls so it should explicitly include module.h to
    avoid compile breakage during header shuffles done in the future.
    
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Cc: David Howells <dhowells@redhat.com>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 743492ccd53008736f169f242479bac6245f8379
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Wed Jun 3 15:45:21 2015 -0400

    drivers/cpufreq: include <module.h> for modular exynos-cpufreq.c code
    
    This file is built off of a tristate Kconfig option ("ARM_EXYNOS_CPUFREQ")
    and also contains modular function calls so it should explicitly include
    module.h to avoid compile breakage during pending header shuffles.
    
    Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
    Cc: Viresh Kumar <viresh.kumar@linaro.org>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Cc: Kukjin Kim <kgene@kernel.org>
    Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Cc: linux-pm@vger.kernel.org
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-samsung-soc@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit a7e9bc55cc144dc40e809e579bd932ef2ec324de
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:02:31 2015 -0400

    drivers/staging: include <module.h> for modular android tegra_ion code
    
    This file is built off of a tristate Kconfig option and also contains
    modular function calls so it should explicitly include module.h to
    avoid compile breakage during header shuffles done in the future.
    
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: "Arve Hj�nnev�g" <arve@android.com>
    Cc: Riley Andrews <riandrews@android.com>
    Cc: Stephen Warren <swarren@wwwdotorg.org>
    Cc: Thierry Reding <thierry.reding@gmail.com>
    Cc: Alexandre Courbot <gnurou@gmail.com>
    Cc: devel@driverdev.osuosl.org
    Cc: linux-tegra@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 88775588b71d28a9020a7faa4ad95bbf76d8bb45
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 21:29:53 2015 -0400

    crypto/asymmetric_keys: pkcs7_key_type needs module.h
    
    This driver builds off of the tristate CONFIG_PKCS7_TEST_KEY and calls
    module_init and module_exit. So it should explicitly include module.h
    to avoid compile breakage during header shuffles done in the future.
    
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: linux-crypto@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 0bbad249a6a4934203b50d574f5d5f9f480b389e
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:02:31 2015 -0400

    sh: mach-highlander/psw.c is tristate and should use module.h
    
    This file is controlled by a tristate Kconfig option, and hence
    needs to include module.h so that it can get module_init() once
    we relocate it from init.h into module.h in the future.
    
    Note that module_exit() appears to be missing from the driver, so
    it is questionable whether it would actually work for a removal
    and reload cycle if it was configured for a modular build.
    
    Cc: Paul Mundt <lethal@linux-sh.org>
    Cc: linux-sh@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit ca1c8e93c37e5a5e27e6149cd3612eb2247e0e4a
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:02:31 2015 -0400

    drivers/regulator: include <module.h> for modular max77802 code
    
    This file is built off of a tristate Kconfig option and also contains
    modular function calls so it should explicitly include module.h to
    avoid compile breakage during header shuffles done in the future.
    
    Cc: Liam Girdwood <lgirdwood@gmail.com>
    Cc: Mark Brown <broonie@kernel.org>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 5468f887bc861b2fe2fa24a44bc6a616a5d33a73
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:02:31 2015 -0400

    drivers/pcmcia: include <module.h> for modular xxs1500_ss code
    
    This file is built off of a tristate Kconfig option and also contains
    modular function calls so it should explicitly include module.h to
    avoid compile breakage during header shuffles done in the future.
    
    Cc: Wolfram Sang <wsa@the-dreams.de>
    Acked-by: Wolfram Sang <wsa@the-dreams.de>
    Cc: linux-pcmcia@lists.infradead.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit a1a0bec593623f49740d7900e4b862c534f219bf
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:02:30 2015 -0400

    drivers/hsi: include <module.h> for modular omap_ssi code
    
    These files are built off of a tristate Kconfig option and also contain
    modular function calls so they should explicitly include module.h to
    avoid compile breakage during header shuffles done in the future.
    
    We change the one header file wich gives us coverage on both files:
       drivers/hsi/controllers/omap_ssi.c
       drivers/hsi/controllers/omap_ssi_port.c
    
    Cc: Sebastian Reichel <sre@kernel.org>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 00fe614863eed7ca39fc72a307c6dff57b690476
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:02:30 2015 -0400

    drivers/gpu: in…
1fed0d9
@nirobin nirobin referenced this pull request from a commit in nirobin/linux
@vineetgarc vineetgarc ARC: signal handling robustify
commit e414081 upstream.

A malicious signal handler / restorer can DOS the system by fudging the
user regs saved on stack, causing weird things such as sigreturn returning
to user mode PC but cpu state still being kernel mode....

Ensure that in sigreturn path status32 always has U bit; any other bogosity
(gargbage PC etc) will be taken care of by normal user mode exceptions mechanisms.

Reproducer signal handler:

    void handle_sig(int signo, siginfo_t *info, void *context)
    {
	ucontext_t *uc = context;
	struct user_regs_struct *regs = &(uc->uc_mcontext.regs);

	regs->scratch.status32 = 0;
    }

Before the fix, kernel would go off to weeds like below:

    --------->8-----------
    [ARCLinux]$ ./signal-test
    Path: /signal-test
    CPU: 0 PID: 61 Comm: signal-test Not tainted 4.0.0-rc5+ #65
    task: 8f177880 ti: 5ffe6000 task.ti: 8f15c000

    [ECR   ]: 0x00220200 => Invalid Write @ 0x00000010 by insn @ 0x00010698
    [EFA   ]: 0x00000010
    [BLINK ]: 0x2007c1ee
    [ERET  ]: 0x10698
    [STAT32]: 0x00000000 :                                   <--------
    BTA: 0x00010680	 SP: 0x5ffe7e48	 FP: 0x00000000
    LPS: 0x20003c6c	LPE: 0x20003c70	LPC: 0x00000000
    ...
    --------->8-----------

Reported-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
dcaf4bf
@torvalds torvalds referenced this pull request from a commit
Peter Zijlstra module: Annotate module version magic
Due to the new lockdep checks in the coming patch, we go:

[    9.759380] ------------[ cut here ]------------
[    9.759389] WARNING: CPU: 31 PID: 597 at ../kernel/module.c:216 each_symbol_section+0x121/0x130()
[    9.759391] Modules linked in:
[    9.759393] CPU: 31 PID: 597 Comm: modprobe Not tainted 4.0.0-rc1+ #65
[    9.759393] Hardware name: Intel Corporation S2600GZ/S2600GZ, BIOS SE5C600.86B.02.02.0002.122320131210 12/23/2013
[    9.759396]  ffffffff817d8676 ffff880424567ca8 ffffffff8157e98b 0000000000000001
[    9.759398]  0000000000000000 ffff880424567ce8 ffffffff8105fbc7 ffff880424567cd8
[    9.759400]  0000000000000000 ffffffff810ec160 ffff880424567d40 0000000000000000
[    9.759400] Call Trace:
[    9.759407]  [<ffffffff8157e98b>] dump_stack+0x4f/0x7b
[    9.759410]  [<ffffffff8105fbc7>] warn_slowpath_common+0x97/0xe0
[    9.759412]  [<ffffffff810ec160>] ? section_objs+0x60/0x60
[    9.759414]  [<ffffffff8105fc2a>] warn_slowpath_null+0x1a/0x20
[    9.759415]  [<ffffffff810ed9c1>] each_symbol_section+0x121/0x130
[    9.759417]  [<ffffffff810eda01>] find_symbol+0x31/0x70
[    9.759420]  [<ffffffff810ef5bf>] load_module+0x20f/0x2660
[    9.759422]  [<ffffffff8104ef10>] ? __do_page_fault+0x190/0x4e0
[    9.759426]  [<ffffffff815880ec>] ? retint_restore_args+0x13/0x13
[    9.759427]  [<ffffffff815880ec>] ? retint_restore_args+0x13/0x13
[    9.759433]  [<ffffffff810ae73d>] ? trace_hardirqs_on_caller+0x11d/0x1e0
[    9.759437]  [<ffffffff812fcc0e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[    9.759439]  [<ffffffff815880ec>] ? retint_restore_args+0x13/0x13
[    9.759441]  [<ffffffff810f1ade>] SyS_init_module+0xce/0x100
[    9.759443]  [<ffffffff81587429>] system_call_fastpath+0x12/0x17
[    9.759445] ---[ end trace 9294429076a9c644 ]---

As per the comment this site should be fine, but lets wrap it in
preempt_disable() anyhow to placate lockdep.

Cc: Rusty Russell <rusty@rustcorp.com.au>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
926a59b
@shenki shenki referenced this pull request from a commit in shenki/linux
@vineetgarc vineetgarc ARC: signal handling robustify
BugLink: http://bugs.launchpad.net/bugs/1465613

commit e414081 upstream.

A malicious signal handler / restorer can DOS the system by fudging the
user regs saved on stack, causing weird things such as sigreturn returning
to user mode PC but cpu state still being kernel mode....

Ensure that in sigreturn path status32 always has U bit; any other bogosity
(gargbage PC etc) will be taken care of by normal user mode exceptions mechanisms.

Reproducer signal handler:

    void handle_sig(int signo, siginfo_t *info, void *context)
    {
	ucontext_t *uc = context;
	struct user_regs_struct *regs = &(uc->uc_mcontext.regs);

	regs->scratch.status32 = 0;
    }

Before the fix, kernel would go off to weeds like below:

    --------->8-----------
    [ARCLinux]$ ./signal-test
    Path: /signal-test
    CPU: 0 PID: 61 Comm: signal-test Not tainted 4.0.0-rc5+ #65
    task: 8f177880 ti: 5ffe6000 task.ti: 8f15c000

    [ECR   ]: 0x00220200 => Invalid Write @ 0x00000010 by insn @ 0x00010698
    [EFA   ]: 0x00000010
    [BLINK ]: 0x2007c1ee
    [ERET  ]: 0x10698
    [STAT32]: 0x00000000 :                                   <--------
    BTA: 0x00010680	 SP: 0x5ffe7e48	 FP: 0x00000000
    LPS: 0x20003c6c	LPE: 0x20003c70	LPC: 0x00000000
    ...
    --------->8-----------

Reported-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
[ luis: backported to 3.16: used Vineet's backport to 3.14 ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
1dfd81d
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Jan 2, 2014
  1. @ngatnicdotmil

    Update REPORTING-BUGS

    ngatnicdotmil authored
This page is out of date. Refresh to see the latest.
Showing with 6 additions and 9 deletions.
  1. +6 −9 REPORTING-BUGS
View
15 REPORTING-BUGS
@@ -59,8 +59,8 @@ Documentation/SecurityBugs for more information.
If you can't figure out which subsystem caused the issue, you should file
a bug in kernel.org bugzilla and send email to
-linux-kernel@vger.kernel.org, referencing the bugzilla URL. (For more
-information on the linux-kernel mailing list see
+linux-kernel@vger.kernel.org, referencing the bugzilla URL.
+(For more information on the linux-kernel mailing list see
http://www.tux.org/lkml/).
@@ -112,10 +112,8 @@ summary from [1.]>" for easy identification by the developers.
[4.1.] Kernel version (from /proc/version):
[4.2.] Kernel .config file:
[5.] Most recent kernel version which did not have the bug:
-[6.] Output of Oops.. message (if applicable) with symbolic information
- resolved (see Documentation/oops-tracing.txt)
-[7.] A small shell script or example program which triggers the
- problem (if possible)
+[6.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt)
+[7.] A small shell script or example program which triggers the problem (if possible)
[8.] Environment
[8.1.] Software (add the output of the ver_linux script here)
[8.2.] Processor information (from /proc/cpuinfo):
@@ -123,9 +121,8 @@ summary from [1.]>" for easy identification by the developers.
[8.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
[8.5.] PCI information ('lspci -vvv' as root)
[8.6.] SCSI information (from /proc/scsi/scsi)
-[8.7.] Other information that might be relevant to the problem
- (please look in /proc and include all information that you
- think to be relevant):
+[8.7.] Other information that might be relevant to the problem (please look in /proc and include all information that you
+think to be relevant):
[X.] Other notes, patches, fixes, workarounds:
Something went wrong with that request. Please try again.