1116 #57

coder280 · 2013-11-16T11:52:45Z

No description provided.

1102

1103

1104

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]>

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+ #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 bf1bb380 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]>

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]>

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]>

[ Upstream commit f221033 ] During the removal of the idxd driver, registered offline callback is invoked as part of the clean up process. However, on systems with only one CPU online, no valid target is available to migrate the perf context, resulting in a kernel oops: BUG: unable to handle page fault for address: 000000000002a2b8 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 1470e1067 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ torvalds#57 Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023 RIP: 0010:mutex_lock+0x2e/0x50 ... Call Trace: <TASK> __die+0x24/0x70 page_fault_oops+0x82/0x160 do_user_addr_fault+0x65/0x6b0 __pfx___rdmsr_safe_on_cpu+0x10/0x10 exc_page_fault+0x7d/0x170 asm_exc_page_fault+0x26/0x30 mutex_lock+0x2e/0x50 mutex_lock+0x1e/0x50 perf_pmu_migrate_context+0x87/0x1f0 perf_event_cpu_offline+0x76/0x90 [idxd] cpuhp_invoke_callback+0xa2/0x4f0 __pfx_perf_event_cpu_offline+0x10/0x10 [idxd] cpuhp_thread_fun+0x98/0x150 smpboot_thread_fn+0x27/0x260 smpboot_thread_fn+0x1af/0x260 __pfx_smpboot_thread_fn+0x10/0x10 kthread+0x103/0x140 __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x50 __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 <TASK> Fix the issue by preventing the migration of the perf context to an invalid target. Fixes: 81dd4d4 ("dmaengine: idxd: Add IDXD performance monitor support") Reported-by: Terrence Xu <[email protected]> Tested-by: Terrence Xu <[email protected]> Signed-off-by: Fenghua Yu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

If there is a symbol link in the given patch, checkpatch.pl reports two inaccurate warnings: $ cat 0001-selftests-bpf-Add-mptcp-pm_nl_ctl-link.patch ... ... ''' # diff --git a/tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c \ # b/tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c # new file mode 120000 # index 000000000000..5a08c255b278 # --- /dev/null # +++ b/tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c # @@ -0,0 +1 @@ # +../net/mptcp/pm_nl_ctl.c # \ No newline at end of file ''' $ ./scripts/checkpatch.pl 0001-selftests-bpf-Add-mptcp-pm_nl_ctl-link.patch ''' WARNING: Missing or malformed SPDX-License-Identifier tag in line 1 torvalds#57: FILE: tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c:1: +../net/mptcp/pm_nl_ctl.c WARNING: adding a line without newline at end of file torvalds#57: FILE: tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c:1: +../net/mptcp/pm_nl_ctl.c total: 0 errors, 2 warnings, 16 lines checked ''' This patch fixes this by adding a new variable $symbol_link in checkpatch script, set it if the new file mode is 120000. Skip these two checks "missing SPDX-License-Identifier" and "adding a line without newline at end of file" if this variable is set. Signed-off-by: Geliang Tang <[email protected]>

[ Upstream commit 8206e4e ] BPF CI reported that selftest deny_namespace failed with s390x. test_unpriv_userns_create_no_bpf:PASS:no-bpf unpriv new user ns 0 nsec test_deny_namespace:PASS:skel load 0 nsec libbpf: prog 'test_userns_create': failed to attach: ERROR: strerror_r(-524)=22 libbpf: prog 'test_userns_create': failed to auto-attach: -524 test_deny_namespace:FAIL:attach unexpected error: -524 (errno 524) torvalds#57/1 deny_namespace/unpriv_userns_create_no_bpf:FAIL torvalds#57 deny_namespace:FAIL BPF program test_userns_create is a BPF LSM type program which is based on trampoline and s390x does not support s390x. Let add the test to x390x deny list to avoid this failure in BPF CI. Signed-off-by: Yonghong Song <[email protected]> Acked-by: Jiri Olsa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Stable-dep-of: aa8ebb2 ("selftests/bpf: Workaround strict bpf_lsm return value check.") Signed-off-by: Sasha Levin <[email protected]>

