As the new x86 CPU bootup printout format code maintainer, I am
taking immediate action to improve and clean (and thus indulge
my OCD) the reporting of the cores when coming up online.

Fix padding to a right-hand alignment, cleanup code and bind
reporting width to the max number of supported CPUs on the
system, like this:

 [    0.074509] smpboot: Booting Node   0, Processors:      #1  #2  #3  #4  #5  #6  #7 OK
 [    0.644008] smpboot: Booting Node   1, Processors:  #8  #9 #10 #11 #12 #13 #14 #15 OK
 [    1.245006] smpboot: Booting Node   2, Processors: #16 #17 #18 #19 #20 #21 #22 #23 OK
 [    1.864005] smpboot: Booting Node   3, Processors: #24 #25 #26 #27 #28 #29 #30 #31 OK
 [    2.489005] smpboot: Booting Node   4, Processors: #32 #33 #34 #35 #36 #37 #38 #39 OK
 [    3.093005] smpboot: Booting Node   5, Processors: #40 #41 #42 #43 #44 #45 #46 #47 OK
 [    3.698005] smpboot: Booting Node   6, Processors: #48 #49 #50 #51 #52 #53 #54 #55 OK
 [    4.304005] smpboot: Booting Node   7, Processors: #56 #57 #58 #59 #60 #61 #62 #63 OK
 [    4.961413] Brought up 64 CPUs

and this:

 [    0.072367] smpboot: Booting Node   0, Processors:    #1 #2 #3 #4 #5 #6 #7 OK
 [    0.686329] Brought up 8 CPUs

Signed-off-by: Borislav Petkov <[email protected]>
Cc: Libin <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>

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 <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: Linus Torvalds <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>

The nm10 gpio driver is being modified to recognize the Panther Point
LPC device as one of valid GPIO controllers.

BUG=chrome-os-partner:8612
TEST=manual
 . build the new kernel
 . observe that the gpio driver gets installed:
    localhost ~ # dmesg | grep gpio
    [    7.020200] nm10_gpio version 0.04 built on Mar 22 2012 at 20:47:08
    [    7.020220] gpiochip_find_base: found new base at 160
 . enable the write protect GPIO (hardkernel#57)
    localhost ~ # echo 217 > /sys/class/gpio/export
 . examine its value
    localhost ~ # cat /sys/class/gpio/gpio217/value
    0
 . short the pins and examine the value again
   localhost ~ # cat /sys/class/gpio/gpio217/value
   1
 . observe value change when the pins status changes

Change-Id: Idf354a64d5b964a37ee72b8e14fcedd3aab83654
Signed-off-by: Vadim Bendebury <[email protected]>
Reviewed-on: https://gerrit.chromium.org/gerrit/18928

…loop-during-umount-checkpatch-fixes

ERROR: code indent should use tabs where possible
torvalds#56: FILE: fs/ocfs2/dlm/dlmmaster.c:3087:
+                       if (tmp->type == DLM_MLE_MASTER) {$

WARNING: please, no spaces at the start of a line
torvalds#56: FILE: fs/ocfs2/dlm/dlmmaster.c:3087:
+                       if (tmp->type == DLM_MLE_MASTER) {$

WARNING: suspect code indent for conditional statements (23, 31)
torvalds#56: FILE: fs/ocfs2/dlm/dlmmaster.c:3087:
+                       if (tmp->type == DLM_MLE_MASTER) {
+                               ret = DLM_MIGRATE_RESPONSE_MASTERY_REF;

ERROR: code indent should use tabs where possible
torvalds#57: FILE: fs/ocfs2/dlm/dlmmaster.c:3088:
+                               ret = DLM_MIGRATE_RESPONSE_MASTERY_REF;$

WARNING: please, no spaces at the start of a line
torvalds#57: FILE: fs/ocfs2/dlm/dlmmaster.c:3088:
+                               ret = DLM_MIGRATE_RESPONSE_MASTERY_REF;$

ERROR: code indent should use tabs where possible
#58: FILE: fs/ocfs2/dlm/dlmmaster.c:3089:
+                               mlog(0, "%s:%.*s: master=%u, newmaster=%u, "$

WARNING: please, no spaces at the start of a line
#58: FILE: fs/ocfs2/dlm/dlmmaster.c:3089:
+                               mlog(0, "%s:%.*s: master=%u, newmaster=%u, "$

WARNING: quoted string split across lines
torvalds#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090:
+                               mlog(0, "%s:%.*s: master=%u, newmaster=%u, "
+                                               "telling master to get ref "

ERROR: code indent should use tabs where possible
torvalds#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090:
+                                               "telling master to get ref "$

WARNING: please, no spaces at the start of a line
torvalds#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090:
+                                               "telling master to get ref "$

WARNING: quoted string split across lines
torvalds#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091:
+                                               "telling master to get ref "
+                                               "for cleared out mle during "

ERROR: code indent should use tabs where possible
torvalds#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091:
+                                               "for cleared out mle during "$

WARNING: please, no spaces at the start of a line
torvalds#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091:
+                                               "for cleared out mle during "$

WARNING: quoted string split across lines
torvalds#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092:
+                                               "for cleared out mle during "
+                                               "migration\n", dlm->name,

ERROR: code indent should use tabs where possible
torvalds#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092:
+                                               "migration\n", dlm->name,$

WARNING: please, no spaces at the start of a line
torvalds#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092:
+                                               "migration\n", dlm->name,$

ERROR: code indent should use tabs where possible
torvalds#62: FILE: fs/ocfs2/dlm/dlmmaster.c:3093:
+                                               namelen, name, master,$

WARNING: please, no spaces at the start of a line
torvalds#62: FILE: fs/ocfs2/dlm/dlmmaster.c:3093:
+                                               namelen, name, master,$

ERROR: code indent should use tabs where possible
torvalds#63: FILE: fs/ocfs2/dlm/dlmmaster.c:3094:
+                                               new_master);$

WARNING: please, no spaces at the start of a line
torvalds#63: FILE: fs/ocfs2/dlm/dlmmaster.c:3094:
+                                               new_master);$

ERROR: code indent should use tabs where possible
torvalds#64: FILE: fs/ocfs2/dlm/dlmmaster.c:3095:
+                       }$

WARNING: please, no spaces at the start of a line
torvalds#64: FILE: fs/ocfs2/dlm/dlmmaster.c:3095:
+                       }$

total: 9 errors, 13 warnings, 20 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
      scripts/cleanfile

./patches/ocfs2-do-not-return-dlm_migrate_response_mastery_ref-to-avoid-endlessloop-during-umount.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: Joel Becker <[email protected]>
Cc: Mark Fasheh <[email protected]>
Cc: Xue jiufei <[email protected]>
Cc: jiangyiwen <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

…loop-during-umount-checkpatch-fixes

ERROR: code indent should use tabs where possible
torvalds#56: FILE: fs/ocfs2/dlm/dlmmaster.c:3087:
+                       if (tmp->type == DLM_MLE_MASTER) {$

WARNING: please, no spaces at the start of a line
torvalds#56: FILE: fs/ocfs2/dlm/dlmmaster.c:3087:
+                       if (tmp->type == DLM_MLE_MASTER) {$

WARNING: suspect code indent for conditional statements (23, 31)
torvalds#56: FILE: fs/ocfs2/dlm/dlmmaster.c:3087:
+                       if (tmp->type == DLM_MLE_MASTER) {
+                               ret = DLM_MIGRATE_RESPONSE_MASTERY_REF;

ERROR: code indent should use tabs where possible
torvalds#57: FILE: fs/ocfs2/dlm/dlmmaster.c:3088:
+                               ret = DLM_MIGRATE_RESPONSE_MASTERY_REF;$

WARNING: please, no spaces at the start of a line
torvalds#57: FILE: fs/ocfs2/dlm/dlmmaster.c:3088:
+                               ret = DLM_MIGRATE_RESPONSE_MASTERY_REF;$

ERROR: code indent should use tabs where possible
#58: FILE: fs/ocfs2/dlm/dlmmaster.c:3089:
+                               mlog(0, "%s:%.*s: master=%u, newmaster=%u, "$

WARNING: please, no spaces at the start of a line
#58: FILE: fs/ocfs2/dlm/dlmmaster.c:3089:
+                               mlog(0, "%s:%.*s: master=%u, newmaster=%u, "$

WARNING: quoted string split across lines
torvalds#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090:
+                               mlog(0, "%s:%.*s: master=%u, newmaster=%u, "
+                                               "telling master to get ref "

ERROR: code indent should use tabs where possible
torvalds#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090:
+                                               "telling master to get ref "$

WARNING: please, no spaces at the start of a line
torvalds#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090:
+                                               "telling master to get ref "$

WARNING: quoted string split across lines
torvalds#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091:
+                                               "telling master to get ref "
+                                               "for cleared out mle during "

ERROR: code indent should use tabs where possible
torvalds#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091:
+                                               "for cleared out mle during "$

WARNING: please, no spaces at the start of a line
torvalds#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091:
+                                               "for cleared out mle during "$

WARNING: quoted string split across lines
torvalds#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092:
+                                               "for cleared out mle during "
+                                               "migration\n", dlm->name,

ERROR: code indent should use tabs where possible
torvalds#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092:
+                                               "migration\n", dlm->name,$

WARNING: please, no spaces at the start of a line
torvalds#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092:
+                                               "migration\n", dlm->name,$

ERROR: code indent should use tabs where possible
torvalds#62: FILE: fs/ocfs2/dlm/dlmmaster.c:3093:
+                                               namelen, name, master,$

WARNING: please, no spaces at the start of a line
torvalds#62: FILE: fs/ocfs2/dlm/dlmmaster.c:3093:
+                                               namelen, name, master,$

ERROR: code indent should use tabs where possible
torvalds#63: FILE: fs/ocfs2/dlm/dlmmaster.c:3094:
+                                               new_master);$

WARNING: please, no spaces at the start of a line
torvalds#63: FILE: fs/ocfs2/dlm/dlmmaster.c:3094:
+                                               new_master);$

ERROR: code indent should use tabs where possible
torvalds#64: FILE: fs/ocfs2/dlm/dlmmaster.c:3095:
+                       }$

WARNING: please, no spaces at the start of a line
torvalds#64: FILE: fs/ocfs2/dlm/dlmmaster.c:3095:
+                       }$

total: 9 errors, 13 warnings, 20 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
      scripts/cleanfile

./patches/ocfs2-do-not-return-dlm_migrate_response_mastery_ref-to-avoid-endlessloop-during-umount.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: Joel Becker <[email protected]>
Cc: Mark Fasheh <[email protected]>
Cc: Xue jiufei <[email protected]>
Cc: jiangyiwen <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

WARNING: Missing a blank line after declarations
torvalds#46: FILE: mm/huge_memory.c:954:
+		struct page *endpage = page + HPAGE_PMD_NR;
+		atomic_add(HPAGE_PMD_NR, &page->_count);

WARNING: Missing a blank line after declarations
torvalds#57: FILE: mm/huge_memory.c:965:
+		struct page *endpage = page + HPAGE_PMD_NR;
+		while (page < endpage)

total: 0 errors, 2 warnings, 65 lines checked

./patches/mm-thp-fix-debug_pagealloc-oops-in-copy_page_rep.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: Hugh Dickins <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

There have been several times where I have had to rebuild a kernel to
cause a panic when hitting a WARN() in the code in order to get a crash
dump from a system.  Sometimes this is easy to do, other times (such as in
the case of a remote admin) it is not trivial to send new images to the
user.

A much easier method would be a switch to change the WARN() over to a
panic.  This makes debugging easier in that I can now test the actual
image the WARN() was seen on and I do not have to engage in remote
debugging.

This patch adds a panic_on_warn kernel parameter and
/proc/sys/kernel/panic_on_warn calls panic() in the warn_slowpath_common()
path.  The function will still print out the location of the warning.

An example of the panic_on_warn output:

The first line below is from the WARN_ON() to output the WARN_ON()'s
location.  After that the panic() output is displayed.

WARNING: CPU: 30 PID: 11698 at /home/prarit/dummy_module/dummy-module.c:25 init_dummy+0x1f/0x30 [dummy_module]()
Kernel panic - not syncing: panic_on_warn set ...

CPU: 30 PID: 11698 Comm: insmod Tainted: G        W  OE  3.17.0+ torvalds#57
Hardware name: Intel Corporation S2600CP/S2600CP, BIOS RMLSDP.86I.00.29.D696.1311111329 11/11/2013
 0000000000000000 000000008e3f87df ffff88080f093c38 ffffffff81665190
 0000000000000000 ffffffff818aea3d ffff88080f093cb8 ffffffff8165e2ec
 ffffffff00000008 ffff88080f093cc8 ffff88080f093c68 000000008e3f87df
Call Trace:
 [<ffffffff81665190>] dump_stack+0x46/0x58
 [<ffffffff8165e2ec>] panic+0xd0/0x204
 [<ffffffffa038e05f>] ? init_dummy+0x1f/0x30 [dummy_module]
 [<ffffffff81076b90>] warn_slowpath_common+0xd0/0xd0
 [<ffffffffa038e040>] ? dummy_greetings+0x40/0x40 [dummy_module]
 [<ffffffff81076c8a>] warn_slowpath_null+0x1a/0x20
 [<ffffffffa038e05f>] init_dummy+0x1f/0x30 [dummy_module]
 [<ffffffff81002144>] do_one_initcall+0xd4/0x210
 [<ffffffff811b52c2>] ? __vunmap+0xc2/0x110
 [<ffffffff810f8889>] load_module+0x16a9/0x1b30
 [<ffffffff810f3d30>] ? store_uevent+0x70/0x70
 [<ffffffff810f49b9>] ? copy_module_from_fd.isra.44+0x129/0x180
 [<ffffffff810f8ec6>] SyS_finit_module+0xa6/0xd0
 [<ffffffff8166cf29>] system_call_fastpath+0x12/0x17

Successfully tested by me.

hpa said: There is another very valid use for this: many operators would
rather a machine shuts down than being potentially compromised either
functionally or security-wise.

Signed-off-by: Prarit Bhargava <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Rusty Russell <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Masami Hiramatsu <[email protected]>
Cc: Fabian Frederick <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

There have been several times where I have had to rebuild a kernel to
cause a panic when hitting a WARN() in the code in order to get a crash
dump from a system.  Sometimes this is easy to do, other times (such as in
the case of a remote admin) it is not trivial to send new images to the
user.

A much easier method would be a switch to change the WARN() over to a
panic.  This makes debugging easier in that I can now test the actual
image the WARN() was seen on and I do not have to engage in remote
debugging.

This patch adds a panic_on_warn kernel parameter and
/proc/sys/kernel/panic_on_warn calls panic() in the warn_slowpath_common()
path.  The function will still print out the location of the warning.

An example of the panic_on_warn output:

The first line below is from the WARN_ON() to output the WARN_ON()'s
location.  After that the panic() output is displayed.

WARNING: CPU: 30 PID: 11698 at /home/prarit/dummy_module/dummy-module.c:25 init_dummy+0x1f/0x30 [dummy_module]()
Kernel panic - not syncing: panic_on_warn set ...

CPU: 30 PID: 11698 Comm: insmod Tainted: G        W  OE  3.17.0+ torvalds#57
Hardware name: Intel Corporation S2600CP/S2600CP, BIOS RMLSDP.86I.00.29.D696.1311111329 11/11/2013
 0000000000000000 000000008e3f87df ffff88080f093c38 ffffffff81665190
 0000000000000000 ffffffff818aea3d ffff88080f093cb8 ffffffff8165e2ec
 ffffffff00000008 ffff88080f093cc8 ffff88080f093c68 000000008e3f87df
Call Trace:
 [<ffffffff81665190>] dump_stack+0x46/0x58
 [<ffffffff8165e2ec>] panic+0xd0/0x204
 [<ffffffffa038e05f>] ? init_dummy+0x1f/0x30 [dummy_module]
 [<ffffffff81076b90>] warn_slowpath_common+0xd0/0xd0
 [<ffffffffa038e040>] ? dummy_greetings+0x40/0x40 [dummy_module]
 [<ffffffff81076c8a>] warn_slowpath_null+0x1a/0x20
 [<ffffffffa038e05f>] init_dummy+0x1f/0x30 [dummy_module]
 [<ffffffff81002144>] do_one_initcall+0xd4/0x210
 [<ffffffff811b52c2>] ? __vunmap+0xc2/0x110
 [<ffffffff810f8889>] load_module+0x16a9/0x1b30
 [<ffffffff810f3d30>] ? store_uevent+0x70/0x70
 [<ffffffff810f49b9>] ? copy_module_from_fd.isra.44+0x129/0x180
 [<ffffffff810f8ec6>] SyS_finit_module+0xa6/0xd0
 [<ffffffff8166cf29>] system_call_fastpath+0x12/0x17

Successfully tested by me.

hpa said: There is another very valid use for this: many operators would
rather a machine shuts down than being potentially compromised either
functionally or security-wise.

Signed-off-by: Prarit Bhargava <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Rusty Russell <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Masami Hiramatsu <[email protected]>
Acked-by: Yasuaki Ishimatsu <[email protected]>
Cc: Fabian Frederick <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

There have been several times where I have had to rebuild a kernel to
cause a panic when hitting a WARN() in the code in order to get a crash
dump from a system.  Sometimes this is easy to do, other times (such as in
the case of a remote admin) it is not trivial to send new images to the
user.

A much easier method would be a switch to change the WARN() over to a
panic.  This makes debugging easier in that I can now test the actual
image the WARN() was seen on and I do not have to engage in remote
debugging.

This patch adds a panic_on_warn kernel parameter and
/proc/sys/kernel/panic_on_warn calls panic() in the warn_slowpath_common()
path.  The function will still print out the location of the warning.

An example of the panic_on_warn output:

The first line below is from the WARN_ON() to output the WARN_ON()'s
location.  After that the panic() output is displayed.

WARNING: CPU: 30 PID: 11698 at /home/prarit/dummy_module/dummy-module.c:25 init_dummy+0x1f/0x30 [dummy_module]()
Kernel panic - not syncing: panic_on_warn set ...

CPU: 30 PID: 11698 Comm: insmod Tainted: G        W  OE  3.17.0+ torvalds#57
Hardware name: Intel Corporation S2600CP/S2600CP, BIOS RMLSDP.86I.00.29.D696.1311111329 11/11/2013
 0000000000000000 000000008e3f87df ffff88080f093c38 ffffffff81665190
 0000000000000000 ffffffff818aea3d ffff88080f093cb8 ffffffff8165e2ec
 ffffffff00000008 ffff88080f093cc8 ffff88080f093c68 000000008e3f87df
Call Trace:
 [<ffffffff81665190>] dump_stack+0x46/0x58
 [<ffffffff8165e2ec>] panic+0xd0/0x204
 [<ffffffffa038e05f>] ? init_dummy+0x1f/0x30 [dummy_module]
 [<ffffffff81076b90>] warn_slowpath_common+0xd0/0xd0
 [<ffffffffa038e040>] ? dummy_greetings+0x40/0x40 [dummy_module]
 [<ffffffff81076c8a>] warn_slowpath_null+0x1a/0x20
 [<ffffffffa038e05f>] init_dummy+0x1f/0x30 [dummy_module]
 [<ffffffff81002144>] do_one_initcall+0xd4/0x210
 [<ffffffff811b52c2>] ? __vunmap+0xc2/0x110
 [<ffffffff810f8889>] load_module+0x16a9/0x1b30
 [<ffffffff810f3d30>] ? store_uevent+0x70/0x70
 [<ffffffff810f49b9>] ? copy_module_from_fd.isra.44+0x129/0x180
 [<ffffffff810f8ec6>] SyS_finit_module+0xa6/0xd0
 [<ffffffff8166cf29>] system_call_fastpath+0x12/0x17

Successfully tested by me.

hpa said: There is another very valid use for this: many operators would
rather a machine shuts down than being potentially compromised either
functionally or security-wise.

Signed-off-by: Prarit Bhargava <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Rusty Russell <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Masami Hiramatsu <[email protected]>
Acked-by: Yasuaki Ishimatsu <[email protected]>
Cc: Fabian Frederick <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

There have been several times where I have had to rebuild a kernel to
cause a panic when hitting a WARN() in the code in order to get a crash
dump from a system.  Sometimes this is easy to do, other times (such as in
the case of a remote admin) it is not trivial to send new images to the
user.

A much easier method would be a switch to change the WARN() over to a
panic.  This makes debugging easier in that I can now test the actual
image the WARN() was seen on and I do not have to engage in remote
debugging.

This patch adds a panic_on_warn kernel parameter and
/proc/sys/kernel/panic_on_warn calls panic() in the warn_slowpath_common()
path.  The function will still print out the location of the warning.

An example of the panic_on_warn output:

The first line below is from the WARN_ON() to output the WARN_ON()'s
location.  After that the panic() output is displayed.

WARNING: CPU: 30 PID: 11698 at /home/prarit/dummy_module/dummy-module.c:25 init_dummy+0x1f/0x30 [dummy_module]()
Kernel panic - not syncing: panic_on_warn set ...

CPU: 30 PID: 11698 Comm: insmod Tainted: G        W  OE  3.17.0+ torvalds#57
Hardware name: Intel Corporation S2600CP/S2600CP, BIOS RMLSDP.86I.00.29.D696.1311111329 11/11/2013
 0000000000000000 000000008e3f87df ffff88080f093c38 ffffffff81665190
 0000000000000000 ffffffff818aea3d ffff88080f093cb8 ffffffff8165e2ec
 ffffffff00000008 ffff88080f093cc8 ffff88080f093c68 000000008e3f87df
Call Trace:
 [<ffffffff81665190>] dump_stack+0x46/0x58
 [<ffffffff8165e2ec>] panic+0xd0/0x204
 [<ffffffffa038e05f>] ? init_dummy+0x1f/0x30 [dummy_module]
 [<ffffffff81076b90>] warn_slowpath_common+0xd0/0xd0
 [<ffffffffa038e040>] ? dummy_greetings+0x40/0x40 [dummy_module]
 [<ffffffff81076c8a>] warn_slowpath_null+0x1a/0x20
 [<ffffffffa038e05f>] init_dummy+0x1f/0x30 [dummy_module]
 [<ffffffff81002144>] do_one_initcall+0xd4/0x210
 [<ffffffff811b52c2>] ? __vunmap+0xc2/0x110
 [<ffffffff810f8889>] load_module+0x16a9/0x1b30
 [<ffffffff810f3d30>] ? store_uevent+0x70/0x70
 [<ffffffff810f49b9>] ? copy_module_from_fd.isra.44+0x129/0x180
 [<ffffffff810f8ec6>] SyS_finit_module+0xa6/0xd0
 [<ffffffff8166cf29>] system_call_fastpath+0x12/0x17

Successfully tested by me.

hpa said: There is another very valid use for this: many operators would
rather a machine shuts down than being potentially compromised either
functionally or security-wise.

Signed-off-by: Prarit Bhargava <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Rusty Russell <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Masami Hiramatsu <[email protected]>
Acked-by: Yasuaki Ishimatsu <[email protected]>
Cc: Fabian Frederick <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

There have been several times where I have had to rebuild a kernel to
cause a panic when hitting a WARN() in the code in order to get a crash
dump from a system.  Sometimes this is easy to do, other times (such as
in the case of a remote admin) it is not trivial to send new images to
the user.

A much easier method would be a switch to change the WARN() over to a
panic.  This makes debugging easier in that I can now test the actual
image the WARN() was seen on and I do not have to engage in remote
debugging.

This patch adds a panic_on_warn kernel parameter and
/proc/sys/kernel/panic_on_warn calls panic() in the
warn_slowpath_common() path.  The function will still print out the
location of the warning.

An example of the panic_on_warn output:

The first line below is from the WARN_ON() to output the WARN_ON()'s
location.  After that the panic() output is displayed.

    WARNING: CPU: 30 PID: 11698 at /home/prarit/dummy_module/dummy-module.c:25 init_dummy+0x1f/0x30 [dummy_module]()
    Kernel panic - not syncing: panic_on_warn set ...

    CPU: 30 PID: 11698 Comm: insmod Tainted: G        W  OE  3.17.0+ #57
    Hardware name: Intel Corporation S2600CP/S2600CP, BIOS RMLSDP.86I.00.29.D696.1311111329 11/11/2013
     0000000000000000 000000008e3f87df ffff88080f093c38 ffffffff81665190
     0000000000000000 ffffffff818aea3d ffff88080f093cb8 ffffffff8165e2ec
     ffffffff00000008 ffff88080f093cc8 ffff88080f093c68 000000008e3f87df
    Call Trace:
     [<ffffffff81665190>] dump_stack+0x46/0x58
     [<ffffffff8165e2ec>] panic+0xd0/0x204
     [<ffffffffa038e05f>] ? init_dummy+0x1f/0x30 [dummy_module]
     [<ffffffff81076b90>] warn_slowpath_common+0xd0/0xd0
     [<ffffffffa038e040>] ? dummy_greetings+0x40/0x40 [dummy_module]
     [<ffffffff81076c8a>] warn_slowpath_null+0x1a/0x20
     [<ffffffffa038e05f>] init_dummy+0x1f/0x30 [dummy_module]
     [<ffffffff81002144>] do_one_initcall+0xd4/0x210
     [<ffffffff811b52c2>] ? __vunmap+0xc2/0x110
     [<ffffffff810f8889>] load_module+0x16a9/0x1b30
     [<ffffffff810f3d30>] ? store_uevent+0x70/0x70
     [<ffffffff810f49b9>] ? copy_module_from_fd.isra.44+0x129/0x180
     [<ffffffff810f8ec6>] SyS_finit_module+0xa6/0xd0
     [<ffffffff8166cf29>] system_call_fastpath+0x12/0x17

Successfully tested by me.

hpa said: There is another very valid use for this: many operators would
rather a machine shuts down than being potentially compromised either
functionally or security-wise.

Signed-off-by: Prarit Bhargava <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Rusty Russell <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Masami Hiramatsu <[email protected]>
Acked-by: Yasuaki Ishimatsu <[email protected]>
Cc: Fabian Frederick <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

The perf core implicitly rejects events spanning multiple HW PMUs, as in
these cases the event->ctx will differ. However this validation is
performed after pmu::event_init() is called in perf_init_event(), and
thus pmu::event_init() may be called with a group leader from a
different HW PMU.

The ARM PMU driver does not take this fact into account, and when
validating groups assumes that it can call to_arm_pmu(event->pmu) for
any HW event. When the event in question is from another HW PMU this is
wrong, and results in dereferencing garbage.

This patch updates the ARM PMU driver to first test for and reject
events from other PMUs, moving the to_arm_pmu and related logic after
this test. Fixes a crash triggered by perf_fuzzer on Linux-4.0-rc2, with
a CCI PMU present:

 ---
CPU: 0 PID: 1527 Comm: perf_fuzzer Not tainted 4.0.0-rc2 #57
Hardware name: ARM-Versatile Express
task: bd8484c0 ti: be676000 task.ti: be676000
PC is at 0xbf1bbc90
LR is at validate_event+0x34/0x5c
pc : [<bf1bbc90>]    lr : [<80016060>]    psr: 00000013
...
[<80016060>] (validate_event) from [<80016198>] (validate_group+0x28/0x90)
[<80016198>] (validate_group) from [<80016398>] (armpmu_event_init+0x150/0x218)
[<80016398>] (armpmu_event_init) from [<800882e4>] (perf_try_init_event+0x30/0x48)
[<800882e4>] (perf_try_init_event) from [<8008f544>] (perf_init_event+0x5c/0xf4)
[<8008f544>] (perf_init_event) from [<8008f8a8>] (perf_event_alloc+0x2cc/0x35c)
[<8008f8a8>] (perf_event_alloc) from [<8009015c>] (SyS_perf_event_open+0x498/0xa70)
[<8009015c>] (SyS_perf_event_open) from [<8000e420>] (ret_fast_syscall+0x0/0x34)
Code: bf1be000 bf1bb38 802a2664 00000000 (00000002)
---[ end trace 01aff0ff00926a0a ]---

Also cleans up the code to use the arm_pmu only when we know that
we are dealing with an arm pmu event.

Cc: Will Deacon <[email protected]>
Acked-by: Mark Rutland <[email protected]>
Acked-by: Peter Ziljstra (Intel) <[email protected]>
Signed-off-by: Suzuki K. Poulose <[email protected]>
Signed-off-by: Will Deacon <[email protected]>

…_0428

Fix console spurious char

Ci20 v3.18 audio fixup

On multi-function JMicron SATA/PATA/AHCI devices, the PATA controller at
function 1 doesn't work if it is powered on before the SATA controller at
function 0.  The result is that PATA doesn't work after resume, and we
print messages like this:

  pata_jmicron 0000:02:00.1: Refused to change power state, currently in D3
  irq 17: nobody cared (try booting with the "irqpoll" option)

Async resume was introduced in v3.15 by 76569fa ("PM / sleep:
Asynchronous threads for resume_noirq").  Prior to that, we powered on
the functions in order, so this problem shouldn't happen.

e6b7e41 ("ata: Disabling the async PM for JMicron chip 363/361")
solved the problem for JMicron 361 and 363 devices.  With async suspend
disabled, we always power on function 0 before function 1.

Barto then reported the same problem with a JMicron 368 (see comment #57 in
the bugzilla).

Rather than extending the blacklist piecemeal, disable async suspend for
all JMicron multi-function SATA/PATA/AHCI devices.

This quirk could stay in the ahci and pata_jmicron drivers, but it's likely
the problem will occur even if pata_jmicron isn't loaded until after the
suspend/resume.  Making it a PCI quirk ensures that we'll preserve the
power-on order even if the drivers aren't loaded.

[bhelgaas: changelog, limit to multi-function, limit to IDE/ATA]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=81551
Reported-and-tested-by: Barto <[email protected]>
Signed-off-by: Zhang Rui <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
CC: [email protected]	# v3.15+

commit 91f15fb upstream.

On multi-function JMicron SATA/PATA/AHCI devices, the PATA controller at
function 1 doesn't work if it is powered on before the SATA controller at
function 0.  The result is that PATA doesn't work after resume, and we
print messages like this:

  pata_jmicron 0000:02:00.1: Refused to change power state, currently in D3
  irq 17: nobody cared (try booting with the "irqpoll" option)

Async resume was introduced in v3.15 by 76569fa ("PM / sleep:
Asynchronous threads for resume_noirq").  Prior to that, we powered on
the functions in order, so this problem shouldn't happen.

e6b7e41 ("ata: Disabling the async PM for JMicron chip 363/361")
solved the problem for JMicron 361 and 363 devices.  With async suspend
disabled, we always power on function 0 before function 1.

Barto then reported the same problem with a JMicron 368 (see comment torvalds#57 in
the bugzilla).

Rather than extending the blacklist piecemeal, disable async suspend for
all JMicron multi-function SATA/PATA/AHCI devices.

This quirk could stay in the ahci and pata_jmicron drivers, but it's likely
the problem will occur even if pata_jmicron isn't loaded until after the
suspend/resume.  Making it a PCI quirk ensures that we'll preserve the
power-on order even if the drivers aren't loaded.

[bhelgaas: changelog, limit to multi-function, limit to IDE/ATA]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=81551
Reported-and-tested-by: Barto <[email protected]>
Signed-off-by: Zhang Rui <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 91f15fb upstream.

On multi-function JMicron SATA/PATA/AHCI devices, the PATA controller at
function 1 doesn't work if it is powered on before the SATA controller at
function 0.  The result is that PATA doesn't work after resume, and we
print messages like this:

  pata_jmicron 0000:02:00.1: Refused to change power state, currently in D3
  irq 17: nobody cared (try booting with the "irqpoll" option)

Async resume was introduced in v3.15 by 76569fa ("PM / sleep:
Asynchronous threads for resume_noirq").  Prior to that, we powered on
the functions in order, so this problem shouldn't happen.

e6b7e41 ("ata: Disabling the async PM for JMicron chip 363/361")
solved the problem for JMicron 361 and 363 devices.  With async suspend
disabled, we always power on function 0 before function 1.

Barto then reported the same problem with a JMicron 368 (see comment torvalds#57 in
the bugzilla).

Rather than extending the blacklist piecemeal, disable async suspend for
all JMicron multi-function SATA/PATA/AHCI devices.

This quirk could stay in the ahci and pata_jmicron drivers, but it's likely
the problem will occur even if pata_jmicron isn't loaded until after the
suspend/resume.  Making it a PCI quirk ensures that we'll preserve the
power-on order even if the drivers aren't loaded.

[bhelgaas: changelog, limit to multi-function, limit to IDE/ATA]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=81551
Reported-and-tested-by: Barto <[email protected]>
Signed-off-by: Zhang Rui <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

On 11/11/2015 03:35 AM, Dmitry Vyukov wrote:
> Hello,
>
> I've hit the following deadlock while running syzkaller on commit
> ce5c2d2 (Nov 7):
>
> [ INFO: possible circular locking dependency detected ]
> 4.3.0+ torvalds#57 Not tainted
> -------------------------------------------------------
> syzkaller_execu/24882 is trying to acquire lock:
>  (&tty->atomic_write_lock){+.+.+.}, at: [<ffffffff81774876>]
> tty_write_lock+0x46/0x70 drivers/tty/tty_io.c:1093
>
> but task is already holding lock:
>  (&tty->termios_rwsem){++++.+}, at: [<ffffffff817864d7>]
> n_tty_ioctl_helper+0x177/0x210 drivers/tty/tty_ioctl.c:1150
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (&tty->termios_rwsem){++++.+}:
>        [<ffffffff81122501>] lock_acquire+0x101/0x1d0 kernel/locking/lockdep.c:3585
>        [<ffffffff821727a9>] down_read+0x39/0x50 kernel/locking/rwsem.c:22
>        [<ffffffff8177eb07>] n_tty_write+0x137/0xaa0 drivers/tty/n_tty.c:2362
>        [<     inline     >] do_tty_write drivers/tty/tty_io.c:1164
>        [<ffffffff8177832e>] tty_write+0x28e/0x4f0 drivers/tty/tty_io.c:1248
>        [<ffffffff81778631>] redirected_tty_write+0xa1/0xb0 drivers/tty/tty_io.c:1269
>        [<ffffffff812d788b>] __vfs_write+0xeb/0x2a0 fs/read_write.c:489
>        [<ffffffff812d8a63>] vfs_write+0x113/0x290 fs/read_write.c:538
>        [<     inline     >] SYSC_write fs/read_write.c:585
>        [<ffffffff812da27b>] SyS_write+0xbb/0x170 fs/read_write.c:577
>        [<ffffffff82175fd1>] entry_SYSCALL_64_fastpath+0x31/0x9a
> arch/x86/entry/entry_64.S:187
>
> -> #0 (&tty->atomic_write_lock){+.+.+.}:
>        [<     inline     >] __mutex_lock_common kernel/locking/mutex.c:518
>        [<ffffffff82170525>] mutex_lock_interruptible_nested+0xa5/0x660 kernel/locking/mutex.c:647
>        [<ffffffff81774876>] tty_write_lock+0x46/0x70 drivers/tty/tty_io.c:1093
>        [<ffffffff8177a5a4>] tty_send_xchar+0x94/0x130 drivers/tty/tty_io.c:1289
>        [<ffffffff81786507>] n_tty_ioctl_helper+0x1a7/0x210 drivers/tty/tty_ioctl.c:1158
>        [<ffffffff8177f6e9>] n_tty_ioctl+0xe9/0x1e0 drivers/tty/n_tty.c:2514
>        [<ffffffff8177979c>] tty_ioctl+0xa4c/0x1650 drivers/tty/tty_io.c:2945
>        [<     inline     >] vfs_ioctl fs/ioctl.c:43
>        [<ffffffff812fdf0f>] do_vfs_ioctl+0x53f/0x980 fs/ioctl.c:607
>        [<     inline     >] SYSC_ioctl fs/ioctl.c:622
>        [<ffffffff812fe3df>] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:613
>        [<ffffffff82175fd1>] entry_SYSCALL_64_fastpath+0x31/0x9a
> arch/x86/entry/entry_64.S:187
>
> other info that might help us debug this:
>
>  Possible unsafe locking scenario:
>
>        CPU0                    CPU1
>        ----                    ----
>   lock(&tty->termios_rwsem);
>                                lock(&tty->atomic_write_lock);
>                                lock(&tty->termios_rwsem);
>   lock(&tty->atomic_write_lock);
>
>  *** DEADLOCK ***

Thanks for the report, Dmitry.
Please re-test with the accompanying patch.

Regards,
Peter Hurley

 fix exfat_super.c

Starting in 4.5-rc1, I noticed this warning on ipmi_si driver removal:

% modprobe ipmi_si
% rmmod ipmi_si

bus: 'platform': driver_probe_device: matched device IPI0001:00 with driver ipmi_si
bus: 'platform': really_probe: probing driver ipmi_si with device IPI0001:00
ipmi_si IPI0001:00: ipmi_si: probing via ACPI
ipmi_si IPI0001:00: [io  0x0ca2-0x0ca3] regsize 1 spacing 1 irq 0
ipmi_si: Adding ACPI-specified kcs state machine
driver: 'ipmi_si': driver_bound: bound to device 'IPI0001:00'
bus: 'platform': really_probe: bound device IPI0001:00 to driver ipmi_si
IPMI System Interface driver.
ipmi_si: probing via SMBIOS
ipmi_si: SMBIOS: io 0xda2 regsize 1 spacing 1 irq 0
ipmi_si: Adding SMBIOS-specified kcs state machine
ipmi_si: Trying ACPI-specified kcs state machine at i/o address 0xca2, slave address 0x0, irq 0
Registering platform device 'ipmi_bmc.0674.66'. Parent at platform
driver: 'ipmi': driver_bound: bound to device 'ipmi_bmc.0674.66'
ipmi_si IPI0001:00: Found new BMC (man_id: 0x000077, prod_id: 0x0674, dev_id: 0x42)
ipmi_si IPI0001:00: IPMI kcs interface initialized
------------[ cut here ]------------
WARNING: CPU: 39 PID: 3678 at drivers/base/power/common.c:150 dev_pm_domain_set+0x52/0x60()
PM domains can only be changed for unbound devices
[ ... snip ... ]
CPU: 39 PID: 3678 Comm: rmmod Tainted: G           OE   4.5.0-rc1+ torvalds#57
Hardware name: Stratus ftServer 6800/G7LYY, BIOS BIOS Version 8.1:61 09/10/2015
0000000000000000 000000003883b68d ffff8820334d7d30 ffffffff8132caf0
ffff8820334d7d78 ffff8820334d7d68 ffffffff8107f1b6 ffff8810351eca00
0000000000000000 0000000000000001 0000000001c2a330 0000000001c29010
Call Trace:
[<ffffffff8132caf0>] dump_stack+0x44/0x64
[<ffffffff8107f1b6>] warn_slowpath_common+0x86/0xc0
[<ffffffff8107f24c>] warn_slowpath_fmt+0x5c/0x80
[<ffffffff8145e152>] dev_pm_domain_set+0x52/0x60
[<ffffffff813a38ae>] acpi_dev_pm_detach+0x3f/0x84
[<ffffffff8145e0d7>] dev_pm_domain_detach+0x27/0x30
[<ffffffff814575f8>] platform_drv_remove+0x38/0x40
[<ffffffff814557ba>] __device_release_driver+0x9a/0x140
[<ffffffff81455968>] driver_detach+0xb8/0xc0
[<ffffffff814547b5>] bus_remove_driver+0x55/0xd0
[<ffffffff814560cc>] driver_unregister+0x2c/0x50
[<ffffffff814576b2>] platform_driver_unregister+0x12/0x20
[<ffffffffa02586c9>] cleanup_ipmi_si+0x29/0xa0 [ipmi_si]
[<ffffffff81102100>] SyS_delete_module+0x190/0x220
[<ffffffff8167ffee>] entry_SYSCALL_64_fastpath+0x12/0x71
---[ end trace 671ca97b9ac15462 ]---

My platform has two BMCs (perhaps this is messing with a refcount
somewhere), but I wonder about the ordering of this code:

__device_release_driver(struct device *dev)

  drv->remove(dev);
    [ platform_drv_remove ]
      ...
      dev_pm_domain_detach
        device_is_bound
          return dev->p && klist_node_attached(&dev->p->knode_driver)
  ...
  klist_remove(&dev->p->knode_driver);

Is the klist_remove at the bottom of __device_release_driver necessary
to satisfy the earlier check in dev_pm_domain_detach's device_is_bound
assertion?  If so, could these be out of order?

This is core driver code, so I'm assuming it's not something as simple
as the following (which avoided the warning on unload at least).  Any
suggestions or extra debugging ideas welcome!  This occurs on every
unload, so I'd be glad to test real solutions :)

Thanks,

-- Joe

-->8--

WARNING: 'occuring' may be misspelled - perhaps 'occurring'?
torvalds#57: FILE: mm/Kconfig.debug:74:
+	   zeros. This makes it harder to detect when errors are occuring

total: 0 errors, 1 warnings, 47 lines checked

./patches/mm-page_poisoningc-allow-for-zero-poisoning.patch has style problems, please review.

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

Please run checkpatch prior to sending patches

Cc: Laura Abbott <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

WARNING: 'occuring' may be misspelled - perhaps 'occurring'?
torvalds#57: FILE: mm/Kconfig.debug:74:
+	   zeros. This makes it harder to detect when errors are occuring

total: 0 errors, 1 warnings, 47 lines checked

./patches/mm-page_poisoningc-allow-for-zero-poisoning.patch has style problems, please review.

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

Please run checkpatch prior to sending patches

Cc: Laura Abbott <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

WARNING: 'occuring' may be misspelled - perhaps 'occurring'?
torvalds#57: FILE: mm/Kconfig.debug:74:
+	   zeros. This makes it harder to detect when errors are occuring

total: 0 errors, 1 warnings, 47 lines checked

./patches/mm-page_poisoningc-allow-for-zero-poisoning.patch has style problems, please review.

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

Please run checkpatch prior to sending patches

Cc: Laura Abbott <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

WARNING: 'occuring' may be misspelled - perhaps 'occurring'?
torvalds#57: FILE: mm/Kconfig.debug:74:
+	   zeros. This makes it harder to detect when errors are occuring

total: 0 errors, 1 warnings, 47 lines checked

./patches/mm-page_poisoningc-allow-for-zero-poisoning.patch has style problems, please review.

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

Please run checkpatch prior to sending patches

Cc: Laura Abbott <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

WARNING: 'occuring' may be misspelled - perhaps 'occurring'?
torvalds#57: FILE: mm/Kconfig.debug:74:
+	   zeros. This makes it harder to detect when errors are occuring

total: 0 errors, 1 warnings, 47 lines checked

./patches/mm-page_poisoningc-allow-for-zero-poisoning.patch has style problems, please review.

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

Please run checkpatch prior to sending patches

Cc: Laura Abbott <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

Hi,

Using checkpatch.pl on the forwarded patch results in:

WARNING: please write a paragraph that describes the config symbol fully
torvalds#57: FILE: mm/Kconfig:451:
+       config OVERCOMMIT_GUESS

WARNING: please write a paragraph that describes the config symbol fully
torvalds#64: FILE: mm/Kconfig:458:
+       config OVERCOMMIT_ALWAYS

but there is a 'help' section for those 'config' sections.
NOTE: I followed the same indentation than the code laying just above the place where I inserted mine.

I think it is a false positive, what do you think?

Best regards,

Sebastian

Message-ID: <[email protected]>
Date: Tue, 10 May 2016 13:56:30 +0200
From: Sebastian Frias <[email protected]>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
To: <[email protected]>, Andrew Morton <[email protected]>, "Michal
 Hocko" <[email protected]>, Linus Torvalds <[email protected]>
CC: LKML <[email protected]>, mason <[email protected]>
Subject: [PATCH] mm: add config option to select the initial overcommit mode
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0

Currently the initial value of the overcommit mode is OVERCOMMIT_GUESS.
However, on embedded systems it is usually better to disable overcommit
to avoid waking up the OOM-killer and its well known undesirable
side-effects.

This config option allows to setup the initial overcommit mode to any of
the 3 available values, OVERCOMMIT_GUESS (which remains as default),
OVERCOMMIT_ALWAYS and OVERCOMMIT_NEVER.
The overcommit mode can still be changed thru sysctl after the system
boots up.

This config option depends on CONFIG_EXPERT.
This patch does not introduces functional changes.

Signed-off-by: Sebastian Frias <[email protected]>

…ch-fixes

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#57: FILE: mm/madvise.c:1598:
+	if (is_memory_failure(behavior))
+	    return 0;

WARNING: Statements should start on a tabstop
#58: FILE: mm/madvise.c:1599:
+	    return 0;

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#72: FILE: mm/madvise.c:1612:
+	if (is_memory_failure(behavior))
+	    return;

WARNING: Statements should start on a tabstop
torvalds#73: FILE: mm/madvise.c:1613:
+	    return;

Please run checkpatch prior to sending patches

Cc: Lorenzo Stoakes <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

…ch-fixes

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#57: FILE: mm/madvise.c:1598:
+	if (is_memory_failure(behavior))
+	    return 0;

WARNING: Statements should start on a tabstop
#58: FILE: mm/madvise.c:1599:
+	    return 0;

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#72: FILE: mm/madvise.c:1612:
+	if (is_memory_failure(behavior))
+	    return;

WARNING: Statements should start on a tabstop
torvalds#73: FILE: mm/madvise.c:1613:
+	    return;

Please run checkpatch prior to sending patches

Cc: Lorenzo Stoakes <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

…ch-fixes

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#57: FILE: mm/madvise.c:1598:
+	if (is_memory_failure(behavior))
+	    return 0;

WARNING: Statements should start on a tabstop
#58: FILE: mm/madvise.c:1599:
+	    return 0;

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#72: FILE: mm/madvise.c:1612:
+	if (is_memory_failure(behavior))
+	    return;

WARNING: Statements should start on a tabstop
torvalds#73: FILE: mm/madvise.c:1613:
+	    return;

Please run checkpatch prior to sending patches

Cc: Lorenzo Stoakes <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

…ch-fixes

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#57: FILE: mm/madvise.c:1598:
+	if (is_memory_failure(behavior))
+	    return 0;

WARNING: Statements should start on a tabstop
#58: FILE: mm/madvise.c:1599:
+	    return 0;

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#72: FILE: mm/madvise.c:1612:
+	if (is_memory_failure(behavior))
+	    return;

WARNING: Statements should start on a tabstop
torvalds#73: FILE: mm/madvise.c:1613:
+	    return;

Please run checkpatch prior to sending patches

Cc: Lorenzo Stoakes <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

…ch-fixes

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#57: FILE: mm/madvise.c:1598:
+	if (is_memory_failure(behavior))
+	    return 0;

WARNING: Statements should start on a tabstop
#58: FILE: mm/madvise.c:1599:
+	    return 0;

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#72: FILE: mm/madvise.c:1612:
+	if (is_memory_failure(behavior))
+	    return;

WARNING: Statements should start on a tabstop
torvalds#73: FILE: mm/madvise.c:1613:
+	    return;

Please run checkpatch prior to sending patches

Cc: Lorenzo Stoakes <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

…ch-fixes

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#57: FILE: mm/madvise.c:1598:
+	if (is_memory_failure(behavior))
+	    return 0;

WARNING: Statements should start on a tabstop
#58: FILE: mm/madvise.c:1599:
+	    return 0;

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#72: FILE: mm/madvise.c:1612:
+	if (is_memory_failure(behavior))
+	    return;

WARNING: Statements should start on a tabstop
torvalds#73: FILE: mm/madvise.c:1613:
+	    return;

Please run checkpatch prior to sending patches

Cc: Lorenzo Stoakes <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

…ch-fixes

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#57: FILE: mm/madvise.c:1598:
+	if (is_memory_failure(behavior))
+	    return 0;

WARNING: Statements should start on a tabstop
#58: FILE: mm/madvise.c:1599:
+	    return 0;

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#72: FILE: mm/madvise.c:1612:
+	if (is_memory_failure(behavior))
+	    return;

WARNING: Statements should start on a tabstop
torvalds#73: FILE: mm/madvise.c:1613:
+	    return;

Please run checkpatch prior to sending patches

Cc: Lorenzo Stoakes <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

…ch-fixes

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#57: FILE: mm/madvise.c:1598:
+	if (is_memory_failure(behavior))
+	    return 0;

WARNING: Statements should start on a tabstop
#58: FILE: mm/madvise.c:1599:
+	    return 0;

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#72: FILE: mm/madvise.c:1612:
+	if (is_memory_failure(behavior))
+	    return;

WARNING: Statements should start on a tabstop
torvalds#73: FILE: mm/madvise.c:1613:
+	    return;

Please run checkpatch prior to sending patches

Cc: Lorenzo Stoakes <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

…ch-fixes

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#57: FILE: mm/madvise.c:1598:
+	if (is_memory_failure(behavior))
+	    return 0;

WARNING: Statements should start on a tabstop
#58: FILE: mm/madvise.c:1599:
+	    return 0;

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#72: FILE: mm/madvise.c:1612:
+	if (is_memory_failure(behavior))
+	    return;

WARNING: Statements should start on a tabstop
torvalds#73: FILE: mm/madvise.c:1613:
+	    return;

Please run checkpatch prior to sending patches

Cc: Lorenzo Stoakes <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

…ch-fixes

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#57: FILE: mm/madvise.c:1598:
+	if (is_memory_failure(behavior))
+	    return 0;

WARNING: Statements should start on a tabstop
#58: FILE: mm/madvise.c:1599:
+	    return 0;

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#72: FILE: mm/madvise.c:1612:
+	if (is_memory_failure(behavior))
+	    return;

WARNING: Statements should start on a tabstop
torvalds#73: FILE: mm/madvise.c:1613:
+	    return;

Please run checkpatch prior to sending patches

Cc: Lorenzo Stoakes <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

…ch-fixes

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#57: FILE: mm/madvise.c:1598:
+	if (is_memory_failure(behavior))
+	    return 0;

WARNING: Statements should start on a tabstop
#58: FILE: mm/madvise.c:1599:
+	    return 0;

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#72: FILE: mm/madvise.c:1612:
+	if (is_memory_failure(behavior))
+	    return;

WARNING: Statements should start on a tabstop
torvalds#73: FILE: mm/madvise.c:1613:
+	    return;

Please run checkpatch prior to sending patches

Cc: Lorenzo Stoakes <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

…ch-fixes

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#57: FILE: mm/madvise.c:1598:
+	if (is_memory_failure(behavior))
+	    return 0;

WARNING: Statements should start on a tabstop
#58: FILE: mm/madvise.c:1599:
+	    return 0;

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#72: FILE: mm/madvise.c:1612:
+	if (is_memory_failure(behavior))
+	    return;

WARNING: Statements should start on a tabstop
torvalds#73: FILE: mm/madvise.c:1613:
+	    return;

Please run checkpatch prior to sending patches

Cc: Lorenzo Stoakes <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

…ch-fixes

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#57: FILE: mm/madvise.c:1598:
+	if (is_memory_failure(behavior))
+	    return 0;

WARNING: Statements should start on a tabstop
#58: FILE: mm/madvise.c:1599:
+	    return 0;

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#72: FILE: mm/madvise.c:1612:
+	if (is_memory_failure(behavior))
+	    return;

WARNING: Statements should start on a tabstop
torvalds#73: FILE: mm/madvise.c:1613:
+	    return;

Please run checkpatch prior to sending patches

Cc: Lorenzo Stoakes <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

…ch-fixes

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#57: FILE: mm/madvise.c:1598:
+	if (is_memory_failure(behavior))
+	    return 0;

WARNING: Statements should start on a tabstop
#58: FILE: mm/madvise.c:1599:
+	    return 0;

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#72: FILE: mm/madvise.c:1612:
+	if (is_memory_failure(behavior))
+	    return;

WARNING: Statements should start on a tabstop
torvalds#73: FILE: mm/madvise.c:1613:
+	    return;

Please run checkpatch prior to sending patches

Cc: Lorenzo Stoakes <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

…ch-fixes

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#57: FILE: mm/madvise.c:1598:
+	if (is_memory_failure(behavior))
+	    return 0;

WARNING: Statements should start on a tabstop
#58: FILE: mm/madvise.c:1599:
+	    return 0;

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#72: FILE: mm/madvise.c:1612:
+	if (is_memory_failure(behavior))
+	    return;

WARNING: Statements should start on a tabstop
torvalds#73: FILE: mm/madvise.c:1613:
+	    return;

Please run checkpatch prior to sending patches

Cc: Lorenzo Stoakes <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

…ch-fixes

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#57: FILE: mm/madvise.c:1598:
+	if (is_memory_failure(behavior))
+	    return 0;

WARNING: Statements should start on a tabstop
#58: FILE: mm/madvise.c:1599:
+	    return 0;

WARNING: suspect code indent for conditional statements (8, 12)
torvalds#72: FILE: mm/madvise.c:1612:
+	if (is_memory_failure(behavior))
+	    return;

WARNING: Statements should start on a tabstop
torvalds#73: FILE: mm/madvise.c:1613:
+	    return;

Please run checkpatch prior to sending patches

Cc: Lorenzo Stoakes <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

WARNING: please, no space before tabs
torvalds#56: FILE: mm/shmem.c:5216:
+^I.uffd_features^I= ^I__VM_UFFD_FLAGS,$

WARNING: please, no space before tabs
torvalds#57: FILE: mm/shmem.c:5217:
+^I.uffd_ioctls^I= ^IBIT(_UFFDIO_COPY) |$

Cc: Peter Xu <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

WARNING: please, no space before tabs
torvalds#56: FILE: mm/shmem.c:5216:
+^I.uffd_features^I= ^I__VM_UFFD_FLAGS,$

WARNING: please, no space before tabs
torvalds#57: FILE: mm/shmem.c:5217:
+^I.uffd_ioctls^I= ^IBIT(_UFFDIO_COPY) |$

Cc: Peter Xu <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

WARNING: please, no space before tabs
torvalds#56: FILE: mm/shmem.c:5216:
+^I.uffd_features^I= ^I__VM_UFFD_FLAGS,$

WARNING: please, no space before tabs
torvalds#57: FILE: mm/shmem.c:5217:
+^I.uffd_ioctls^I= ^IBIT(_UFFDIO_COPY) |$

Cc: Peter Xu <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

All of the ID tables based on <linux/mod_devicetable.h> (of_device_id,
pci_device_id, ...) require their arrays to end in an empty sentinel
value. That's usually spelled with an empty initializer entry (e.g.,
"{}"), but also sometimes with explicit 0 entries, field initializers
(e.g., '.id = ""'), or even a macro entry (like PCMCIA_DEVICE_NULL).

Without a sentinel, device-matching code may read out of bounds.

I've found a number of such bugs in driver reviews, and we even
occasionally commit one to the tree. See commit 5751eee ("i2c:
nomadik: Add missing sentinel to match table") for example.

Teach checkpatch to find these ID tables, and complain if it looks like
there wasn't a sentinel value.

Test output:

  $ git format-patch -1 a0d15cc --stdout | scripts/checkpatch.pl -
  ERROR: missing sentinel in ID array
  torvalds#57: FILE: drivers/i2c/busses/i2c-nomadik.c:1073:
  +static const struct of_device_id nmk_i2c_eyeq_match_table[] = {
   	{
   		.compatible = "XXXXXXXXXXXXXXXXXX",
   		.data = (void *)(NMK_I2C_EYEQ_FLAG_32B_BUS | NMK_I2C_EYEQ_FLAG_IS_EYEQ5),
   	},
   };

  total: 1 errors, 0 warnings, 66 lines checked

  NOTE: For some of the reported defects, checkpatch may be able to
        mechanically convert to the typical style using --fix or --fix-inplace.

  "[PATCH] i2c: nomadik: switch from of_device_is_compatible() to" has style problems, please review.

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

When run across the entire tree (scripts/checkpatch.pl -q --types
MISSING_SENTINEL -f ...), false positives exist:

* where macros are used that hide the table from analysis
  (e.g., drivers/gpu/drm/radeon/radeon_drv.c / radeon_PCI_IDS).
  There are fewer than 5 of these.

* where such tables are processed correctly via ARRAY_SIZE() (fewer than
  5 instances). This is by far not the typical usage of *_device_id
  arrays.

* some odd parsing artifacts, where ctx_statement_block() seems to quit
  in the middle of a block due to #if/#else/#endif.

Signed-off-by: Brian Norris <[email protected]>

WARNING: please, no space before tabs
torvalds#56: FILE: mm/shmem.c:5216:
+^I.uffd_features^I= ^I__VM_UFFD_FLAGS,$

WARNING: please, no space before tabs
torvalds#57: FILE: mm/shmem.c:5217:
+^I.uffd_ioctls^I= ^IBIT(_UFFDIO_COPY) |$

Cc: Peter Xu <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

All of the ID tables based on <linux/mod_devicetable.h> (of_device_id,
pci_device_id, ...) require their arrays to end in an empty sentinel
value. That's usually spelled with an empty initializer entry (e.g.,
"{}"), but also sometimes with explicit 0 entries, field initializers
(e.g., '.id = ""'), or even a macro entry (like PCMCIA_DEVICE_NULL).

Without a sentinel, device-matching code may read out of bounds.

I've found a number of such bugs in driver reviews, and we even
occasionally commit one to the tree. See commit 5751eee ("i2c:
nomadik: Add missing sentinel to match table") for example.

Teach checkpatch to find these ID tables, and complain if it looks like
there wasn't a sentinel value.

Test output:

  $ git format-patch -1 a0d15cc --stdout | scripts/checkpatch.pl -
  ERROR: missing sentinel in ID array
  torvalds#57: FILE: drivers/i2c/busses/i2c-nomadik.c:1073:
  +static const struct of_device_id nmk_i2c_eyeq_match_table[] = {
   	{
   		.compatible = "XXXXXXXXXXXXXXXXXX",
   		.data = (void *)(NMK_I2C_EYEQ_FLAG_32B_BUS | NMK_I2C_EYEQ_FLAG_IS_EYEQ5),
   	},
   };

  total: 1 errors, 0 warnings, 66 lines checked

  NOTE: For some of the reported defects, checkpatch may be able to
        mechanically convert to the typical style using --fix or --fix-inplace.

  "[PATCH] i2c: nomadik: switch from of_device_is_compatible() to" has style problems, please review.

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

When run across the entire tree (scripts/checkpatch.pl -q --types
MISSING_SENTINEL -f ...), false positives exist:

* where macros are used that hide the table from analysis
  (e.g., drivers/gpu/drm/radeon/radeon_drv.c / radeon_PCI_IDS).
  There are fewer than 5 of these.

* where such tables are processed correctly via ARRAY_SIZE() (fewer than
  5 instances). This is by far not the typical usage of *_device_id
  arrays.

* some odd parsing artifacts, where ctx_statement_block() seems to quit
  in the middle of a block due to #if/#else/#endif.

Also, not every "struct *_device_id" is in fact a sentinel-requiring
structure, but even with such types, false positives are very rare.

Signed-off-by: Brian Norris <[email protected]>

All of the ID tables based on <linux/mod_devicetable.h> (of_device_id,
pci_device_id, ...) require their arrays to end in an empty sentinel
value.  That's usually spelled with an empty initializer entry (e.g.,
"{}"), but also sometimes with explicit 0 entries, field initializers
(e.g., '.id = ""'), or even a macro entry (like PCMCIA_DEVICE_NULL).

Without a sentinel, device-matching code may read out of bounds.

I've found a number of such bugs in driver reviews, and we even
occasionally commit one to the tree.  See commit 5751eee ("i2c:
nomadik: Add missing sentinel to match table") for example.

Teach checkpatch to find these ID tables, and complain if it looks like
there wasn't a sentinel value.

Test output:

  $ git format-patch -1 a0d15cc --stdout | scripts/checkpatch.pl -
  ERROR: missing sentinel in ID array
  torvalds#57: FILE: drivers/i2c/busses/i2c-nomadik.c:1073:
  +static const struct of_device_id nmk_i2c_eyeq_match_table[] = {
   	{
   		.compatible = "XXXXXXXXXXXXXXXXXX",
   		.data = (void *)(NMK_I2C_EYEQ_FLAG_32B_BUS | NMK_I2C_EYEQ_FLAG_IS_EYEQ5),
   	},
   };

  total: 1 errors, 0 warnings, 66 lines checked

  NOTE: For some of the reported defects, checkpatch may be able to
        mechanically convert to the typical style using --fix or --fix-inplace.

  "[PATCH] i2c: nomadik: switch from of_device_is_compatible() to" has style problems, please review.

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

When run across the entire tree (scripts/checkpatch.pl -q --types
MISSING_SENTINEL -f ...), false positives exist:

* where macros are used that hide the table from analysis
  (e.g., drivers/gpu/drm/radeon/radeon_drv.c / radeon_PCI_IDS).
  There are fewer than 5 of these.

* where such tables are processed correctly via ARRAY_SIZE() (fewer than
  5 instances). This is by far not the typical usage of *_device_id
  arrays.

* some odd parsing artifacts, where ctx_statement_block() seems to quit
  in the middle of a block due to #if/#else/#endif.

Also, not every "struct *_device_id" is in fact a sentinel-requiring
structure, but even with such types, false positives are very rare.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Brian Norris <[email protected]>
Acked-by: Joe Perches <[email protected]>
Cc: Andy Whitcroft <[email protected]>
Cc: Brian Norris <[email protected]>
Cc: Dwaipayan Ray <[email protected]>
Cc: Lukas Bulwahn <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

All of the ID tables based on <linux/mod_devicetable.h> (of_device_id,
pci_device_id, ...) require their arrays to end in an empty sentinel
value.  That's usually spelled with an empty initializer entry (e.g.,
"{}"), but also sometimes with explicit 0 entries, field initializers
(e.g., '.id = ""'), or even a macro entry (like PCMCIA_DEVICE_NULL).

Without a sentinel, device-matching code may read out of bounds.

I've found a number of such bugs in driver reviews, and we even
occasionally commit one to the tree.  See commit 5751eee ("i2c:
nomadik: Add missing sentinel to match table") for example.

Teach checkpatch to find these ID tables, and complain if it looks like
there wasn't a sentinel value.

Test output:

  $ git format-patch -1 a0d15cc --stdout | scripts/checkpatch.pl -
  ERROR: missing sentinel in ID array
  torvalds#57: FILE: drivers/i2c/busses/i2c-nomadik.c:1073:
  +static const struct of_device_id nmk_i2c_eyeq_match_table[] = {
   	{
   		.compatible = "XXXXXXXXXXXXXXXXXX",
   		.data = (void *)(NMK_I2C_EYEQ_FLAG_32B_BUS | NMK_I2C_EYEQ_FLAG_IS_EYEQ5),
   	},
   };

  total: 1 errors, 0 warnings, 66 lines checked

  NOTE: For some of the reported defects, checkpatch may be able to
        mechanically convert to the typical style using --fix or --fix-inplace.

  "[PATCH] i2c: nomadik: switch from of_device_is_compatible() to" has style problems, please review.

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

When run across the entire tree (scripts/checkpatch.pl -q --types
MISSING_SENTINEL -f ...), false positives exist:

* where macros are used that hide the table from analysis
  (e.g., drivers/gpu/drm/radeon/radeon_drv.c / radeon_PCI_IDS).
  There are fewer than 5 of these.

* where such tables are processed correctly via ARRAY_SIZE() (fewer than
  5 instances). This is by far not the typical usage of *_device_id
  arrays.

* some odd parsing artifacts, where ctx_statement_block() seems to quit
  in the middle of a block due to #if/#else/#endif.

Also, not every "struct *_device_id" is in fact a sentinel-requiring
structure, but even with such types, false positives are very rare.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Brian Norris <[email protected]>
Acked-by: Joe Perches <[email protected]>
Cc: Andy Whitcroft <[email protected]>
Cc: Brian Norris <[email protected]>
Cc: Dwaipayan Ray <[email protected]>
Cc: Lukas Bulwahn <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

All of the ID tables based on <linux/mod_devicetable.h> (of_device_id,
pci_device_id, ...) require their arrays to end in an empty sentinel
value.  That's usually spelled with an empty initializer entry (e.g.,
"{}"), but also sometimes with explicit 0 entries, field initializers
(e.g., '.id = ""'), or even a macro entry (like PCMCIA_DEVICE_NULL).

Without a sentinel, device-matching code may read out of bounds.

I've found a number of such bugs in driver reviews, and we even
occasionally commit one to the tree.  See commit 5751eee ("i2c:
nomadik: Add missing sentinel to match table") for example.

Teach checkpatch to find these ID tables, and complain if it looks like
there wasn't a sentinel value.

Test output:

  $ git format-patch -1 a0d15cc --stdout | scripts/checkpatch.pl -
  ERROR: missing sentinel in ID array
  torvalds#57: FILE: drivers/i2c/busses/i2c-nomadik.c:1073:
  +static const struct of_device_id nmk_i2c_eyeq_match_table[] = {
   	{
   		.compatible = "XXXXXXXXXXXXXXXXXX",
   		.data = (void *)(NMK_I2C_EYEQ_FLAG_32B_BUS | NMK_I2C_EYEQ_FLAG_IS_EYEQ5),
   	},
   };

  total: 1 errors, 0 warnings, 66 lines checked

  NOTE: For some of the reported defects, checkpatch may be able to
        mechanically convert to the typical style using --fix or --fix-inplace.

  "[PATCH] i2c: nomadik: switch from of_device_is_compatible() to" has style problems, please review.

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

When run across the entire tree (scripts/checkpatch.pl -q --types
MISSING_SENTINEL -f ...), false positives exist:

* where macros are used that hide the table from analysis
  (e.g., drivers/gpu/drm/radeon/radeon_drv.c / radeon_PCI_IDS).
  There are fewer than 5 of these.

* where such tables are processed correctly via ARRAY_SIZE() (fewer than
  5 instances). This is by far not the typical usage of *_device_id
  arrays.

* some odd parsing artifacts, where ctx_statement_block() seems to quit
  in the middle of a block due to #if/#else/#endif.

Also, not every "struct *_device_id" is in fact a sentinel-requiring
structure, but even with such types, false positives are very rare.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Brian Norris <[email protected]>
Acked-by: Joe Perches <[email protected]>
Cc: Andy Whitcroft <[email protected]>
Cc: Brian Norris <[email protected]>
Cc: Dwaipayan Ray <[email protected]>
Cc: Lukas Bulwahn <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

All of the ID tables based on <linux/mod_devicetable.h> (of_device_id,
pci_device_id, ...) require their arrays to end in an empty sentinel
value.  That's usually spelled with an empty initializer entry (e.g.,
"{}"), but also sometimes with explicit 0 entries, field initializers
(e.g., '.id = ""'), or even a macro entry (like PCMCIA_DEVICE_NULL).

Without a sentinel, device-matching code may read out of bounds.

I've found a number of such bugs in driver reviews, and we even
occasionally commit one to the tree.  See commit 5751eee ("i2c:
nomadik: Add missing sentinel to match table") for example.

Teach checkpatch to find these ID tables, and complain if it looks like
there wasn't a sentinel value.

Test output:

  $ git format-patch -1 a0d15cc --stdout | scripts/checkpatch.pl -
  ERROR: missing sentinel in ID array
  torvalds#57: FILE: drivers/i2c/busses/i2c-nomadik.c:1073:
  +static const struct of_device_id nmk_i2c_eyeq_match_table[] = {
   	{
   		.compatible = "XXXXXXXXXXXXXXXXXX",
   		.data = (void *)(NMK_I2C_EYEQ_FLAG_32B_BUS | NMK_I2C_EYEQ_FLAG_IS_EYEQ5),
   	},
   };

  total: 1 errors, 0 warnings, 66 lines checked

  NOTE: For some of the reported defects, checkpatch may be able to
        mechanically convert to the typical style using --fix or --fix-inplace.

  "[PATCH] i2c: nomadik: switch from of_device_is_compatible() to" has style problems, please review.

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

When run across the entire tree (scripts/checkpatch.pl -q --types
MISSING_SENTINEL -f ...), false positives exist:

* where macros are used that hide the table from analysis
  (e.g., drivers/gpu/drm/radeon/radeon_drv.c / radeon_PCI_IDS).
  There are fewer than 5 of these.

* where such tables are processed correctly via ARRAY_SIZE() (fewer than
  5 instances). This is by far not the typical usage of *_device_id
  arrays.

* some odd parsing artifacts, where ctx_statement_block() seems to quit
  in the middle of a block due to #if/#else/#endif.

Also, not every "struct *_device_id" is in fact a sentinel-requiring
structure, but even with such types, false positives are very rare.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Brian Norris <[email protected]>
Acked-by: Joe Perches <[email protected]>
Cc: Andy Whitcroft <[email protected]>
Cc: Brian Norris <[email protected]>
Cc: Dwaipayan Ray <[email protected]>
Cc: Lukas Bulwahn <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

All of the ID tables based on <linux/mod_devicetable.h> (of_device_id,
pci_device_id, ...) require their arrays to end in an empty sentinel
value.  That's usually spelled with an empty initializer entry (e.g.,
"{}"), but also sometimes with explicit 0 entries, field initializers
(e.g., '.id = ""'), or even a macro entry (like PCMCIA_DEVICE_NULL).

Without a sentinel, device-matching code may read out of bounds.

I've found a number of such bugs in driver reviews, and we even
occasionally commit one to the tree.  See commit 5751eee ("i2c:
nomadik: Add missing sentinel to match table") for example.

Teach checkpatch to find these ID tables, and complain if it looks like
there wasn't a sentinel value.

Test output:

  $ git format-patch -1 a0d15cc --stdout | scripts/checkpatch.pl -
  ERROR: missing sentinel in ID array
  torvalds#57: FILE: drivers/i2c/busses/i2c-nomadik.c:1073:
  +static const struct of_device_id nmk_i2c_eyeq_match_table[] = {
   	{
   		.compatible = "XXXXXXXXXXXXXXXXXX",
   		.data = (void *)(NMK_I2C_EYEQ_FLAG_32B_BUS | NMK_I2C_EYEQ_FLAG_IS_EYEQ5),
   	},
   };

  total: 1 errors, 0 warnings, 66 lines checked

  NOTE: For some of the reported defects, checkpatch may be able to
        mechanically convert to the typical style using --fix or --fix-inplace.

  "[PATCH] i2c: nomadik: switch from of_device_is_compatible() to" has style problems, please review.

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

When run across the entire tree (scripts/checkpatch.pl -q --types
MISSING_SENTINEL -f ...), false positives exist:

* where macros are used that hide the table from analysis
  (e.g., drivers/gpu/drm/radeon/radeon_drv.c / radeon_PCI_IDS).
  There are fewer than 5 of these.

* where such tables are processed correctly via ARRAY_SIZE() (fewer than
  5 instances). This is by far not the typical usage of *_device_id
  arrays.

* some odd parsing artifacts, where ctx_statement_block() seems to quit
  in the middle of a block due to #if/#else/#endif.

Also, not every "struct *_device_id" is in fact a sentinel-requiring
structure, but even with such types, false positives are very rare.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Brian Norris <[email protected]>
Acked-by: Joe Perches <[email protected]>
Cc: Andy Whitcroft <[email protected]>
Cc: Brian Norris <[email protected]>
Cc: Dwaipayan Ray <[email protected]>
Cc: Lukas Bulwahn <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

All of the ID tables based on <linux/mod_devicetable.h> (of_device_id,
pci_device_id, ...) require their arrays to end in an empty sentinel
value.  That's usually spelled with an empty initializer entry (e.g.,
"{}"), but also sometimes with explicit 0 entries, field initializers
(e.g., '.id = ""'), or even a macro entry (like PCMCIA_DEVICE_NULL).

Without a sentinel, device-matching code may read out of bounds.

I've found a number of such bugs in driver reviews, and we even
occasionally commit one to the tree.  See commit 5751eee ("i2c:
nomadik: Add missing sentinel to match table") for example.

Teach checkpatch to find these ID tables, and complain if it looks like
there wasn't a sentinel value.

Test output:

  $ git format-patch -1 a0d15cc --stdout | scripts/checkpatch.pl -
  ERROR: missing sentinel in ID array
  torvalds#57: FILE: drivers/i2c/busses/i2c-nomadik.c:1073:
  +static const struct of_device_id nmk_i2c_eyeq_match_table[] = {
   	{
   		.compatible = "XXXXXXXXXXXXXXXXXX",
   		.data = (void *)(NMK_I2C_EYEQ_FLAG_32B_BUS | NMK_I2C_EYEQ_FLAG_IS_EYEQ5),
   	},
   };

  total: 1 errors, 0 warnings, 66 lines checked

  NOTE: For some of the reported defects, checkpatch may be able to
        mechanically convert to the typical style using --fix or --fix-inplace.

  "[PATCH] i2c: nomadik: switch from of_device_is_compatible() to" has style problems, please review.

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

When run across the entire tree (scripts/checkpatch.pl -q --types
MISSING_SENTINEL -f ...), false positives exist:

* where macros are used that hide the table from analysis
  (e.g., drivers/gpu/drm/radeon/radeon_drv.c / radeon_PCI_IDS).
  There are fewer than 5 of these.

* where such tables are processed correctly via ARRAY_SIZE() (fewer than
  5 instances). This is by far not the typical usage of *_device_id
  arrays.

* some odd parsing artifacts, where ctx_statement_block() seems to quit
  in the middle of a block due to #if/#else/#endif.

Also, not every "struct *_device_id" is in fact a sentinel-requiring
structure, but even with such types, false positives are very rare.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Brian Norris <[email protected]>
Acked-by: Joe Perches <[email protected]>
Cc: Andy Whitcroft <[email protected]>
Cc: Brian Norris <[email protected]>
Cc: Dwaipayan Ray <[email protected]>
Cc: Lukas Bulwahn <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

All of the ID tables based on <linux/mod_devicetable.h> (of_device_id,
pci_device_id, ...) require their arrays to end in an empty sentinel
value.  That's usually spelled with an empty initializer entry (e.g.,
"{}"), but also sometimes with explicit 0 entries, field initializers
(e.g., '.id = ""'), or even a macro entry (like PCMCIA_DEVICE_NULL).

Without a sentinel, device-matching code may read out of bounds.

I've found a number of such bugs in driver reviews, and we even
occasionally commit one to the tree.  See commit 5751eee ("i2c:
nomadik: Add missing sentinel to match table") for example.

Teach checkpatch to find these ID tables, and complain if it looks like
there wasn't a sentinel value.

Test output:

  $ git format-patch -1 a0d15cc --stdout | scripts/checkpatch.pl -
  ERROR: missing sentinel in ID array
  torvalds#57: FILE: drivers/i2c/busses/i2c-nomadik.c:1073:
  +static const struct of_device_id nmk_i2c_eyeq_match_table[] = {
   	{
   		.compatible = "XXXXXXXXXXXXXXXXXX",
   		.data = (void *)(NMK_I2C_EYEQ_FLAG_32B_BUS | NMK_I2C_EYEQ_FLAG_IS_EYEQ5),
   	},
   };

  total: 1 errors, 0 warnings, 66 lines checked

  NOTE: For some of the reported defects, checkpatch may be able to
        mechanically convert to the typical style using --fix or --fix-inplace.

  "[PATCH] i2c: nomadik: switch from of_device_is_compatible() to" has style problems, please review.

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

When run across the entire tree (scripts/checkpatch.pl -q --types
MISSING_SENTINEL -f ...), false positives exist:

* where macros are used that hide the table from analysis
  (e.g., drivers/gpu/drm/radeon/radeon_drv.c / radeon_PCI_IDS).
  There are fewer than 5 of these.

* where such tables are processed correctly via ARRAY_SIZE() (fewer than
  5 instances). This is by far not the typical usage of *_device_id
  arrays.

* some odd parsing artifacts, where ctx_statement_block() seems to quit
  in the middle of a block due to #if/#else/#endif.

Also, not every "struct *_device_id" is in fact a sentinel-requiring
structure, but even with such types, false positives are very rare.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Brian Norris <[email protected]>
Acked-by: Joe Perches <[email protected]>
Cc: Andy Whitcroft <[email protected]>
Cc: Brian Norris <[email protected]>
Cc: Dwaipayan Ray <[email protected]>
Cc: Lukas Bulwahn <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

All of the ID tables based on <linux/mod_devicetable.h> (of_device_id,
pci_device_id, ...) require their arrays to end in an empty sentinel
value.  That's usually spelled with an empty initializer entry (e.g.,
"{}"), but also sometimes with explicit 0 entries, field initializers
(e.g., '.id = ""'), or even a macro entry (like PCMCIA_DEVICE_NULL).

Without a sentinel, device-matching code may read out of bounds.

I've found a number of such bugs in driver reviews, and we even
occasionally commit one to the tree.  See commit 5751eee ("i2c:
nomadik: Add missing sentinel to match table") for example.

Teach checkpatch to find these ID tables, and complain if it looks like
there wasn't a sentinel value.

Test output:

  $ git format-patch -1 a0d15cc --stdout | scripts/checkpatch.pl -
  ERROR: missing sentinel in ID array
  torvalds#57: FILE: drivers/i2c/busses/i2c-nomadik.c:1073:
  +static const struct of_device_id nmk_i2c_eyeq_match_table[] = {
   	{
   		.compatible = "XXXXXXXXXXXXXXXXXX",
   		.data = (void *)(NMK_I2C_EYEQ_FLAG_32B_BUS | NMK_I2C_EYEQ_FLAG_IS_EYEQ5),
   	},
   };

  total: 1 errors, 0 warnings, 66 lines checked

  NOTE: For some of the reported defects, checkpatch may be able to
        mechanically convert to the typical style using --fix or --fix-inplace.

  "[PATCH] i2c: nomadik: switch from of_device_is_compatible() to" has style problems, please review.

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

When run across the entire tree (scripts/checkpatch.pl -q --types
MISSING_SENTINEL -f ...), false positives exist:

* where macros are used that hide the table from analysis
  (e.g., drivers/gpu/drm/radeon/radeon_drv.c / radeon_PCI_IDS).
  There are fewer than 5 of these.

* where such tables are processed correctly via ARRAY_SIZE() (fewer than
  5 instances). This is by far not the typical usage of *_device_id
  arrays.

* some odd parsing artifacts, where ctx_statement_block() seems to quit
  in the middle of a block due to #if/#else/#endif.

Also, not every "struct *_device_id" is in fact a sentinel-requiring
structure, but even with such types, false positives are very rare.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Brian Norris <[email protected]>
Acked-by: Joe Perches <[email protected]>
Cc: Andy Whitcroft <[email protected]>
Cc: Brian Norris <[email protected]>
Cc: Dwaipayan Ray <[email protected]>
Cc: Lukas Bulwahn <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>