…si_free_irqs_all() The follow steps trigger kernel dump warning and platform_device_msi_init_and_alloc_irqs() return false. 1: platform_device_msi_init_and_alloc_irqs(); 2: platform_device_msi_free_irqs_all(); 3: platform_device_msi_init_and_alloc_irqs(); [ 76.713677] WARNING: CPU: 3 PID: 134 at kernel/irq/msi.c:1028 msi_create_device_irq_domain+0x1bc/0x22c [ 76.723010] Modules linked in: [ 76.726082] CPU: 3 UID: 0 PID: 134 Comm: kworker/3:1H Not tainted 6.13.0-rc1-00015-gd60b98003b43-dirty torvalds#57 [ 76.735741] Hardware name: NXP i.MX95 19X19 board (DT) [ 76.740883] Workqueue: kpcitest pci_epf_test_cmd_handler [ 76.746212] pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 76.753172] pc : msi_create_device_irq_domain+0x1bc/0x22c [ 76.758586] lr : msi_create_device_irq_domain+0x104/0x22c [ 76.763988] sp : ffff800083f43be0 [ 76.767313] x29: ffff800083f43be0 x28: 0000000000000000 x27: ffff8000827a7000 [ 76.774466] x26: ffff00008085f400 x25: ffff00008000b180 x24: ffff000080fc6410 [ 76.781624] x23: ffff000085704cc0 x22: ffff8000811c8828 x21: ffff000085704cc0 [ 76.788774] x20: ffff000082814000 x19: 0000000000000000 x18: ffffffffffffffff [ 76.795933] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 76.803083] x14: 0000000000000000 x13: 0000000f00000000 x12: 0000000000000000 [ 76.810233] x11: 0000000000000000 x10: 000000000000002d x9 : ffff800083f43ba0 [ 76.817383] x8 : 00000000ffffffff x7 : 0000000000000019 x6 : ffff0000857e443a [ 76.824533] x5 : 0000000000000000 x4 : ffffffffffffffff x3 : ffff000085704ce8 [ 76.831683] x2 : ffff000080835640 x1 : 0000000000000213 x0 : ffff0000877189c0 [ 76.838840] Call trace: [ 76.841287] msi_create_device_irq_domain+0x1bc/0x22c (P) [ 76.846701] msi_create_device_irq_domain+0x104/0x22c (L) [ 76.852118] platform_device_msi_init_and_alloc_irqs+0x6c/0xb8 Do below two things in platform_device_msi_init_and_alloc_irqs(). - msi_create_device_irq_domain() - msi_domain_alloc_irqs_range() But only call msi_domain_free_irqs_all() in platform_device_msi_free_irqs_all(), which missed call msi_remove_device_irq_domain(). This cause above kernel dump when call platform_device_msi_init_and_alloc_irqs() again. Signed-off-by: Frank Li <[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]>

coder280 added 3 commits November 3, 2013 00:51

Merge pull request #1 from torvalds/master

bfd4116

1102

Merge pull request #2 from torvalds/master

f391f49

1103

Merge pull request #3 from torvalds/master

8b2ac89

1104

coder280 closed this Nov 16, 2013

hzhuang1 pushed a commit to hzhuang1/linux that referenced this pull request May 22, 2015

Merge pull request torvalds#57 from Leo-Yan/fix_console_spurious_char…

d17a7fb

…_0428 Fix console spurious char

aejsmith pushed a commit to aejsmith/linux that referenced this pull request Jul 28, 2015

Merge pull request torvalds#57 from mpredfearn/ci20-v3.18-audio-fixup

677ac02

Ci20 v3.18 audio fixup

diaevd referenced this pull request in diaevd/zen-kernel Dec 30, 2015

Merge pull request zen-kernel#57 from mzhboy/master

f02406c

fix exfat_super.c

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

1116 #57

1116 #57

coder280 commented Nov 16, 2013

1116 #57

1116 #57

Conversation

coder280 commented Nov 16, 2013