. #69
Closed
. #69
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
shr-buildhost
pushed a commit
to shr-distribution/linux
that referenced
this pull request
Jan 22, 2014
commit 266ccd5 upstream. ae7f164 ("cgroup: move cgroup->subsys[] assignment to online_css()") moved cgroup->subsys[] assignements later in cgroup_create() but didn't update error handling path accordingly leading to the following oops and leaking later css's after an online_css() failure. The oops is from cgroup destruction path being invoked on the partially constructed cgroup which is not ready to handle empty slots in cgrp->subsys[] array. BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: [<ffffffff810eeaa8>] cgroup_destroy_locked+0x118/0x2f0 PGD a780a067 PUD aadbe067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: CPU: 6 PID: 7360 Comm: mkdir Not tainted 3.13.0-rc2+ torvalds#69 Hardware name: task: ffff8800b9dbec00 ti: ffff8800a781a000 task.ti: ffff8800a781a000 RIP: 0010:[<ffffffff810eeaa8>] [<ffffffff810eeaa8>] cgroup_destroy_locked+0x118/0x2f0 RSP: 0018:ffff8800a781bd98 EFLAGS: 00010282 RAX: ffff880586903878 RBX: ffff880586903800 RCX: ffff880586903820 RDX: ffff880586903860 RSI: ffff8800a781bdb0 RDI: ffff880586903820 RBP: ffff8800a781bde8 R08: ffff88060e0b8048 R09: ffffffff811d7bc1 R10: 000000000000008c R11: 0000000000000001 R12: ffff8800a72286c0 R13: 0000000000000000 R14: ffffffff81cf7a40 R15: 0000000000000001 FS: 00007f60ecda57a0(0000) GS:ffff8806272c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 00000000a7a03000 CR4: 00000000000007e0 Stack: ffff880586903860 ffff880586903910 ffff8800a72286c0 ffff880586903820 ffffffff81cf7a40 ffff880586903800 ffff88060e0b8018 ffffffff81cf7a40 ffff8800b9dbec00 ffff8800b9dbf098 ffff8800a781bec8 ffffffff810ef5bf Call Trace: [<ffffffff810ef5bf>] cgroup_mkdir+0x55f/0x5f0 [<ffffffff811c90ae>] vfs_mkdir+0xee/0x140 [<ffffffff811cb07e>] SyS_mkdirat+0x6e/0xf0 [<ffffffff811c6a19>] SyS_mkdir+0x19/0x20 [<ffffffff8169e569>] system_call_fastpath+0x16/0x1b This patch moves reference bumping inside online_css() loop, clears css_ar[] as css's are brought online successfully, and updates err_destroy path so that either a css is fully online and destroyed by cgroup_destroy_locked() or the error path frees it. This creates a duplicate css free logic in the error path but it will be cleaned up soon. v2: Li pointed out that cgroup_destroy_locked() would do NULL-deref if invoked with a cgroup which doesn't have all css's populated. Update cgroup_destroy_locked() so that it skips NULL css's. Signed-off-by: Tejun Heo <[email protected]> Acked-by: Li Zefan <[email protected]> Reported-by: Vladimir Davydov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
antonblanchard
pushed a commit
to antonblanchard/linux
that referenced
this pull request
Jan 23, 2014
Turn it into (for example): [ 0.073380] x86: Booting SMP configuration: [ 0.074005] .... node #0, CPUs: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 [ 0.603005] .... node #1, CPUs: torvalds#8 torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 [ 1.200005] .... node #2, CPUs: torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 [ 1.796005] .... node #3, CPUs: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 [ 2.393005] .... node #4, CPUs: torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 [ 2.996005] .... node #5, CPUs: torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 [ 3.600005] .... node torvalds#6, CPUs: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 [ 4.202005] .... node torvalds#7, CPUs: torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 [ 4.811005] .... node torvalds#8, CPUs: torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71 [ 5.421006] .... node torvalds#9, CPUs: torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 [ 6.032005] .... node torvalds#10, CPUs: torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 [ 6.648006] .... node torvalds#11, CPUs: torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95 [ 7.262005] .... node torvalds#12, CPUs: torvalds#96 torvalds#97 torvalds#98 torvalds#99 torvalds#100 torvalds#101 torvalds#102 torvalds#103 [ 7.865005] .... node torvalds#13, CPUs: torvalds#104 torvalds#105 torvalds#106 torvalds#107 torvalds#108 torvalds#109 torvalds#110 torvalds#111 [ 8.466005] .... node torvalds#14, CPUs: torvalds#112 torvalds#113 torvalds#114 torvalds#115 torvalds#116 torvalds#117 torvalds#118 torvalds#119 [ 9.073006] .... node torvalds#15, CPUs: torvalds#120 torvalds#121 torvalds#122 torvalds#123 torvalds#124 torvalds#125 torvalds#126 torvalds#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]>
antonblanchard
pushed a commit
to antonblanchard/linux
that referenced
this pull request
Jan 23, 2014
ae7f164 ("cgroup: move cgroup->subsys[] assignment to online_css()") moved cgroup->subsys[] assignements later in cgroup_create() but didn't update error handling path accordingly leading to the following oops and leaking later css's after an online_css() failure. The oops is from cgroup destruction path being invoked on the partially constructed cgroup which is not ready to handle empty slots in cgrp->subsys[] array. BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: [<ffffffff810eeaa8>] cgroup_destroy_locked+0x118/0x2f0 PGD a780a067 PUD aadbe067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: CPU: 6 PID: 7360 Comm: mkdir Not tainted 3.13.0-rc2+ torvalds#69 Hardware name: task: ffff8800b9dbec00 ti: ffff8800a781a000 task.ti: ffff8800a781a000 RIP: 0010:[<ffffffff810eeaa8>] [<ffffffff810eeaa8>] cgroup_destroy_locked+0x118/0x2f0 RSP: 0018:ffff8800a781bd98 EFLAGS: 00010282 RAX: ffff880586903878 RBX: ffff880586903800 RCX: ffff880586903820 RDX: ffff880586903860 RSI: ffff8800a781bdb0 RDI: ffff880586903820 RBP: ffff8800a781bde8 R08: ffff88060e0b8048 R09: ffffffff811d7bc1 R10: 000000000000008c R11: 0000000000000001 R12: ffff8800a72286c0 R13: 0000000000000000 R14: ffffffff81cf7a40 R15: 0000000000000001 FS: 00007f60ecda57a0(0000) GS:ffff8806272c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 00000000a7a03000 CR4: 00000000000007e0 Stack: ffff880586903860 ffff880586903910 ffff8800a72286c0 ffff880586903820 ffffffff81cf7a40 ffff880586903800 ffff88060e0b8018 ffffffff81cf7a40 ffff8800b9dbec00 ffff8800b9dbf098 ffff8800a781bec8 ffffffff810ef5bf Call Trace: [<ffffffff810ef5bf>] cgroup_mkdir+0x55f/0x5f0 [<ffffffff811c90ae>] vfs_mkdir+0xee/0x140 [<ffffffff811cb07e>] SyS_mkdirat+0x6e/0xf0 [<ffffffff811c6a19>] SyS_mkdir+0x19/0x20 [<ffffffff8169e569>] system_call_fastpath+0x16/0x1b This patch moves reference bumping inside online_css() loop, clears css_ar[] as css's are brought online successfully, and updates err_destroy path so that either a css is fully online and destroyed by cgroup_destroy_locked() or the error path frees it. This creates a duplicate css free logic in the error path but it will be cleaned up soon. v2: Li pointed out that cgroup_destroy_locked() would do NULL-deref if invoked with a cgroup which doesn't have all css's populated. Update cgroup_destroy_locked() so that it skips NULL css's. Signed-off-by: Tejun Heo <[email protected]> Acked-by: Li Zefan <[email protected]> Reported-by: Vladimir Davydov <[email protected]> Cc: [email protected] # v3.12+
jlelli
pushed a commit
to jlelli/linux
that referenced
this pull request
Jan 29, 2014
BUG: sleeping function called from invalid context at kernel/workqueue.c:2752 in_atomic(): 1, irqs_disabled(): 1, pid: 360, name: zfcperp0.0.1700 CPU: 1 Not tainted 3.9.3+ torvalds#69 Process zfcperp0.0.1700 (pid: 360, task: 0000000075b7e080, ksp: 000000007476bc30) <snip> Call Trace: ([<00000000001165de>] show_trace+0x106/0x154) [<00000000001166a0>] show_stack+0x74/0xf4 [<00000000006ff646>] dump_stack+0xc6/0xd4 [<000000000017f3a0>] __might_sleep+0x128/0x148 [<000000000015ece8>] flush_work+0x54/0x1f8 [<00000000001630de>] __cancel_work_timer+0xc6/0x128 [<00000000005067ac>] scsi_device_dev_release_usercontext+0x164/0x23c [<0000000000161816>] execute_in_process_context+0x96/0xa8 [<00000000004d33d8>] device_release+0x60/0xc0 [<000000000048af48>] kobject_release+0xa8/0x1c4 [<00000000004f4bf2>] __scsi_iterate_devices+0xfa/0x130 [<000003ff801b307a>] zfcp_erp_strategy+0x4da/0x1014 [zfcp] [<000003ff801b3caa>] zfcp_erp_thread+0xf6/0x2b0 [zfcp] [<000000000016b75a>] kthread+0xf2/0xfc [<000000000070c9de>] kernel_thread_starter+0x6/0xc [<000000000070c9d8>] kernel_thread_starter+0x0/0xc Apparently, the ref_count for some scsi_device drops down to zero, triggering device removal through execute_in_process_context(), while the lldd error recovery thread iterates through a scsi device list. Unfortunately, execute_in_process_context() decides to immediately execute that device removal function, instead of scheduling asynchronous execution, since it detects process context and thinks it is safe to do so. But almost all calls to shost_for_each_device() in our lldd are inside spin_lock_irq, even in thread context. Obviously, schedule() inside spin_lock_irq sections is a bad idea. Change the lldd to use the proper iterator function, __shost_for_each_device(), in combination with required locking. Occurences that need to be changed include all calls in zfcp_erp.c, since those might be executed in zfcp error recovery thread context with a lock held. Other occurences of shost_for_each_device() in zfcp_fsf.c do not need to be changed (no process context, no surrounding locking). The problem was introduced in Linux 2.6.37 by commit b62a8d9 "[SCSI] zfcp: Use SCSI device data zfcp_scsi_dev instead of zfcp_unit". Reported-by: Christian Borntraeger <[email protected]> Signed-off-by: Martin Peschke <[email protected]> Cc: [email protected] #2.6.37+ Signed-off-by: Steffen Maier <[email protected]> Signed-off-by: James Bottomley <[email protected]>
huangrui
pushed a commit
to huangrui/linux
that referenced
this pull request
Feb 12, 2014
commit 924dd58 upstream. BUG: sleeping function called from invalid context at kernel/workqueue.c:2752 in_atomic(): 1, irqs_disabled(): 1, pid: 360, name: zfcperp0.0.1700 CPU: 1 Not tainted 3.9.3+ torvalds#69 Process zfcperp0.0.1700 (pid: 360, task: 0000000075b7e080, ksp: 000000007476bc30) <snip> Call Trace: ([<00000000001165de>] show_trace+0x106/0x154) [<00000000001166a0>] show_stack+0x74/0xf4 [<00000000006ff646>] dump_stack+0xc6/0xd4 [<000000000017f3a0>] __might_sleep+0x128/0x148 [<000000000015ece8>] flush_work+0x54/0x1f8 [<00000000001630de>] __cancel_work_timer+0xc6/0x128 [<00000000005067ac>] scsi_device_dev_release_usercontext+0x164/0x23c [<0000000000161816>] execute_in_process_context+0x96/0xa8 [<00000000004d33d8>] device_release+0x60/0xc0 [<000000000048af48>] kobject_release+0xa8/0x1c4 [<00000000004f4bf2>] __scsi_iterate_devices+0xfa/0x130 [<000003ff801b307a>] zfcp_erp_strategy+0x4da/0x1014 [zfcp] [<000003ff801b3caa>] zfcp_erp_thread+0xf6/0x2b0 [zfcp] [<000000000016b75a>] kthread+0xf2/0xfc [<000000000070c9de>] kernel_thread_starter+0x6/0xc [<000000000070c9d8>] kernel_thread_starter+0x0/0xc Apparently, the ref_count for some scsi_device drops down to zero, triggering device removal through execute_in_process_context(), while the lldd error recovery thread iterates through a scsi device list. Unfortunately, execute_in_process_context() decides to immediately execute that device removal function, instead of scheduling asynchronous execution, since it detects process context and thinks it is safe to do so. But almost all calls to shost_for_each_device() in our lldd are inside spin_lock_irq, even in thread context. Obviously, schedule() inside spin_lock_irq sections is a bad idea. Change the lldd to use the proper iterator function, __shost_for_each_device(), in combination with required locking. Occurences that need to be changed include all calls in zfcp_erp.c, since those might be executed in zfcp error recovery thread context with a lock held. Other occurences of shost_for_each_device() in zfcp_fsf.c do not need to be changed (no process context, no surrounding locking). The problem was introduced in Linux 2.6.37 by commit b62a8d9 "[SCSI] zfcp: Use SCSI device data zfcp_scsi_dev instead of zfcp_unit". Reported-by: Christian Borntraeger <[email protected]> Signed-off-by: Martin Peschke <[email protected]> Signed-off-by: Steffen Maier <[email protected]> Signed-off-by: James Bottomley <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
swarren
pushed a commit
to swarren/linux-tegra
that referenced
this pull request
Feb 12, 2014
…tch-fixes WARNING: line over 80 characters torvalds#67: FILE: kernel/kmod.c:214: + * Kthreadd can be restricted to a set of processors if the user wants to WARNING: line over 80 characters torvalds#69: FILE: kernel/kmod.c:216: + * we do not want to disturb the other processors here either so we start WARNING: line over 80 characters #70: FILE: kernel/kmod.c:217: + * the usermode helper threads only on the processors allowed for kthreadd. total: 0 errors, 3 warnings, 44 lines checked ./patches/kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2.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: Christoph Lameter <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
swarren
pushed a commit
to swarren/linux-tegra
that referenced
this pull request
Feb 18, 2014
…tch-fixes WARNING: line over 80 characters torvalds#67: FILE: kernel/kmod.c:214: + * Kthreadd can be restricted to a set of processors if the user wants to WARNING: line over 80 characters torvalds#69: FILE: kernel/kmod.c:216: + * we do not want to disturb the other processors here either so we start WARNING: line over 80 characters #70: FILE: kernel/kmod.c:217: + * the usermode helper threads only on the processors allowed for kthreadd. total: 0 errors, 3 warnings, 44 lines checked ./patches/kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2.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: Christoph Lameter <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
swarren
pushed a commit
to swarren/linux-tegra
that referenced
this pull request
Feb 26, 2014
…tch-fixes WARNING: line over 80 characters torvalds#67: FILE: kernel/kmod.c:214: + * Kthreadd can be restricted to a set of processors if the user wants to WARNING: line over 80 characters torvalds#69: FILE: kernel/kmod.c:216: + * we do not want to disturb the other processors here either so we start WARNING: line over 80 characters #70: FILE: kernel/kmod.c:217: + * the usermode helper threads only on the processors allowed for kthreadd. total: 0 errors, 3 warnings, 44 lines checked ./patches/kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2.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: Christoph Lameter <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
niwamatsu
pushed a commit
to renesas-devel/linux
that referenced
this pull request
Feb 27, 2014
commit 924dd58 upstream. BUG: sleeping function called from invalid context at kernel/workqueue.c:2752 in_atomic(): 1, irqs_disabled(): 1, pid: 360, name: zfcperp0.0.1700 CPU: 1 Not tainted 3.9.3+ torvalds#69 Process zfcperp0.0.1700 (pid: 360, task: 0000000075b7e080, ksp: 000000007476bc30) <snip> Call Trace: ([<00000000001165de>] show_trace+0x106/0x154) [<00000000001166a0>] show_stack+0x74/0xf4 [<00000000006ff646>] dump_stack+0xc6/0xd4 [<000000000017f3a0>] __might_sleep+0x128/0x148 [<000000000015ece8>] flush_work+0x54/0x1f8 [<00000000001630de>] __cancel_work_timer+0xc6/0x128 [<00000000005067ac>] scsi_device_dev_release_usercontext+0x164/0x23c [<0000000000161816>] execute_in_process_context+0x96/0xa8 [<00000000004d33d8>] device_release+0x60/0xc0 [<000000000048af48>] kobject_release+0xa8/0x1c4 [<00000000004f4bf2>] __scsi_iterate_devices+0xfa/0x130 [<000003ff801b307a>] zfcp_erp_strategy+0x4da/0x1014 [zfcp] [<000003ff801b3caa>] zfcp_erp_thread+0xf6/0x2b0 [zfcp] [<000000000016b75a>] kthread+0xf2/0xfc [<000000000070c9de>] kernel_thread_starter+0x6/0xc [<000000000070c9d8>] kernel_thread_starter+0x0/0xc Apparently, the ref_count for some scsi_device drops down to zero, triggering device removal through execute_in_process_context(), while the lldd error recovery thread iterates through a scsi device list. Unfortunately, execute_in_process_context() decides to immediately execute that device removal function, instead of scheduling asynchronous execution, since it detects process context and thinks it is safe to do so. But almost all calls to shost_for_each_device() in our lldd are inside spin_lock_irq, even in thread context. Obviously, schedule() inside spin_lock_irq sections is a bad idea. Change the lldd to use the proper iterator function, __shost_for_each_device(), in combination with required locking. Occurences that need to be changed include all calls in zfcp_erp.c, since those might be executed in zfcp error recovery thread context with a lock held. Other occurences of shost_for_each_device() in zfcp_fsf.c do not need to be changed (no process context, no surrounding locking). The problem was introduced in Linux 2.6.37 by commit b62a8d9 "[SCSI] zfcp: Use SCSI device data zfcp_scsi_dev instead of zfcp_unit". Reported-by: Christian Borntraeger <[email protected]> Signed-off-by: Martin Peschke <[email protected]> Signed-off-by: Steffen Maier <[email protected]> Signed-off-by: James Bottomley <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
zeitgeist87
pushed a commit
to zeitgeist87/linux
that referenced
this pull request
Mar 14, 2014
…tch-fixes WARNING: line over 80 characters torvalds#67: FILE: kernel/kmod.c:214: + * Kthreadd can be restricted to a set of processors if the user wants to WARNING: line over 80 characters torvalds#69: FILE: kernel/kmod.c:216: + * we do not want to disturb the other processors here either so we start WARNING: line over 80 characters #70: FILE: kernel/kmod.c:217: + * the usermode helper threads only on the processors allowed for kthreadd. total: 0 errors, 3 warnings, 44 lines checked ./patches/kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2.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: Christoph Lameter <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
swarren
pushed a commit
to swarren/linux-tegra
that referenced
this pull request
Mar 19, 2014
…tch-fixes WARNING: line over 80 characters torvalds#67: FILE: kernel/kmod.c:214: + * Kthreadd can be restricted to a set of processors if the user wants to WARNING: line over 80 characters torvalds#69: FILE: kernel/kmod.c:216: + * we do not want to disturb the other processors here either so we start WARNING: line over 80 characters #70: FILE: kernel/kmod.c:217: + * the usermode helper threads only on the processors allowed for kthreadd. total: 0 errors, 3 warnings, 44 lines checked ./patches/kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2.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: Christoph Lameter <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
zeitgeist87
pushed a commit
to zeitgeist87/linux
that referenced
this pull request
Mar 26, 2014
…tch-fixes WARNING: line over 80 characters torvalds#67: FILE: kernel/kmod.c:214: + * Kthreadd can be restricted to a set of processors if the user wants to WARNING: line over 80 characters torvalds#69: FILE: kernel/kmod.c:216: + * we do not want to disturb the other processors here either so we start WARNING: line over 80 characters #70: FILE: kernel/kmod.c:217: + * the usermode helper threads only on the processors allowed for kthreadd. total: 0 errors, 3 warnings, 44 lines checked ./patches/kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2.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: Christoph Lameter <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
ddstreet
pushed a commit
to ddstreet/linux
that referenced
this pull request
Apr 8, 2014
…tch-fixes WARNING: line over 80 characters torvalds#67: FILE: kernel/kmod.c:214: + * Kthreadd can be restricted to a set of processors if the user wants to WARNING: line over 80 characters torvalds#69: FILE: kernel/kmod.c:216: + * we do not want to disturb the other processors here either so we start WARNING: line over 80 characters #70: FILE: kernel/kmod.c:217: + * the usermode helper threads only on the processors allowed for kthreadd. total: 0 errors, 3 warnings, 44 lines checked ./patches/kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2.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: Christoph Lameter <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
gregnietsky
pushed a commit
to Distrotech/linux
that referenced
this pull request
Apr 9, 2014
commit 924dd58 upstream. BUG: sleeping function called from invalid context at kernel/workqueue.c:2752 in_atomic(): 1, irqs_disabled(): 1, pid: 360, name: zfcperp0.0.1700 CPU: 1 Not tainted 3.9.3+ torvalds#69 Process zfcperp0.0.1700 (pid: 360, task: 0000000075b7e080, ksp: 000000007476bc30) <snip> Call Trace: ([<00000000001165de>] show_trace+0x106/0x154) [<00000000001166a0>] show_stack+0x74/0xf4 [<00000000006ff646>] dump_stack+0xc6/0xd4 [<000000000017f3a0>] __might_sleep+0x128/0x148 [<000000000015ece8>] flush_work+0x54/0x1f8 [<00000000001630de>] __cancel_work_timer+0xc6/0x128 [<00000000005067ac>] scsi_device_dev_release_usercontext+0x164/0x23c [<0000000000161816>] execute_in_process_context+0x96/0xa8 [<00000000004d33d8>] device_release+0x60/0xc0 [<000000000048af48>] kobject_release+0xa8/0x1c4 [<00000000004f4bf2>] __scsi_iterate_devices+0xfa/0x130 [<000003ff801b307a>] zfcp_erp_strategy+0x4da/0x1014 [zfcp] [<000003ff801b3caa>] zfcp_erp_thread+0xf6/0x2b0 [zfcp] [<000000000016b75a>] kthread+0xf2/0xfc [<000000000070c9de>] kernel_thread_starter+0x6/0xc [<000000000070c9d8>] kernel_thread_starter+0x0/0xc Apparently, the ref_count for some scsi_device drops down to zero, triggering device removal through execute_in_process_context(), while the lldd error recovery thread iterates through a scsi device list. Unfortunately, execute_in_process_context() decides to immediately execute that device removal function, instead of scheduling asynchronous execution, since it detects process context and thinks it is safe to do so. But almost all calls to shost_for_each_device() in our lldd are inside spin_lock_irq, even in thread context. Obviously, schedule() inside spin_lock_irq sections is a bad idea. Change the lldd to use the proper iterator function, __shost_for_each_device(), in combination with required locking. Occurences that need to be changed include all calls in zfcp_erp.c, since those might be executed in zfcp error recovery thread context with a lock held. Other occurences of shost_for_each_device() in zfcp_fsf.c do not need to be changed (no process context, no surrounding locking). The problem was introduced in Linux 2.6.37 by commit b62a8d9 "[SCSI] zfcp: Use SCSI device data zfcp_scsi_dev instead of zfcp_unit". Reported-by: Christian Borntraeger <[email protected]> Signed-off-by: Martin Peschke <[email protected]> Signed-off-by: Steffen Maier <[email protected]> Signed-off-by: James Bottomley <[email protected]> Signed-off-by: Ben Hutchings <[email protected]>
gregnietsky
pushed a commit
to Distrotech/linux
that referenced
this pull request
Apr 9, 2014
commit 924dd58 upstream. BUG: sleeping function called from invalid context at kernel/workqueue.c:2752 in_atomic(): 1, irqs_disabled(): 1, pid: 360, name: zfcperp0.0.1700 CPU: 1 Not tainted 3.9.3+ torvalds#69 Process zfcperp0.0.1700 (pid: 360, task: 0000000075b7e080, ksp: 000000007476bc30) <snip> Call Trace: ([<00000000001165de>] show_trace+0x106/0x154) [<00000000001166a0>] show_stack+0x74/0xf4 [<00000000006ff646>] dump_stack+0xc6/0xd4 [<000000000017f3a0>] __might_sleep+0x128/0x148 [<000000000015ece8>] flush_work+0x54/0x1f8 [<00000000001630de>] __cancel_work_timer+0xc6/0x128 [<00000000005067ac>] scsi_device_dev_release_usercontext+0x164/0x23c [<0000000000161816>] execute_in_process_context+0x96/0xa8 [<00000000004d33d8>] device_release+0x60/0xc0 [<000000000048af48>] kobject_release+0xa8/0x1c4 [<00000000004f4bf2>] __scsi_iterate_devices+0xfa/0x130 [<000003ff801b307a>] zfcp_erp_strategy+0x4da/0x1014 [zfcp] [<000003ff801b3caa>] zfcp_erp_thread+0xf6/0x2b0 [zfcp] [<000000000016b75a>] kthread+0xf2/0xfc [<000000000070c9de>] kernel_thread_starter+0x6/0xc [<000000000070c9d8>] kernel_thread_starter+0x0/0xc Apparently, the ref_count for some scsi_device drops down to zero, triggering device removal through execute_in_process_context(), while the lldd error recovery thread iterates through a scsi device list. Unfortunately, execute_in_process_context() decides to immediately execute that device removal function, instead of scheduling asynchronous execution, since it detects process context and thinks it is safe to do so. But almost all calls to shost_for_each_device() in our lldd are inside spin_lock_irq, even in thread context. Obviously, schedule() inside spin_lock_irq sections is a bad idea. Change the lldd to use the proper iterator function, __shost_for_each_device(), in combination with required locking. Occurences that need to be changed include all calls in zfcp_erp.c, since those might be executed in zfcp error recovery thread context with a lock held. Other occurences of shost_for_each_device() in zfcp_fsf.c do not need to be changed (no process context, no surrounding locking). The problem was introduced in Linux 2.6.37 by commit b62a8d9 "[SCSI] zfcp: Use SCSI device data zfcp_scsi_dev instead of zfcp_unit". Reported-by: Christian Borntraeger <[email protected]> Signed-off-by: Martin Peschke <[email protected]> Signed-off-by: Steffen Maier <[email protected]> Signed-off-by: James Bottomley <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Gnurou
pushed a commit
to Gnurou/linux
that referenced
this pull request
Jul 1, 2014
At probe time, the musb_am335x driver register its childs by calling of_platform_populate(), which registers all childs in the devicetree hierarchy recursively. On the other side, the driver's remove() function uses of_device_unregister() to remove each child of musb_am335x's. However, when musb_dsps is loaded, its devices are attached to the musb_am335x device as musb_am335x childs. Hence, musb_am335x remove() will attempt to unregister the devices registered by musb_dsps, which produces a kernel panic. In other words, the childs in the "struct device" hierarchy are not the same as the childs in the "devicetree" hierarchy. Ideally, we should enforce the removal of the devices registered by musb_am335x *only*, instead of all its child devices. However, because of the recursive nature of of_platform_populate, this doesn't seem possible. Therefore, as the only solution at hand, this commit disables musb_am335x driver removal capability, preventing it from being ever removed. This was originally suggested by Sebastian Siewior: https://www.mail-archive.com/[email protected]/msg104946.html And for reference, here's the panic upon module removal: musb-hdrc musb-hdrc.0.auto: remove, state 4 usb usb1: USB disconnect, device number 1 musb-hdrc musb-hdrc.0.auto: USB bus 1 deregistered Unable to handle kernel NULL pointer dereference at virtual address 0000008c pgd = de11c000 [0000008c] *pgd=9e174831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] ARM Modules linked in: musb_am335x(-) musb_dsps musb_hdrc usbcore usb_common CPU: 0 PID: 623 Comm: modprobe Not tainted 3.15.0-rc4-00001-g24efd13 torvalds#69 task: de1b7500 ti: de122000 task.ti: de122000 PC is at am335x_shutdown+0x10/0x28 LR is at am335x_shutdown+0xc/0x28 pc : [<c0327798>] lr : [<c0327794>] psr: a0000013 sp : de123df8 ip : 00000004 fp : 00028f00 r10: 00000000 r9 : de122000 r8 : c000e6c4 r7 : de0e3c10 r6 : de0e3800 r5 : de624010 r4 : de1ec750 r3 : de0e3810 r2 : 00000000 r1 : 00000001 r0 : 00000000 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 9e11c019 DAC: 00000015 Process modprobe (pid: 623, stack limit = 0xde122240) Stack: (0xde123df8 to 0xde124000) 3de0: de0e3810 bf054488 3e00: bf05444c de624010 60000013 bf043650 000012fc de624010 de0e3810 bf043a20 3e20: de0e3810 bf04b240 c0635b88 c02ca37c c02ca364 c02c8db0 de1b7500 de0e3844 3e40: de0e3810 c02c8e28 c0635b88 de02824c de0e3810 c02c884c de0e3800 de0e3810 3e60: de0e3818 c02c5b20 bf05417c de0e3800 de0e3800 c0635b88 de0f2410 c02ca838 3e80: bf05417c de0e3800 bf055438 c02ca8cc de0e3c10 bf054194 de0e3c10 c02ca37c 3ea0: c02ca364 c02c8db0 de1b7500 de0e3c44 de0e3c10 c02c8e28 c0635b88 de02824c 3ec0: de0e3c10 c02c884c de0e3c10 de0e3c10 de0e3c18 c02c5b20 de0e3c10 de0e3c10 3ee0: 00000000 bf059000 a0000013 c02c5bc0 00000000 bf05900c de0e3c10 c02c5c48 3f00: de0dd0c0 de1ec970 de0f2410 bf05929c de0f2444 bf05902c de0f2410 c02ca37c 3f20: c02ca364 c02c8db0 bf05929c de0f2410 bf05929c c02c94c8 bf05929c 00000000 3f40: 00000800 c02c8ab4 bf0592e0 c007fc40 c00dd820 6273756d 336d615f 00783533 3f60: c064a0ac de1b7500 de122000 de1b7500 c000e590 00000001 c000e6c4 c0060160 3f80: 00028e70 00028e70 00028ea4 00000081 60000010 00028e70 00028e70 00028ea4 3fa0: 00000081 c000e500 00028e70 00028e70 00028ea4 00000800 becb59f8 00027608 3fc0: 00028e70 00028e70 00028ea4 00000081 00000001 00000001 00000000 00028f00 3fe0: b6e6b6f0 becb59d4 000160e8 b6e6b6fc 60000010 00028ea4 00000000 00000000 [<c0327798>] (am335x_shutdown) from [<bf054488>] (dsps_musb_exit+0x3c/0x4c [musb_dsps]) [<bf054488>] (dsps_musb_exit [musb_dsps]) from [<bf043650>] (musb_shutdown+0x80/0x90 [musb_hdrc]) [<bf043650>] (musb_shutdown [musb_hdrc]) from [<bf043a20>] (musb_remove+0x24/0x68 [musb_hdrc]) [<bf043a20>] (musb_remove [musb_hdrc]) from [<c02ca37c>] (platform_drv_remove+0x18/0x1c) [<c02ca37c>] (platform_drv_remove) from [<c02c8db0>] (__device_release_driver+0x70/0xc8) [<c02c8db0>] (__device_release_driver) from [<c02c8e28>] (device_release_driver+0x20/0x2c) [<c02c8e28>] (device_release_driver) from [<c02c884c>] (bus_remove_device+0xdc/0x10c) [<c02c884c>] (bus_remove_device) from [<c02c5b20>] (device_del+0x104/0x198) [<c02c5b20>] (device_del) from [<c02ca838>] (platform_device_del+0x14/0x9c) [<c02ca838>] (platform_device_del) from [<c02ca8cc>] (platform_device_unregister+0xc/0x20) [<c02ca8cc>] (platform_device_unregister) from [<bf054194>] (dsps_remove+0x18/0x38 [musb_dsps]) [<bf054194>] (dsps_remove [musb_dsps]) from [<c02ca37c>] (platform_drv_remove+0x18/0x1c) [<c02ca37c>] (platform_drv_remove) from [<c02c8db0>] (__device_release_driver+0x70/0xc8) [<c02c8db0>] (__device_release_driver) from [<c02c8e28>] (device_release_driver+0x20/0x2c) [<c02c8e28>] (device_release_driver) from [<c02c884c>] (bus_remove_device+0xdc/0x10c) [<c02c884c>] (bus_remove_device) from [<c02c5b20>] (device_del+0x104/0x198) [<c02c5b20>] (device_del) from [<c02c5bc0>] (device_unregister+0xc/0x20) [<c02c5bc0>] (device_unregister) from [<bf05900c>] (of_remove_populated_child+0xc/0x14 [musb_am335x]) [<bf05900c>] (of_remove_populated_child [musb_am335x]) from [<c02c5c48>] (device_for_each_child+0x44/0x70) [<c02c5c48>] (device_for_each_child) from [<bf05902c>] (am335x_child_remove+0x18/0x30 [musb_am335x]) [<bf05902c>] (am335x_child_remove [musb_am335x]) from [<c02ca37c>] (platform_drv_remove+0x18/0x1c) [<c02ca37c>] (platform_drv_remove) from [<c02c8db0>] (__device_release_driver+0x70/0xc8) [<c02c8db0>] (__device_release_driver) from [<c02c94c8>] (driver_detach+0xb4/0xb8) [<c02c94c8>] (driver_detach) from [<c02c8ab4>] (bus_remove_driver+0x4c/0xa0) [<c02c8ab4>] (bus_remove_driver) from [<c007fc40>] (SyS_delete_module+0x128/0x1cc) [<c007fc40>] (SyS_delete_module) from [<c000e500>] (ret_fast_syscall+0x0/0x48) Fixes: 97238b3 ("usb: musb: dsps: use proper child nodes") Cc: <[email protected]> # v3.12+ Acked-by: George Cherian <[email protected]> Signed-off-by: Ezequiel Garcia <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
heftig
referenced
this pull request
in zen-kernel/zen-kernel
Jul 10, 2014
commit 7adb5c8 upstream. At probe time, the musb_am335x driver register its childs by calling of_platform_populate(), which registers all childs in the devicetree hierarchy recursively. On the other side, the driver's remove() function uses of_device_unregister() to remove each child of musb_am335x's. However, when musb_dsps is loaded, its devices are attached to the musb_am335x device as musb_am335x childs. Hence, musb_am335x remove() will attempt to unregister the devices registered by musb_dsps, which produces a kernel panic. In other words, the childs in the "struct device" hierarchy are not the same as the childs in the "devicetree" hierarchy. Ideally, we should enforce the removal of the devices registered by musb_am335x *only*, instead of all its child devices. However, because of the recursive nature of of_platform_populate, this doesn't seem possible. Therefore, as the only solution at hand, this commit disables musb_am335x driver removal capability, preventing it from being ever removed. This was originally suggested by Sebastian Siewior: https://www.mail-archive.com/[email protected]/msg104946.html And for reference, here's the panic upon module removal: musb-hdrc musb-hdrc.0.auto: remove, state 4 usb usb1: USB disconnect, device number 1 musb-hdrc musb-hdrc.0.auto: USB bus 1 deregistered Unable to handle kernel NULL pointer dereference at virtual address 0000008c pgd = de11c000 [0000008c] *pgd=9e174831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] ARM Modules linked in: musb_am335x(-) musb_dsps musb_hdrc usbcore usb_common CPU: 0 PID: 623 Comm: modprobe Not tainted 3.15.0-rc4-00001-g24efd13 #69 task: de1b7500 ti: de122000 task.ti: de122000 PC is at am335x_shutdown+0x10/0x28 LR is at am335x_shutdown+0xc/0x28 pc : [<c0327798>] lr : [<c0327794>] psr: a0000013 sp : de123df8 ip : 00000004 fp : 00028f00 r10: 00000000 r9 : de122000 r8 : c000e6c4 r7 : de0e3c10 r6 : de0e3800 r5 : de624010 r4 : de1ec750 r3 : de0e3810 r2 : 00000000 r1 : 00000001 r0 : 00000000 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 9e11c019 DAC: 00000015 Process modprobe (pid: 623, stack limit = 0xde122240) Stack: (0xde123df8 to 0xde124000) 3de0: de0e3810 bf054488 3e00: bf05444c de624010 60000013 bf043650 000012fc de624010 de0e3810 bf043a20 3e20: de0e3810 bf04b240 c0635b88 c02ca37c c02ca364 c02c8db0 de1b7500 de0e3844 3e40: de0e3810 c02c8e28 c0635b88 de02824c de0e3810 c02c884c de0e3800 de0e3810 3e60: de0e3818 c02c5b20 bf05417c de0e3800 de0e3800 c0635b88 de0f2410 c02ca838 3e80: bf05417c de0e3800 bf055438 c02ca8cc de0e3c10 bf054194 de0e3c10 c02ca37c 3ea0: c02ca364 c02c8db0 de1b7500 de0e3c44 de0e3c10 c02c8e28 c0635b88 de02824c 3ec0: de0e3c10 c02c884c de0e3c10 de0e3c10 de0e3c18 c02c5b20 de0e3c10 de0e3c10 3ee0: 00000000 bf059000 a0000013 c02c5bc0 00000000 bf05900c de0e3c10 c02c5c48 3f00: de0dd0c0 de1ec970 de0f2410 bf05929c de0f2444 bf05902c de0f2410 c02ca37c 3f20: c02ca364 c02c8db0 bf05929c de0f2410 bf05929c c02c94c8 bf05929c 00000000 3f40: 00000800 c02c8ab4 bf0592e0 c007fc40 c00dd820 6273756d 336d615f 00783533 3f60: c064a0ac de1b7500 de122000 de1b7500 c000e590 00000001 c000e6c4 c0060160 3f80: 00028e70 00028e70 00028ea4 00000081 60000010 00028e70 00028e70 00028ea4 3fa0: 00000081 c000e500 00028e70 00028e70 00028ea4 00000800 becb59f8 00027608 3fc0: 00028e70 00028e70 00028ea4 00000081 00000001 00000001 00000000 00028f00 3fe0: b6e6b6f0 becb59d4 000160e8 b6e6b6fc 60000010 00028ea4 00000000 00000000 [<c0327798>] (am335x_shutdown) from [<bf054488>] (dsps_musb_exit+0x3c/0x4c [musb_dsps]) [<bf054488>] (dsps_musb_exit [musb_dsps]) from [<bf043650>] (musb_shutdown+0x80/0x90 [musb_hdrc]) [<bf043650>] (musb_shutdown [musb_hdrc]) from [<bf043a20>] (musb_remove+0x24/0x68 [musb_hdrc]) [<bf043a20>] (musb_remove [musb_hdrc]) from [<c02ca37c>] (platform_drv_remove+0x18/0x1c) [<c02ca37c>] (platform_drv_remove) from [<c02c8db0>] (__device_release_driver+0x70/0xc8) [<c02c8db0>] (__device_release_driver) from [<c02c8e28>] (device_release_driver+0x20/0x2c) [<c02c8e28>] (device_release_driver) from [<c02c884c>] (bus_remove_device+0xdc/0x10c) [<c02c884c>] (bus_remove_device) from [<c02c5b20>] (device_del+0x104/0x198) [<c02c5b20>] (device_del) from [<c02ca838>] (platform_device_del+0x14/0x9c) [<c02ca838>] (platform_device_del) from [<c02ca8cc>] (platform_device_unregister+0xc/0x20) [<c02ca8cc>] (platform_device_unregister) from [<bf054194>] (dsps_remove+0x18/0x38 [musb_dsps]) [<bf054194>] (dsps_remove [musb_dsps]) from [<c02ca37c>] (platform_drv_remove+0x18/0x1c) [<c02ca37c>] (platform_drv_remove) from [<c02c8db0>] (__device_release_driver+0x70/0xc8) [<c02c8db0>] (__device_release_driver) from [<c02c8e28>] (device_release_driver+0x20/0x2c) [<c02c8e28>] (device_release_driver) from [<c02c884c>] (bus_remove_device+0xdc/0x10c) [<c02c884c>] (bus_remove_device) from [<c02c5b20>] (device_del+0x104/0x198) [<c02c5b20>] (device_del) from [<c02c5bc0>] (device_unregister+0xc/0x20) [<c02c5bc0>] (device_unregister) from [<bf05900c>] (of_remove_populated_child+0xc/0x14 [musb_am335x]) [<bf05900c>] (of_remove_populated_child [musb_am335x]) from [<c02c5c48>] (device_for_each_child+0x44/0x70) [<c02c5c48>] (device_for_each_child) from [<bf05902c>] (am335x_child_remove+0x18/0x30 [musb_am335x]) [<bf05902c>] (am335x_child_remove [musb_am335x]) from [<c02ca37c>] (platform_drv_remove+0x18/0x1c) [<c02ca37c>] (platform_drv_remove) from [<c02c8db0>] (__device_release_driver+0x70/0xc8) [<c02c8db0>] (__device_release_driver) from [<c02c94c8>] (driver_detach+0xb4/0xb8) [<c02c94c8>] (driver_detach) from [<c02c8ab4>] (bus_remove_driver+0x4c/0xa0) [<c02c8ab4>] (bus_remove_driver) from [<c007fc40>] (SyS_delete_module+0x128/0x1cc) [<c007fc40>] (SyS_delete_module) from [<c000e500>] (ret_fast_syscall+0x0/0x48) Fixes: 97238b3 ("usb: musb: dsps: use proper child nodes") Acked-by: George Cherian <[email protected]> Signed-off-by: Ezequiel Garcia <[email protected]> Signed-off-by: Felipe Balbi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
pstglia
pushed a commit
to pstglia/linux
that referenced
this pull request
Oct 6, 2014
At probe time, the musb_am335x driver register its childs by calling of_platform_populate(), which registers all childs in the devicetree hierarchy recursively. On the other side, the driver's remove() function uses of_device_unregister() to remove each child of musb_am335x's. However, when musb_dsps is loaded, its devices are attached to the musb_am335x device as musb_am335x childs. Hence, musb_am335x remove() will attempt to unregister the devices registered by musb_dsps, which produces a kernel panic. In other words, the childs in the "struct device" hierarchy are not the same as the childs in the "devicetree" hierarchy. Ideally, we should enforce the removal of the devices registered by musb_am335x *only*, instead of all its child devices. However, because of the recursive nature of of_platform_populate, this doesn't seem possible. Therefore, as the only solution at hand, this commit disables musb_am335x driver removal capability, preventing it from being ever removed. This was originally suggested by Sebastian Siewior: https://www.mail-archive.com/[email protected]/msg104946.html And for reference, here's the panic upon module removal: musb-hdrc musb-hdrc.0.auto: remove, state 4 usb usb1: USB disconnect, device number 1 musb-hdrc musb-hdrc.0.auto: USB bus 1 deregistered Unable to handle kernel NULL pointer dereference at virtual address 0000008c pgd = de11c000 [0000008c] *pgd=9e174831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] ARM Modules linked in: musb_am335x(-) musb_dsps musb_hdrc usbcore usb_common CPU: 0 PID: 623 Comm: modprobe Not tainted 3.15.0-rc4-00001-g24efd13 torvalds#69 task: de1b7500 ti: de122000 task.ti: de122000 PC is at am335x_shutdown+0x10/0x28 LR is at am335x_shutdown+0xc/0x28 pc : [<c0327798>] lr : [<c0327794>] psr: a0000013 sp : de123df8 ip : 00000004 fp : 00028f00 r10: 00000000 r9 : de122000 r8 : c000e6c4 r7 : de0e3c10 r6 : de0e3800 r5 : de624010 r4 : de1ec750 r3 : de0e3810 r2 : 00000000 r1 : 00000001 r0 : 00000000 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 9e11c019 DAC: 00000015 Process modprobe (pid: 623, stack limit = 0xde122240) Stack: (0xde123df8 to 0xde124000) 3de0: de0e3810 bf054488 3e00: bf05444c de624010 60000013 bf043650 000012fc de624010 de0e3810 bf043a20 3e20: de0e3810 bf04b240 c0635b88 c02ca37c c02ca364 c02c8db0 de1b7500 de0e3844 3e40: de0e3810 c02c8e28 c0635b88 de02824c de0e3810 c02c884c de0e3800 de0e3810 3e60: de0e3818 c02c5b20 bf05417c de0e3800 de0e3800 c0635b88 de0f2410 c02ca838 3e80: bf05417c de0e3800 bf055438 c02ca8cc de0e3c10 bf054194 de0e3c10 c02ca37c 3ea0: c02ca364 c02c8db0 de1b7500 de0e3c44 de0e3c10 c02c8e28 c0635b88 de02824c 3ec0: de0e3c10 c02c884c de0e3c10 de0e3c10 de0e3c18 c02c5b20 de0e3c10 de0e3c10 3ee0: 00000000 bf059000 a0000013 c02c5bc0 00000000 bf05900c de0e3c10 c02c5c48 3f00: de0dd0c0 de1ec970 de0f2410 bf05929c de0f2444 bf05902c de0f2410 c02ca37c 3f20: c02ca364 c02c8db0 bf05929c de0f2410 bf05929c c02c94c8 bf05929c 00000000 3f40: 00000800 c02c8ab4 bf0592e0 c007fc40 c00dd820 6273756d 336d615f 00783533 3f60: c064a0ac de1b7500 de122000 de1b7500 c000e590 00000001 c000e6c4 c0060160 3f80: 00028e70 00028e70 00028ea4 00000081 60000010 00028e70 00028e70 00028ea4 3fa0: 00000081 c000e500 00028e70 00028e70 00028ea4 00000800 becb59f8 00027608 3fc0: 00028e70 00028e70 00028ea4 00000081 00000001 00000001 00000000 00028f00 3fe0: b6e6b6f0 becb59d4 000160e8 b6e6b6fc 60000010 00028ea4 00000000 00000000 [<c0327798>] (am335x_shutdown) from [<bf054488>] (dsps_musb_exit+0x3c/0x4c [musb_dsps]) [<bf054488>] (dsps_musb_exit [musb_dsps]) from [<bf043650>] (musb_shutdown+0x80/0x90 [musb_hdrc]) [<bf043650>] (musb_shutdown [musb_hdrc]) from [<bf043a20>] (musb_remove+0x24/0x68 [musb_hdrc]) [<bf043a20>] (musb_remove [musb_hdrc]) from [<c02ca37c>] (platform_drv_remove+0x18/0x1c) [<c02ca37c>] (platform_drv_remove) from [<c02c8db0>] (__device_release_driver+0x70/0xc8) [<c02c8db0>] (__device_release_driver) from [<c02c8e28>] (device_release_driver+0x20/0x2c) [<c02c8e28>] (device_release_driver) from [<c02c884c>] (bus_remove_device+0xdc/0x10c) [<c02c884c>] (bus_remove_device) from [<c02c5b20>] (device_del+0x104/0x198) [<c02c5b20>] (device_del) from [<c02ca838>] (platform_device_del+0x14/0x9c) [<c02ca838>] (platform_device_del) from [<c02ca8cc>] (platform_device_unregister+0xc/0x20) [<c02ca8cc>] (platform_device_unregister) from [<bf054194>] (dsps_remove+0x18/0x38 [musb_dsps]) [<bf054194>] (dsps_remove [musb_dsps]) from [<c02ca37c>] (platform_drv_remove+0x18/0x1c) [<c02ca37c>] (platform_drv_remove) from [<c02c8db0>] (__device_release_driver+0x70/0xc8) [<c02c8db0>] (__device_release_driver) from [<c02c8e28>] (device_release_driver+0x20/0x2c) [<c02c8e28>] (device_release_driver) from [<c02c884c>] (bus_remove_device+0xdc/0x10c) [<c02c884c>] (bus_remove_device) from [<c02c5b20>] (device_del+0x104/0x198) [<c02c5b20>] (device_del) from [<c02c5bc0>] (device_unregister+0xc/0x20) [<c02c5bc0>] (device_unregister) from [<bf05900c>] (of_remove_populated_child+0xc/0x14 [musb_am335x]) [<bf05900c>] (of_remove_populated_child [musb_am335x]) from [<c02c5c48>] (device_for_each_child+0x44/0x70) [<c02c5c48>] (device_for_each_child) from [<bf05902c>] (am335x_child_remove+0x18/0x30 [musb_am335x]) [<bf05902c>] (am335x_child_remove [musb_am335x]) from [<c02ca37c>] (platform_drv_remove+0x18/0x1c) [<c02ca37c>] (platform_drv_remove) from [<c02c8db0>] (__device_release_driver+0x70/0xc8) [<c02c8db0>] (__device_release_driver) from [<c02c94c8>] (driver_detach+0xb4/0xb8) [<c02c94c8>] (driver_detach) from [<c02c8ab4>] (bus_remove_driver+0x4c/0xa0) [<c02c8ab4>] (bus_remove_driver) from [<c007fc40>] (SyS_delete_module+0x128/0x1cc) [<c007fc40>] (SyS_delete_module) from [<c000e500>] (ret_fast_syscall+0x0/0x48) Fixes: 97238b3 ("usb: musb: dsps: use proper child nodes") Cc: <[email protected]> # v3.12+ Acked-by: George Cherian <[email protected]> Signed-off-by: Ezequiel Garcia <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
kees
pushed a commit
to kees/linux
that referenced
this pull request
Oct 9, 2014
BugLink: http://bugs.launchpad.net/bugs/1356913 commit 7adb5c8 upstream. At probe time, the musb_am335x driver register its childs by calling of_platform_populate(), which registers all childs in the devicetree hierarchy recursively. On the other side, the driver's remove() function uses of_device_unregister() to remove each child of musb_am335x's. However, when musb_dsps is loaded, its devices are attached to the musb_am335x device as musb_am335x childs. Hence, musb_am335x remove() will attempt to unregister the devices registered by musb_dsps, which produces a kernel panic. In other words, the childs in the "struct device" hierarchy are not the same as the childs in the "devicetree" hierarchy. Ideally, we should enforce the removal of the devices registered by musb_am335x *only*, instead of all its child devices. However, because of the recursive nature of of_platform_populate, this doesn't seem possible. Therefore, as the only solution at hand, this commit disables musb_am335x driver removal capability, preventing it from being ever removed. This was originally suggested by Sebastian Siewior: https://www.mail-archive.com/[email protected]/msg104946.html And for reference, here's the panic upon module removal: musb-hdrc musb-hdrc.0.auto: remove, state 4 usb usb1: USB disconnect, device number 1 musb-hdrc musb-hdrc.0.auto: USB bus 1 deregistered Unable to handle kernel NULL pointer dereference at virtual address 0000008c pgd = de11c000 [0000008c] *pgd=9e174831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] ARM Modules linked in: musb_am335x(-) musb_dsps musb_hdrc usbcore usb_common CPU: 0 PID: 623 Comm: modprobe Not tainted 3.15.0-rc4-00001-g24efd13 torvalds#69 task: de1b7500 ti: de122000 task.ti: de122000 PC is at am335x_shutdown+0x10/0x28 LR is at am335x_shutdown+0xc/0x28 pc : [<c0327798>] lr : [<c0327794>] psr: a0000013 sp : de123df8 ip : 00000004 fp : 00028f00 r10: 00000000 r9 : de122000 r8 : c000e6c4 r7 : de0e3c10 r6 : de0e3800 r5 : de624010 r4 : de1ec750 r3 : de0e3810 r2 : 00000000 r1 : 00000001 r0 : 00000000 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 9e11c019 DAC: 00000015 Process modprobe (pid: 623, stack limit = 0xde122240) Stack: (0xde123df8 to 0xde124000) 3de0: de0e3810 bf054488 3e00: bf05444c de624010 60000013 bf043650 000012fc de624010 de0e3810 bf043a20 3e20: de0e3810 bf04b240 c0635b88 c02ca37c c02ca364 c02c8db0 de1b7500 de0e3844 3e40: de0e3810 c02c8e28 c0635b88 de02824c de0e3810 c02c884c de0e3800 de0e3810 3e60: de0e3818 c02c5b20 bf05417c de0e3800 de0e3800 c0635b88 de0f2410 c02ca838 3e80: bf05417c de0e3800 bf055438 c02ca8cc de0e3c10 bf054194 de0e3c10 c02ca37c 3ea0: c02ca364 c02c8db0 de1b7500 de0e3c44 de0e3c10 c02c8e28 c0635b88 de02824c 3ec0: de0e3c10 c02c884c de0e3c10 de0e3c10 de0e3c18 c02c5b20 de0e3c10 de0e3c10 3ee0: 00000000 bf059000 a0000013 c02c5bc0 00000000 bf05900c de0e3c10 c02c5c48 3f00: de0dd0c0 de1ec970 de0f2410 bf05929c de0f2444 bf05902c de0f2410 c02ca37c 3f20: c02ca364 c02c8db0 bf05929c de0f2410 bf05929c c02c94c8 bf05929c 00000000 3f40: 00000800 c02c8ab4 bf0592e0 c007fc40 c00dd820 6273756d 336d615f 00783533 3f60: c064a0ac de1b7500 de122000 de1b7500 c000e590 00000001 c000e6c4 c0060160 3f80: 00028e70 00028e70 00028ea4 00000081 60000010 00028e70 00028e70 00028ea4 3fa0: 00000081 c000e500 00028e70 00028e70 00028ea4 00000800 becb59f8 00027608 3fc0: 00028e70 00028e70 00028ea4 00000081 00000001 00000001 00000000 00028f00 3fe0: b6e6b6f0 becb59d4 000160e8 b6e6b6fc 60000010 00028ea4 00000000 00000000 [<c0327798>] (am335x_shutdown) from [<bf054488>] (dsps_musb_exit+0x3c/0x4c [musb_dsps]) [<bf054488>] (dsps_musb_exit [musb_dsps]) from [<bf043650>] (musb_shutdown+0x80/0x90 [musb_hdrc]) [<bf043650>] (musb_shutdown [musb_hdrc]) from [<bf043a20>] (musb_remove+0x24/0x68 [musb_hdrc]) [<bf043a20>] (musb_remove [musb_hdrc]) from [<c02ca37c>] (platform_drv_remove+0x18/0x1c) [<c02ca37c>] (platform_drv_remove) from [<c02c8db0>] (__device_release_driver+0x70/0xc8) [<c02c8db0>] (__device_release_driver) from [<c02c8e28>] (device_release_driver+0x20/0x2c) [<c02c8e28>] (device_release_driver) from [<c02c884c>] (bus_remove_device+0xdc/0x10c) [<c02c884c>] (bus_remove_device) from [<c02c5b20>] (device_del+0x104/0x198) [<c02c5b20>] (device_del) from [<c02ca838>] (platform_device_del+0x14/0x9c) [<c02ca838>] (platform_device_del) from [<c02ca8cc>] (platform_device_unregister+0xc/0x20) [<c02ca8cc>] (platform_device_unregister) from [<bf054194>] (dsps_remove+0x18/0x38 [musb_dsps]) [<bf054194>] (dsps_remove [musb_dsps]) from [<c02ca37c>] (platform_drv_remove+0x18/0x1c) [<c02ca37c>] (platform_drv_remove) from [<c02c8db0>] (__device_release_driver+0x70/0xc8) [<c02c8db0>] (__device_release_driver) from [<c02c8e28>] (device_release_driver+0x20/0x2c) [<c02c8e28>] (device_release_driver) from [<c02c884c>] (bus_remove_device+0xdc/0x10c) [<c02c884c>] (bus_remove_device) from [<c02c5b20>] (device_del+0x104/0x198) [<c02c5b20>] (device_del) from [<c02c5bc0>] (device_unregister+0xc/0x20) [<c02c5bc0>] (device_unregister) from [<bf05900c>] (of_remove_populated_child+0xc/0x14 [musb_am335x]) [<bf05900c>] (of_remove_populated_child [musb_am335x]) from [<c02c5c48>] (device_for_each_child+0x44/0x70) [<c02c5c48>] (device_for_each_child) from [<bf05902c>] (am335x_child_remove+0x18/0x30 [musb_am335x]) [<bf05902c>] (am335x_child_remove [musb_am335x]) from [<c02ca37c>] (platform_drv_remove+0x18/0x1c) [<c02ca37c>] (platform_drv_remove) from [<c02c8db0>] (__device_release_driver+0x70/0xc8) [<c02c8db0>] (__device_release_driver) from [<c02c94c8>] (driver_detach+0xb4/0xb8) [<c02c94c8>] (driver_detach) from [<c02c8ab4>] (bus_remove_driver+0x4c/0xa0) [<c02c8ab4>] (bus_remove_driver) from [<c007fc40>] (SyS_delete_module+0x128/0x1cc) [<c007fc40>] (SyS_delete_module) from [<c000e500>] (ret_fast_syscall+0x0/0x48) Fixes: 97238b3 ("usb: musb: dsps: use proper child nodes") Acked-by: George Cherian <[email protected]> Signed-off-by: Ezequiel Garcia <[email protected]> Signed-off-by: Felipe Balbi <[email protected]> Signed-off-by: Kamal Mostafa <[email protected]> Signed-off-by: Joseph Salisbury <[email protected]>
prahal
added a commit
to prahal/linux
that referenced
this pull request
Nov 9, 2014
Revert "drm/exynos: enable vsync interrupt while waiting for vblank" This reverts commit 5d39b9e. This fixes closing twice : - starting gdm, stopping, then starting it anew: [ 201.440447] kernel BUG at drivers/gpu/drm/drm_irq.c:1032! [ 201.444737] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM [ 201.450553] Modules linked in: bnep cfg80211 nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace sunrpc r8712u(C) smsc95xx usbnet mii btusb bluetooth rfkill vfat fat s5p_csis s5p_fimc snd_soc_odroidx2_max98 090 v4l2_mem2mem videobuf2_dma_contig videobuf2_memops exynos4_is_common videobuf2_core v4l2_common videodev media snd_soc_i2s snd_soc_idma snd_soc_max98090 ehci_exynos s5p_sss phy_exynos_mipi_video s3c2410_wdt exynosdrm(O) drm_kms_helper phy_exynos_usb2 fuse [ 201.491526] CPU: 0 PID: 2173 Comm: Xorg Tainted: G C O 3.18.0-rc3-00168-gd9d00f7-dirty torvalds#69 [ 201.500637] task: e22e8000 ti: e5ace000 task.ti: e5ace000 [ 201.506026] PC is at drm_vblank_put+0x2c/0xec [ 201.510484] LR is at mixer_wait_for_vblank+0x13c/0x148 [exynosdrm] [ 201.516522] pc : [<c040102c>] lr : [<bf056bc8>] psr: 60010053 [ 201.516522] sp : e5acfcf8 ip : e5acfd08 fp : e5acfd04 [ 201.527977] r10: e5acfe64 r9 : e7a1cdc0 r8 : eade0a80 [ 201.533185] r7 : bf06da98 r6 : eae99a1c r5 : eae998d0 r4 : 0000000a [ 201.539695] r3 : eaca2a00 r2 : 00000000 r1 : 00000000 r0 : eb6e2bc0 [ 201.546207] Flags: nZCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment user [ 201.553410] Control: 10c5387d Table: 65abc04a DAC: 00000015 [ 201.559139] Process Xorg (pid: 2173, stack limit = 0xe5ace248) [ 201.564954] Stack: (0xe5acfcf8 to 0xe5ad0000) [ 201.569296] fce0: e5acfd3c e5acfd08 [ 201.577458] fd00: bf056bc8 c040100c c004f4a0 00000000 e22e8000 c00644c8 e5acfd18 e5acfd18 [ 201.585617] fd20: eac16880 eb6e2e7c eb6e2bc0 e7a1cdc0 e5acfd54 e5acfd40 bf046a34 bf056a98 [ 201.593776] fd40: e7a1cdc4 eb6e2e10 e5acfd84 e5acfd58 bf047298 bf0469fc bf04727c e7a1cdc4 [ 201.601935] fd60: eb6e2e10 eb6e2bc0 e7a1cdc0 eade0a80 eade0a80 e5acfe64 e5acfda4 e5acfd88 [ 201.610094] fd80: c0408cd8 bf047288 e7a1cdc0 e7a1cdc0 eb6e2bc0 eb6e2bc0 e5acfdc4 e5acfda8 [ 201.618253] fda0: c0408d5c c0408c88 eb6e2dc0 c0a844f4 e5acfddc e7a1cdc0 e5acfe0c e5acfdc8 [ 201.626412] fdc0: c0409244 c0408ce8 eade0aec c0a844f4 e5acfdfc e5acfde0 c06ca1d8 c006c158 [ 201.634572] fde0: e7a1cdc0 eade0aec eb6e2e10 e7a1cdc0 eade0aec eb6e2e10 eb6e2bc0 eade0a80 [ 201.642731] fe00: e5acfe34 e5acfe10 c040cee4 c0409134 c040ce10 c0a1540c c0b3515c 000000af [ 201.650890] fe20: eb6e2bc0 e5acfe64 e5acff14 e5acfe38 c03ff900 c040ce1c e5ace020 0000081f [ 201.659049] fe40: b700b3d4 e2031680 c040ce10 c07250b8 00000004 be833b04 00000004 c00464af [ 201.667208] fe60: e5acfeac 0000001b c01476f4 c06c3a78 00000000 c016cfc8 00000000 00000800 [ 201.675368] fe80: 00000008 000000a9 e2fab220 e4c73c80 e2fab220 e2fab220 00000008 00000000 [ 201.683528] fea0: e5acfec4 e5acfeb0 c016cfc8 c01474e4 00408000 e4c73c30 e5acfed4 e5acfec8 [ 201.691686] fec0: c016d044 c016cf8c e5acfefc e5acfed8 c016d250 0000081f c06ce9d4 c0a1c324 [ 201.699845] fee0: b700b3d4 dc8cb000 b6fea010 e3854900 e3854900 00000007 be833b04 eaca5c18 [ 201.708004] ff00: be833b04 00000000 e5acff7c e5acff18 c0169e94 c03ff578 c015a190 c0176e20 [ 201.716163] ff20: 00000020 00000000 00000000 e5856008 e5acff54 e22e8504 00000000 c0a81ea4 [ 201.724323] ff40: e22e8000 c00438c8 e5ace000 00000000 e5acff6c e3854900 e3854900 c00464af [ 201.732482] ff60: be833b04 00000007 e5ace000 00000000 e5acffa4 e5acff80 c0169f20 c0169900 [ 201.740641] ff80: 00000000 b7003a40 be833b04 c00464af 00000036 c000fac4 00000000 e5acffa8 [ 201.748800] ffa0: c000f880 c0169ee8 b7003a40 be833b04 00000007 c00464af be833b04 00000000 [ 201.756960] ffc0: b7003a40 be833b04 c00464af 00000036 b6fd7000 b6fea010 b6fde754 b6fea478 [ 201.765119] ffe0: b6d26664 be833ae4 b6d12b03 b6b40406 80010070 00000007 5a5a5a5a 5a5a5a5a [ 201.773354] [<c040102c>] (drm_vblank_put) from [<bf056bc8>] (mixer_wait_for_vblank+0x13c/0x148 [exynosdrm]) [ 201.783101] [<bf056bc8>] (mixer_wait_for_vblank [exynosdrm]) from [<bf046a34>] (exynos_drm_crtc_complete_scanout+0x44/0x58 [exynosdrm]) [ 201.795231] [<bf046a34>] (exynos_drm_crtc_complete_scanout [exynosdrm]) from [<bf047298>] (exynos_drm_fb_destroy+0x1c/0xd8 [exynosdrm]) [ 201.807355] [<bf047298>] (exynos_drm_fb_destroy [exynosdrm]) from [<c0408cd8>] (drm_framebuffer_free+0x5c/0x60) [ 201.817379] [<c0408cd8>] (drm_framebuffer_free) from [<c0408d5c>] (drm_framebuffer_unreference+0x80/0x8c) [ 201.826925] [<c0408d5c>] (drm_framebuffer_unreference) from [<c0409244>] (drm_framebuffer_remove+0x11c/0x128) [ 201.836820] [<c0409244>] (drm_framebuffer_remove) from [<c040cee4>] (drm_mode_rmfb+0xd4/0xfc) [ 201.845325] [<c040cee4>] (drm_mode_rmfb) from [<c03ff900>] (drm_ioctl+0x394/0x57c) [ 201.852881] [<c03ff900>] (drm_ioctl) from [<c0169e94>] (do_vfs_ioctl+0x5a0/0x5e8) [ 201.860342] [<c0169e94>] (do_vfs_ioctl) from [<c0169f20>] (SyS_ioctl+0x44/0x6c) [ 201.867638] [<c0169f20>] (SyS_ioctl) from [<c000f880>] (ret_fast_syscall+0x0/0x30) [ 201.875182] Code: e0833102 e5932064 e3520000 1a000000 (e7f001f2) [ 201.881258] ---[ end trace 0261a23fb128fce8 ]--- [ 201.885856] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:41 [ 201.894187] in_atomic(): 0, irqs_disabled(): 128, pid: 2173, name: Xorg [ 201.900787] CPU: 0 PID: 2173 Comm: Xorg Tainted: G D C O 3.18.0-rc3-00168-gd9d00f7-dirty torvalds#69 [ 201.909911] [<c0017d5c>] (unwind_backtrace) from [<c0013a48>] (show_stack+0x20/0x24) [ 201.917630] [<c0013a48>] (show_stack) from [<c06c61d0>] (dump_stack+0x88/0xc8) [ 201.924841] [<c06c61d0>] (dump_stack) from [<c004c66c>] (__might_sleep+0x164/0x16c) [ 201.932475] [<c004c66c>] (__might_sleep) from [<c06cab20>] (down_read+0x2c/0x60) [ 201.939853] [<c06cab20>] (down_read) from [<c00371fc>] (exit_signals+0x28/0x154) [ 201.947231] [<c00371fc>] (exit_signals) from [<c002bb78>] (do_exit+0x118/0x9e8) [ 201.954518] [<c002bb78>] (do_exit) from [<c0013d24>] (die+0x2d8/0x308) [ 201.961027] [<c0013d24>] (die) from [<c0013db4>] (arm_notify_die+0x60/0x64) [ 201.967972] [<c0013db4>] (arm_notify_die) from [<c000841c>] (do_undefinstr+0x1dc/0x1f8) [ 201.975962] [<c000841c>] (do_undefinstr) from [<c06ccdec>] (__und_svc_finish+0x0/0x34) [ 201.983851] Exception stack(0xe5acfc70 to 0xe5acfcb8) [ 201.988888] fc60: eb6e2bc0 00000000 00000000 eaca2a00 [ 201.997049] fc80: 0000000a eae998d0 eae99a1c bf06da98 eade0a80 e7a1cdc0 e5acfe64 e5acfd04 [ 202.005206] fca0: e5acfd08 e5acfcf8 bf056bc8 c040102c 60010053 ffffffff [ 202.011808] [<c06ccdec>] (__und_svc_finish) from [<c040102c>] (drm_vblank_put+0x2c/0xec) [ 202.019944] [<c040102c>] (drm_vblank_put) from [<bf056bc8>] (mixer_wait_for_vblank+0x13c/0x148 [exynosdrm]) [ 202.029694] [<bf056bc8>] (mixer_wait_for_vblank [exynosdrm]) from [<bf046a34>] (exynos_drm_crtc_complete_scanout+0x44/0x58 [exynosdrm]) [ 202.041829] [<bf046a34>] (exynos_drm_crtc_complete_scanout [exynosdrm]) from [<bf047298>] (exynos_drm_fb_destroy+0x1c/0xd8 [exynosdrm]) [ 202.053950] [<bf047298>] (exynos_drm_fb_destroy [exynosdrm]) from [<c0408cd8>] (drm_framebuffer_free+0x5c/0x60) [ 202.063978] [<c0408cd8>] (drm_framebuffer_free) from [<c0408d5c>] (drm_framebuffer_unreference+0x80/0x8c) [ 202.073524] [<c0408d5c>] (drm_framebuffer_unreference) from [<c0409244>] (drm_framebuffer_remove+0x11c/0x128) [ 202.083418] [<c0409244>] (drm_framebuffer_remove) from [<c040cee4>] (drm_mode_rmfb+0xd4/0xfc) [ 202.091922] [<c040cee4>] (drm_mode_rmfb) from [<c03ff900>] (drm_ioctl+0x394/0x57c) [ 202.099476] [<c03ff900>] (drm_ioctl) from [<c0169e94>] (do_vfs_ioctl+0x5a0/0x5e8) [ 202.106940] [<c0169e94>] (do_vfs_ioctl) from [<c0169f20>] (SyS_ioctl+0x44/0x6c) [ 202.114233] [<c0169f20>] (SyS_ioctl) from [<c000f880>] (ret_fast_syscall+0x0/0x30) - starting retroarch, closing it , then starting it anew: [ 259.913036] kernel BUG at drivers/gpu/drm/drm_irq.c:1032! [ 259.917372] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM [ 259.923238] Modules linked in: cfg80211 bnep nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace sunrpc r8712u(C) smsc95xx usbnet mii btusb bluetooth rfkill vfat fat s5p_csis s5p_fimc v4l2_mem2mem videobuf2 _dma_contig videobuf2_memops exynos4_is_common videobuf2_core v4l2_common videodev snd_soc_odroidx2_max98090 media snd_soc_i2s snd_soc_max98090 snd_soc_idma ehci_exynos s5p_sss s3c2410_wdt phy_exynos_mipi_video exynosdrm(O) drm_kms_helper phy_exynos_usb2 fuse [ 259.964669] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G C O 3.18.0-rc3-00168-gd9d00f7-dirty torvalds#69 [ 259.974405] task: c0a19da8 ti: c0a0c000 task.ti: c0a0c000 [ 259.979802] PC is at drm_vblank_put+0x2c/0xec [ 259.984244] LR is at exynos_drm_crtc_finish_pageflip+0xc4/0xf4 [exynosdrm] [ 259.991103] pc : [<c040102c>] lr : [<bf046900>] psr: 600001d3 [ 259.991103] sp : c0a0dd98 ip : c0a0dda8 fp : c0a0dda4 [ 260.006095] r10: 00100100 r9 : eac117c0 r8 : 00200200 [ 260.009687] r7 : eb6dabc0 r6 : 00000000 r5 : eaf77d00 r4 : eaf77d00 [ 260.015777] r3 : eaf73b80 r2 : 00000000 r1 : 00000000 r0 : eb6dabc0 [ 260.022317] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [ 260.029875] Control: 10c5387d Table: 602ec04a DAC: 00000015 [ 260.035658] Process swapper/0 (pid: 0, stack limit = 0xc0a0c248) [ 260.041720] Stack: (0xc0a0dd98 to 0xc0a0e000) [ 260.046106] dd80: c0a0dde4 c0a0dda8 [ 260.054378] dda0: bf046900 c040100c 00000103 200001d3 eac11b10 eb6dad20 00000000 eaec9e50 [ 260.062611] ddc0: 00000801 eaec9e9c 00000801 00000001 00000000 00000000 c0a0de04 c0a0dde8 [ 260.070793] dde0: bf056c34 bf046848 eb7ca800 edc1cddc 0000007b 00000000 c0a0de4c c0a0de08 [ 260.078969] de00: c007dde8 bf056be0 c0a0de64 c0a0de18 c0a7292c edc1cd80 c0a72bf8 c0a72c14 [ 260.087184] de20: 18be26c7 edc1cd80 edc1cddc eb7ca800 00000000 00000001 c0a0df00 edc176c0 [ 260.095416] de40: c0a0de6c c0a0de50 c007dff8 c007dd4c 00000000 edc1cd80 edc1cddc c0a4379c [ 260.103656] de60: c0a0de8c c0a0de70 c0080e60 c007dfb8 c0080d54 0000007b 00000000 0000007b [ 260.111877] de80: c0a0dea4 c0a0de90 c007d3e0 c0080d60 000000bf c0a08fb0 c0a0ded4 c0a0dea8 [ 260.120069] dea0: c007d710 c007d3b0 c0a0df00 f881000c 0000007b 0000006b c0a16a78 c0a0df00 [ 260.128285] dec0: f8810000 c0a733bc c0a0defc c0a0ded8 c00086d8 c007d664 c001057c 60000053 [ 260.136491] dee0: ffffffff c0a0df34 00000000 c0a0c000 c0a0df54 c0a0df00 c06ccd40 c0008688 [ 260.144715] df00: ffffffed 00000000 ffffffed c0023980 c0a0c018 c0a154ec c06d2cf8 00000000 [ 260.152925] df20: 00000000 c0a0c000 c0a733bc c0a0df54 c0a0df58 c0a0df48 c0010578 c001057c [ 260.161142] df40: 60000053 ffffffff c0a0df94 c0a0df58 c0064a2c c0010544 00000001 c0a0c000 [ 260.169365] df60: c0a0df84 c0a0df70 c0a09f80 c0a72929 00000000 c0a167f0 c0a09f80 c0a091c8 [ 260.177567] df80: c06c7928 c0a15400 c0a0dfac c0a0df98 c06c060c c0064810 c0a0c000 c0a16570 [ 260.185753] dfa0: c0a0dff4 c0a0dfb0 c0992d80 c06c0584 ffffffff ffffffff c0992638 00000000 [ 260.193989] dfc0: 00000000 c09daa38 00000000 c0a80e94 c0a1547c c09daa34 c0a1b208 4000406a [ 260.202209] dfe0: 413fc090 00000000 00000000 c0a0dff8 40008070 c0992990 00000000 00000000 [ 260.210483] [<c040102c>] (drm_vblank_put) from [<bf046900>] (exynos_drm_crtc_finish_pageflip+0xc4/0xf4 [exynosdrm]) [ 260.221140] [<bf046900>] (exynos_drm_crtc_finish_pageflip [exynosdrm]) from [<bf056c34>] (mixer_irq_handler+0x60/0x110 [exynosdrm]) [ 260.232991] [<bf056c34>] (mixer_irq_handler [exynosdrm]) from [<c007dde8>] (handle_irq_event_percpu+0xa8/0x26c) [ 260.243118] [<c007dde8>] (handle_irq_event_percpu) from [<c007dff8>] (handle_irq_event+0x4c/0x6c) [ 260.252056] [<c007dff8>] (handle_irq_event) from [<c0080e60>] (handle_fasteoi_irq+0x10c/0x1a8) [ 260.260676] [<c0080e60>] (handle_fasteoi_irq) from [<c007d3e0>] (generic_handle_irq+0x3c/0x4c) [ 260.269328] [<c007d3e0>] (generic_handle_irq) from [<c007d710>] (__handle_domain_irq+0xb8/0xe4) [ 260.278055] [<c007d710>] (__handle_domain_irq) from [<c00086d8>] (gic_handle_irq+0x5c/0x78) [ 260.286467] [<c00086d8>] (gic_handle_irq) from [<c06ccd40>] (__irq_svc+0x40/0x74) [ 260.294064] Exception stack(0xc0a0df00 to 0xc0a0df48) [ 260.299921] df00: ffffffed 00000000 ffffffed c0023980 c0a0c018 c0a154ec c06d2cf8 00000000 [ 260.308388] df20: 00000000 c0a0c000 c0a733bc c0a0df54 c0a0df58 c0a0df48 c0010578 c001057c [ 260.316929] df40: 60000053 ffffffff [ 260.322986] [<c06ccd40>] (__irq_svc) from [<c001057c>] (arch_cpu_idle+0x44/0x48) [ 260.330892] [<c001057c>] (arch_cpu_idle) from [<c0064a2c>] (cpu_startup_entry+0x228/0x43c) [ 260.339786] [<c0064a2c>] (cpu_startup_entry) from [<c06c060c>] (rest_init+0x94/0x98) [ 260.348245] [<c06c060c>] (rest_init) from [<c0992d80>] (start_kernel+0x3fc/0x408) [ 260.356491] Code: e0833102 e5932064 e3520000 1a000000 (e7f001f2) [ 260.363444] ---[ end trace 741583fda3bdfbd0 ]--- [ 260.369952] Kernel panic - not syncing: Fatal exception in interrupt [ 274.220295] BUG: spinlock lockup suspected on CPU#0, swapper/0/0 [ 274.227876] lock: 0xeaec9e9c, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0 [ 274.237063] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G D C O 3.18.0-rc3-00168-gd9d00f7-dirty torvalds#69 [ 274.247905] [<c0017d5c>] (unwind_backtrace) from [<c0013a48>] (show_stack+0x20/0x24) [ 274.257202] [<c0013a48>] (show_stack) from [<c06c61d0>] (dump_stack+0x88/0xc8) [ 274.265928] [<c06c61d0>] (dump_stack) from [<c06c1fb4>] (spin_dump+0x94/0x9c) [ 274.274525] [<c06c1fb4>] (spin_dump) from [<c006db4c>] (do_raw_spin_lock+0x100/0x1a0) [ 274.283849] [<c006db4c>] (do_raw_spin_lock) from [<c06cc2ec>] (_raw_spin_lock_irqsave+0x30/0x38) [ 274.294220] [<c06cc2ec>] (_raw_spin_lock_irqsave) from [<bf0579b8>] (mixer_win_commit+0x910/0xc2c [exynosdrm]) [ 274.305845] [<bf0579b8>] (mixer_win_commit [exynosdrm]) from [<bf04698c>] (exynos_drm_crtc_plane_commit+0x2c/0x30 [exynosdrm]) [ 274.318923] [<bf04698c>] (exynos_drm_crtc_plane_commit [exynosdrm]) from [<bf049458>] (exynos_plane_commit+0x24/0x28 [exynosdrm]) [ 274.332328] [<bf049458>] (exynos_plane_commit [exynosdrm]) from [<bf046300>] (exynos_drm_crtc_commit+0x2c/0x54 [exynosdrm]) [ 274.345263] [<bf046300>] (exynos_drm_crtc_commit [exynosdrm]) from [<bf046484>] (exynos_drm_crtc_mode_set_commit.isra.1+0x98/0xa8 [exynosdrm]) [ 274.359941] [<bf046484>] (exynos_drm_crtc_mode_set_commit.isra.1 [exynosdrm]) from [<bf0464ac>] (exynos_drm_crtc_mode_set_base+0x18/0x1c [exynosdrm]) [ 274.375305] [<bf0464ac>] (exynos_drm_crtc_mode_set_base [exynosdrm]) from [<bf0264cc>] (drm_crtc_helper_set_config+0x80c/0x9cc [drm_kms_helper]) [ 274.390222] [<bf0264cc>] (drm_crtc_helper_set_config [drm_kms_helper]) from [<c0408dac>] (drm_mode_set_config_internal+0x44/0xf0) [ 274.403895] [<c0408dac>] (drm_mode_set_config_internal) from [<bf02d6f0>] (restore_fbdev_mode+0xe8/0x108 [drm_kms_helper]) [ 274.417019] [<bf02d6f0>] (restore_fbdev_mode [drm_kms_helper]) from [<bf02da80>] (drm_fb_helper_force_kernel_mode+0x68/0x9c [drm_kms_helper]) [ 274.431894] [<bf02da80>] (drm_fb_helper_force_kernel_mode [drm_kms_helper]) from [<bf02db24>] (drm_fb_helper_panic+0x38/0x44 [drm_kms_helper]) [ 274.446943] [<bf02db24>] (drm_fb_helper_panic [drm_kms_helper]) from [<c00462c4>] (notifier_call_chain+0x54/0x94) [ 274.459472] [<c00462c4>] (notifier_call_chain) from [<c0046600>] (atomic_notifier_call_chain+0x44/0x58) [ 274.471182] [<c0046600>] (atomic_notifier_call_chain) from [<c06c1844>] (panic+0xcc/0x224) [ 274.481748] [<c06c1844>] (panic) from [<c0013cf4>] (die+0x2a8/0x308) [ 274.490376] [<c0013cf4>] (die) from [<c0013db4>] (arm_notify_die+0x60/0x64) [ 274.499577] [<c0013db4>] (arm_notify_die) from [<c000841c>] (do_undefinstr+0x1dc/0x1f8) [ 274.509870] [<c000841c>] (do_undefinstr) from [<c06ccdec>] (__und_svc_finish+0x0/0x34) [ 274.520123] Exception stack(0xc0a0dd10 to 0xc0a0dd58) [ 274.528108] dd00: eb6dabc0 00000000 00000000 eaf73b80 [ 274.538623] dd20: eaf77d00 eaf77d00 00000000 eb6dabc0 00200200 eac117c0 00100100 c0a0dda4 [ 274.549124] dd40: c0a0dda8 c0a0dd98 bf046900 c040102c 600001d3 ffffffff [ 274.558034] [<c06ccdec>] (__und_svc_finish) from [<c040102c>] (drm_vblank_put+0x2c/0xec) [ 274.568502] [<c040102c>] (drm_vblank_put) from [<bf046900>] (exynos_drm_crtc_finish_pageflip+0xc4/0xf4 [exynosdrm]) [ 274.581430] [<bf046900>] (exynos_drm_crtc_finish_pageflip [exynosdrm]) from [<bf056c34>] (mixer_irq_handler+0x60/0x110 [exynosdrm]) [ 274.595800] [<bf056c34>] (mixer_irq_handler [exynosdrm]) from [<c007dde8>] (handle_irq_event_percpu+0xa8/0x26c) [ 274.608413] [<c007dde8>] (handle_irq_event_percpu) from [<c007dff8>] (handle_irq_event+0x4c/0x6c) [ 274.619814] [<c007dff8>] (handle_irq_event) from [<c0080e60>] (handle_fasteoi_irq+0x10c/0x1a8) [ 274.630931] [<c0080e60>] (handle_fasteoi_irq) from [<c007d3e0>] (generic_handle_irq+0x3c/0x4c) [ 274.642032] [<c007d3e0>] (generic_handle_irq) from [<c007d710>] (__handle_domain_irq+0xb8/0xe4) [ 274.653171] [<c007d710>] (__handle_domain_irq) from [<c00086d8>] (gic_handle_irq+0x5c/0x78) [ 274.663965] [<c00086d8>] (gic_handle_irq) from [<c06ccd40>] (__irq_svc+0x40/0x74) [ 274.673915] Exception stack(0xc0a0df00 to 0xc0a0df48) [ 274.682075] df00: ffffffed 00000000 ffffffed c0023980 c0a0c018 c0a154ec c06d2cf8 00000000 [ 274.692772] df20: 00000000 c0a0c000 c0a733bc c0a0df54 c0a0df58 c0a0df48 c0010578 c001057c [ 274.703444] df40: 60000053 ffffffff [ 274.711547] [<c06ccd40>] (__irq_svc) from [<c001057c>] (arch_cpu_idle+0x44/0x48) [ 274.721431] [<c001057c>] (arch_cpu_idle) from [<c0064a2c>] (cpu_startup_entry+0x228/0x43c) [ 274.732202] [<c0064a2c>] (cpu_startup_entry) from [<c06c060c>] (rest_init+0x94/0x98) [ 274.742445] [<c06c060c>] (rest_init) from [<c0992d80>] (start_kernel+0x3fc/0x408)
alexandrebelloni
pushed a commit
to alexandrebelloni/linux
that referenced
this pull request
Nov 10, 2014
The handle_rx() path calls uart_handle_sysrq_char() with the port lock held. This causes a spinlock recursion. Release and reacquire the lock here to avoid this. BUG: spinlock recursion on CPU#0, swapper/0 lock: msm_uart_ports+0x1e0/0x2d0, .magic: dead4ead, .owner: swapper/0, .owner_cpu: 0 CPU: 0 PID: 0 Comm: swapper Not tainted 3.17.0-rc7-00012-gb38ee8265941 torvalds#69 [<c0013964>] (unwind_backtrace) from [<c0011f74>] (show_stack+0x10/0x14) [<c0011f74>] (show_stack) from [<c004ed1c>] (do_raw_spin_lock+0x11c/0x13c) [<c004ed1c>] (do_raw_spin_lock) from [<c02d44c0>] (msm_console_write+0x78/0x188) [<c02d44c0>] (msm_console_write) from [<c0052880>] (call_console_drivers.constprop.22+0xb4/0x144) [<c0052880>] (call_console_drivers.constprop.22) from [<c0053570>] (console_unlock+0x27c/0x4ac) [<c0053570>] (console_unlock) from [<c0053bb4>] (vprintk_emit+0x1f4/0x5a8) [<c0053bb4>] (vprintk_emit) from [<c04ad0ac>] (printk+0x30/0x40) [<c04ad0ac>] (printk) from [<c02c2990>] (__handle_sysrq+0x58/0x1b8) [<c02c2990>] (__handle_sysrq) from [<c02d41b0>] (msm_irq+0x694/0x6f8) [<c02d41b0>] (msm_irq) from [<c0055740>] (handle_irq_event_percpu+0x58/0x270) [<c0055740>] (handle_irq_event_percpu) from [<c0055994>] (handle_irq_event+0x3c/0x5c) [<c0055994>] (handle_irq_event) from [<c0057e84>] (handle_level_irq+0x9c/0x138) [<c0057e84>] (handle_level_irq) from [<c005509c>] (generic_handle_irq+0x24/0x38) [<c005509c>] (generic_handle_irq) from [<c000f730>] (handle_IRQ+0x44/0xb0) [<c000f730>] (handle_IRQ) from [<c0008518>] (msm_vic_handle_irq+0x44/0x64) [<c0008518>] (msm_vic_handle_irq) from [<c04b5ac4>] (__irq_svc+0x44/0x7c) Exception stack(0xc0719f68 to 0xc0719fb0) 9f60: 00000001 00000001 00000000 c0722938 c0718000 c0769acc 9f80: 00000000 c0720098 c0769305 4117b362 c0769acc 00000000 01000000 c0719fb0 9fa0: c004cab0 c000f880 20000013 ffffffff [<c04b5ac4>] (__irq_svc) from [<c000f880>] (arch_cpu_idle+0x20/0x30) [<c000f880>] (arch_cpu_idle) from [<c004691c>] (cpu_startup_entry+0xf4/0x23c) [<c004691c>] (cpu_startup_entry) from [<c06d8b70>] (start_kernel+0x32c/0x394) Cc: Frank Rowand <[email protected]> Cc: Daniel Thompson <[email protected]> Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
aryabinin
referenced
this pull request
in aryabinin/linux
Nov 18, 2014
GIT ca1fa22e67bcfc84f49e44ad6f728e3e3d487dce commit 48eb5b9c3dd2768b6a4de9c1eab606820fd84192 Author: Daniel Borkmann <[email protected]> Date: Tue Nov 11 10:22:05 2014 -0800 ixgbe: phy: fix uninitialized status in ixgbe_setup_phy_link_tnx Status variable is never initialized, can carry an arbitrary value on the stack and thus may let the function fail. Fixes: e90dd2645664 ("ixgbe: Make return values more direct") Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Emil Tantilov <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 4eed83a252257ad8ad41ba1c769341960ed4cdc5 Author: James Cameron <[email protected]> Date: Tue Nov 11 16:21:28 2014 +1100 mwifiex: simplify ad hoc join capability info While preparing an ad-hoc start command, the capability info bitmap is needlessly set from the command, and then the ESS bit cleared. Change to set the bitmap directly without reference to the command. Signed-off-by: James Cameron <[email protected]> Acked-by: Amitkumar Karwar <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit d351f5fea44a7527819598070e11b5c9dc53c017 Author: Luciano Coelho <[email protected]> Date: Mon Nov 10 09:25:57 2014 +0200 wlcore: make wlcore_cmd_send_failsafe() static The wlcore_cmd_send_failsafe() function is only called in the cmd.c file, where it is definde. Make it static. Additionally, move the EXPORT_SYMBOL macro for wl1271_cmd_send() to the right place. Signed-off-by: Luciano Coelho <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit f5b8f4790bb5dfd541f9d61589357ea6042cc668 Author: Luciano Coelho <[email protected]> Date: Mon Nov 10 09:25:17 2014 +0200 wlcore: check minimum buffer size in some cmd_send functions Check for the minimum required buffer length in wlcore_cmd_send() and wlcore_cmd_configure_failsafe. This ensures that we will never try to use a buffer that is smaller than the required header. Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Luciano Coelho <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 0d4b5c7c0892cb377cc71c388433425f598b902b Author: Amitkumar Karwar <[email protected]> Date: Fri Nov 7 02:14:52 2014 -0800 mwifiex: fix version display problem on big endian platforms It's been observed that wrong firmware version (ex. 66.14.96.p9 instead of 14.66.9.p96) is displayed on big endian platforms. The problem is fixed here. Reported-by: Daniel Mosquera <[email protected]> Tested-by: Daniel Mosquera <[email protected]> Signed-off-by: Amitkumar Karwar <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 3f2aa13f6d16a53a4cf5de369c685c6f75fe4d58 Author: Oleksij Rempel <[email protected]> Date: Thu Nov 6 08:53:38 2014 +0100 ath9k_htc: add spectral scan debug interface Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 83fb287ecd8ae60ed79c647a5df8beacdf4f4807 Author: Oleksij Rempel <[email protected]> Date: Thu Nov 6 08:53:37 2014 +0100 ath9k_htc: process rx spectral packets use code provided by Ashish Patro <[email protected]> Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 911544f6a8d66c27ff807f5d71e3f0f5a904c100 Author: Oleksij Rempel <[email protected]> Date: Thu Nov 6 08:53:36 2014 +0100 ath9k_htc: trigger spectral scan on set_channel Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 88a2e3fb7b7e9dd3c51ceef81e0415478c27910c Author: Oleksij Rempel <[email protected]> Date: Thu Nov 6 08:53:35 2014 +0100 ath9k_htc: set initial spec_config values use values provided by Ashish Patro <[email protected]> Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit fe30e8bb5be52e2e6b913db77dda6c22b643dbd7 Author: Oleksij Rempel <[email protected]> Date: Thu Nov 6 08:53:34 2014 +0100 ath9k_htc: add struct ath_spec_scan_priv to ath9k_htc_priv Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 94cd95c217a5ed4c45e2a8c97043c3efcd66dac9 Author: Oleksij Rempel <[email protected]> Date: Thu Nov 6 08:53:33 2014 +0100 ath9k_htc: add ath_ps_ops bindings Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 525d09456b9fc2f769647c744c75629d9926fb9e Author: Oleksij Rempel <[email protected]> Date: Thu Nov 6 08:53:32 2014 +0100 ath9k_htc: fix rs_datalen conversation For some reason it didn't coused obvious problems. Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 46140ddf169703ef0538bf00098233b24b2269e8 Author: Oleksij Rempel <[email protected]> Date: Thu Nov 6 08:53:31 2014 +0100 ath9k: For AR9271 chipsets, set count = 0 for endless samples. not sure why. Initially provided by Ashish Patro <[email protected]> Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 67dc74f15f147b9f88702de2952d2951e3e000ec Author: Oleksij Rempel <[email protected]> Date: Thu Nov 6 08:53:30 2014 +0100 ath9k: move spectral.* to common-spectral.* and rename exports from ath9k_spectral_* to ath9k_cmn_spectral_* Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit f00a422cc81ef665f5098c0bc43cb0c616e55a9b Author: Oleksij Rempel <[email protected]> Date: Thu Nov 6 08:53:29 2014 +0100 ath9k: move ath9k_spectral_scan_ from main.c to spectral.c Now we should be ready to make this code common. Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 963916dfe2907d91eb8a250d12d2b5ae5a1bb343 Author: Oleksij Rempel <[email protected]> Date: Thu Nov 6 08:53:28 2014 +0100 ath9k: make ath9k_spectral_scan_ do not depend on ath_softc last preparation before moving ath9k_spectral_scan_ to spectral.c Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit ef948da55f20edbb68dac427b7e067c805c852f5 Author: Oleksij Rempel <[email protected]> Date: Thu Nov 6 08:53:27 2014 +0100 ath9k: use ath_common instead of ieee80211_hw in ath9k_spectral_scan_ we don't have here any ieee80211_hw dependencies any way. Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 934bdc73dd3029c1b91e1a3538268b4afccd58cf Author: Oleksij Rempel <[email protected]> Date: Thu Nov 6 08:53:26 2014 +0100 ath9k: use ath_ps_ops in ath9k_spectral_scan_ Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 99d2217b731e664aa31001839f12944b1e114a08 Author: Oleksij Rempel <[email protected]> Date: Thu Nov 6 08:53:25 2014 +0100 ath9k: add ath_ps_ops bindings Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 0198c2e2987c5cd4980f15126d7c68759f4def95 Author: Oleksij Rempel <[email protected]> Date: Thu Nov 6 08:53:24 2014 +0100 ath: add struct ath_ps_ops we will need it to make common code Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 1111d426ef6a62903a8427a80c2a20cdf0380349 Author: Oleksij Rempel <[email protected]> Date: Thu Nov 6 08:53:23 2014 +0100 ath9k: remove all struct ath_softc dependencies from spectral code Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit dd7657be756551b23b3431d81e66a8d95a72c923 Author: Oleksij Rempel <[email protected]> Date: Thu Nov 6 08:53:22 2014 +0100 ath9k: add ath_hw to ath_spec_scan_priv spectral code mostly depends on ath_hw, not on ath_softc Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit c10b75af4344fe0e678d167cb401a94f565e978c Author: Oleksij Rempel <[email protected]> Date: Thu Nov 6 08:53:21 2014 +0100 ath9k: use struct dentry by ath9k_spectral_init_debug this will alow us to make ath_softc independent code. Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 21af25d00b8bdf03a899b316d41d31ac3eafaf78 Author: Oleksij Rempel <[email protected]> Date: Thu Nov 6 08:53:20 2014 +0100 ath9k: move spec_config to ath_spec_scan_priv Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 8391f60194bd0d9ab489105381df6455afe1f39a Author: Oleksij Rempel <[email protected]> Date: Thu Nov 6 08:53:19 2014 +0100 ath9k: move spectral_mode to ath_spec_scan_priv Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 911ea79f435302fabefa305d3649efd4e205672b Author: Oleksij Rempel <[email protected]> Date: Thu Nov 6 08:53:18 2014 +0100 ath9k: add struct ath_spec_scan_priv and move rfs_chan_spec_scan to this struct. We will need it for common spectral scan code. Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit d7d8b83473e6932cfe9f89e6d839f27abf35b319 Author: Avinash Patil <[email protected]> Date: Wed Nov 5 17:04:31 2014 +0530 mwifiex: fix warning while starting BSS We see this warning while starting mwifiex AP: Unsupported RX-STBC, default to 2x2 This was happening because of wrong offset while copying HT capabilities from BSS configuration of start_ap handler. Signed-off-by: Amitkumar Karwar <[email protected]> Signed-off-by: Avinash Patil <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit bfd713bc1a5d7f01e3d7febe0849b21ae1355c7c Author: Avinash Patil <[email protected]> Date: Wed Nov 5 17:04:30 2014 +0530 mwifiex: do not setup AMPDU/AMSDU with broadcast receiver It is observed that device sometimes sends BA setup requests for broadcast mac address. This patch adds a check to avoid checking availability of AMPDU/AMSDU streams for broadcast mac address. Signed-off-by: Amitkumar Karwar <[email protected]> Signed-off-by: Avinash Patil <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit cf6a64fd603ae0f7391f7589b0f3568d4e79605c Author: Amitkumar Karwar <[email protected]> Date: Wed Nov 5 17:04:29 2014 +0530 mwifiex: fix out of memory issue observed for USB chipsets On some platforms, system goes out of memory during heavy Rx traffic with our USB chipsets. In case of SDIO/PCIe, after receiving 50 packets in Rx queue we stop processing interrupts till packets pending fall below low threshold i.e 20. We don't have similar logic for USB, so if host platform is slow, we would hit a case where firmware keeps on pushing packets at high speed than driver/kernel can process. We will stop submitting URBs for Rx data when pending packet count reaches high threshold and restart them when enough packets are consumed to solve the problem. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=85071 Reported-by: Marek Belisko <[email protected]> Tested-by: Marek Belisko <[email protected]> Signed-off-by: Avinash Patil <[email protected]> Signed-off-by: Cathy Luo <[email protected]> Signed-off-by: Amitkumar Karwar <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 041bfab5bbb6ec721c743f487e3e22b87f666996 Author: Avinash Patil <[email protected]> Date: Wed Nov 5 17:04:28 2014 +0530 mwifiex: remove data_complete handler This patch removes redundant data complete handler. Signed-off-by: Avinash Patil <[email protected]> Signed-off-by: Cathy Luo <[email protected]> Signed-off-by: Amitkumar Karwar <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit ec4a16b4d287d4d0f7465ae7e61ce4e9021d715c Author: Avinash Patil <[email protected]> Date: Wed Nov 5 17:04:27 2014 +0530 mwifiex: rx workqueue support for USB interface This patch adds RX workqueue support for USB interfaces. Currently rx_pending is applicable for cmd/events and Rx data in USB interface. Let's use it only for Rx data. Signed-off-by: Avinash Patil <[email protected]> Signed-off-by: Cathy Luo <[email protected]> Signed-off-by: Amitkumar Karwar <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit d385c5c2860075e1f3e03074f043dd8a828b2862 Author: Felix Fietkau <[email protected]> Date: Tue Nov 4 16:56:57 2014 +0100 ath9k: add support for reporting tx power to mac80211 Track it per channel context instead of in the softc Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 71783576b5345d63df048c0f18974037eea6e4f9 Author: Hauke Mehrtens <[email protected]> Date: Sat Nov 1 16:54:56 2014 +0100 bcma: get IRQ numbers from dt It is not possible to auto detect the irq numbers used by the cores on an arm SoC. If bcma was registered with device tree it will search for some device tree nodes with the irq number and add it to the core configuration. Signed-off-by: Hauke Mehrtens <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 85eb92e81801d64686eb78928d500a4c83ee9623 Author: Hauke Mehrtens <[email protected]> Date: Sat Nov 1 16:54:55 2014 +0100 bcma: make it possible to specify a IRQ num in bcma_core_irq() This moves bcma_core_irq() to main.c and add a extra parameter with a number so that we can return different irq number for devices with more than one. Signed-off-by: Hauke Mehrtens <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 09626e9d153326ca82568e4e27f2daa53713992e Author: WANG Cong <[email protected]> Date: Tue Nov 11 13:29:42 2014 -0800 net: kill netif_copy_real_num_queues() vlan was the only user of netif_copy_real_num_queues(), but it no longer calls it after commit 4af429d29b341bb1735f04c2fb960178 ("vlan: lockless transmit path"). So we can just remove it. Cc: Eric Dumazet <[email protected]> Cc: David S. Miller <[email protected]> Signed-off-by: Cong Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 67732cd34382066ae5df313b6dad65ab14b9735f Author: Ulf Hansson <[email protected]> Date: Tue Nov 11 11:07:08 2014 +0100 PM / Domains: Fix initial default state of the need_restore flag The initial state of the device's need_restore flag should'nt depend on the current state of the PM domain. For example it should be perfectly valid to attach an inactive device to a powered PM domain. The pm_genpd_dev_need_restore() API allow us to update the need_restore flag to somewhat cope with such scenarios. Typically that should have been done from drivers/buses ->probe() since it's those that put the requirements on the value of the need_restore flag. Until recently, the Exynos SOCs were the only user of the pm_genpd_dev_need_restore() API, though invoking it from a centralized location while adding devices to their PM domains. Due to that Exynos now have swithed to the generic OF-based PM domain look-up, it's no longer possible to invoke the API from a centralized location. The reason is because devices are now added to their PM domains during the probe sequence. Commit "ARM: exynos: Move to generic PM domain DT bindings" did the switch for Exynos to the generic OF-based PM domain look-up, but it also removed the call to pm_genpd_dev_need_restore(). This caused a regression for some of the Exynos drivers. To handle things more properly in the generic PM domain, let's change the default initial value of the need_restore flag to reflect that the state is unknown. As soon as some of the runtime PM callbacks gets invoked, update the initial value accordingly. Moreover, since the generic PM domain is verifying that all devices are both runtime PM enabled and suspended, using pm_runtime_suspended() while pm_genpd_poweroff() is invoked from the scheduled work, we can be sure of that the PM domain won't be powering off while having active devices. Do note that, the generic PM domain can still only know about active devices which has been activated through invoking its runtime PM resume callback. In other words, buses/drivers using pm_runtime_set_active() during ->probe() will still suffer from a race condition, potentially probing a device without having its PM domain being powered. That issue will have to be solved using a different approach. This a log from the boot regression for Exynos5, which is being fixed in this patch. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 308 at ../drivers/clk/clk.c:851 clk_disable+0x24/0x30() Modules linked in: CPU: 0 PID: 308 Comm: kworker/0:1 Not tainted 3.18.0-rc3-00569-gbd9449f-dirty #10 Workqueue: pm pm_runtime_work [<c0013c64>] (unwind_backtrace) from [<c0010dec>] (show_stack+0x10/0x14) [<c0010dec>] (show_stack) from [<c03ee4cc>] (dump_stack+0x70/0xbc) [<c03ee4cc>] (dump_stack) from [<c0020d34>] (warn_slowpath_common+0x64/0x88) [<c0020d34>] (warn_slowpath_common) from [<c0020d74>] (warn_slowpath_null+0x1c/0x24) [<c0020d74>] (warn_slowpath_null) from [<c03107b0>] (clk_disable+0x24/0x30) [<c03107b0>] (clk_disable) from [<c02cc834>] (gsc_runtime_suspend+0x128/0x160) [<c02cc834>] (gsc_runtime_suspend) from [<c0249024>] (pm_generic_runtime_suspend+0x2c/0x38) [<c0249024>] (pm_generic_runtime_suspend) from [<c024f44c>] (pm_genpd_default_save_state+0x2c/0x8c) [<c024f44c>] (pm_genpd_default_save_state) from [<c024ff2c>] (pm_genpd_poweroff+0x224/0x3ec) [<c024ff2c>] (pm_genpd_poweroff) from [<c02501b4>] (pm_genpd_runtime_suspend+0x9c/0xcc) [<c02501b4>] (pm_genpd_runtime_suspend) from [<c024a4f8>] (__rpm_callback+0x2c/0x60) [<c024a4f8>] (__rpm_callback) from [<c024a54c>] (rpm_callback+0x20/0x74) [<c024a54c>] (rpm_callback) from [<c024a930>] (rpm_suspend+0xd4/0x43c) [<c024a930>] (rpm_suspend) from [<c024bbcc>] (pm_runtime_work+0x80/0x90) [<c024bbcc>] (pm_runtime_work) from [<c0032a9c>] (process_one_work+0x12c/0x314) [<c0032a9c>] (process_one_work) from [<c0032cf4>] (worker_thread+0x3c/0x4b0) [<c0032cf4>] (worker_thread) from [<c003747c>] (kthread+0xcc/0xe8) [<c003747c>] (kthread) from [<c000e738>] (ret_from_fork+0x14/0x3c) ---[ end trace 40cd58bcd6988f12 ]--- Fixes: a4a8c2c4962bb655 (ARM: exynos: Move to generic PM domain DT bindings) Reported-and-tested0by: Sylwester Nawrocki <[email protected]> Reviewed-by: Sylwester Nawrocki <[email protected]> Reviewed-by: Kevin Hilman <[email protected]> Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> commit 4e6ce4dc7ce71d0886908d55129d5d6482a27ff9 Author: Miaoqing Pan <[email protected]> Date: Thu Nov 6 10:52:23 2014 +0530 ath9k: Fix RTC_DERIVED_CLK usage Based on the reference clock, which could be 25MHz or 40MHz, AR_RTC_DERIVED_CLK is programmed differently for AR9340 and AR9550. But, when a chip reset is done, processing the initvals sets the register back to the default value. Fix this by moving the code in ath9k_hw_init_pll() to ar9003_hw_override_ini(). Also, do this override for AR9531. Cc: [email protected] Signed-off-by: Miaoqing Pan <[email protected]> Signed-off-by: Sujith Manoharan <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 8bca81d9875c7768c40a19fb439eebaf6cec898d Author: Sudip Mukherjee <[email protected]> Date: Tue Nov 11 14:10:47 2014 +0530 usbnet: smsc95xx: dereferencing NULL pointer we were dereferencing dev to initialize pdata. but just after that we have a BUG_ON(!dev). so we were basically dereferencing the pointer first and then tesing it for NULL. Signed-off-by: Sudip Mukherjee <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit d65c4e4e0aeb699e984bd4b382efffab418aa359 Author: Joe Perches <[email protected]> Date: Tue Nov 11 13:13:41 2014 -0800 irda: Simplify IRDA logging macros These are the same as net_<level>_ratelimited, so use the more common style in the macro definition. Signed-off-by: Joe Perches <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 79ce0477ffe82e7e49e55179cd176a1c33382744 Author: Brian Hill <[email protected]> Date: Tue Nov 11 13:39:39 2014 -0700 net: phy: Correctly handle MII ioctl which changes autonegotiation. When advertised capabilities are changed with mii-tool, such as: mii-tool -A 10baseT the existing handler has two errors. - An actual PHY register value is provided by mii-tool, and this must be mapped to internal state with mii_adv_to_ethtool_adv_t(). - The PHY state machine needs to be told that autonegotiation has again been performed. If not, the MAC will not be notified of the new link speed and duplex, resulting in a possible config mismatch. Signed-off-by: Brian Hill <[email protected]> Acked-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 0cd75b19899fd86b51a6480fb8c00dcd85a54591 Author: Arend van Spriel <[email protected]> Date: Tue Nov 11 13:58:44 2014 +0100 brcmfmac: fix conversion of channel width 20MHZ_NOHT The function chandef_to_chanspec() failed when converting a chandef with bandwidth set to NL80211_CHAN_WIDTH_20_NOHT. This was reported by user running the device in AP mode. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 304 at drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c:381 chandef_to_chanspec.isra.11+0x158/0x184() Modules linked in: CPU: 0 PID: 304 Comm: hostapd Not tainted 3.16.0-rc7-abb+g64aa90f #8 [<c0014bb4>] (unwind_backtrace) from [<c0012314>] (show_stack+0x10/0x14) [<c0012314>] (show_stack) from [<c001d3f8>] (warn_slowpath_common+0x6c/0x8c) [<c001d3f8>] (warn_slowpath_common) from [<c001d4b4>] (warn_slowpath_null+0x1c/0x24) [<c001d4b4>] (warn_slowpath_null) from [<c03449a4>] (chandef_to_chanspec.isra.11+0x158/0x184) [<c03449a4>] (chandef_to_chanspec.isra.11) from [<c0348e00>] (brcmf_cfg80211_start_ap+0x1e4/0x614) [<c0348e00>] (brcmf_cfg80211_start_ap) from [<c04d1468>] (nl80211_start_ap+0x288/0x414) [<c04d1468>] (nl80211_start_ap) from [<c043d144>] (genl_rcv_msg+0x21c/0x38c) [<c043d144>] (genl_rcv_msg) from [<c043c740>] (netlink_rcv_skb+0xac/0xc0) [<c043c740>] (netlink_rcv_skb) from [<c043cf14>] (genl_rcv+0x20/0x34) [<c043cf14>] (genl_rcv) from [<c043c0a0>] (netlink_unicast+0x150/0x20c) [<c043c0a0>] (netlink_unicast) from [<c043c4b8>] (netlink_sendmsg+0x2b8/0x398) [<c043c4b8>] (netlink_sendmsg) from [<c04066a4>] (sock_sendmsg+0x84/0xa8) [<c04066a4>] (sock_sendmsg) from [<c0407c5c>] (___sys_sendmsg.part.29+0x268/0x278) [<c0407c5c>] (___sys_sendmsg.part.29) from [<c0408bdc>] (__sys_sendmsg+0x4c/0x7c) [<c0408bdc>] (__sys_sendmsg) from [<c000ec60>] (ret_fast_syscall+0x0/0x44) ---[ end trace 965ee2158c9905a2 ]--- Cc: [email protected] # v3.17 Reported-by: Pontus Fuchs <[email protected]> Reviewed-by: Hante Meuleman <[email protected]> Reviewed-by: Daniel (Deognyoun) Kim <[email protected]> Reviewed-by: Franky (Zhenhui) Lin <[email protected]> Reviewed-by: Pieter-Paul Giesberts <[email protected]> Signed-off-by: Arend van Spriel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit cfd9167af14eb4ec21517a32911d460083ee3d59 Author: Stanislaw Gruszka <[email protected]> Date: Tue Nov 11 14:28:47 2014 +0100 rt2x00: do not align payload on modern H/W RT2800 and newer hardware require padding between header and payload if header length is not multiple of 4. For historical reasons we also align payload to to 4 bytes boundary, but such alignment is not needed on modern H/W. Patch fixes skb_under_panic problems reported from time to time: https://bugzilla.kernel.org/show_bug.cgi?id=84911 https://bugzilla.kernel.org/show_bug.cgi?id=72471 http://marc.info/?l=linux-wireless&m=139108549530402&w=2 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1087591 Panic happened because we eat 4 bytes of skb headroom on each (re)transmission when sending frame without the payload and the header length not being multiple of 4 (i.e. QoS header has 26 bytes). On such case because paylad_aling=2 is bigger than header_align=0 we increase header_align by 4 bytes. To prevent that we could change the check to: if (payload_length && payload_align > header_align) header_align += 4; but not aligning payload at all is more effective and alignment is not really needed by H/W (that has been tested on OpenWrt project for few years now). Reported-and-tested-by: Antti S. Lankila <[email protected]> Debugged-by: Antti S. Lankila <[email protected]> Reported-by: Henrik Asp <[email protected]> Originally-From: Helmut Schaa <[email protected]> Cc: [email protected] Signed-off-by: Stanislaw Gruszka <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit f47436734dc89ece62654d4db8d08163a89dd7ca Author: Joe Perches <[email protected]> Date: Fri Oct 31 10:50:46 2014 -0700 tile: Use the more common pr_warn instead of pr_warning And other message logging neatening. Other miscellanea: o coalesce formats o realign arguments o standardize a couple of macros o use __func__ instead of embedding the function name Signed-off-by: Joe Perches <[email protected]> Signed-off-by: Chris Metcalf <[email protected]> commit ebd25caf7d511312d1a9724ab5752e9e661dfe60 Author: Chen Gang <[email protected]> Date: Sun Nov 9 18:32:03 2014 +0800 arch: tile: gxio: Export symbols for module using in 'mpipe.c' 'gxio_mpipe_adjust_timestamp', 'gxio_mpipe_link_instance', 'gxio_mpipe_get_timestamp', and 'gxio_mpipe_set_timestamp' may be use by other tile modules, so export them. The related error (with allmodconfig under tile): MODPOST 4002 modules ERROR: "gxio_mpipe_link_instance" [drivers/net/ethernet/tile/tile_net.ko] undefined! ERROR: "gxio_mpipe_get_timestamp" [drivers/net/ethernet/tile/tile_net.ko] undefined! ERROR: "gxio_mpipe_set_timestamp" [drivers/net/ethernet/tile/tile_net.ko] undefined! ERROR: "gxio_mpipe_adjust_timestamp" [drivers/net/ethernet/tile/tile_net.ko] undefined! Signed-off-by: Chen Gang <[email protected]> Signed-off-by: Chris Metcalf <[email protected]> commit 5337b5b75cd9bd3624a6820e3c2a084d2480061c Author: Eric Dumazet <[email protected]> Date: Mon Nov 10 17:54:25 2014 -0800 ipv6: fix IPV6_PKTINFO with v4 mapped Use IS_ENABLED(CONFIG_IPV6), to enable this code if IPv6 is a module. Signed-off-by: Eric Dumazet <[email protected]> Fixes: c8e6ad0829a7 ("ipv6: honor IPV6_PKTINFO with v4 mapped addresses on sendmsg") Acked-by: Hannes Frederic Sowa <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit d7480fd3b1738a8eae6a76098b17af318cf9b9cc Author: WANG Cong <[email protected]> Date: Mon Nov 10 15:59:36 2014 -0800 neigh: remove dynamic neigh table registration support Currently there are only three neigh tables in the whole kernel: arp table, ndisc table and decnet neigh table. What's more, we don't support registering multiple tables per family. Therefore we can just make these tables statically built-in. Cc: David S. Miller <[email protected]> Signed-off-by: Cong Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 4184b2a79a7612a9272ce20d639934584a1f3786 Author: Daniel Borkmann <[email protected]> Date: Mon Nov 10 18:00:09 2014 +0100 net: sctp: fix memory leak in auth key management A very minimal and simple user space application allocating an SCTP socket, setting SCTP_AUTH_KEY setsockopt(2) on it and then closing the socket again will leak the memory containing the authentication key from user space: unreferenced object 0xffff8800837047c0 (size 16): comm "a.out", pid 2789, jiffies 4296954322 (age 192.258s) hex dump (first 16 bytes): 01 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff816d7e8e>] kmemleak_alloc+0x4e/0xb0 [<ffffffff811c88d8>] __kmalloc+0xe8/0x270 [<ffffffffa0870c23>] sctp_auth_create_key+0x23/0x50 [sctp] [<ffffffffa08718b1>] sctp_auth_set_key+0xa1/0x140 [sctp] [<ffffffffa086b383>] sctp_setsockopt+0xd03/0x1180 [sctp] [<ffffffff815bfd94>] sock_common_setsockopt+0x14/0x20 [<ffffffff815beb61>] SyS_setsockopt+0x71/0xd0 [<ffffffff816e58a9>] system_call_fastpath+0x12/0x17 [<ffffffffffffffff>] 0xffffffffffffffff This is bad because of two things, we can bring down a machine from user space when auth_enable=1, but also we would leave security sensitive keying material in memory without clearing it after use. The issue is that sctp_auth_create_key() already sets the refcount to 1, but after allocation sctp_auth_set_key() does an additional refcount on it, and thus leaving it around when we free the socket. Fixes: 65b07e5d0d0 ("[SCTP]: API updates to suport SCTP-AUTH extensions.") Signed-off-by: Daniel Borkmann <[email protected]> Cc: Vlad Yasevich <[email protected]> Acked-by: Neil Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit e40607cbe270a9e8360907cb1e62ddf0736e4864 Author: Daniel Borkmann <[email protected]> Date: Mon Nov 10 17:54:26 2014 +0100 net: sctp: fix NULL pointer dereference in af->from_addr_param on malformed packet An SCTP server doing ASCONF will panic on malformed INIT ping-of-death in the form of: ------------ INIT[PARAM: SET_PRIMARY_IP] ------------> While the INIT chunk parameter verification dissects through many things in order to detect malformed input, it misses to actually check parameters inside of parameters. E.g. RFC5061, section 4.2.4 proposes a 'set primary IP address' parameter in ASCONF, which has as a subparameter an address parameter. So an attacker may send a parameter type other than SCTP_PARAM_IPV4_ADDRESS or SCTP_PARAM_IPV6_ADDRESS, param_type2af() will subsequently return 0 and thus sctp_get_af_specific() returns NULL, too, which we then happily dereference unconditionally through af->from_addr_param(). The trace for the log: BUG: unable to handle kernel NULL pointer dereference at 0000000000000078 IP: [<ffffffffa01e9c62>] sctp_process_init+0x492/0x990 [sctp] PGD 0 Oops: 0000 [#1] SMP [...] Pid: 0, comm: swapper Not tainted 2.6.32-504.el6.x86_64 #1 Bochs Bochs RIP: 0010:[<ffffffffa01e9c62>] [<ffffffffa01e9c62>] sctp_process_init+0x492/0x990 [sctp] [...] Call Trace: <IRQ> [<ffffffffa01f2add>] ? sctp_bind_addr_copy+0x5d/0xe0 [sctp] [<ffffffffa01e1fcb>] sctp_sf_do_5_1B_init+0x21b/0x340 [sctp] [<ffffffffa01e3751>] sctp_do_sm+0x71/0x1210 [sctp] [<ffffffffa01e5c09>] ? sctp_endpoint_lookup_assoc+0xc9/0xf0 [sctp] [<ffffffffa01e61f6>] sctp_endpoint_bh_rcv+0x116/0x230 [sctp] [<ffffffffa01ee986>] sctp_inq_push+0x56/0x80 [sctp] [<ffffffffa01fcc42>] sctp_rcv+0x982/0xa10 [sctp] [<ffffffffa01d5123>] ? ipt_local_in_hook+0x23/0x28 [iptable_filter] [<ffffffff8148bdc9>] ? nf_iterate+0x69/0xb0 [<ffffffff81496d10>] ? ip_local_deliver_finish+0x0/0x2d0 [<ffffffff8148bf86>] ? nf_hook_slow+0x76/0x120 [<ffffffff81496d10>] ? ip_local_deliver_finish+0x0/0x2d0 [...] A minimal way to address this is to check for NULL as we do on all other such occasions where we know sctp_get_af_specific() could possibly return with NULL. Fixes: d6de3097592b ("[SCTP]: Add the handling of "Set Primary IP Address" parameter to INIT") Signed-off-by: Daniel Borkmann <[email protected]> Cc: Vlad Yasevich <[email protected]> Acked-by: Neil Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 5748eb8f8e989a9da1ac7c96dc73d68cbdedf7df Author: Takashi Iwai <[email protected]> Date: Mon Nov 10 11:50:21 2014 +0100 net: ppp: Don't call bpf_prog_create() in ppp_lock In ppp_ioctl(), bpf_prog_create() is called inside ppp_lock, which eventually calls vmalloc() and hits BUG_ON() in vmalloc.c. This patch works around the problem by moving the allocation outside the lock. The bug was revealed by the recent change in net/core/filter.c, as it allocates via vmalloc() instead of kmalloc() now. Reported-and-tested-by: Stefan Seyfried <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit b2e2f0c779fefede3a871781c8827bd8e76c7c0f Author: Andy Shevchenko <[email protected]> Date: Mon Nov 10 12:38:59 2014 +0200 stmmac: split to core library and probe drivers Instead of registering the platform and PCI drivers in one module let's move necessary bits to where it belongs. During this procedure we convert the module registration part to use module_*_driver() macros which makes code simplier. >From now on the driver consists three parts: core library, PCI, and platform drivers. Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Giuseppe Cavallaro <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit dc680b989d519952e0e0d37204fec850925a0225 Author: Linus Walleij <[email protected]> Date: Mon Nov 10 18:52:31 2014 +0100 ARM: fix multiplatform allmodcompile Commit 68f3b875f7848f5304472184a4634148c5330cbd "ARM: integrator: make the Integrator multiplatform" broke allmodconfig like this: >> arch/arm/include/asm/cmpxchg.h:114:2: error: #error "SMP is not supported on this platform" (etc) This is due to the fact that as we turned on multiplatform for the Integrator, this enabled a lot of non-applicable CPU's to be selected for its multiplatform images, due to a lot of "depends on ARCH_INTEGRATOR" restrictions in arch/arm/mm/Kconfig for the different ARM CPU types. Fix this by restricting the CPU selections to respective multiplatform config, which now becomes a subset of the possible Integrator configurations, or alternatively the non-multiplatform config plus ARCH_INTEGRATOR, i.e.: if (!ARCH_MULTIPLATFORM || ARCH_MULTI_Vx) && (ARCH_INTEGRATOR || ARCH_FOO ...) Since the Integrator has been converted to multiplatform, this will often take the short form: if (ARCH_MULTI_Vx && ARCH_INTEGRATOR) If no other non-multiplatform platforms are elegible. Reported-by: Build bot for Mark Brown <[email protected]> Reported-by: Kbuild test robot <[email protected]> Suggested-by: Russell King <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> commit ba7a46f16dd29f93303daeb1fee8af316c5a07f4 Author: Joe Perches <[email protected]> Date: Tue Nov 11 10:59:17 2014 -0800 net: Convert LIMIT_NETDEBUG to net_dbg_ratelimited Use the more common dynamic_debug capable net_dbg_ratelimited and remove the LIMIT_NETDEBUG macro. All messages are still ratelimited. Some KERN_<LEVEL> uses are changed to KERN_DEBUG. This may have some negative impact on messages that were emitted at KERN_INFO that are not not enabled at all unless DEBUG is defined or dynamic_debug is enabled. Even so, these messages are now _not_ emitted by default. This also eliminates the use of the net_msg_warn sysctl "/proc/sys/net/core/warnings". For backward compatibility, the sysctl is not removed, but it has no function. The extern declaration of net_msg_warn is removed from sock.h and made static in net/core/sysctl_net_core.c Miscellanea: o Update the sysctl documentation o Remove the embedded uses of pr_fmt o Coalesce format fragments o Realign arguments Signed-off-by: Joe Perches <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit e349d9d5b3f9509e6a053d9d1d9f4c7d9471c8f0 Author: Neelesh Gupta <[email protected]> Date: Wed Nov 5 16:45:14 2014 +0530 hwmon: (ibmpowernv) Use platform 'id_table' to probe the device The current driver probe() function assumes the sensor device to be always present and gets executed every time if the driver is loaded, but the appropriate hardware could not be present. So, move the platform device creation as part of platform init code and use the 'id_table' to check if the device is present or not. Signed-off-by: Neelesh Gupta <[email protected]> Acked-by: Michael Ellerman <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> commit eebb2554a0a4ce8f637c72febc883997a58093ca Author: Guenter Roeck <[email protected]> Date: Sat Sep 27 08:31:12 2014 -0700 hwmon: (iio_hwmon) Add support for humidity sensors The iio subsystem supports humidity sensors, so it makes sense to support it in the iio-hwmon bridge as well. Cc: Jonathan Cameron <[email protected]> Acked-by: Jonathan Cameron <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> commit c2827f34af5ced95daddefd7de6105d7fcf0d4d5 Author: Alan Tull <[email protected]> Date: Wed Oct 15 13:55:10 2014 -0500 hwmon: (ltc2978) Add regulator support Add simple on/off regulator support for ltc2978 and other pmbus parts supported by the ltc2978 driver. Signed-off-by: Alan Tull <[email protected]> Cc: Guenter Roeck <[email protected]> Cc: Mark Brown <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> commit 3ca7aa3feedc0cc838b242e09ff6b306501029d0 Author: Alan Tull <[email protected]> Date: Wed Oct 15 13:55:09 2014 -0500 hwmon: (pmbus) Add regulator support Add support for simple on/off control of each channel. To add regulator support, the pmbus part driver needs to add regulator_desc information and number of regulators to its pmbus_driver_info struct. regulator_desc can be declared using default macro for a regulator (PMBUS_REGULATOR) that is in pmbus.h The regulator_init_data can be initialized from either platform data or the device tree. Signed-off-by: Alan Tull <[email protected]> Reviewed-by: Mark Brown <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> commit e94c450610a10a9b798b39754a6099fea5d5279e Author: Alan Tull <[email protected]> Date: Wed Oct 15 13:55:08 2014 -0500 hwmon: (pmbus) add helpers for byte write and read modify write Add two helper functions: * pmbus_write_byte_data = paged byte write * pmbus_update_byte_data = paged byte read/modify/write Signed-off-by: Alan Tull <[email protected]> Cc: Mark Brown <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> commit 7c6d297620427048742977c2258669f3cc926f1f Author: Alan Tull <[email protected]> Date: Wed Oct 15 13:55:07 2014 -0500 hwmon: (ltc2978) device tree bindings documentation Add device tree bindings documentation for ltc2978. Signed-off-by: Alan Tull <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Mark Brown <[email protected]> [Guenter Roeck: Minor correction of 'compatible' example] Signed-off-by: Guenter Roeck <[email protected]> commit 5b61c4db49e2530ed10631321d4c73f49d560a93 Author: Denis Kirjanov <[email protected]> Date: Mon Nov 10 08:59:43 2014 +0300 PPC: bpf_jit_comp: add SKF_AD_HATYPE instruction Add BPF extension SKF_AD_HATYPE to ppc JIT to check the hw type of the interface Before: [ 57.723666] test_bpf: #20 LD_HATYPE [ 57.723675] BPF filter opcode 0020 (@0) unsupported [ 57.724168] 48 48 PASS After: [ 103.053184] test_bpf: #20 LD_HATYPE 7 6 PASS CC: Alexei Starovoitov<[email protected]> CC: Daniel Borkmann<[email protected]> CC: Philippe Bergheaud<[email protected]> Signed-off-by: Denis Kirjanov <[email protected]> v2: address Alexei's comments Acked-by: Alexei Starovoitov <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 0bd52941586b3b59ab9b6e89e55b2dc9e2680de9 Author: Aravind Gopalakrishnan <[email protected]> Date: Tue Nov 4 11:49:02 2014 -0600 hwmon: (fam15h_power) Fix NB device ID for F16h M30h F3 device ID is wrongly included in fam15h_power_id_table for F16h M30h. It should be F4 device ID. Fix this. Signed-off-by: Aravind Gopalakrishnan <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> commit 48b9d5b4f408259cd6800c4b17d4fe5025435da2 Author: Kamil Debski <[email protected]> Date: Mon Nov 3 15:42:55 2014 +0100 hwmon: (pwm-fan) Fix suspend/resume behavior The state of a PWM output is not clearly defined after resume. Some PWM drivers do not restore the duty cycle upon resume, thus it is necessary to manually restore the correct value. Signed-off-by: Kamil Debski <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> commit aab18da44f243cf59b4dee335ea50b32f529b5b0 Author: Michael Ellerman <[email protected]> Date: Fri Oct 31 17:45:22 2014 +1100 hwmon: (ibmpowernv) Quieten when probing finds no device Because we build kernels with drivers built in for many platforms, it's normal for the ibmpowernv driver to be loaded on systems that don't have the appropriate hardware. Currently the driver spams the log with: ibmpowernv ibmpowernv.0: Opal node 'sensors' not found ibmpowernv: Platfrom driver probe failed But there is no error, this machine is not a powernv and doesn't have the hardware. So change the sensors message to dev_dbg(), and only print an error about the probe failing if it's not ENODEV. Also fix the spelling of "Platfrom" and print the actual error value. Signed-off-by: Michael Ellerman <[email protected]> Reviewed-by: Jean Delvare <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> commit a2ae6007a442d6bb27d77bf20ec1b06cda9e306e Author: Joe Perches <[email protected]> Date: Sun Nov 9 16:32:46 2014 -0800 dsa: Use netdev_<level> instead of printk Neaten and standardize the logging output. Other miscellanea: o Use pr_notice_once instead of a guard flag. o Convert existing pr_<level> uses too. Signed-off-by: Joe Perches <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit f4a1edd56120249198073aa4a373b77e3700ac8f Author: Or Gerlitz <[email protected]> Date: Sun Nov 9 14:25:39 2014 +0200 net/mlx4_en: Advertize encapsulation offloads features only when VXLAN tunnel is set Currenly we only support Large-Send and TX checksum offloads for encapsulated traffic of type VXLAN. We must make sure to advertize these offloads up to the stack only when VXLAN tunnel is set. Failing to do so, would mislead the the networking stack to assume that the driver can offload the internal TX checksum for GRE packets and other buggy schemes. Reported-by: Florian Westphal <[email protected]> Signed-off-by: Or Gerlitz <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit f8c6455bb04b944edb69e9b074e28efee2c56bdd Author: Shani Michaeli <[email protected]> Date: Sun Nov 9 13:51:53 2014 +0200 net/mlx4_en: Extend checksum offloading by CHECKSUM COMPLETE When processing received traffic, pass CHECKSUM_COMPLETE status to the stack, with calculated checksum for non TCP/UDP packets (such as GRE or ICMP). Although the stack expects checksum which doesn't include the pseudo header, the HW adds it. To address that, we are subtracting the pseudo header checksum from the checksum value provided by the HW. In the IPv6 case, we also compute/add the IP header checksum which is not added by the HW for such packets. Cc: Jerry Chu <[email protected]> Signed-off-by: Shani Michaeli <[email protected]> Signed-off-by: Matan Barak <[email protected]> Signed-off-by: Or Gerlitz <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit dd65beac48a5259945846956d4b27344dfb73bd9 Author: Shani Michaeli <[email protected]> Date: Sun Nov 9 13:51:52 2014 +0200 net/mlx4_en: Extend usage of napi_gro_frags We can call napi_gro_frags for all the received traffic regardless of the checksum status. Specifically, received packets whose status is CHECKSUM_NONE (and soon to be added CHECKSUM_COMPLETE) are eligible for napi_gro_frags as well. Signed-off-by: Or Gerlitz <[email protected]> Signed-off-by: Shani Michaeli <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 242fe7a1fd7af133d4c0ae2aae1de4e33b1b39af Author: Rafał Miłecki <[email protected]> Date: Wed Sep 3 07:36:51 2014 +0200 MIPS: Fix info about plat_setup in arch_mem_init comment Signed-off-by: Rafał Miłecki <[email protected]> Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/7607/ Signed-off-by: Ralf Baechle <[email protected]> commit 5996d33df117bc3c56c28d6a930679ddcb693626 Author: Rafał Miłecki <[email protected]> Date: Thu Oct 30 12:50:03 2014 +0100 MIPS: BCM47XX: Clean up nvram header 1) Move private defines to the .c file 2) Move SPROM helper to the sprom.c 3) Drop unused code 4) Rename magic to the NVRAM_MAGIC 5) Add const to the char pointer we never modify Signed-off-by: Rafał Miłecki <[email protected]> Acked-by: Hauke Mehrtens <[email protected]> Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/8289/ Signed-off-by: Ralf Baechle <[email protected]> commit 1bb002b25f08e7e295b2c16dfc09a4cefc3cc5db Author: Rafał Miłecki <[email protected]> Date: Wed Oct 29 10:05:06 2014 +0100 MIPS: BCM47XX: Use mtd as an alternative way/API to get NVRAM content NVRAM can be read using magic memory offset, but after all it's just a flash partition. On platforms where NVRAM isn't needed early we can get it using mtd subsystem. Signed-off-by: Rafał Miłecki <[email protected]> Acked-by: Hauke Mehrtens <[email protected]> Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/8266/ Signed-off-by: Ralf Baechle <[email protected]> commit 2a90d4aae5509e9cf1ba848c5d0b3458201160a0 Author: Paolo Bonzini <[email protected]> Date: Fri Nov 7 23:04:00 2014 +0100 blk-mq: use get_cpu/put_cpu instead of preempt_disable/preempt_enable blk-mq is using preempt_disable/enable in order to ensure that the queue runners are placed on the right CPU. This does not work with the RT patches, because __blk_mq_run_hw_queue takes a non-raw spinlock with the preemption-disabled region. If there is contention on the lock, this violates the rules for preemption-disabled regions. While this should be easily fixable within the RT patches just by doing migrate_disable/enable, we can do better and document _why_ this particular region runs with disabled preemption. After the previous patch, it is trivial to switch it to get/put_cpu; the RT patches then can change it to get_cpu_light, which lets virtio-blk run under RT kernels. Cc: Jens Axboe <[email protected]> Cc: Thomas Gleixner <[email protected]> Reported-by: Clark Williams <[email protected]> Tested-by: Clark Williams <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Jens Axboe <[email protected]> commit 398205b8391b208f0034a392242867b28ad8af3d Author: Paolo Bonzini <[email protected]> Date: Fri Nov 7 23:03:59 2014 +0100 blk_mq: call preempt_disable/enable in blk_mq_run_hw_queue, and only if needed preempt_disable/enable surrounds every call to blk_mq_run_hw_queue, except the one in blk-flush.c. In fact that one is always asynchronous, and it does not need smp_processor_id(). We can do the same for all other calls, avoiding preempt_disable when async is true. This avoids peppering blk-mq.c with preemption-disabled regions. Cc: Jens Axboe <[email protected]> Cc: Thomas Gleixner <[email protected]> Reported-by: Clark Williams <[email protected]> Tested-by: Clark Williams <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Jens Axboe <[email protected]> commit 9169051617df7fca597274e9e43324332cb8f0ee Author: Mark Brown <[email protected]> Date: Sat Nov 8 10:28:10 2014 +0000 spi: spidev: Don't mangle max_speed_hz in underlying spi device Currently spidev allows callers to set the default speed by overriding the max_speed_hz in the underlying device. This achieves the immediate goal but is not what devices expect and can easily lead to userspace trying to set unsupported speeds and succeeding, apart from anything else drivers can't set a limit on the speed using max_speed_hz as they'd expect and any other devices on the bus will be affected. Instead store the default speed in the spidev struct and fill this in on each transfer. Signed-off-by: Mark Brown <[email protected]> commit 2c8c56e15df3d4c2af3d656e44feb18789f75837 Author: Eric Dumazet <[email protected]> Date: Tue Nov 11 05:54:28 2014 -0800 net: introduce SO_INCOMING_CPU Alternative to RPS/RFS is to use hardware support for multiple queues. Then split a set of million of sockets into worker threads, each one using epoll() to manage events on its own socket pool. Ideally, we want one thread per RX/TX queue/cpu, but we have no way to know after accept() or connect() on which queue/cpu a socket is managed. We normally use one cpu per RX queue (IRQ smp_affinity being properly set), so remembering on socket structure which cpu delivered last packet is enough to solve the problem. After accept(), connect(), or even file descriptor passing around processes, applications can use : int cpu; socklen_t len = sizeof(cpu); getsockopt(fd, SOL_SOCKET, SO_INCOMING_CPU, &cpu, &len); And use this information to put the socket into the right silo for optimal performance, as all networking stack should run on the appropriate cpu, without need to send IPI (RPS/RFS). Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 3d97379a67486bc481ab5b8f7aa5b7ceb6154a95 Author: Eric Dumazet <[email protected]> Date: Tue Nov 11 05:54:27 2014 -0800 tcp: move sk_mark_napi_id() at the right place sk_mark_napi_id() is used to record for a flow napi id of incoming packets for busypoll sake. We should do this only on established flows, not on listeners. This was 'working' by virtue of the socket cloning, but doing this on SYN packets in unecessary cache line dirtying. Even if we move sk_napi_id in the same cache line than sk_lock, we are working to make SYN processing lockless, so it is desirable to set sk_napi_id only for established flows. Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 26488b3723270880a28b542ff2276689506d6a9f Author: Jiang Liu <[email protected]> Date: Thu Aug 22 20:59:39 2013 +0800 tracing: Add entry->next_cpu to trace_ctxwake_bin() Function trace_ctxwake_bin() misses ctx_switch_entry->next_cpu field, so user will get stale value for "next_cpu". Link: http://lkml.kernel.org/p/[email protected] Signed-off-by: Jiang Liu <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> commit 243f7610a68a606eb1787c09450a440bf30bebe0 Author: Steven Rostedt (Red Hat) <[email protected]> Date: Thu Oct 30 20:44:53 2014 -0400 tracing: Move tracing_sched_{switch,wakeup}() into wakeup tracer The only code that references tracing_sched_switch_trace() and tracing_sched_wakeup_trace() is the wakeup latency tracer. Those two functions use to belong to the sched_switch tracer which has long been removed. These functions were left behind because the wakeup latency tracer used them. But since the wakeup latency tracer is the only one to use them, they should be static functions inside that code. Signed-off-by: Steven Rostedt <[email protected]> commit 458faf0b88b19a46d51bb9760fa6e03a1bc6d97b Author: Oleg Nesterov <[email protected]> Date: Wed Jul 23 21:35:03 2014 +0200 tracing: Kill the dead code in probe_sched_switch() and probe_sched_wakeup() After the previous patch it is clear that "tracer_enabled" can never be true, we can remove the "if (tracer_enabled)" code in probe_sched_switch() and probe_sched_wakeup(). Plus we can obviously remove tracer_enabled, ctx_trace, and sched_stopped as well. Link: http://lkml.kernel.org/p/[email protected] Signed-off-by: Oleg Nesterov <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> commit 632537256e9f969a188cc4d0159e0027a459d3e7 Author: Oleg Nesterov <[email protected]> Date: Wed Jul 23 21:35:01 2014 +0200 tracing: Kill tracing_{start,stop}_sched_switch_record() and tracing_sched_switch_assign_trace() tracing_{start,stop}_sched_switch_record() have no callers since 87d80de2800d "tracing: Remove obsolete sched_switch tracer". The last caller of tracing_sched_switch_assign_trace() was removed by 30dbb20e68e6 "tracing: Remove boot tracer". Link: http://lkml.kernel.org/p/[email protected] Signed-off-by: Oleg Nesterov <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> commit 4fd3279b48605ae3ea509b9b2c02e46aa0975930 Author: Steven Rostedt (Red Hat) <[email protected]> Date: Fri Oct 24 17:56:04 2014 -0400 ftrace: Add more information to ftrace_bug() output With the introduction of the dynamic trampolines, it is useful that if things go wrong that ftrace_bug() produces more information about what the current state is. This can help debug issues that may arise. Ftrace has lots of checks to make sure that the state of the system it touchs is exactly what it expects it to be. When it detects an abnormality it calls ftrace_bug() and disables itself to prevent any further damage. It is crucial that ftrace_bug() produces sufficient information that can be used to debug the situation. Cc: Benjamin Herrenschmidt <[email protected]> Acked-by: Borislav Petkov <[email protected]> Tested-by: Masami Hiramatsu <[email protected]> Tested-by: Jiri Kosina <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> commit 12cce594fa8f12e002e7eb5d10141853c1e6a112 Author: Steven Rostedt (Red Hat) <[email protected]> Date: Thu Jul 3 15:48:16 2014 -0400 ftrace/x86: Allow !CONFIG_PREEMPT dynamic ops to use allocated trampolines When the static ftrace_ops (like function tracer) enables tracing, and it is the only callback that is referencing a function, a trampoline is dynamically allocated to the function that calls the callback directly instead of calling a loop function that iterates over all the registered ftrace ops (if more than one ops is registered). But when it comes to dynamically allocated ftrace_ops, where they may be freed, on a CONFIG_PREEMPT kernel there's no way to know when it is safe to free the trampoline. If a task was preempted while executing on the trampoline, there's currently no way to know when it will be off that trampoline. But this is not true when it comes to !CONFIG_PREEMPT. The current method of calling schedule_on_each_cpu() will force tasks off the trampoline, becaues they can not schedule while on it (kernel preemption is not configured). That means it is safe to free a dynamically allocated ftrace ops trampoline when CONFIG_PREEMPT is not configured. Cc: H. Peter Anvin <[email protected]> Cc: Paul E. McKenney <[email protected]> Acked-by: Borislav Petkov <[email protected]> Tested-by: Masami Hiramatsu <[email protected]> Tested-by: Jiri Kosina <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> commit 19ca5a3cc425cc9a8abedb0f4fb7b4e7ceee2255 Author: Andreas Ruprecht <[email protected]> Date: Sun Aug 10 21:10:03 2014 +0200 EDAC, pci_sysfs: remove unneccessary ifdef around entire file The file edac_pci_sysfs.c is dependent on CONFIG_PCI. This is already modelled in the Makefile, but edac_pci_sysfs.o is still contained in the list of files compiled even without CONFIG_PCI. This change removes edac_pci_sysfs.o from the list of built objects when not having CONFIG_PCI enabled and removes the then-unnecessary ifdef from the source file. Signed-off-by: Andreas Ruprecht <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Borislav Petkov <[email protected]> commit 419a2ea074189be8de0b0ab052dd98061fed1c16 Author: Mike Snitzer <[email protected]> Date: Tue Oct 28 20:58:45 2014 -0400 dm thin: suspend/resume active thin devices when reloading thin-pool Before this change it was expected that userspace would first suspend all active thin devices, reload/resize the thin-pool target, then resume all active thin devices. Now the thin-pool suspend/resume will trigger the suspend/resume of all active thins via appropriate calls to dm_internal_suspend and dm_internal_resume. Store the mapped_device for each thin device in struct thin_c to make these calls possible. Signed-off-by: Mike Snitzer <[email protected]> commit 665aa8cdc499b9aeea6532e682a58ca34b7f94e6 Author: Dan Carpenter <[email protected]> Date: Fri Aug 1 11:25:14 2014 +0300 ghes_edac: Use snprintf() to silence a static checker warning My static checker complains because the "e->location" has up to 256 characters but we are copying it into the "pvt->detail_location" which only has space for 240 characters. That's not counting the surrounding text and the "e->other_detail" string which can be over 80 characters long. I am not familiar with this code but presumably it normally works. Let's add a limit though for safety. Signed-off-by: Dan Carpenter <[email protected]> Acked-by: Mauro Carvalho Chehab <[email protected]> Link: http://lkml.kernel.org/r/20140801082514.GD28869@mwanda Signed-off-by: Borislav Petkov <[email protected]> commit 8860704ea9afa699484c9fe7822da1cd37e40690 Author: Mike Snitzer <[email protected]> Date: Tue Oct 28 18:34:52 2014 -0400 dm: enhance internal suspend and resume interface Rename dm_internal_{suspend,resume} to dm_internal_{suspend,resume}_fast -- dm-stats will continue using these methods to avoid all the extra suspend/resume logic that is not needed in order to quickly flush IO. Introduce dm_internal_suspend_noflush() variant that actually calls the mapped_device's target callbacks -- otherwise target-specific hooks are avoided (e.g. dm-thin's thin_presuspend and thin_postsuspend). Common code between dm_internal_{suspend_noflush,resume} and dm_{suspend,resume} was factored out as __dm_{suspend,resume}. Update dm_internal_{suspend_noflush,resume} to always take and release the mapped_device's suspend_lock. Also update dm_{suspend,resume} to be aware of potential for DM_INTERNAL_SUSPEND_FLAG to be set and respond accordingly by interruptibly waiting for the DM_INTERNAL_SUSPEND_FLAG to be cleared. Add lockdep annotation to dm_suspend() and dm_resume(). Also add DM_INTERNAL_SUSPEND_FLAG to status report. This new DM_INTERNAL_SUSPEND_FLAG state is being tracked/reported to assist with debugging (e.g. 'dmsetup info' will report an internally suspended device accordingly). The existing DM_SUSPEND_FLAG remains unchanged. DM_INTERNAL_SUSPEND_FLAG is set by dm_internal_suspend_noflush() and cleared by dm_internal_resume(). Both DM_SUSPEND_FLAG and DM_INTERNAL_SUSPEND_FLAG may be set if a device was already suspended when dm_internal_suspend_noflush() was called -- this can be thought of as a "nested suspend". A "nested suspend" can with legacy userspace dm-thin code that might suspend all active thin volumes before suspending the pool for resize. But otherwise, in the normal dm-thin-pool suspend case moving forward: the thin-pool will have DM_SUSPEND_FLAG set and all active thins from that thin-pool will have DM_INTERNAL_SUSPEND_FLAG set. Signed-off-by: Mike Snitzer <[email protected]> commit bf735ebb898c1348f635488bee737b95886aa20e Author: Mike Snitzer <[email protected]> Date: Fri Nov 7 15:09:46 2014 -0500 dm thin: do not allow thin device activation while pool is suspended Otherwise IO could be issued to the pool while it is suspended. Care was taken to properly interlock between the thin and thin-pool targets when accessing the pool's 'suspended' flag. Signed-off-by: Mike Snitzer <[email protected]> commit 3ca4517dc53569ad82152ff035be0e909c06c722 Author: Mike Snitzer <[email protected]> Date: Tue Oct 28 20:13:31 2014 -0400 dm: add presuspend_undo hook to target_type The DM thin-pool target now must undo the changes performed during pool_presuspend() so introduce presuspend_undo hook in target_type. Signed-off-by: Mike Snitzer <[email protected]> commit f35d0679e47ef97c6037f7aefba41f18a7865421 Author: Mike Snitzer <[email protected]> Date: Fri Nov 7 15:27:56 2014 -0500 dm thin: remove stale 'trim' message in block comment above pool_message Signed-off-by: M…
aryabinin
referenced
this pull request
in aryabinin/linux
Nov 24, 2014
GIT c04878ff13662bf8e5361d3f96ce3e38bf3bf1f2 commit c04878ff13662bf8e5361d3f96ce3e38bf3bf1f2 Author: Stephen Rothwell <[email protected]> Date: Wed Nov 19 18:49:07 2014 +1100 sparc: io: fix for implement dummy relaxed accessor macros for writes Signed-off-by: Stephen Rothwell <[email protected]> commit 882407763830dd34fc527dc96998bd4d124ed799 Author: Matthew Garrett <[email protected]> Date: Tue Feb 18 11:28:29 2014 -0500 Change ACPI IPMI support to "default y" The ACPI IPMI driver implements IPMI operation region support for the ACPI core. Systems that declare ACPI operation regions may reference them at any time, including during kernel initialisation. These accesses will fail unless the ACPI IPMI driver is present, and undesirable system behaviour may result. Set the default to Y in order to encourage distributions and users to configure kernels to avoid awkward surprises. Signed-off-by: Matthew Garrett <[email protected]> Signed-off-by: Corey Minyard <[email protected]> commit 0d7c4ceb16d175f719fbe728799f9a7d4fd69297 Author: Corey Minyard <[email protected]> Date: Mon Nov 10 21:24:45 2014 -0600 ipmi: Handle I2C parms in the SSIF driver. Signed-off-by: Corey Minyard <[email protected]> commit 99a7a9582a0206ca2fded95d85fddfd399cfcbe4 Author: Corey Minyard <[email protected]> Date: Mon Nov 10 21:10:49 2014 -0600 i2c: Add parameters to sysfs-added i2c devices Some devices might need parameters to control their operation, add the ability to pass these parameters to the client. This also makes the parsing of sysfs-added I2C devices a little more flexible, allowing tabs and arbitrary numbers of spaces. Signed-off-by: Corey Minyard <[email protected]> commit 451b7a67f772a923135e57e0e710f7aeed62b5bf Author: Jeremy Kerr <[email protected]> Date: Wed Nov 12 15:41:05 2014 +0800 drivers/char/ipmi: Add powernv IPMI driver This change adds an initial IPMI driver for powerpc OPAL firmware. The interface is exposed entirely through firmware: we have two functions to send and receive IPMI messages, and an interrupt notification from the firmware to signify that a message is available. Signed-off-by: Jeremy Kerr <[email protected]> Signed-off-by: Corey Minyard <[email protected]> commit 5ad7fb122df9e16d0f3bdb3723995b70e978e035 Author: Jeremy Kerr <[email protected]> Date: Thu Nov 6 11:38:27 2014 +0800 powerpc/powernv: Add OPAL IPMI interface Recent OPAL firmare adds a couple of functions to send and receive IPMI messages: https://github.com/open-power/skiboot/commit/b2a374da This change updates the token list and wrappers to suit, and adds the platform devices for any IPMI interfaces. Signed-off-by: Jeremy Kerr <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> commit 02b8f3c67cf074350611983f8b963d9f00b02d64 Author: Corey Minyard <[email protected]> Date: Mon Mar 19 16:00:55 2012 -0500 ipmi: Add SMBus interface driver (SSIF) This patch adds the SMBus interface to the IPMI driver. Signed-off-by: Corey Minyard <[email protected]> Documentation/IPMI.txt | 32 drivers/char/ipmi/Kconfig | 11 drivers/char/ipmi/Makefile | 1 drivers/char/ipmi/ipmi_smb.c | 1737 +++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 1769 insertions(+), 12 deletions(-) commit 08bb7beae7fe102939fe5931222fc09e10d27cda Author: Jean-Baptiste Maneyrol <[email protected]> Date: Sun Nov 16 22:45:43 2014 +0800 HID: i2c-hid: print the correct data in dbg msg Report is received in "buffer"; fix the following i2c_hid_dbg() to dump data from the correct pointer. Signed-off-by: Jean-Baptiste Maneyrol <[email protected]> [Antonio Borneo: cleanup and rebase to v3.17] Signed-off-by: Antonio Borneo <[email protected]> Reviewed-by: Benjamin Tissoires <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> commit 11bf7828a59880427403e13dcff8228d67e9e0f7 Author: Joe Stringer <[email protected]> Date: Mon Nov 17 16:24:54 2014 -0800 vxlan: Inline vxlan_gso_check(). Suggested-by: Or Gerlitz <[email protected]> Signed-off-by: Joe Stringer <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit e3e3217029a35c579bf100998b43976d0b1cb8d7 Author: Rick Jones <[email protected]> Date: Mon Nov 17 14:04:29 2014 -0800 icmp: Remove some spurious dropped packet profile hits from the ICMP path If icmp_rcv() has successfully processed the incoming ICMP datagram, we should use consume_skb() rather than kfree_skb() because a hit on the likes of perf -e skb:kfree_skb is not called-for. Signed-off-by: Rick Jones <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 54aeba7f06323e04d59a6053ee3c6023079667b2 Author: Fabian Frederick <[email protected]> Date: Mon Nov 17 22:23:17 2014 +0100 dev_ioctl: use sizeof(x) instead of sizeof x Also remove spaces after cast. Signed-off-by: Fabian Frederick <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit e56f735913c8d3c417c65c7e7fcdd65011f8d96f Author: Fabian Frederick <[email protected]> Date: Mon Nov 17 22:08:22 2014 +0100 net/core: include linux/types.h instead of asm/types.h Signed-off-by: Fabian Frederick <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 1d2398dc7c78f32c50ee23a21ad9141e5e08a2ed Author: Fabian Frederick <[email protected]> Date: Mon Nov 17 22:04:03 2014 +0100 net: fix spelling for synchronized Signed-off-by: Fabian Frederick <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit a77b634367d4987718012b896c3d19c4cd7e8b4c Author: Fabian Frederick <[email protected]> Date: Mon Nov 17 22:00:22 2014 +0100 dccp: spelling s/reseting/resetting Signed-off-by: Fabian Frederick <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 02c31d2e56dfc6e65ebf5891cf6953e3391ce590 Author: Fabian Frederick <[email protected]> Date: Mon Nov 17 21:58:37 2014 +0100 dccp: replace min/casting by min_t Signed-off-by: Fabian Frederick <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 54da7996b85b3a3e7388c5010ec0f1d866fc4830 Author: Fabian Frederick <[email protected]> Date: Mon Nov 17 21:54:58 2014 +0100 dccp: remove blank lines between function/EXPORT_SYMBOL See Documentation/CodingStyle chapter 6. Signed-off-by: Fabian Frederick <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 6d80c4732bbbd8a76057337cb758ed64cf34f804 Author: Fabian Frederick <[email protected]> Date: Mon Nov 17 21:51:21 2014 +0100 dccp: kerneldoc warning fixes Signed-off-by: Fabian Frederick <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit c20e599bb57bf12177cd5404d124cae0b6fc7970 Author: Lothar Waßmann <[email protected]> Date: Mon Nov 17 10:51:24 2014 +0100 net: fec: remove unused return value from swap_buffer() The return value of swap_buffer() is not used by any caller, thus remove it. Signed-off-by: Lothar Waßmann <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 7b487d070a0edea01816135d3b1a9c8f2c069657 Author: Lothar Waßmann <[email protected]> Date: Mon Nov 17 10:51:23 2014 +0100 net: fec: simplify loop counter handling in swap_buffer() Eliminate the DIV_ROUND_UP() and change the loop counter increment to 4 instead. This results in saving 6 instructions in the functions assembly code. Signed-off-by: Lothar Waßmann <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit e453789a66ab152ecee80ded3279539d826c48ed Author: Lothar Waßmann <[email protected]> Date: Mon Nov 17 10:51:22 2014 +0100 net: fec: use swab32s() instead of cpu_to_be32() when swap_buffer() is being called, we know for sure, that we need to byte swap the data. Furthermore, this function is called for swapping data in both directions. Thus cpu_to_be32() is semantically not correct for all use cases. Use swab32s() to reflect this. Signed-off-by: Lothar Waßmann <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 6b7e4008389c8cb8140a9aef424b10048c44da39 Author: Lothar Waßmann <[email protected]> Date: Mon Nov 17 10:51:21 2014 +0100 net: fec: improve access to quirk flags by copying them into fec_enet_private struct Signed-off-by: Lothar Waßmann <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 217b5844e279c279414fdeb47a89959fad1fbc8f Author: Lothar Waßmann <[email protected]> Date: Mon Nov 17 10:51:20 2014 +0100 net: fec: change type of 'bufdesc_ex' to bool fep->bufdesc_ex is treated as a boolean value, thus declare it as such. Signed-off-by: Lothar Waßmann <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit df406bc9c0d002ef52671dc7b6887ff1bb9142e9 Author: Lothar Waßmann <[email protected]> Date: Mon Nov 17 10:51:19 2014 +0100 net: fec: properly parenthesize macro args Signed-off-by: Lothar Waßmann <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 745f42ba2a52d5b95594c24fb3755ff678f669f9 Author: Lothar Waßmann <[email protected]> Date: Mon Nov 17 10:51:18 2014 +0100 net: fec: consistently use lower case chars as hex digits Signed-off-by: Lothar Waßmann <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit ea209de3dded8acd37677cf4e2f5fc06b791e052 Author: Lothar Waßmann <[email protected]> Date: Mon Nov 17 10:51:17 2014 +0100 net: fec: indentation cleanup consistently use TABs for indentation Signed-off-by: Lothar Waßmann <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit be603bbb7bc12a006f1db36c338ac1c7f20c5a4a Author: J. Bruce Fields <[email protected]> Date: Wed Oct 29 14:23:21 2014 -0400 OOPS commit 92424e9c63e5d74ff1c282258f3e5c82bf1d913b Author: Christoph Hellwig <[email protected]> Date: Thu Nov 6 15:11:36 2014 -0500 nfsd: implement DATA_SYNC4 support Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]> commit 14fdfac3e8fe1f6f73578a3ea964dab2f844e52c Author: Trond Myklebust <[email protected]> Date: Wed Nov 12 18:04:04 2014 -0500 SUNRPC: Fix locking around callback channel reply receive Both xprt_lookup_rqst() and xprt_complete_rqst() require that you take the transport lock in order to avoid races with xprt_transmit(). Signed-off-by: Trond Myklebust <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]> commit ffa21a408184e95424035234496ec1b0cdde4b79 Author: Jeff Layton <[email protected]> Date: Mon Nov 17 17:02:57 2014 -0500 sunrpc: eliminate the XPT_DETACHED flag All it does is indicate whether a xprt has already been deleted from a list or not, which is unnecessary since we use list_del_init and it's always set and checked under the sv_lock anyway. Signed-off-by: Jeff Layton <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]> commit ea7aaa26273431650cb94e712c7c7cfec4306587 Author: Sebastian Hesselbarth <[email protected]> Date: Mon Nov 17 14:35:47 2014 +0100 ARM: dts: berlin: enable USB on the Google Chromecast Enable usb1 on Google Chromecast which is connected to micro-USB plug used for external power supply, too. Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Sebastian Hesselbarth <[email protected]> commit e802b3a2bfd4f52a9b23037800fa0965aae92013 Author: Sebastian Hesselbarth <[email protected]> Date: Mon Nov 17 14:35:46 2014 +0100 ARM: dts: berlin: add BG2CD nodes for USB support Adds nodes describing the Marvell Berlin BG2CD USB PHY and USB. The BG2CD SoC has 2 USB ChipIdea controllers, with usb0 host-only and usb1 dual-role capable. Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Sebastian Hesselbarth <[email protected]> commit fe354939edffe1f2579b4b372bad44e72bd9a9b3 Author: Antoine Tenart <[email protected]> Date: Mon Nov 17 14:35:45 2014 +0100 ARM: dts: Berlin: enable USB on the BG2Q DMP Enable the 2 available USB PHY and USB nodes on the Marvell Berlin BG2Q DMP. Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Sebastian Hesselbarth <[email protected]> commit c539711ee79f997b0cdc136382167963932461b8 Author: Antoine Tenart <[email protected]> Date: Mon Nov 17 14:35:44 2014 +0100 ARM: dts: berlin: add BG2Q nodes for USB support Adds nodes describing the Marvell Berlin BG2Q USB PHY and USB. The BG2Q SoC has 3 USB host controller, compatible with ChipIdea. Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Sebastian Hesselbarth <[email protected]> commit 81906906d8d95837c87b934a1a929cc43b61f4ee Author: Antoine Tenart <[email protected]> Date: Mon Nov 17 14:33:12 2014 +0100 ARM: berlin: do not select RESET_CONTROLLER RESET_CONTROLLER is meant to be user-selectable. To respect that, do not select it automatically when using ARCH_BERLIN. Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Sebastian Hesselbarth <[email protected]> commit 7943c0f329d33f531607d66f5781f2210e1e278c Author: Alexei Starovoitov <[email protected]> Date: Thu Nov 13 17:36:50 2014 -0800 bpf: remove test map scaffolding and user proper types proper types and function helpers are ready. Use them in verifier testsuite. Remove temporary stubs Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit d0003ec01c667b731c139e23de3306a8b328ccf5 Author: Alexei Starovoitov <[email protected]> Date: Thu Nov 13 17:36:49 2014 -0800 bpf: allow eBPF programs to use maps expose bpf_map_lookup_elem(), bpf_map_update_elem(), bpf_map_delete_elem() map accessors to eBPF programs Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit ffb65f27a15583379567b6a59a9758163b7f5750 Author: Alexei Starovoitov <[email protected]> Date: Thu Nov 13 17:36:48 2014 -0800 bpf: add a testsuite for eBPF maps . check error conditions and sanity of hash and array map APIs . check large maps (that kernel gracefully switches to vmalloc from kmalloc) . check multi-process parallel access and stress test Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit a1854d6ac0008518bfc45e791172ad250999c2a2 Author: Alexei Starovoitov <[email protected]> Date: Thu Nov 13 17:36:47 2014 -0800 bpf: fix BPF_MAP_LOOKUP_ELEM command return code fix errno of BPF_MAP_LOOKUP_ELEM command as bpf manpage described it in commit b4fc1a460f30("Merge branch 'bpf-next'"): ----- BPF_MAP_LOOKUP_ELEM int bpf_lookup_elem(int fd, void *key, void *value) { union bpf_attr attr = { .map_fd = fd, .key = ptr_to_u64(key), .value = ptr_to_u64(value), }; return bpf(BPF_MAP_LOOKUP_ELEM, &attr, sizeof(attr)); } bpf() syscall looks up an element with given key in a map fd. If element is found it returns zero and stores element's value into value. If element is not found it returns -1 and sets errno to ENOENT. and further down in manpage: ENOENT For BPF_MAP_LOOKUP_ELEM or BPF_MAP_DELETE_ELEM, indicates that element with given key was not found. ----- In general all BPF commands return ENOENT when map element is not found (including BPF_MAP_GET_NEXT_KEY and BPF_MAP_UPDATE_ELEM with flags == BPF_MAP_UPDATE_ONLY) Subsequent patch adds a testsuite to check return values for all of these combinations. Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 28fbcfa08d8ed7c5a50d41a0433aad222835e8e3 Author: Alexei Starovoitov <[email protected]> Date: Thu Nov 13 17:36:46 2014 -0800 bpf: add array type of eBPF maps add new map type BPF_MAP_TYPE_ARRAY and its implementation - optimized for fastest possible lookup() . in the future verifier/JIT may recognize lookup() with constant key and optimize it into constant pointer. Can optimize non-constant key into direct pointer arithmetic as well, since pointers and value_size are constant for the life of the eBPF program. In other words array_map_lookup_elem() may be 'inlined' by verifier/JIT while preserving concurrent access to this map from user space - two main use cases for array type: . 'global' eBPF variables: array of 1 element with key=0 and value is a collection of 'global' variables which programs can use to keep the state between events . aggregation of tracing events into fixed set of buckets - all array elements pre-allocated and zero initialized at init time - key as an index in array and can only be 4 byte - map_delete_elem() returns EINVAL, since elements cannot be deleted - map_update_elem() replaces elements in an non-atomic way (for atomic updates hashtable type should be used instead) Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 0f8e4bd8a1fc8c4185f1630061d0a1f2d197a475 Author: Alexei Starovoitov <[email protected]> Date: Thu Nov 13 17:36:45 2014 -0800 bpf: add hashtable type of eBPF maps add new map type BPF_MAP_TYPE_HASH and its implementation - maps are created/destroyed by userspace. Both userspace and eBPF programs can lookup/update/delete elements from the map - eBPF programs can be called in_irq(), so use spin_lock_irqsave() mechanism for concurrent updates - key/value are opaque range of bytes (aligned to 8 bytes) - user space provides 3 configuration attributes via BPF syscall: key_size, value_size, max_entries - map takes care of allocating/freeing key/value pairs - map_update_elem() must fail to insert new element when max_entries limit is reached to make sure that eBPF programs cannot exhaust memory - map_update_elem() replaces elements in an atomic way - optimized for speed of lookup() which can be called multiple times from eBPF program which itself is triggered by high volume of events . in the future JIT compiler may recognize lookup() call and optimize it further, since key_size is constant for life of eBPF program Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 3274f52073d88b62f3c5ace82ae9d48546232e72 Author: Alexei Starovoitov <[email protected]> Date: Thu Nov 13 17:36:44 2014 -0800 bpf: add 'flags' attribute to BPF_MAP_UPDATE_ELEM command the current meaning of BPF_MAP_UPDATE_ELEM syscall command is: either update existing map element or create a new one. Initially the plan was to add a new command to handle the case of 'create new element if it didn't exist', but 'flags' style looks cleaner and overall diff is much smaller (more code reused), so add 'flags' attribute to BPF_MAP_UPDATE_ELEM command with the following meaning: #define BPF_ANY 0 /* create new element or update existing */ #define BPF_NOEXIST 1 /* create new element if it didn't exist */ #define BPF_EXIST 2 /* update existing element */ bpf_update_elem(fd, key, value, BPF_NOEXIST) call can fail with EEXIST if element already exists. bpf_update_elem(fd, key, value, BPF_EXIST) can fail with ENOENT if element doesn't exist. Userspace will call it as: int bpf_update_elem(int fd, void *key, void *value, __u64 flags) { union bpf_attr attr = { .map_fd = fd, .key = ptr_to_u64(key), .value = ptr_to_u64(value), .flags = flags; }; return bpf(BPF_MAP_UPDATE_ELEM, &attr, sizeof(attr)); } First two bits of 'flags' are used to encode style of bpf_update_elem() command. Bits 2-63 are reserved for future use. Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 2d791d2259d465ba1669a4cf3d7395d54f5e9772 Author: Ralf Baechle <[email protected]> Date: Tue Nov 18 18:47:13 2014 +0100 MIPS: Zero variable read by get_user / __get_user in case of an error. This wasn't happening in all cases. Signed-off-by: Ralf Baechle <[email protected]> commit cadaecd2188b99d93de676150007f0e097223232 Author: Denis Kirjanov <[email protected]> Date: Mon Nov 17 23:07:41 2014 +0300 PPC: bpf_jit_comp: Unify BPF_MOD | BPF_X and BPF_DIV | BPF_X Reduce duplicated code by unifying BPF_ALU | BPF_MOD | BPF_X and BPF_ALU | BPF_DIV | BPF_X CC: Alexei Starovoitov<[email protected]> CC: Daniel Borkmann<[email protected]> CC: Philippe Bergheaud<[email protected]> Signed-off-by: Denis Kirjanov <[email protected]> Acked-by: Alexei Starovoitov <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit a0e27f51ba8a04125c22a95c4d3e98297a7191de Author: Soren Brinkmann <[email protected]> Date: Thu Nov 6 07:38:51 2014 -0800 documentation: pinctrl bindings: Fix trivial typo 'abitrary' A misspelled 'arbitrary' propagated to quite a few locations in the DT binding documentation for pin-controllers. Fixing by: git grep abitrary | cut -f1 -d: | xargs sed -i 's/abitrary/arbitrary/' Reported-by: Andreas Färber <[email protected]> Signed-off-by: Soren Brinkmann <[email protected]> Signed-off-by: Rob Herring <[email protected]> commit 5641c09226f401ee054e48521707fb185380e8d3 Author: bpqw <[email protected]> Date: Wed Nov 12 14:26:42 2014 +0000 devicetree: bindings: Add vendor prefix for Micron Technology, Inc. This patch is used to add vendor prefix for Micron Technology, Inc. in the vendor-prefixes.txt file. Micron Technology, Inc. is an American multinational corporation based in Boise, Idaho, best known for producing many forms of semiconductor devices. This includes DRAM, SDRAM, flash memory, eMMC and SSDs. Signed-off-by: Bean Huo <[email protected]> [robh: cleanup commit msg formatting and company name] Signed-off-by: Rob Herring <[email protected]> commit f9cb89b63db8cb2755a5179843a0643cc284f1ef Author: Philipp Zabel <[email protected]> Date: Wed May 14 11:24:43 2014 +0200 of: Add vendor prefix for Chips&Media, Inc. Chips&Media is a developer of Video Codec IP cores. Signed-off-by: Philipp Zabel <[email protected]> [robh: fix-up alphabetical ordering] Signed-off-by: Rob Herring <[email protected]> commit 746c9e9f92dde2789908e51a354ba90a1962a2eb Author: Benjamin Herrenschmidt <[email protected]> Date: Fri Nov 14 17:55:03 2014 +1100 of/base: Fix PowerPC address parsing hack We have a historical hack that treats missing ranges properties as the equivalent of an empty one. This is needed for ancient PowerMac "bad" device-trees, and shouldn't be enabled for any other PowerPC platform, otherwise we get some nasty layout of devices in sysfs or even duplication when a set of otherwise identically named devices is created multiple times under a different parent node with no ranges property. This fix is needed for the PowerNV i2c busses to be exposed properly and will fix a number of other embedded cases. Signed-off-by: Benjamin Herrenschmidt <[email protected]> CC: <[email protected]> Acked-by: Grant Likely <[email protected]> Signed-off-by: Rob Herring <[email protected]> commit 9b6eab07588c2de102423fe99c875fc4bfda2508 Author: Antony Pavlov <[email protected]> Date: Sun Nov 9 01:37:34 2014 +0300 devicetree: vendor-prefixes.txt: fix whitespace Signed-off-by: Antony Pavlov <[email protected]> Signed-off-by: Rob Herring <[email protected]> commit ab74d00a39f70e1bc34a01322bb59f3750ca7a8c Author: Kevin Cernekee <[email protected]> Date: Sun Nov 9 00:55:47 2014 -0800 of: Fix crash if an earlycon driver is not found __earlycon_of_table_sentinel.compatible is a char[128], not a pointer, so it will never be NULL. Checking it against NULL causes the match loop to run past the end of the array, and eventually match a bogus entry, under the following conditions: - Kernel command line specifies "earlycon" with no parameters - DT has a stdout-path pointing to a UART node - The UART driver doesn't use OF_EARLYCON_DECLARE (or maybe the console driver is compiled out) Fix this by checking to see if match->compatible is a non-empty string. Signed-off-by: Kevin Cernekee <[email protected]> Cc: <[email protected]> # 3.16+ Signed-off-by: Rob Herring <[email protected]> commit 66865de4314caca30598244b86817e774c188afa Author: Bjorn Helgaas <[email protected]> Date: Sat Nov 1 17:35:31 2014 -0600 of/irq: Drop obsolete 'interrupts' vs 'interrupts-extended' text a9ecdc0fdc54 ("of/irq: Fix lookup to use 'interrupts-extended' property first") updated the description to say that: - Both 'interrupts' and 'interrupts-extended' may be present - Software should prefer 'interrupts-extended' - Software that doesn't comprehend 'interrupts-extended' may use 'interrupts' But there is still a paragraph at the end that prohibits having both and says 'interrupts' should be preferred. Remove the contradictory text. Fixes: a9ecdc0fdc54 ("of/irq: Fix lookup to use 'interrupts-extended' property first") Signed-off-by: Bjorn Helgaas <[email protected]> CC: [email protected] # v3.13+ Acked-by: Brian Norris <[email protected]> Acked-by: Mark Rutland <[email protected]> Signed-off-by: Rob Herring <[email protected]> commit 27b3383a1432127bfcf9f8a63bf184ff4d866141 Author: Geert Uytterhoeven <[email protected]> Date: Wed Oct 22 11:49:01 2014 +0200 of: Spelling s/stucture/structure/ Signed-off-by: Geert Uytterhoeven <[email protected]> Cc: Grant Likely <[email protected]> Cc: Rob Herring <[email protected]> Signed-off-by: Rob Herring <[email protected]> commit f2a306c29d024193b1272cd014108882f7887a9e Author: Robert Jarzmik <[email protected]> Date: Fri Sep 26 00:26:27 2014 +0200 devicetree: bindings: add sandisk to the vendor prefixes Add sandisk to the list of vendors. This prefix should be used also for companies absorbed by Sandisk, like M-Systems. Signed-off-by: Robert Jarzmik <[email protected]> Signed-off-by: Rob Herring <[email protected]> commit 00e4c3b6e285da90e736fbefff3d9e74a200ee54 Author: Charles Keepax <[email protected]> Date: Tue Nov 18 16:25:27 2014 +0000 ASoC: wm_adsp: Move core_ena to be co-located with start bit Many firmwares do not wait for the start bit before they begin processing audio, whilst this is a bug on the firmware side there are too many such firmwares in the wild to ignore the situation. This patch moves the core enable to happen at same time as the start, the firmware looses the ability to overlap its own startup with the audio path bring up but we ensure that all firmwares behave. Signed-off-by: Charles Keepax <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit 17c1861eabd12f28c24d4929efcc8aba8920b88f Author: Alexey Ishchuk <[email protected]> Date: Fri Nov 14 14:27:58 2014 +0100 s390/kernel: add system calls for access PCI memory Add the new __NR_s390_pci_mmio_write and __NR_s390_pci_mmio_read system calls to allow user space applications to access device PCI I/O memory pages on s390x platform. [ Martin Schwidefsky: some code beautification ] Signed-off-by: Alexey Ishchuk <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]> commit 6d1e2e1783deecb7b922716295ca17deebbd3d0e Author: Martin Schwidefsky <[email protected]> Date: Fri Nov 14 16:37:47 2014 +0100 s390: fix ptrace of user area if the inferior uses vector registers The floating point registers f a process that uses vector instruction are not store into task->thread.fp_regs anymore but in the upper halves of the first 16 vector registers. The ptrace interface for the peeks and pokes to the user area fails to take this into account. Fix __peek_user[_compat] and __poke_user[_compat] to use the vector array for the floating pointer register if the process has one. Signed-off-by: Martin Schwidefsky <[email protected]> commit afaa7d29bc04bf0fcf2e7bda2a802392a38d059b Author: Sebastian Ott <[email protected]> Date: Fri Nov 14 11:01:37 2014 +0100 s390/irq: use irq 0 Irq 0 is currently unused on s390. Since there is no reason to do this start counting at the beginning and gain an additional irq. Also correctly report the smallest usable irq number for dynamic allocation. Signed-off-by: Sebastian Ott <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]> commit 99e97b7106d492a3cac4f7963f4a89935d2fbca4 Author: Frank Blaschka <[email protected]> Date: Thu Nov 6 13:17:06 2014 +0100 s390/io: add ioport_map stubs add ioport_map stubs to make vfio build on s390. Signed-off-by: Frank Blaschka <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]> commit a6b42afa3fc452339e157ad5245320804cf1206f Author: Thomas Huth <[email protected]> Date: Tue Oct 28 15:12:23 2014 +0100 s390/docs: Remove sections that are not related to s390 Information how to use the GCC pre-processor, objdump, strace, top, etc. are generic and not specific to the S390 architecture, so we do not need this information in Debugging390.txt Signed-off-by: Thomas Huth <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]> commit b19556231156ce3e58ffd677747bf3ef7890a937 Author: Thomas Huth <[email protected]> Date: Fri Oct 31 14:10:14 2014 +0100 s390/docs: Fix the documentation of the address spaces The information about the address spaces was completely outdated, since the usage of the address spaces changed quite a bit since the early days. This patch now updates the information about the usage of the address spaces, mostly by using the description from Heiko's patch "rework uaccess code - fix locking issues" (457f2180951cdcbfb4657ddcc83b486e93497f56). Signed-off-by: Thomas Huth <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]> commit 5f217f905bc5e9d609d0aac830736bcfc087c7f5 Author: Takashi Sakamoto <[email protected]> Date: Tue Nov 18 23:59:40 2014 +0900 ALSA: firewire-lib: fix kerneldoc errors Complete missing parameters, correct wrong reference, and add an explaination about the differences between the latest specification and our implementation. Signed-off-by: Takashi Sakamoto <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> commit d6d521799fac14e14dead4e9428158340ff6b95f Author: JS Park <[email protected]> Date: Tue Nov 18 16:07:22 2014 +0000 ASoC: wm_adsp: Fix memory leak in wm_adsp_setup_algs Signed-off-by: JS Park <[email protected]> Signed-off-by: Charles Keepax <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit 139768895309c6c1d6913e909e9c9422f81a1640 Author: Jens Axboe <[email protected]> Date: Tue Nov 18 08:45:31 2014 -0700 NVMe: enable IO stats by default Before the blk-mq conversion they were on by default, we should not change behavior there. Signed-off-by: Jens Axboe <[email protected]> commit a5a267cf9ca9937b0ef946b502657ae7638282f6 Author: Sudip Mukherjee <[email protected]> Date: Tue Nov 18 17:42:54 2014 +0530 ASoC: rt286: build warning of section mismatch while building we were getting the following build warning: Section mismatch in reference from the function rt286_i2c_probe() to the variable .init.data:force_combo_jack_table The function rt286_i2c_probe() references the variable __initdata force_combo_jack_table. This is often because rt286_i2c_probe lacks a __initdata annotation or the annotation of force_combo_jack_table is wrong. we were getting the warning as force_combo_jack_table was marked with __initdata Signed-off-by: Sudip Mukherjee <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit 358a8bb5628420529e4f0b77068155ca8fa8973b Author: Lars-Peter Clausen <[email protected]> Date: Mon Nov 10 22:41:53 2014 +0100 ASoC: ac97: Push snd_ac97 pointer to the driver level Now that the ASoC core no longer needs a handle to the AC'97 device that is associated with a CODEC we can remove it from the snd_soc_codec struct and push it into the individual driver state structs like we do for other communication buses. Doing so creates a clean separation between the AC'97 bus support and the ASoC core. Signed-off-by: Lars-Peter Clausen <[email protected]> Acked-by: Charles Keepax <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit bc2632140435cc84f9817f1c362479b23dbdfebc Author: Lars-Peter Clausen <[email protected]> Date: Mon Nov 10 22:41:52 2014 +0100 ASoC: Rename snd_soc_dai_driver struct ac97_control field to bus_control Setting the ac97_control field on a CPU DAI tells the ASoC core that this DAI in addition to audio data also transports control data to the CODEC. This causes the core to suspend the DAI after the CODEC and resume it before the CODEC so communication to the CODEC is still possible. This is not necessarily something that is specific to AC'97 and can be used by other buses with the same requirement. This patch renames the flag from ac97_control to bus_control to make this explicit. While we are at it also change the type from int to bool. The following semantich patch was used for automatic conversion of the drivers: // <smpl> @@ identifier drv; @@ struct snd_soc_dai_driver drv = { - .ac97_control + .bus_control = - 1 + true }; // </smpl> Signed-off-by: Lars-Peter Clausen <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit 4bafcf074aca3bd191e4d93c6a140ca52654f192 Author: Lars-Peter Clausen <[email protected]> Date: Mon Nov 10 22:41:51 2014 +0100 ASoC: Drop ac97_control initialization from CODEC driver DAIs This is no longer necessary as there is no code anymore that uses this for CODEC DAIs. Signed-off-by: Lars-Peter Clausen <[email protected]> Acked-by: Charles Keepax <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit 6794f709b7124ff1e574c4f4c9494418ab56c4b4 Author: Lars-Peter Clausen <[email protected]> Date: Mon Nov 10 22:41:50 2014 +0100 ASoC: ac97: Drop delayed device registration We have all the information and dependencies we need to initialize and register the device available in snd_soc_new_ac97_codec(). So there is no need to delay the device registration until after the card itself as been registered. This makes the code significantly simpler and also makes it possible to use the AC'97 device in the CODECs probe function. The later will be required to be able to convert the AC'97 CODEC drivers to regmap. Signed-off-by: Lars-Peter Clausen <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit ca005f324ee38308b319c693f40523d959027acf Author: Lars-Peter Clausen <[email protected]> Date: Mon Nov 10 22:41:49 2014 +0100 ASoC: ac97: Drop support for setting platform data via the CPU DAI This has no users since commit f0fba2ad1b6b ("ASoC: multi-component - ASoC Multi-Component Support") which was almost 5 years ago. Given that this runs after CODEC probe functions have been run it also doesn't seem to be that useful. So drop it altogether to make the code simpler. Signed-off-by: Lars-Peter Clausen <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit bdfd60e3c0affb914549f1d22e8aeef71e7828e6 Author: Lars-Peter Clausen <[email protected]> Date: Mon Nov 10 22:41:48 2014 +0100 ASoC: ac97: Merge soc_ac97_dev_{un,}register()/soc_{un,}register_ac97_codec() soc_{un,}register_ac97_codec() is just a simple wrapper around soc_ac97_dev_{un,}register(). There is no need to split these up into two different sets of functions. Signed-off-by: Lars-Peter Clausen <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit eda1a701fd9589b6ed15b109558bd4f6202e3829 Author: Lars-Peter Clausen <[email protected]> Date: Mon Nov 10 22:41:47 2014 +0100 ASoC: ac97: Use static ac97_bus We always pass soc_ac97_ops to snd_soc_new_ac97_codec(). So instead of allocating a snd_ac97_bus in snd_soc_new_ac97_codec() just use a static one that gets initialized when snd_soc_set_ac97_ops() is called. Also drop the device number parameter from snd_soc_new_ac97_codec(). We currently only support one device per bus and all drivers pass 0 for the device number. And if we should ever support multiple devices per bus it wouldn't be up to individual AC'97 device drivers to pick their number, but rather either the AC'97 adapter driver or the core code will assign them. Signed-off-by: Lars-Peter Clausen <[email protected]> Acked-by: Charles Keepax <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit 336b8423e285174ebecf02a743d69913b83bbc48 Author: Lars-Peter Clausen <[email protected]> Date: Mon Nov 10 22:41:46 2014 +0100 ASoC: Move AC'97 support to its own file Currently the AC'97 support is splattered all throughout soc-core.c. Some parts are #ifdef'd some parts are not. This patch moves the AC'97 support to its own file, this should make the code a bit more clearer and also makes it possible to easily not compile it into the kernel when not needed. Signed-off-by: Lars-Peter Clausen <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit 70f3af3ca15affaef3d026a5aa6e44c4627ea6c7 Author: Lars-Peter Clausen <[email protected]> Date: Mon Nov 10 22:41:45 2014 +0100 ASoC: Properly handle AC'97 device lifetime management The memory that a struct device is contained in must not be freed except from within the device's release callback. The ASoC code currently does not adhere to this rule for the AC'97 device. This patch fixes it by moving the freeing of the AC'97 to the release callback and splitting up the registration and unregistration of the device into separate steps for getting/putting the reference to the device and adding/removing it to the device hierarchy. Signed-off-by: Lars-Peter Clausen <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit 65c72efd1ea370f0311a5d89754996fff9fc0747 Author: Lars-Peter Clausen <[email protected]> Date: Mon Nov 10 22:41:44 2014 +0100 ASoC: mpc5200_dma: Don't overwrite ac97 device private_data The mpc5200_dma overwrites the private_data field of the CODEC's AC'97 device with the DMA drivers private data, but never actually reads it again. Given that the private_data field is supposed to be owned by the AC'97 driver, overwriting it may cause undefined behavior. This patch removes the code that overwrites the field from the driver. Signed-off-by: Lars-Peter Clausen <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit 35480e3536cdab1ee1976675e798f16d707f5356 Author: Lars-Peter Clausen <[email protected]> Date: Mon Nov 10 22:41:43 2014 +0100 ASoC: mpc5200_psc_ac97: Remove unused on-stack snd_ac97 device The mpc5200_psc_ac97 driver puts a snd_ac97 device on the stack in the driver probe function, initializes the private data member of the device and the never uses the device again. It should be safe to remove it. Signed-off-by: Lars-Peter Clausen <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit 77c1aa84de0096792de673aa1c64c36b38553cf5 Author: Daniel Vetter <[email protected]> Date: Tue Nov 18 13:27:07 2014 +0100 drm/i915: Don't print header in error state for non-existing CS This goes back to commit 362b8af7ad1d91266aa4931e62be45c1e5cf753b Author: Ben Widawsky <[email protected]> Date: Thu Jan 30 00:19:38 2014 -0800 drm/i915: Move per ring error state to ring_error Spotted while reading error states. Cc: Ben Widawsky <[email protected]> Cc: Chris Wilson <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> commit 6dcc0cf6cb3120cedc0d4c12171894f3d6415981 Author: Jens Axboe <[email protected]> Date: Tue Nov 18 08:21:18 2014 -0700 NVMe: nvme_submit_async_admin_req() must use atomic rq allocation We are called for async event notification issues, and the nvmeq lock is already held. If we fail the request allocation, we'll just retry next time. Reported-by: Julia Lawall <[email protected]> Signed-off-by: Jens Axboe <[email protected]> commit 30021e3707a75cc29dc1252c062d374151c5985f Author: Beniamino Galvani <[email protected]> Date: Thu Nov 13 20:32:01 2014 +0100 i2c: add support for Amlogic Meson I2C controller This is a driver for the I2C controller found in Amlogic Meson SoCs. Signed-off-by: Beniamino Galvani <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> commit c9449affad2ae0824927df5a207705e07f346fb1 Author: Gerlando Falauto <[email protected]> Date: Thu Nov 13 14:39:56 2014 +0100 i2c: mux: create "channel-n" symlinks for child segments in the mux device This makes the topology clearer. For instance, by adding a pca9547 device with address 0x70 to bus i2c-0, you get: /sys/class/i2c-dev/i2c-0/device/0-0070/channel-0 -> i2c-1 ... /sys/class/i2c-dev/i2c-0/device/0-0070/channel-7 -> i2c-8 Signed-off-by: Gerlando Falauto <[email protected]> [wsa: simplified sysfs-usage and fixed format string usage] Signed-off-by: Wolfram Sang <[email protected]> Acked-by: Martin Belanger <[email protected]> Acked-by: Danielle Costantino <[email protected]> commit 51cf3b0e2a72bb08cd280be6c0ead4e08ed50a2c Author: Wolfram Sang <[email protected]> Date: Thu Nov 13 14:39:55 2014 +0100 i2c: mux: create symlink to actual mux device The current implementation creates muxed i2c-<n> busses as immediate children of their i2c-<n> parent bus. In case of multiple muxes on one bus, it is impossible to determine which muxed bus comes from which mux. It could be argued that the parent device should be changed from the parent adapter to the mux device. This has pros and cons. To improve the topology, simply add a "mux_device" symlink pointing to the actual muxing device, so we can distinguish muxed busses. Doing it this way, we don't break the ABI. Signed-off-by: Wolfram Sang <[email protected]> Tested-by: Guenter Roeck <[email protected]> commit 4470c725ba7b86481c31466640ab487f927de6b7 Author: Wolfram Sang <[email protected]> Date: Tue Nov 18 15:12:43 2014 +0100 i2c: acpi: remove unneeded variable initialization No need to initialize 'ret' if it gets assigned directly after that. Signed-off-by: Wolfram Sang <[email protected]> Acked-by: Mika Westerberg <[email protected]> commit bb29a93b38610d2adc6ead40b75e1a1991617550 Author: Masanari Iida <[email protected]> Date: Wed Nov 12 00:52:23 2014 +0900 ASoC: jack: Fix warning while make htmldocs caused by soc-jack.c This patch fix following errors while "make htmldocs" on linux-next-20141110. Warning(.//sound/soc/soc-jack.c:126): No description found for parameter 'zones' Warning(.//sound/soc/soc-jack.c:126): Excess function parameter 'zone' description in 'snd_soc_jack_add_zones' Signed-off-by: Masanari Iida <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit ce1a78840ff7ab846065d5b65eaac959bafe1949 Author: Yao Yuan <[email protected]> Date: Tue Nov 18 18:31:06 2014 +0800 i2c: imx: add DMA support for freescale i2c driver Add dma support for i2c. This function depend on DMA driver. You can turn on it by write both the dmas and dma-name properties in dts node. DMA is optional, even DMA request unsuccessfully, i2c can also work well. Signed-off-by: Yuan Yao <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> commit 2fbed5119d6a07a6777b2131262587df338df22b Author: Yao Yuan <[email protected]> Date: Tue Nov 18 18:31:05 2014 +0800 i2c: imx: Sort include headers alphabetically If the inlcude headers aren't sorted alphabetically, then the logical choice is to append new ones, however that creates a lot of potential for conflicts or duplicates because every change will then add new includes in the same location. Signed-off-by: Yuan Yao <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> commit fcc50e5cd2deb8316d19e446d8efdfc9b35646ef Author: Qipan Li <[email protected]> Date: Mon Nov 17 23:17:03 2014 +0800 spi: sirf: assign spi_master's max_speed_hz member if spi device has no frequency, spi core will setup the default frequency to max_speed_hz of spi_master according to int spi_setup(struct spi_device *spi) { ... if (!spi->max_speed_hz) spi->max_speed_hz = spi->master->max_speed_hz; ... } this patch moves CSR SiRFSoC SPI frequency set to follow SPI core behaviour. Signed-off-by: Qipan Li <[email protected]> Signed-off-by: Barry Song <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit 9c4b19a07dddda3ba35a2eb9b4134d485908e2f5 Author: Qipan Li <[email protected]> Date: Mon Nov 17 23:17:02 2014 +0800 spi: sirf: fix word width configuration commit 8c328a262f ("spi: sirf: Avoid duplicate code in various bits_per_word cases") is wrong in setting data width register of fifo is not right, it should use sspi->word_width >> 1 to set related bits. According to hardware spec, the mapping between register value and data width: 0 - byte 1 - WORD 2 - DWORD Fixes: 8c328a262f ("spi: sirf: Avoid duplicate code in various bits_per_word cases") is wrong in setting data width register of Signed-off-by: Qipan Li <[email protected]> Signed-off-by: Barry Song <[email protected]> Signed-off-by: Mark Brown <[email protected]> Cc: [email protected] commit 864b94adfcba752aa902ee34497bbe58b97aa8d3 Author: Jiang Liu <[email protected]> Date: Sun Nov 9 22:48:03 2014 +0800 pci, ACPI, iommu: Enhance pci_root to support DMAR device hotplug Finally enhance pci_root driver to support DMAR device hotplug when hot-plugging PCI host bridges. Signed-off-by: Jiang Liu <[email protected]> Reviewed-by: Yijing Wang <[email protected]> Acked-by: Bjorn Helgaas <[email protected]> Signed-off-by: Joerg Roedel <[email protected]> commit 30badc9543490f41497c42f004db02f1e8a29341 Author: Markus Elfring <[email protected]> Date: Tue Nov 18 11:31:23 2014 +0100 GFS2: Deletion of unnecessary checks before two function calls The functions iput() and put_pid() test whether their argument is NULL and then return immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <[email protected]> Signed-off-by: Steven Whitehouse <[email protected]> commit 0690cbd2e55a72a8eae557c389d1a136ed9fa142 Author: Joerg Roedel <[email protected]> Date: Wed Nov 5 15:28:30 2014 +0100 powerpc/iommu: Rename iommu_[un]map_sg functions The IOMMU-API gained support for a new iommu_map_sg function. This causes compile failures on powerpc because the function name is already globally used there. This patch renames adds a ppc_ prefix to these functions to solve the compile problem. Signed-off-by: Joerg Roedel <[email protected]> commit ffebeb46dd34736c90ffbca1ccb0bef8f4827c44 Author: Jiang Liu <[email protected]> Date: Sun Nov 9 22:48:02 2014 +0800 iommu/vt-d: Enhance intel-iommu driver to support DMAR unit hotplug Implement required callback functions for intel-iommu driver to support DMAR unit hotplug. Signed-off-by: Jiang Liu <[email protected]> Reviewed-by: Yijing Wang <[email protected]> Signed-off-by: Joerg Roedel <[email protected]> commit 51acce33c4df6ee23b5ad4c2e6c239e0d6f25771 Author: Jiang Liu <[email protected]> Date: Sun Nov 9 22:48:01 2014 +0800 iommu/vt-d: Enhance error recovery in function intel_enable_irq_remapping() Enhance error recovery in function intel_enable_irq_remapping() by tearing down all created data structures. Signed-off-by: Jiang Liu <[email protected]> Reviewed-by: Yijing Wang <[email protected]> Signed-off-by: Joerg Roedel <[email protected]> commit a7a3dad944344caf034699b0c0e8dc51b469cf20 Author: Jiang Liu <[email protected]> Date: Sun Nov 9 22:48:00 2014 +0800 iommu/vt-d: Enhance intel_irq_remapping driver to support DMAR unit hotplug Implement required callback functions for intel_irq_remapping driver to support DMAR unit hotplug. Signed-off-by: Jiang Liu <[email protected]> Signed-off-by: Joerg Roedel <[email protected]> commit d35165a955f095095cdb8512cb7cd8f63101649a Author: Jiang Liu <[email protected]> Date: Sun Nov 9 22:47:59 2014 +0800 iommu/vt-d: Search for ACPI _DSM method for DMAR hotplug According to Intel VT-d specification, _DSM method to support DMAR hotplug should exist directly under corresponding ACPI object representing PCI host bridge. But some BIOSes doesn't conform to this, so search for _DSM method in the subtree starting from the ACPI object representing the PCI host bridge. Signed-off-by: Jiang Liu <[email protected]> Reviewed-by: Yijing Wang <[email protected]> Signed-off-by: Joerg Roedel <[email protected]> commit 6b1972493a84f8fe13ff9d202745590f6c53d670 Author: Jiang Liu <[email protected]> Date: Sun Nov 9 22:47:58 2014 +0800 iommu/vt-d: Implement DMAR unit hotplug framework On Intel platforms, an IO Hub (PCI/PCIe host bridge) may contain DMAR units, so we need to support DMAR hotplug when supporting PCI host bridge hotplug on Intel platforms. According to Section 8.8 "Remapping Hardware Unit Hot Plug" in "Intel Virtualization Technology for Directed IO Architecture Specification Rev 2.2", ACPI BIOS should implement ACPI _DSM method under the ACPI object for the PCI host bridge to support DMAR hotplug. This patch introduces interfaces to parse ACPI _DSM method for DMAR unit hotplug. It also implements state machines for DMAR unit hot-addition and hot-removal. The PCI host bridge hotplug driver should call dmar_hotplug_hotplug() before scanning PCI devices connected for hot-addition and after destroying all PCI devices for hot-removal. Signed-off-by: Jiang Liu <[email protected]> Reviewed-by: Yijing Wang <[email protected]> Signed-off-by: Joerg Roedel <[email protected]> commit 78d8e7046111425bb688cddc4303d79cb0f0d281 Author: Jiang Liu <[email protected]> Date: Sun Nov 9 22:47:57 2014 +0800 iommu/vt-d: Dynamically allocate and free seq_id for DMAR units Introduce functions to support dynamic IOMMU seq_id allocating and releasing, which will be used to support DMAR hotplug. Also rename IOMMU_UNITS_SUPPORTED as DMAR_UNITS_SUPPORTED. Signed-off-by: Jiang Liu <[email protected]> Reviewed-by: Yijing Wang <[email protected]> Signed-off-by: Joerg Roedel <[email protected]> commit c2a0b538d2c778aef7bf2fbe7973229192c9a392 Author: Jiang Liu <[email protected]> Date: Sun Nov 9 22:47:56 2014 +0800 iommu/vt-d: Introduce helper function dmar_walk_resources() Introduce helper function dmar_walk_resources to walk resource entries in DMAR table and ACPI buffer object returned by ACPI _DSM method for IOMMU hot-plug. Signed-off-by: Jiang Liu <[email protected]> Signed-off-by: Joerg Roedel <[email protected]> commit eb45fa0b93e03b03848cd048dcc57648409c8125 Author: Jani Nikula <[email protected]> Date: Tue Nov 18 12:11:29 2014 +0200 drm/i915/audio: fix monitor presence indication after disable Indicate the monitor has been disconnected on disable. The regression has been introduced in commit 5fad84a7530f8e7664cdc6f490cb90653fed1266 Author: Jani Nikula <[email protected]> Date: Tue Nov 4 10:30:23 2014 +0200 drm/i915: rewrite hsw/bdw audio codec enable/disable sequences Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86424 Cc: Rodrigo Vivi <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> commit 6676f3081f7e3dae64e05b87d47a041b782f898a Author: Hui Wang <[email protected]> Date: Tue Nov 18 17:57:41 2014 +0800 ALSA: hda - fix the mic mute led problem for Latitude E5550 The microphone mute led on the Latitude E5550 can't work. We need to apply DELL_WMI_MIC_MUTE_LED quirk to this machine. The machine uses alc293 codec and already applied the quirk ALC293_FIXUP_DELL1_MIC_NO_PRESENCE through pin_fixup_tbl[]. Here we just let DELL_WMI_MIC_MUTE_LED be chained to ALC269_FIXUP_HEADSET_MODE, then the machine will have these quirks ALC293_FIXUP_DELL1_MIC_NO_PRESENCE--> ALC269_FIXUP_HEADSET_MODE-->ALC255_FIXUP_DELL_WMI_MIC_MUTE_LED. BugLink: https://bugs.launchpad.net/bugs/1381856 Reported-and-tested-by: Po-Hsu Lin <[email protected]> Signed-off-by: Hui Wang <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> commit 4a83d42ae2041d5b76f1a0662bc3a5a85e4eb0d1 Author: Hui Wang <[email protected]> Date: Tue Nov 18 17:57:40 2014 +0800 ALSA: hda - move DELL_WMI_MIC_MUTE_LED to the tail in the quirk chain We have one more Dell machine needs DELL_WMI_MIC_MUTE_LED quirk, but the machine uses alc293 instead of alc255. So if DELL_WMI_MIC_MUTE_LED still chain ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, the machine can't use this quirk. To change this situation, let the DELL_WMI_MIC_MUTE_LED to be a standalone quirk, and let other quirks chain it. After this change, this quirk can be chained to any existing quirks, and as a result, it is possible that this quirk is applied to a non-Dell machine or a Dell machine without mic mute led on it, but it is still safe since alc_fixup_dell_wmi() will return an error in these situations. And remove the quirk for machine with subsystem id 0x6010 and 0x601f, these two machines will fall back to the quirk ALC255_FIXUP_DELL1_MIC_NO_PRESENCE-->ALC255_FIXUP_HEADSET_MODE--> ALC255_FIXUP_DELL_WMI_MIC_MUTE_LED through pin_fixup_tbl[]. BugLink: https://bugs.launchpad.net/bugs/1381856 Reported-and-tested-by: Po-Hsu Lin <[email protected]> Signed-off-by: Hui Wang <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> commit 3ffa037d7f78ceb25115eda29176c2bd2844866f Author: Neerav Parikh <[email protected]> Date: Wed Nov 12 00:19:02 2014 +0000 i40e: Set XPS bit mask to zero in DCB mode Due to DCBX configuration change if the VSI needs to use more than 1 TC; it needs to disable the XPS maps that were set when operating in 1 TC mode. Without disabling XPS the netdev layer will select queues based on those settings and not use the TC queue mapping to make the queue selection. This patch allows the driver to enable/disable the XPS based on the number of TCs being enabled for the given VSI. Change-ID: Idc4dec47a672d2a509f6d7fe11ed1ee65b4f0e08 Signed-off-by: Neerav Parikh <[email protected]> Tested-By: Jack Morgan <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]> commit 4b7698cb95638693e3d9a2fc01a2bdbd8710ff81 Author: Neerav Parikh <[email protected]> Date: Wed Nov 12 00:18:57 2014 +0000 i40e: Prevent link flow control settings when PFC is enabled When PFC is enabled we should not proceed with setting the link flow control parameters. Also, always report the link flow Tx/Rx settings as off when PFC is enabled. Change-ID: Ib09ec58afdf0b2e587ac9d8851a5c80ad58206c4 Signed-off-by: Neerav Parikh <[email protected]> Tested-By: Jack Morgan <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]> commit d341b7a52be79520f8e8b1ed0e3df657b2442e5b Author: Neerav Parikh <[email protected]> Date: Wed Nov 12 00:18:51 2014 +0000 i40e: Do not disable/enable FCoE VSI with DCB reconfig FCoE VSI Tx queue disable times out when reconfiguring as a result of DCB TC configuration change event. The hardware allows us to skip disabling and enabling of Tx queues for VSIs with single TC enabled. As FCoE VSI is configured to have only single TC we skip it from disable/enable flow. Change-ID: Ia73ff3df8785ba2aa3db91e6f2c9005e61ebaec2 Signed-off-by: Neerav Parikh <[email protected]> Tested-By: Jack Morgan <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]> commit 69129dc39fac45e0ea1dbbca995abdac279df376 Author: Neerav Parikh <[email protected]> Date: Wed Nov 12 00:18:46 2014 +0000 i40e: Modify Tx disable wait flow in case of DCB reconfiguration When DCB TC configuration changes the firmware suspends the port's Tx. Now, as DCB TCs may have changed the PF driver tries to reconfigure the TC configuration of the VSIs it manages. As part of this process it disables the VSI queues but the Tx queue disable will not complete as the port's Tx has been suspended. So, waiting for Tx queues to go to disable state in this flow may lead to detection of Tx queue disable timeout errors. Hence, this patch adds a new PF state so that if a port's Tx is in suspended state the Tx queue disable flow would just put the request for the queue to be disabled and return without waiting for the queue to be actually disabled. Once the VSI(s) TC reconfiguration has been done and driver has called firmware AQC "Resume PF Traffic" the driver checks the Tx queues requested to be disabled are actually disabled before re-enabling them again. Change-ID: If3e03ce4813a4e342dbd5a1eb1d2861e952b7544 Signed-off-by: Neerav Parikh <[email protected]> Tested-By: Jack Morgan <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]> commit 23cd1f095adf110d118ef972914c714176cd48d0 Author: Neerav Parikh <[email protected]> Date: Wed Nov 12 00:18:41 2014 +0000 i40e: Update VEB's enabled_tc after reconfiguration When the port TC configuration changes as a result of DCBx the driver modifies the enabled TCs for the VEBs it manages. But, in the process it did not update the enabled_tc value that it caches on a per VEB basis. So, when the next reconfiguration event occurs where the number of TC value is same as the value cached in enabled_tc for a given VEB; driver does not modify it's TC configuration by calling appropriate AQ command believing it is running with the same configuration as requested. Now, as the VEB is not actually enabled for the TCs that are there any TC configuration command for VSI attached to that VEB with TCs that are not enabled for the VEB fails. This patch fixes this issue. Change-ID: Ife5694469b05494228e0d850429ea1734738cf29 Signed-off-by: Neerav Parikh <[email protected]> Tested-By: Jack Morgan <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]> commit e1c4751ee22f5d5f6f6cfcb70614e18e4218892e Author: Neerav Parikh <[email protected]> Date: Wed Nov 12 00:18:30 2014 +0000 i40e: Check for LLDP AdminStatus before querying DCBX This patch adds a check whether LLDP Agent's default AdminStatus is enabled or disabled on a given port. If it is disabled then it sets the DCBX status to disabled as well; and would not query firmware for any DCBX configuration data. Change-ID: I73c0b9f0adbf4cae177d14914b20a48c9a8f50fd Signed-off-by: Neerav Parikh <[email protected]> Tested-By: Jack Morgan <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]> commit 9fa61dd2153a4ff3a57891d4866a2595eb9ac81a Author: Neerav Parikh <[email protected]> Date: Wed Nov 12 00:18:25 2014 +0000 i40e: Add support to firmware CEE DCBX mode This patch allows i40e driver to query and use DCB configuration from firmware when firmware DCBX agent is in CEE mode. Change-ID: I30f92a67eb890f0f024f35339696e6e83d49a274 Signed-off-by: Neerav Parikh <[email protected]> Tested-By: Jack Morgan <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]> commit 2fd75f31f6bacaed38061f95f0fee26de3e01170 Author: Neerav Parikh <[email protected]> Date: Wed Nov 12 00:18:20 2014 +0000 i40e: Resume Port Tx after DCB event When there are DCB configuration changes based on DCBX the firmware suspends the port's Tx and generates an event to the PF. The PF is then responsible to reconfigure the PF VSIs and switching topology as per the updated DCB configuration and then resume the port's Tx by calling the "Resume Port Tx" AQ command. This patch adds this call to the flow that handles DCB re-configuration in the PF. Change-ID: I5b860ad48abfbf379b003143c4d3453e2ed5cc1c Signed-off-by: Neerav Parikh <[email protected]> Tested-By: Jack Morgan <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]> commit 7bda87c7fb2eaab8e144d6d0a2638099d7b6e5f5 Author: Catherine Sullivan <[email protected]> Date: Tue Nov 11 03:15:06 2014 +0000 i40e: Bump version to 1.1.23 Bumping minor version as this will be the second SW release and it should be 1. Change-ID: If0bd102095d2f059ae0c9b7f4ad625535ffbbdee Signed-off-by: Catherine Sullivan <[email protected]> Signed-off-by: Jeff Kirsher <jeffrey.t.kirshe…
aryabinin
referenced
this pull request
in aryabinin/linux
Nov 27, 2014
GIT 30a727e4802f48182d33e2bdaca586bfb6a62868 commit 6d4e81ed89c092cb156c8d19cb68c8733cd502b3 Author: Tomeu Vizoso <[email protected]> Date: Mon Nov 24 10:08:03 2014 +0100 cpufreq: Ref the policy object sooner Do it before it's assigned to cpufreq_cpu_data, otherwise when a driver tries to get the cpu frequency during initialization the policy kobj is referenced and we get this warning: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 64 at include/linux/kref.h:47 kobject_get+0x64/0x70() Modules linked in: CPU: 1 PID: 64 Comm: irq/77-tegra-ac Not tainted 3.18.0-rc4-next-20141114ccu-00050-g3eff942 #326 [<c0016fac>] (unwind_backtrace) from [<c001272c>] (show_stack+0x10/0x14) [<c001272c>] (show_stack) from [<c06085d8>] (dump_stack+0x98/0xd8) [<c06085d8>] (dump_stack) from [<c002892c>] (warn_slowpath_common+0x84/0xb4) [<c002892c>] (warn_slowpath_common) from [<c00289f8>] (warn_slowpath_null+0x1c/0x24) [<c00289f8>] (warn_slowpath_null) from [<c0220290>] (kobject_get+0x64/0x70) [<c0220290>] (kobject_get) from [<c03e944c>] (cpufreq_cpu_get+0x88/0xc8) [<c03e944c>] (cpufreq_cpu_get) from [<c03e9500>] (cpufreq_get+0xc/0x64) [<c03e9500>] (cpufreq_get) from [<c0285288>] (actmon_thread_isr+0x134/0x198) [<c0285288>] (actmon_thread_isr) from [<c0069008>] (irq_thread_fn+0x1c/0x40) [<c0069008>] (irq_thread_fn) from [<c0069324>] (irq_thread+0x134/0x174) [<c0069324>] (irq_thread) from [<c0040290>] (kthread+0xdc/0xf4) [<c0040290>] (kthread) from [<c000f4b8>] (ret_from_fork+0x14/0x3c) ---[ end trace b7bd64a81b340c59 ]--- Signed-off-by: Tomeu Vizoso <[email protected]> Acked-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> commit e874bf5f7647a9fdf14d72dbb376ec95327e3a81 Author: Lars-Peter Clausen <[email protected]> Date: Tue Nov 25 21:41:03 2014 +0100 ASoC: Disable regmap helpers if regmap is disabled If regmap is disabled there will be no users of the ASoC regmap helpers. Furthermore regmap_exit() will no be defined causing the following compile error: sound/soc/soc-core.c: In function 'snd_soc_component_exit_regmap': sound/soc/soc-core.c:2645:2: error: implicit declaration of function 'regmap_exit' [-Werror=implicit-function-declaration] So disable the helpers if regmap is disabled. Reported-by: kbuild test robot <[email protected]> Fixes: 20feb881988c ASoC: Add helper functions for deferred regmap setup") Signed-off-by: Lars-Peter Clausen <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit a5e9ab291c608c62691b9d565104a30d931998bf Author: Greg Kroah-Hartman <[email protected]> Date: Tue Nov 25 12:46:39 2014 -0800 Revert "serial: of-serial: add PM suspend/resume support" This reverts commit 2dea53bf57783f243c892e99c10c6921e956aa7e. Turns out to be broken :( Cc: Jingchang Lu <[email protected]> Cc: Arnd Bergmann <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 86261fdd65ce076c0aa05dbf3f5f5fe10aab1bcf Author: Petr Cvek <[email protected]> Date: Tue Nov 25 06:05:33 2014 +0100 i2c: pxa: add support for SCCB devices Add support for SCCB by implementing I2C_M_IGNORE_NAK and I2C_M_STOP flags and advertising functionality flag I2C_FUNC_PROTOCOL_MANGLING. Also fixed missing functionality flag I2C_FUNC_NOSTART. Signed-off-by: Petr Cvek <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> commit 23173eae7b9a5389d3f7031b77cde34f63b814a2 Author: Alexander Kochetkov <[email protected]> Date: Tue Nov 25 02:20:55 2014 +0400 omap: i2c: don't check bus state IP rev3.3 and earlier Commit 0f5768bf894f ("i2c: omap: implement workaround for handling invalid BB-bit values") introduce the error result in boot test fault on OMAP3530 boards. The patch fix the error (disable i2c bus test for OMAP3530). Reported-by: Kevin Hilman <[email protected]> Signed-off-by: Alexander Kochetkov <[email protected]> Fixes: 0f5768bf894f ("i2c: omap: implement workaround for handling invalid BB-bit values") Tested-by: Tony Lindgren <[email protected]> Tested-by: Kevin Hilman <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> commit a620a6bc1c94c22d6c312892be1e0ae171523125 Author: Thadeu Lima de Souza Cascardo <[email protected]> Date: Tue Nov 25 14:21:11 2014 -0200 tg3: fix ring init when there are more TX than RX channels If TX channels are set to 4 and RX channels are set to less than 4, using ethtool -L, the driver will try to initialize more RX channels than it has allocated, causing an oops. This fix only initializes the RX ring if it has been allocated. Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 69b93607a9862b1db2f0f2e078e1396f8e20fa9b Author: Lars-Peter Clausen <[email protected]> Date: Tue Nov 25 20:29:40 2014 +0100 ASoC: qi_lb60: Pass flags to gpiod_get() Pass flags to gpiod_get() to automatically configure the GPIOs. This is shorter and not passing any flags to gpiod_get() will eventually no longer be supported. Signed-off-by: Lars-Peter Clausen <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit c3658e8d0f10147fc86018be7f11668246c156d3 Author: Eric Dumazet <[email protected]> Date: Tue Nov 25 07:40:04 2014 -0800 tcp: fix possible NULL dereference in tcp_vX_send_reset() After commit ca777eff51f7 ("tcp: remove dst refcount false sharing for prequeue mode") we have to relax check against skb dst in tcp_v[46]_send_reset() if prequeue dropped the dst. If a socket is provided, a full lookup was done to find this socket, so the dst test can be skipped. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88191 Reported-by: Jaša Bartelj <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Reported-by: Daniel Borkmann <[email protected]> Fixes: ca777eff51f7 ("tcp: remove dst refcount false sharing for prequeue mode") Signed-off-by: David S. Miller <[email protected]> commit 7d63a5f9b25ba6b130da8eb2d32a72b1462d0249 Author: Larry Finger <[email protected]> Date: Tue Nov 25 10:32:07 2014 -0600 rtlwifi: Change order in device startup The existing order of steps when starting the PCI devices works for 2.4G devices, but fails to initialize the 5G section of the RTL8821AE hardware. This patch is needed to fix the regression reported in Bug #88811 (https://bugzilla.kernel.org/show_bug.cgi?id=88811). Reported-by: Valerio Passini <[email protected]> Tested-by: Valerio Passini <[email protected]> Signed-off-by: Larry Finger <[email protected]> Cc: Valerio Passini <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit a91ed1901a80b401afa1b718d941d3450d868151 Author: Larry Finger <[email protected]> Date: Tue Nov 25 10:32:06 2014 -0600 rtlwifi: rtl8821ae: Fix 5G detection problem The changes associated with moving this driver from staging to the regular tree missed one section setting the allowable rates for the 5GHz band. This patch is needed to fix the regression reported in Bug #88811 (https://bugzilla.kernel.org/show_bug.cgi?id=88811). Reported-by: Valerio Passini <[email protected]> Tested-by: Valerio Passini <[email protected]> Signed-off-by: Larry Finger <[email protected]> Cc: Valerio Passini <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 43612d7c04f1a4f5e60104143918fcdf018b66ee Author: Pablo Neira <[email protected]> Date: Tue Nov 25 19:54:47 2014 +0100 Revert "netfilter: conntrack: fix race in __nf_conntrack_confirm against get_next_corpse" This reverts commit 5195c14c8b27cc0b18220ddbf0e5ad3328a04187. If the conntrack clashes with an existing one, it is left out of the unconfirmed list, thus, crashing when dropping the packet and releasing the conntrack since golden rule is that conntracks are always placed in any of the existing lists for traceability reasons. Reported-by: Daniel Borkmann <[email protected]> Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=88841 Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 3dc2b6a8d38cf6c7604ec25f3d50d6ec8da04435 Author: Alexander Duyck <[email protected]> Date: Mon Nov 24 20:08:38 2014 -0800 vxlan: Fix boolean flip in VXLAN_F_UDP_ZERO_CSUM6_[TX|RX] In "vxlan: Call udp_sock_create" there was a logic error that resulted in the default for IPv6 VXLAN tunnels going from using checksums to not using checksums. Since there is currently no support in iproute2 for setting these values it means that a kernel after the change cannot talk over a IPv6 VXLAN tunnel to a kernel prior the change. Fixes: 3ee64f3 ("vxlan: Call udp_sock_create") Cc: Tom Herbert <[email protected]> Signed-off-by: Alexander Duyck <[email protected]> Acked-by: Tom Herbert <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit f3750817a9034bd8cbb5ba583cd544e7cf14c7d8 Author: Alexander Duyck <[email protected]> Date: Mon Nov 24 20:08:32 2014 -0800 ip6_udp_tunnel: Fix checksum calculation The UDP checksum calculation for VXLAN tunnels is currently using the socket addresses instead of the actual packet source and destination addresses. As a result the checksum calculated is incorrect in some cases. Also uh->check was being set twice, first it was set to 0, and then it is set again in udp6_set_csum. This change removes the redundant assignment to 0. Fixes: acbf74a7 ("vxlan: Refactor vxlan driver to make use of the common UDP tunnel functions.") Cc: Andy Zhou <[email protected]> Signed-off-by: Alexander Duyck <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 18ca43823f3ce111c6efb8cc90d9f35246527727 Author: Amitkumar Karwar <[email protected]> Date: Tue Nov 25 06:43:06 2014 -0800 mwifiex: add Tx status support for ACTION frames ACK status (0/1) for ACTION frames is informed to cfg80211. We will extend existing logic used for EAPOL frames. The cfg80211 API is different here. Also, we need to explicitly free cloned skb. Signed-off-by: Cathy Luo <[email protected]> Signed-off-by: Avinash Patil <[email protected]> Signed-off-by: Amitkumar Karwar <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 808bbebcc8fcbcb2b93aefd8b181a0fdccb407c6 Author: Amitkumar Karwar <[email protected]> Date: Tue Nov 25 06:43:05 2014 -0800 mwifiex: add Tx status support for EAPOL packets Firmware notifies the driver through event if EAPOL data packet has been acked or not. We will inform this status to userspace listening on a socket. Signed-off-by: Cathy Luo <[email protected]> Signed-off-by: Avinash Patil <[email protected]> Signed-off-by: Amitkumar Karwar <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 381e9fffe6b8343c2479939178ef7ded50bf32d3 Author: Amitkumar Karwar <[email protected]> Date: Tue Nov 25 06:43:04 2014 -0800 mwifiex: skip delay main work logic for USB interface. We had introduced delay main work logic to avoid processing interrupts when Rx pending packet count reaches high threshold. interrupt processing is restarted later when packet count reduces lower threashold. This helped to reduce unnecessary overhead and improve throughput for SD and PCIe chipsets. As there are no interrupts for USB, we will skip this logic for USB chipsets. Signed-off-by: Cathy Luo <[email protected]> Signed-off-by: Avinash Patil <[email protected]> Signed-off-by: Amitkumar Karwar <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 798ea8eec16d33e0553b6be7175a23e8ddf60eee Author: Amitkumar Karwar <[email protected]> Date: Tue Nov 25 06:43:03 2014 -0800 mwifiex: fix scan problem on big endian platforms This patch adds missing endian conversion for beacon size while processing scan response. Reported-by: Daniel Mosquera <[email protected]> Tested-by: Daniel Mosquera <[email protected]> Signed-off-by: Avinash Patil <[email protected]> Signed-off-by: Amitkumar Karwar <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 51974611154038f1aaf6ce843bdc6445d5684ee3 Author: Amitkumar Karwar <[email protected]> Date: Tue Nov 25 06:43:02 2014 -0800 mwifiex: fix sparse warning This patch fixes following sparse warnings: drivers/net/wireless/mwifiex/util.c:152:19: warning: cast from restricted __le16 drivers/net/wireless/mwifiex/util.c:152:19: warning: restricted __le16 degrades to integer Signed-off-by: Amitkumar Karwar <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 8b537686a116b060475d94b6f548c78289935fef Author: Lorenzo Bianconi <[email protected]> Date: Tue Nov 25 00:21:41 2014 +0100 ath9k: add TPC capability to TX descriptor path Add TPC capability to TX descriptor path. Cap per-packet TX power according to TX power per-rate tables. Currently TPC is supported just by AR9003 based chips Signed-off-by: Lorenzo Bianconi <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 23f53dd3062628d2215cab810e4cfc22c29d47ee Author: Lorenzo Bianconi <[email protected]> Date: Tue Nov 25 00:21:40 2014 +0100 ath9k: add TX power per-rate tables Add TX power per-rate tables for different MIMO modes (e.g STBC) in order to cap the maximum TX power value per-rate in the TX descriptor path. Cap TX power for self generated frames (ACK, RTS/CTS). Currently TPC is supported just by AR9003 based chips Signed-off-by: Lorenzo Bianconi <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 4f3fff148679d5850994e53c57eb798cd201c88c Author: Arend van Spriel <[email protected]> Date: Thu Nov 20 22:27:02 2014 +0100 brcmfmac: correct .disconnect() callback while connecting When the driver has sent a join iovar to the firmware it waits for the events to report result of the connection. However, the wpa_supplicant will request a .disconnect() after a timeout. So upon calling .disconnect() the interface state may still be CONNECTING. Clear the CONNECTING bit as well. Reviewed-by: Hante Meuleman <[email protected]> Reviewed-by: Pieter-Paul Giesberts <[email protected]> Signed-off-by: Arend van Spriel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 3fedeab10b3bb09744a6467fe7cd157f055137c3 Author: Hariprasad Shenai <[email protected]> Date: Tue Nov 25 08:33:58 2014 +0530 cxgb4/cxgb4vf/csiostor: Add T4/T5 PCI ID Table Add a new file t4_pci_id_tbl.h that contains T4/T5 PCI ID Table so that for all drivers that uses T4/T5 PCI functions changes can be done in one place. checkpatch.pl script reports following error, which if tried to fix ends up in compilation error. ERROR: Macros with complex values should be enclosed in parentheses +#define CH_PCI_DEVICE_ID_TABLE_DEFINE_END \ + { 0, } \ + } WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? new file mode 100644 ERROR: Macros with complex values should be enclosed in parentheses +#define CH_PCI_ID_TABLE_FENTRY(devid) \ + CH_PCI_ID_TABLE_ENTRY((devid) | \ + ((CH_PCI_DEVICE_ID_FUNCTION) << 8)), \ + CH_PCI_ID_TABLE_ENTRY((devid) | \ + ((CH_PCI_DEVICE_ID_FUNCTION2) << 8)) ERROR: Macros with complex values should be enclosed in parentheses +#define CH_PCI_DEVICE_ID_TABLE_DEFINE_END { 0, } } ERROR: Macros with complex values should be enclosed in parentheses +#define CH_PCI_DEVICE_ID_TABLE_DEFINE_END { 0, } } Signed-off-by: Hariprasad Shenai <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 138a7f49270fde7547afe976a01cef2b9fbf3a0e Author: Andrew Lutomirski <[email protected]> Date: Mon Nov 24 12:02:29 2014 -0800 net-timestamp: Fix a documentation typo SOF_TIMESTAMPING_OPT_ID puts the id in ee_data, not ee_info. Cc: Willem de Bruijn <[email protected]> Signed-off-by: Andy Lutomirski <[email protected]> Acked-by: Willem de Bruijn <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit c2d00875c151087c41e23a5afd6bd807019c9a53 Author: Dmitry Monakhov <[email protected]> Date: Tue Nov 25 13:18:39 2014 -0500 ext4: fix potential use after free during resize We need some sort of synchronization while updating ->s_group_desc because there are a lot of users which can access old ->s_group_desc array after it was released. It is reasonable to use lightweight seqcount_t here instead of RCU. Signed-off-by: Dmitry Monakhov <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> commit d6d12b85f7daa15a02cabfc9026225b6e16d9aad Author: Dmitry Monakhov <[email protected]> Date: Tue Nov 25 13:08:04 2014 -0500 ext4: cleanup GFP flags inside resize path We must use GFP_NOFS instead GFP_KERNEL inside ext4_mb_add_groupinfo and ext4_calculate_overhead() because they are called from inside a journal transaction. Call trace: ioctl ->ext4_group_add ->journal_start ->ext4_setup_new_descs ->ext4_mb_add_groupinfo -> GFP_KERNEL ->ext4_flex_group_add ->ext4_update_super ->ext4_calculate_overhead -> GFP_KERNEL ->journal_stop Signed-off-by: Dmitry Monakhov <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> commit 2193dda5eec60373c7a061c129c6ab9d658f78e9 Author: Alan Stern <[email protected]> Date: Tue Nov 25 12:28:46 2014 +0100 USB: host: Remove ehci-octeon and ohci-octeon drivers Remove special-purpose octeon drivers and instead use ehci-platform and ohci-platform as suggested with http://marc.info/?l=linux-mips&m=140139694721623&w=2 [andreas.herrmann: fixed compile error] Cc: David Daney <[email protected]> Cc: Alex Smith <[email protected]> Signed-off-by: Alan Stern <[email protected]> Signed-off-by: Andreas Herrmann <[email protected]> Acked-by: Ralf Baechle <[email protected]> Tested-by: Aaro Koskinen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit f83b050b3c223278c4299d8736ffdafceb2c6c7c Author: Jan Kara <[email protected]> Date: Tue Nov 25 11:55:24 2014 -0500 ext4: introduce aging to extent status tree Introduce a simple aging to extent status tree. Each extent has a REFERENCED bit which gets set when the extent is used. Shrinker then skips entries with referenced bit set and clears the bit. Thus frequently used extents have higher chances of staying in memory. Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> commit ee4bb47d2bc8149b11e4d1dc2378730cb166d5a8 Author: Jan Kara <[email protected]> Date: Tue Nov 25 11:53:47 2014 -0500 ext4: cleanup flag definitions for extent status tree Currently flags for extent status tree are defined twice, once shifted and once without a being shifted. Consolidate these definitions into one place and make some computations automatic to make adding flags less error prone. Compiler should be clever enough to figure out these are constants and generate the same code. Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> commit 9915b75359e3cc99a4dd3b39f83f394395f8f1aa Author: Jan Kara <[email protected]> Date: Tue Nov 25 11:51:23 2014 -0500 ext4: limit number of scanned extents in status tree shrinker Currently we scan extent status trees of inodes until we reclaim nr_to_scan extents. This can however require a lot of scanning when there are lots of delayed extents (as those cannot be reclaimed). Change shrinker to work as shrinkers are supposed to and *scan* only nr_to_scan extents regardless of how many extents did we actually reclaim. We however need to be careful and avoid scanning each status tree from the beginning - that could lead to a situation where we would not be able to reclaim anything at all when first nr_to_scan extents in the tree are always unreclaimable. We remember with each inode offset where we stopped scanning and continue from there when we next come across the inode. Note that we also need to update places calling __es_shrink() manually to pass reasonable nr_to_scan to have a chance of reclaiming anything and not just 1. Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> commit 149f510220f5df2e3eada0dfc8a0b18208ffaf65 Author: Jan Kara <[email protected]> Date: Tue Nov 25 11:49:25 2014 -0500 ext4: move handling of list of shrinkable inodes into extent status code Currently callers adding extents to extent status tree were responsible for adding the inode to the list of inodes with freeable extents. This is error prone and puts list handling in unnecessarily many places. Just add inode to the list automatically when the first non-delay extent is added to the tree and remove inode from the list when the last non-delay extent is removed. Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> commit aaf3ce623d42e534492c19e3b314c800e8d97b84 Author: Zheng Liu <[email protected]> Date: Tue Nov 25 11:47:01 2014 -0500 ext4: change LRU to round-robin in extent status tree shrinker In this commit we discard the lru algorithm for inodes with extent status tree because it takes significant effort to maintain a lru list in extent status tree shrinker and the shrinker can take a long time to scan this lru list in order to reclaim some objects. We replace the lru ordering with a simple round-robin. After that we never need to keep a lru list. That means that the list needn't be sorted if the shrinker can not reclaim any objects in the first round. Cc: Andreas Dilger <[email protected]> Signed-off-by: Zheng Liu <[email protected]> Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> commit 036d4c3764f230f39fba5b2574a6c29b00a48bf9 Author: Zheng Liu <[email protected]> Date: Tue Nov 25 11:44:37 2014 -0500 ext4: cache extent hole in extent status tree for ext4_da_map_blocks() Currently extent status tree doesn't cache extent hole when a write looks up in extent tree to make sure whether a block has been allocated or not. In this case, we don't put extent hole in extent cache because later this extent might be removed and a new delayed extent might be added back. But it will cause a defect when we do a lot of writes. If we don't put extent hole in extent cache, the following writes also need to access extent tree to look at whether or not a block has been allocated. It brings a cache miss. This commit fixes this defect. Also if the inode doesn't have any extent, this extent hole will be cached as well. Cc: Andreas Dilger <[email protected]> Signed-off-by: Zheng Liu <[email protected]> Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> commit f3c08e9bdc8b51aa941aed2fedb4ab468ce7588e Author: Jan Kara <[email protected]> Date: Tue Nov 25 11:41:49 2014 -0500 ext4: fix block reservation for bigalloc filesystems For bigalloc filesystems we have to check whether newly requested inode block isn't already part of a cluster for which we already have delayed allocation reservation. This check happens in ext4_ext_map_blocks() and that function sets EXT4_MAP_FROM_CLUSTER if that's the case. However if ext4_da_map_blocks() finds in extent cache information about the block, we don't call into ext4_ext_map_blocks() and thus we always end up getting new reservation even if the space for cluster is already reserved. This results in overreservation and premature ENOSPC reports. Fix the problem by checking for existing cluster reservation already in ext4_da_map_blocks(). That simplifies the logic and actually allows us to get rid of the EXT4_MAP_FROM_CLUSTER flag completely. Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> commit 439b8bddaa1ebed9f9f8fb2f6f33f5e639d76ab8 Author: Dmitry Lavnikevich <[email protected]> Date: Fri Nov 21 18:29:07 2014 +0300 mfd: da9063: Get irq base dynamically before registering device After registering mfd device with proper irq_base platform_get_irq_byname() calls will return VIRQ instead of local IRQ. This fixes da9063 rtc registration issue: da9063-rtc da9063-rtc: Failed to request ALARM IRQ 1: -22 Signed-off-by: Dmitry Lavnikevich <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit 2c20f6de95afef89127163d16c88cd0456c48077 Author: Krzysztof Kozlowski <[email protected]> Date: Wed Nov 12 16:28:02 2014 +0100 mfd: max14577: Fix obvious typo in company name in copyright Fix a typo in name of company in copyright comment. Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit 0e50e92669357e4702fcd6a85e2f0d6e92295664 Author: Lee Jones <[email protected]> Date: Tue Nov 11 12:36:46 2014 +0000 mfd: axp20x: Constify axp20x_acpi_match and rid unused warning axp20x.c:239:30: warning: ‘axp20x_acpi_match’ defined but not used [-Wunused-variable] Signed-off-by: Lee Jones <[email protected]> commit 71d679b84ce8ca3207e547488f70c259575d2f2f Author: Dmitry Eremin-Solenikov <[email protected]> Date: Mon Nov 17 18:07:42 2014 +0300 mfd: t7l66xb: prepare/unprepare clocks Change clk_enable/disable() calls to clk_prepare_enable() and clk_disable_unprepare(). Signed-off-by: Dmitry Eremin-Solenikov <[email protected]> commit 7263bd39251e6926ca7fa5591679b26577fdaccb Author: Dmitry Eremin-Solenikov <[email protected]> Date: Mon Nov 17 18:07:43 2014 +0300 mfd: tc6387xb: prepare/unprepare clocks Change clk_enable/disable() calls to clk_prepare_enable() and clk_disable_unprepare(). Signed-off-by: Dmitry Eremin-Solenikov <[email protected]> commit 21cf3318d675b6ceeb5a3ed82ffe467a2b6eaee4 Author: Laurentiu Palcu <[email protected]> Date: Fri Nov 7 14:45:14 2014 +0200 mfd: dln2: add support for USB-SPI module Signed-off-by: Laurentiu Palcu <[email protected]> commit 783f6fc4cecd770dfdb1418c7c890dbeb3bf3c91 Author: Charles Keepax <[email protected]> Date: Tue Nov 4 13:04:07 2014 +0000 mfd: wm5110: Add missing registers for AIF2 channels 3-6 When the extra 4 channels were added to AIF2 the necessary frame control registers were not given defaults and marked readable. This patch fixes this. Signed-off-by: Charles Keepax <[email protected]> commit 90f2d0f7bf069b1a2798156b7dcc8e7d1e874406 Author: Linus Walleij <[email protected]> Date: Tue Oct 28 11:06:56 2014 +0100 mfd: tc3589x: get rid of static base The TC3589x driver is now a device tree-only driver, so we want only dynamic IRQs and GPIO numbers from the tc3589x, no static assignments. Signed-off-by: Linus Walleij <[email protected]> commit 47958c5ab4035bd91f05598f76a61cd9f7f2934c Author: Charles Keepax <[email protected]> Date: Tue Nov 4 15:24:36 2014 +0000 mfd: arizona: Document HP_CTRL_1L and HP_CTRL_1R registers These registers are documented in the datasheet and used as part of the extcon driver. Expose them properly through regmap as the datasheet notes they should be treated as volatile do so. Signed-off-by: Charles Keepax <[email protected]> commit e62cace7b602b29cc9226e64dfb2c47ddfb9558e Author: Charles Keepax <[email protected]> Date: Tue Nov 4 15:26:22 2014 +0000 mfd: wm8997: Mark INTERRUPT_STATUS_2_MASK as readable Technically this register is not used on wm8997 however the regmap core requires a continuous block of IRQs. The simplest solution is just to add the register. Signed-off-by: Charles Keepax <[email protected]> commit a64ab6b4cd098f6c2ea959fe9bf1fd3f8b13b1f3 Author: Dmitry Eremin-Solenikov <[email protected]> Date: Thu Nov 6 11:52:38 2014 +0300 mfd: tc6393xb: Prepare/unprepare clocks Change clk_enable/disable() calls to clk_prepare_enable() and clk_disable_unrepapre(). Signed-off-by: Dmitry Eremin-Solenikov <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit 12849b63a4e9e22fb63d0fc967726e8cdf2a19c2 Author: Lee Jones <[email protected]> Date: Mon Nov 10 12:28:36 2014 +0000 mfd: tps65090: Fix bonkers indenting strategy First spotted pointless (incorrect) indent of 'if (ret)', then double indentations of a struct attribute 'mask'. Decided to go through the whole file and make amendments instead and this is the result. Signed-off-by: Lee Jones <[email protected]> commit 1a5fb99de4850cba710d91becfa2c65653048589 Author: Dmitry Eremin-Solenikov <[email protected]> Date: Fri Oct 24 21:19:57 2014 +0400 mfd: tc6393xb: Fail ohci suspend if full state restore is required Some boards with TC6393XB chip require full state restore during system resume thanks to chip's VCC being cut off during suspend (Sharp SL-6000 tosa is one of them). Failing to do so would result in ohci Oops on resume due to internal memory contentes being changed. Fail ohci suspend on tc6393xb is full state restore is required. Recommended workaround is to unbind tmio-ohci driver before suspend and rebind it after resume. Cc: [email protected] Signed-off-by: Dmitry Eremin-Solenikov <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit bde3e706a63d5c258b3e4f5e327bcf032fb1adfe Author: Andy Shevchenko <[email protected]> Date: Mon Nov 3 19:29:23 2014 +0200 mfd: lpc_sch: Don't call mfd_remove_devices() MFD core already cares about failing registration. It will remove successfully registered devices in case of error. Thus, no need to repeatedly call mfd_remove_devices(). Fixes: 5829e9b64e65 (mfd: lpc_sch: Accomodate partial population of the MFD devices) Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit 1753b40f5c97e0d0bf2f0a562603cfc592945a5e Author: Joe Perches <[email protected]> Date: Sun Oct 26 22:25:02 2014 -0700 mfd: wm8350-core: Fix probable mask then right shift defect Precedence of & and >> is not the same and is not left to right. shift has higher precedence and should be done after the mask. Add parentheses around the mask. Signed-off-by: Joe Perches <[email protected]> Acked-by: Charles Keepax <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit 7d082baa349e59ce3de6452abc05e5de6436aad4 Author: Guenter Roeck <[email protected]> Date: Thu Oct 9 09:18:38 2014 -0700 mfd: ab8500-sysctrl: Drop ab8500_restart ab8500_restart is not called from anywhere in the kernel, so drop it. Signed-off-by: Guenter Roeck <[email protected]> Acked-by: Linus Walleij <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit 6bdf891a17148a1b91beb603b09c599dc98eb4fb Author: Lee Jones <[email protected]> Date: Mon Nov 3 16:12:26 2014 +0000 mfd: db8500-prcmu: Provide sane error path values Also rid superfluous gotos and label. Cc: Linus Walleij <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit 51a7e02bb629498c32915881ed4fb61ef778282a Author: Pramod Gurav <[email protected]> Date: Thu Oct 30 14:51:35 2014 +0530 mfd: db8500-prcmu: Check return of devm_ioremap for error Error check around return value of devm_ioremap is missing. Add the same to avoid NULL pointer dereference. Signed-off-by: Pramod Gurav <[email protected]> Acked-by: Linus Walleij <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit 1b9b46d05f887aec418b3a5f4f55abf79316fcda Author: Tony Lindgren <[email protected]> Date: Sun Nov 2 10:09:38 2014 -0800 mfd: twl4030-power: Fix regression with missing compatible flag Commit e7cd1d1eb16f ("mfd: twl4030-power: Add generic reset configuration") accidentally removed the compatible flag for "ti,twl4030-power" that should be there as documented in the binding. If "ti,twl4030-power" only the poweroff configuration is done by the driver. Fixes: e7cd1d1eb16f ("mfd: twl4030-power: Add generic reset configuration") Cc: [email protected] # v3.16+ Reported-by: "Dr. H. Nikolaus Schaller" <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit 5cb5d9616a47d5383a85379afa4429382ef46b38 Author: Micky Ching <[email protected]> Date: Fri Oct 10 13:58:44 2014 +0800 mfd: rtsx: Fix PM suspend for 5227 & 5249 Fix rts5227&5249 failed send buffer cmd after suspend, PM_CTRL3 should reset before send any buffer cmd after suspend. Otherwise, buffer cmd will failed, this will lead resume fail. Signed-off-by: Micky Ching <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit 130dd5b039dcbab7bcb2fdce0bb3cc7347b08b29 Author: Krzysztof Kozlowski <[email protected]> Date: Tue Oct 21 13:23:16 2014 +0200 mfd/regulator: dt-bindings: max77686: Document regulators off in suspend Add information which regulators can be disabled during system suspend. Suggested-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit 6ce286f182e22837a02a368eeb49a0057b2cd5f9 Author: Javier Martinez Canillas <[email protected]> Date: Mon Oct 20 23:05:50 2014 +0200 Revert "mfd: sec-core: Prepare regulators for suspend state to reduce power-consumption" This reverts commit b7cde7078d2344073c310aa65fc2b0a845d2cb5b ("mfd: sec-core: Prepare regulators for suspend state to reduce power-consumption") Commit b7cde7078d23 called regulator_suspend_prepare() to prepare the regulators for a suspend state. But it did from the device pm suspend handler while the regulator suspend prepare function iterates over all regulators and not only the one managed by this device so it doesn't seems to be correct to call it from within a device driver. It is better to call the regulator suspend prepare/finish functions from platform code instead so this patch reverts the mentioned commit. Suggested-by: Doug Anderson <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Chanwoo Choi <[email protected]> Reviewed-by: Doug Anderson <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit efa3ca414be9b930774b5c1a3190f735596f5115 Author: Krzysztof Kozlowski <[email protected]> Date: Mon Oct 20 14:34:46 2014 +0200 mfd: max77693: Map charger device to its own of_node Add a "maxim,max77693-charger" of_compatible to the mfd_cell so the MFD child device (the charger) will have its own of_node set. This will be used by the max77693 charger driver in next patches to obtain battery configuration from DTS. Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit 6f467e5f0cdc3c0304bfcabcbaf56970ddea3d52 Author: Will Sheppard <[email protected]> Date: Wed Oct 15 09:38:47 2014 +0100 mfd: arizona-spi: Add lines after declarations - checkpatch catch This was found whilst running checkpatch.pl on arizona-spi. WARNING: Missing a blank line after declarations + struct arizona *arizona = spi_get_drvdata(spi); + arizona_dev_exit(arizona); Signed-off-by: Will Sheppard <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit 6cbac55368324ec2a0e59e192c5b596d0f4569f7 Author: Krzysztof Kozlowski <[email protected]> Date: Fri Oct 10 10:23:53 2014 +0200 mfd: max77693: Remove unused define Remove old MAX77693_NUM_IRQ_MUIC_REGS define. Not used anywhere. Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit 590b7795b3dc293a36136a4321ba59da60e5853c Author: Boris Brezillon <[email protected]> Date: Mon Oct 6 15:48:44 2014 +0200 mfd: Add documentation for atmel-hlcdc DT bindings The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5 family or sama5d3 family) exposes 2 subdevices: - a display controller (controlled by a DRM driver) - a PWM chip This patch adds documentation for atmel-hlcdc DT bindings. Signed-off-by: Boris Brezillon <[email protected]> Tested-by: Anthony Harivel <[email protected]> Tested-by: Ludovic Desroches <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit 2c86e9fb7263dbca2c21a086090d32ba90129f7b Author: Boris Brezillon <[email protected]> Date: Mon Oct 6 15:48:43 2014 +0200 mfd: Add atmel-hlcdc driver The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5 family or sama5d3 family) exposes 2 subdevices: - a display controller (controlled by a DRM driver) - a PWM chip The MFD device provides a regmap and several clocks (those connected to this hardware block) to its subdevices. This way concurrent accesses to the iomem range are handled by the regmap framework, and each subdevice can safely access HLCDC registers. Signed-off-by: Boris Brezillon <[email protected]> Tested-by: Anthony Harivel <[email protected]> Tested-by: Ludovic Desroches <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit 6e3f62f0793ebff3f91076490ff0fbb107939701 Author: Johan Hovold <[email protected]> Date: Fri Sep 26 12:55:33 2014 +0200 mfd: core: Fix platform-device id generation Make sure to always honour multi-function devices registered with PLATFORM_DEVID_NONE (-1) or PLATFORM_DEVID_AUTO (-2) as id base. In this case it does not make sense to append the cell id to the mfd-id base and potentially change the requested behaviour. Specifically this will allow multi-function devices to be registered with PLATFORM_DEVID_AUTO while still having non-zero cell ids. Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit 16b5fe2966b8dc4a474d6618d382d26933d90b24 Author: Johan Hovold <[email protected]> Date: Fri Sep 26 12:55:32 2014 +0200 HID: hid-sensor-hub: Use mfd_add_hotplug_devices() helper Use mfd_add_hotplug_devices() helper to register the subdevices. Compile-only tested. Signed-off-by: Johan Hovold <[email protected]> Acked-by: Jiri Kosina <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit 1ab589c72ef66f5f281d658ab606e02d661031d8 Author: Johan Hovold <[email protected]> Date: Fri Sep 26 12:55:31 2014 +0200 mfd: Use mfd_add_hotplug_devices() helper Use mfd_add_hotplug_devices helper to register the subdevices. Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit bdb0066df96e74a4002125467ebe459feff1ebef Author: Pankaj Dubey <[email protected]> Date: Tue Sep 30 14:05:27 2014 +0530 mfd: syscon: Decouple syscon interface from platform devices Currently a syscon entity can be only registered directly through a platform device that binds to a dedicated syscon driver. However in certain use cases it is desirable to make a device used with another driver a syscon interface provider. For example, certain SoCs (e.g. Exynos) contain system controller blocks which perform various functions such as power domain control, CPU power management, low power mode control, but in addition contain certain IP integration glue, such as various signal masks, coprocessor power control, etc. In such case, there is a need to have a dedicated driver for such system controller but also share registers with other drivers. The latter is where the syscon interface is helpful. In case of DT based platforms, this patch decouples syscon object from syscon platform driver, and allows to create syscon objects first time when it is required by calling of syscon_regmap_lookup_by APIs and keep a list of such syscon objects along with syscon provider device_nodes and regmap handles. For non-DT based platforms, this patch keeps syscon platform driver structure so that syscon can be probed and such non-DT based drivers can use syscon_regmap_lookup_by_pdev API and access regmap handles. Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based, we can completely remove platform driver of syscon, and keep only helper functions to get regmap handles. Suggested-by: Arnd Bergmann <[email protected]> Suggested-by: Tomasz Figa <[email protected]> Tested-by: Vivek Gautam <[email protected]> Tested-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Pankaj Dubey <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit ee828d02611f325a70ef6a3c1fd2dd1eb3bc9704 Author: Jaewon Kim <[email protected]> Date: Thu Sep 18 01:40:26 2014 +0900 mfd: max77693: Update DT binding to support haptic This patch add haptic DT binding documentation and example to support haptic driver in max77693 Multifunction device. Signed-off-by: Jaewon Kim <[email protected]> Acked-by: Chanwoo Choi <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit d1bafd78fce5f07bfc9c2c8a77146f74528a469e Author: Jaewon Kim <[email protected]> Date: Thu Sep 18 01:40:25 2014 +0900 mfd: max77693: Add haptic of_compatible in mfd_cell This patch add haptic of_compatible in order to use the haptic device driver using Devicetree. Signed-off-by: Jaewon Kim <[email protected]> Acked-by: Chanwoo Choi <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit efbf49224acc8ba5ac4d7ac93b5035836aebf400 Author: Jaewon Kim <[email protected]> Date: Thu Sep 18 01:40:24 2014 +0900 mfd: max77693: Initialize haptic register map This patch add regmap_haptic initialization to use haptic register map in haptic device driver. Signed-off-by: Jaewon Kim <[email protected]> Acked-by: Chanwoo Choi <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit 11d0d30093301169833aedfc130d9e4abe621be1 Author: Johannes Pointner <[email protected]> Date: Thu Sep 25 08:31:42 2014 +0200 mfd: tps65217: Add compatible string for subdevices Adds of_compatible strings to mfd_cells for sub devices of the tps65217. Signed-off-by: Johannes Pointner <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit 65fa5f773196ccc88c4aae43ece9119f092c20a6 Author: Damien Lespiau <[email protected]> Date: Tue Nov 25 13:45:41 2014 +0000 drm/i915: Fix short description of intel_display_power_is_enabled() That's the version actually taking the dev_priv->power_domains lock. Signed-off-by: Damien Lespiau <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> commit 07c802bd7c3951410b105356787d655e273ab537 Author: Will Deacon <[email protected]> Date: Tue Nov 25 15:26:13 2014 +0000 arm64: vmlinux.lds.S: don't discard .exit.* sections at link-time .exit.* sections may be subject to patching by the new alternatives framework and so shouldn't be discarded at link-time. Without this patch, such a section will result in the following linker error: `.exit.text' referenced in section `.altinstructions' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o Signed-off-by: Will Deacon <[email protected]> commit af86e5974d3069bd26ebcf7c046c6e59726acaaa Author: Laura Abbott <[email protected]> Date: Fri Nov 21 21:50:42 2014 +0000 arm64: Factor out fixmap initialization from ioremap The fixmap API was originally added for arm64 for early_ioremap purposes. It can be used for other purposes too so move the initialization from ioremap to somewhere more generic. This makes it obvious where the fixmap is being set up and allows for a cleaner implementation of __set_fixmap. Reviewed-by: Kees Cook <[email protected]> Acked-by: Mark Rutland <[email protected]> Tested-by: Mark Rutland <[email protected]> Tested-by: Kees Cook <[email protected]> Signed-off-by: Laura Abbott <[email protected]> Signed-off-by: Will Deacon <[email protected]> commit c3684fbb446501b48dec6677a6a9f61c215053de Author: Laura Abbott <[email protected]> Date: Fri Nov 21 21:50:40 2014 +0000 arm64: Move cpu_resume into the text section The function cpu_resume currently lives in the .data section. There's no reason for it to be there since we can use relative instructions without a problem. Move a few cpu_resume data structures out of the assembly file so the .data annotation can be dropped completely and cpu_resume ends up in the read only text section. Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Mark Rutland <[email protected]> Reviewed-by: Lorenzo Pieralisi <[email protected]> Tested-by: Mark Rutland <[email protected]> Tested-by: Lorenzo Pieralisi <[email protected]> Tested-by: Kees Cook <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Laura Abbott <[email protected]> Signed-off-by: Will Deacon <[email protected]> commit ac2dec5f6c27a581f8571da605d9ba04df18330d Author: Laura Abbott <[email protected]> Date: Fri Nov 21 21:50:39 2014 +0000 arm64: Switch to adrp for loading the stub vectors The hyp stub vectors are currently loaded using adr. This instruction has a +/- 1MB range for the loading address. If the alignment for sections is changed the address may be more than 1MB away, resulting in reclocation errors. Switch to using adrp for getting the address to ensure we aren't affected by the location of the __hyp_stub_vectors. Acked-by: Ard Biesheuvel <[email protected]> Acked-by: Marc Zyngier <[email protected]> Tested-by: Mark Rutland <[email protected]> Tested-by: Kees Cook <[email protected]> Signed-off-by: Laura Abbott <[email protected]> Signed-off-by: Will Deacon <[email protected]> commit fcff588633e848aa728a4437ef96d437299ba03d Author: Laura Abbott <[email protected]> Date: Fri Nov 21 21:50:38 2014 +0000 arm64: Treat handle_arch_irq as a function pointer handle_arch_irq isn't actually text, it's just a function pointer. It doesn't need to be stored in the text section and doing so causes problesm if we ever want to make the kernel text read only. Declare handle_arch_irq as a proper function pointer stored in the data section. Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Mark Rutland <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Tested-by: Mark Rutland <[email protected]> Tested-by: Kees Cook <[email protected]> Signed-off-by: Laura Abbott <[email protected]> Signed-off-by: Will Deacon <[email protected]> commit 3eebdbe5fc7d64c7a6ef14cc5b8be518ffd563fa Author: Mark Rutland <[email protected]> Date: Tue Nov 25 13:27:43 2014 +0000 arm64: sanity checks: add ID_AA64DFR{0,1}_EL1 While we currently expect self-hosted debug support to be identical across CPUs, we don't currently sanity check this. This patch adds logging of the ID_AA64DFR{0,1}_EL1 values and associated sanity checking code. It's not clear to me whether we need to check PMUVer, TraceVer, and DebugVer, as we don't currently rely on these fields at all. Signed-off-by: Mark Rutland <[email protected]> Cc: Catalin Marinas <[email protected]> Acked-by: Will Deacon <[email protected]> Signed-off-by: Will Deacon <[email protected]> commit efdf4211d5b103535ae22972acadf57c9fc38b30 Author: Mark Rutland <[email protected]> Date: Tue Nov 25 13:27:42 2014 +0000 arm64: sanity checks: add missing newline to print A missing newline in the WARN_TAINT_ONCE string results in ugly and somewhat difficult to read output in the case of a sanity check failure, as the next print does not appear on a new line: Unsupported CPU feature variation.Modules linked in: This patch adds the missing newline, fixing the output formatting. Signed-off-by: Mark Rutland <[email protected]> Cc: Catalin Marinas <[email protected]> Acked-by: Will Deacon <[email protected]> Signed-off-by: Will Deacon <[email protected]> commit 9760270c36a4d2ac640ea6294f4f8634a8b27121 Author: Mark Rutland <[email protected]> Date: Tue Nov 25 13:27:41 2014 +0000 arm64: sanity checks: ignore ID_MMFR0.AuxReg It seems that Cortex-A53 r0p4 added support for AIFSR and ADFSR, and ID_MMFR0.AuxReg has been updated accordingly to report this fact. As Cortex-A53 could be paired with CPUs which do not implement these registers (e.g. all current revisions of Cortex-A57), this may trigger a sanity check failure at boot. The AuxReg value describes the availability of the ACTLR, AIFSR, and ADFSR registers, which are only of use to 32-bit guest OSs, and have IMPLEMENTATION DEFINED contents. Given the nature of these registers it is likely that KVM will need to trap accesses regardless of whether the CPUs are heterogeneous. This patch masks out the ID_MMFR0.AuxReg value from the sanity checks, preventing spurious warnings at boot time. Signed-off-by: Mark Rutland <[email protected]> Reported-by: Andre Przywara <[email protected]> Cc: Catalin Marinas <[email protected]> Acked-by: Will Deacon <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Peter Maydell <[email protected]> Signed-off-by: Will Deacon <[email protected]> commit 1cefdaea613bcd247b2235079fcbb0ca4687542d Author: Mark Brown <[email protected]> Date: Fri Nov 21 00:36:49 2014 +0000 arm64: topology: Fix handling of multi-level cluster MPIDR-based detection The only requirement the scheduler has on cluster IDs is that they must be unique. When enumerating the topology based on MPIDR information the kernel currently generates cluster IDs by using the first level of affinity above the core ID (either level one or two depending on if the core has multiple threads) however the ARMv8 architecture allows for up to three levels of affinity. This means that an ARMv8 system may contain cores which have MPIDRs identical other than affinity level three which with current code will cause us to report multiple cores with the same identification to the scheduler in violation of its uniqueness requirement. Ensure that we do not violate the scheduler requirements on systems that uses all the affinity levels by incorporating both affinity levels two and three into the cluser ID when the cores are not threaded. While no currently known hardware uses multi-level clusters it is better to program defensively, this will help ease bringup of systems that have them and will ensure that things like distribution install media do not need to be respun to replace kernels in order to deploy such systems. In the worst case the system will work but perform suboptimally until a kernel modified to handle the new topology better is installed, in the best case this will be an adequate description of such topologies for the scheduler to perform well. Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Will Deacon <[email protected]> commit c0a01b84b1fdbd98bff5bca5b201fe73fda7e9d9 Author: Andre Przywara <[email protected]> Date: Fri Nov 14 15:54:12 2014 +0000 arm64: protect alternatives workarounds with Kconfig options Not all of the errata we have workarounds for apply necessarily to all SoCs, so people compiling a kernel for one very specific SoC may not need to patch the kernel. Introduce a new submenu in the "Platform selection" menu to allow people to turn off certain bugs if they are not affected. By default all of them are enabled. Normal users or distribution kernels shouldn't bother to deselect any bugs here, since the alternatives framework will take care of patching them in only if needed. Signed-off-by: Andre Przywara <[email protected]> [will: moved kconfig menu under `Kernel Features'] Signed-off-by: Will Deacon <[email protected]> commit 5afaa1fc1b320cec48affa7e6949f2493f875c12 Author: Andre Przywara <[email protected]> Date: Fri Nov 14 15:54:11 2014 +0000 arm64: add Cortex-A57 erratum 832075 workaround The ARM erratum 832075 applies to certain revisions of Cortex-A57, one of the workarounds is to change device loads into using load-aquire semantics. This is achieved using the alternatives framework. Signed-off-by: Andre Przywara <[email protected]> Signed-off-by: Will Deacon <[email protected]> commit 301bcfac42897dbd1b0b3c1be49f24654a1bc49e Author: Andre Przywara <[email protected]> Date: Fri Nov 14 15:54:10 2014 +0000 arm64: add Cortex-A53 cache errata workaround The ARM errata 819472, 826319, 827319 and 824069 define the same workaround for these hardware issues in certain Cortex-A53 parts. Use the new alternatives framework and the CPU MIDR detection to patch "cache clean" into "cache clean and invalidate" instructions if an affected CPU is detected at runtime. Signed-off-by: Andre Przywara <[email protected]> [will: add __maybe_unused to squash gcc warning] Signed-off-by: Will Deacon <[email protected]> commit 159a5e920446aed12fe373ecc3c7b3dc667091ae Author: Chanwoo Choi <[email protected]> Date: Tue Nov 18 17:59:43 2014 +0900 mfd: s2mps11: Add binding documentation for Samsung S2MPS13 PMIC This patch adds the binding documentation for Samsung S2MPS13 PMIC which is similiar with existing S2MPS14 PMIC. S2MPS13 has the different number of regulators from S2MPS14 and RTC/Clock is the same with the S2MPS14. Signed-off-by: Chanwoo Choi <[email protected]> Acked-by: Sangbeom Kim <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit f928b53d749bac4514c2ed1ea4d553fa581578b5 Author: Chanwoo Choi <[email protected]> Date: Tue Nov 18 17:59:41 2014 +0900 clk: s2mps11: Add the support for S2MPS13 PMIC clock This patch adds the support for S2MPS13 PMIC clock which is same with existing S2MPS14 RTC IP. But, S2MPS13 uses all of clocks (32khz_{ap|bt|cp}). Signed-off-by: Chanwoo Choi <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Acked-by: Michael Turquette <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit 76b9840b24ae049b39f1b3cf0e49f21b7c41748f Author: Chanwoo Choi <[email protected]> Date: Tue Nov 18 17:59:40 2014 +0900 regulator: s2mps11: Add support S2MPS13 regulator device This patch adds S2MPS13 regulator device to existing S2MPS11 device driver. The S2MPS13 has just different number of regulators from S2MPS14. The S2MPS13 regulator device includes LDO[1-40] and BUCK[1-10]. Signed-off-by: Chanwoo Choi <[email protected]> Acked-by: Sangbeom Kim <[email protected]> Acked-by: Mark Brown <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit 3bc2ee91a470c52fb3979c23c12d43283455f10d Author: Chanwoo Choi <[email protected]> Date: Tue Nov 18 17:59:39 2014 +0900 mfd: sec-core: Add support for S2MPS13 device This patch adds the support for Samsung S2MPS13 PMIC device to the sec-core MFD driver. The S2MPS13 is very similar with existing S2MPS14 and includes PMIC/ RTC/CLOCK devices. Signed-off-by: Chanwoo Choi <[email protected]> Acked-by: Sangbeom Kim <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit ce79d54ae447d65117303ca9f61ffe9dcbc2465d Author: Pantelis Antoniou <[email protected]> Date: Tue Oct 28 22:36:05 2014 +0200 spi/of: Add OF notifier handler Add OF notifier handler needed for creating/destroying spi devices according to dynamic runtime changes in the DT live tree. This code is enabled when CONFIG_OF_DYNAMIC is selected. Signed-off-by: Pantelis Antoniou <[email protected]> Signed-off-by: Grant Likely <[email protected]> Reviewed-by: Mark Brown <[email protected]> Cc: <[email protected]> commit aff5e3f89a0b07e7edf9243f913378cc27e4110d Author: Pantelis Antoniou <[email protected]> Date: Wed Oct 29 10:40:37 2014 +0200 spi/of: Create new device registration method and accessors Dynamically inserting spi device nodes requires the use of a single device registration method. Refactor the existing of_register_spi_devices() to split out the core functionality for a single device into a separate function; of_register_spi_device(). This function will be used by the OF_DYNAMIC overlay code to make live modifications to the tree. Methods to lookup a device/master using a device node are added as well, of_find_spi_master_by_node() & of_find_spi_device_by_node(). Signed-off-by: Pantelis Antoniou <[email protected]> [grant.likely] Split patch into two pieces for clarity Signed-off-by: Grant Likely <[email protected]> Reviewed-by: Mark Brown <[email protected]> Cc: <[email protected]> commit ea7513bbc04170f1cbf42953187a4d8b731c71c4 Author: Pantelis Antoniou <[email protected]> Date: Tue Oct 28 22:36:03 2014 +0200 i2c/of: Add OF_RECONFIG notifier handler CONFIG_OF_DYNAMIC enables runtime changes to the device tree which in turn may trigger addition or removal of devices from Linux. Add an OF_RECONFIG notifier handler to receive tree change events and to creating or destroy i2c devices as required. Signed-off-by: Pantelis Antoniou <[email protected]> [grant.likely: clean up #ifdefs and drop unneeded error handling] Signed-off-by: Grant Likely <[email protected]> Reviewed-by: Wolfram Sang <[email protected]> Cc: Rob Herring <[email protected]> Cc: [email protected] commit a430a3455f2c48995e06b359a82a1109a419e9ef Author: Pantelis Antoniou <[email protected]> Date: Tue Oct 28 22:36:02 2014 +0200 i2c/of: Factor out Devicetree registration code Dynamically inserting i2c client device nodes requires the use of a single device registration method. Factor out the loop body of of_i2c_register_devices() so that it can be called for individual device_nodes instead of for all the children of a node. Note: The diff of this commit looks far more complicated than it actually is due the indentation being changed for a large block of code. When viewed using the diff -w flag to ignore whitespace changes it can be seen that the change is actually quite simple. Signed-off-by: Pantelis Antoniou <[email protected]> [grant.likely: Made new function static and removed changes to header] Signed-off-by: Grant Likely <[email protected]> Reviewed-by: Wolfram Sang <[email protected]> Cc: Rob Herring <[email protected]> Cc: [email protected] commit ebf3992061db1f7b3aa093f37fb308acc74fbc82 Author: Tony Lindgren <[email protected]> Date: Mon Nov 24 11:05:06 2014 -0800 usb: musb: Use IS_ENABLED for tusb6010 This removes the ifdef clutter a bit and saves few lines. It also makes it easier to detect the remaining places where we have conditional building of code done based on if defined for things like DMA. Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Felipe Balbi <[email protected]> commit 82c02f58ba3a1ee0a067c0f90513e826d6152ba6 Author: Tony Lindgren <[email protected]> Date: Mon Nov 24 11:05:05 2014 -0800 usb: musb: Allow multiple glue layers to be built in There's no reason any longer to keep it as a choice now that the IO access has been fixed. Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Felipe Balbi <[email protected]> commit 8a77f05aa39be879535f22a9757e703581fa1392 Author: Tony Lindgren <[email protected]> Date: Mon Nov 24 11:05:04 2014 -0800 usb: musb: Pass fifo_mode in platform data This allows setting the correct fifo_mode when multiple MUSB glue layers are built-in. Cc: Fabio Baltieri <[email protected]> Cc: Lee Jones <[email protected]> Cc: Linus Walleij <[email protected]> Cc: Lars-Peter Clausen <[email protected]> Acked-by: Apelete Seketeli <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Felipe Balbi <[email protected]> commit d026e9c76aac3632af174cf02d5c94defa5e6026 Author: Tony Lindgren <[email protected]> Date: Mon Nov 24 11:05:03 2014 -0800 usb: musb: Change end point selection to use new IO access This allows the endpoints to work when multiple MUSB glue layers are built in. Cc: Fabio Baltieri <[email protected]> Cc: Lee Jones <[email protected]> Cc: Lars-Peter Clausen <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Apelete Seketeli <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Felipe Balbi <[email protected]> commit 1b40fc57a517878cf4c2e16ce29cc9a066dc1064 Author: Tony Lindgren <[email protected]> Date: Mon Nov 24 11:05:02 2014 -0800 usb: musb: Change to use new IO access Change to use new IO access. This allows us to build in multiple …
tobetter
pushed a commit
to tobetter/linux
that referenced
this pull request
May 12, 2015
exynos: asv: Correct a typo in voltage tables
laodzu
pushed a commit
to laodzu/linux
that referenced
this pull request
May 22, 2015
BUG: sleeping function called from invalid context at kernel/workqueue.c:2752 in_atomic(): 1, irqs_disabled(): 1, pid: 360, name: zfcperp0.0.1700 CPU: 1 Not tainted 3.9.3+ torvalds#69 Process zfcperp0.0.1700 (pid: 360, task: 0000000075b7e080, ksp: 000000007476bc30) <snip> Call Trace: ([<00000000001165de>] show_trace+0x106/0x154) [<00000000001166a0>] show_stack+0x74/0xf4 [<00000000006ff646>] dump_stack+0xc6/0xd4 [<000000000017f3a0>] __might_sleep+0x128/0x148 [<000000000015ece8>] flush_work+0x54/0x1f8 [<00000000001630de>] __cancel_work_timer+0xc6/0x128 [<00000000005067ac>] scsi_device_dev_release_usercontext+0x164/0x23c [<0000000000161816>] execute_in_process_context+0x96/0xa8 [<00000000004d33d8>] device_release+0x60/0xc0 [<000000000048af48>] kobject_release+0xa8/0x1c4 [<00000000004f4bf2>] __scsi_iterate_devices+0xfa/0x130 [<000003ff801b307a>] zfcp_erp_strategy+0x4da/0x1014 [zfcp] [<000003ff801b3caa>] zfcp_erp_thread+0xf6/0x2b0 [zfcp] [<000000000016b75a>] kthread+0xf2/0xfc [<000000000070c9de>] kernel_thread_starter+0x6/0xc [<000000000070c9d8>] kernel_thread_starter+0x0/0xc Apparently, the ref_count for some scsi_device drops down to zero, triggering device removal through execute_in_process_context(), while the lldd error recovery thread iterates through a scsi device list. Unfortunately, execute_in_process_context() decides to immediately execute that device removal function, instead of scheduling asynchronous execution, since it detects process context and thinks it is safe to do so. But almost all calls to shost_for_each_device() in our lldd are inside spin_lock_irq, even in thread context. Obviously, schedule() inside spin_lock_irq sections is a bad idea. Change the lldd to use the proper iterator function, __shost_for_each_device(), in combination with required locking. Occurences that need to be changed include all calls in zfcp_erp.c, since those might be executed in zfcp error recovery thread context with a lock held. Other occurences of shost_for_each_device() in zfcp_fsf.c do not need to be changed (no process context, no surrounding locking). The problem was introduced in Linux 2.6.37 by commit b62a8d9 "[SCSI] zfcp: Use SCSI device data zfcp_scsi_dev instead of zfcp_unit". Reported-by: Christian Borntraeger <[email protected]> Signed-off-by: Martin Peschke <[email protected]> Cc: [email protected] #2.6.37+ Signed-off-by: Steffen Maier <[email protected]> Signed-off-by: James Bottomley <[email protected]>
hzhuang1
pushed a commit
to hzhuang1/linux
that referenced
this pull request
May 22, 2015
Add LED triggers for bluetooth activity on both receive and transmit
jdpanderson
pushed a commit
to jdpanderson/linux
that referenced
this pull request
Oct 8, 2023
The drm_exec tests where crashing[0] because of a null dereference. This is caused by a new access of the `driver` attribute of `struct drm_driver` on drm_gem_private_object_init(). Alloc the drm_device to fix that. [0] [15:05:24] ================== drm_exec (6 subtests) =================== [15:05:24] [PASSED] sanitycheck ^CERROR:root:Build interruption occurred. Cleaning console. [15:05:50] [ERROR] Test: drm_exec: missing expected subtest! [15:05:50] BUG: kernel NULL pointer dereference, address: 00000000000000b0 [15:05:50] #PF: supervisor read access in kernel mode [15:05:50] #PF: error_code(0x0000) - not-present page [15:05:50] PGD 0 P4D 0 [15:05:50] Oops: 0000 [#1] PREEMPT NOPTI [15:05:50] CPU: 0 PID: 23 Comm: kunit_try_catch Tainted: G N 6.4.0-rc7-02032-ge6303f323b1a torvalds#69 [15:05:50] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc37 04/01/2014 [15:05:50] RIP: 0010:drm_gem_private_object_init+0x60/0xc0 Fixes: e6303f3 ("drm: manager to keep track of GPUs VA mappings") Signed-off-by: Arthur Grillo <[email protected]> Tested-by: Danilo Krummrich <[email protected]> Acked-by: Danilo Krummrich <[email protected]> Reviewed-by: Maíra Canal <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
gyroninja
added a commit
to gyroninja/linux
that referenced
this pull request
Jan 28, 2024
KSAN calls into rcu code which then triggers a write that reenters into KSAN getting the system stuck doing infinite recursion. #0 kmsan_get_context () at mm/kmsan/kmsan.h:106 #1 __msan_get_context_state () at mm/kmsan/instrumentation.c:331 #2 0xffffffff81495671 in get_current () at ./arch/x86/include/asm/current.h:42 #3 rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 #4 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 #5 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#6 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#7 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#8 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#9 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#10 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#11 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#12 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#13 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#14 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#15 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#16 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#17 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#18 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#19 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#20 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#21 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#22 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#23 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#24 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#25 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#26 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#27 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#28 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#29 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#30 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#31 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#32 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#33 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#34 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#35 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#36 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#37 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#38 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#39 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#40 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#41 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#42 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#43 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#44 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#45 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#46 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#47 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#48 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#49 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#50 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#51 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 #52 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 #53 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#54 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#55 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#56 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#57 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 #58 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#59 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#60 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#61 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#62 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#63 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#64 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#65 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#66 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#67 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#68 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#69 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 #70 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#71 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#72 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#73 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#74 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#75 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#76 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#77 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff86203c90) at ./arch/x86/include/asm/kmsan.h:82 torvalds#78 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff86203c90) at mm/kmsan/shadow.c:75 torvalds#79 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff86203c90, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#80 kmsan_get_shadow_origin_ptr (address=0xffffffff86203c90, size=8, store=false) at mm/kmsan/shadow.c:97 torvalds#81 0xffffffff81b1dc72 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=8, store=false) at mm/kmsan/instrumentation.c:36 torvalds#82 __msan_metadata_ptr_for_load_8 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:92 torvalds#83 0xffffffff814fdb9e in filter_irq_stacks (entries=<optimized out>, nr_entries=4) at kernel/stacktrace.c:397 torvalds#84 0xffffffff829520e8 in stack_depot_save_flags (entries=0xffffffff8620d974 <init_task+1012>, nr_entries=4, alloc_flags=0, depot_flags=0) at lib/stackdepot.c:500 torvalds#85 0xffffffff81b1e560 in __msan_poison_alloca (address=0xffffffff86203da0, size=24, descr=<optimized out>) at mm/kmsan/instrumentation.c:285 torvalds#86 0xffffffff8562821c in _printk (fmt=0xffffffff85f191a5 "\0016Attempting lock1") at kernel/printk/printk.c:2324 torvalds#87 0xffffffff81942aa2 in kmem_cache_create_usercopy (name=0xffffffff85f18903 "mm_struct", size=1296, align=0, flags=270336, useroffset=<optimized out>, usersize=<optimized out>, ctor=0x0 <fixed_percpu_data>) at mm/slab_common.c:296 torvalds#88 0xffffffff86f337a0 in mm_cache_init () at kernel/fork.c:3262 torvalds#89 0xffffffff86eacb8e in start_kernel () at init/main.c:932 torvalds#90 0xffffffff86ecdf94 in x86_64_start_reservations (real_mode_data=0x140e0 <exception_stacks+28896> <error: Cannot access memory at address 0x140e0>) at arch/x86/kernel/head64.c:555 torvalds#91 0xffffffff86ecde9b in x86_64_start_kernel (real_mode_data=0x140e0 <exception_stacks+28896> <error: Cannot access memory at address 0x140e0>) at arch/x86/kernel/head64.c:536 torvalds#92 0xffffffff810001d3 in secondary_startup_64 () at /pool/workspace/linux/arch/x86/kernel/head_64.S:461 torvalds#93 0x0000000000000000 in ??
gyroninja
added a commit
to gyroninja/linux
that referenced
this pull request
Jan 28, 2024
As of 5ec8e8e(mm/sparsemem: fix race in accessing memory_section->usage) KMSAN now calls into RCU tree code during kmsan_get_metadata. This will trigger a write that will reenter into KMSAN getting the system stuck doing infinite recursion. #0 kmsan_get_context () at mm/kmsan/kmsan.h:106 #1 __msan_get_context_state () at mm/kmsan/instrumentation.c:331 #2 0xffffffff81495671 in get_current () at ./arch/x86/include/asm/current.h:42 #3 rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 #4 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 #5 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#6 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#7 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#8 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#9 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#10 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#11 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#12 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#13 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#14 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#15 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#16 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#17 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#18 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#19 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#20 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#21 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#22 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#23 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#24 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#25 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#26 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#27 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#28 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#29 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#30 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#31 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#32 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#33 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#34 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#35 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#36 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#37 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#38 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#39 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#40 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#41 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#42 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#43 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#44 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#45 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#46 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#47 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#48 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#49 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#50 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#51 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 #52 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 #53 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#54 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#55 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#56 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#57 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 #58 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#59 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#60 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#61 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#62 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#63 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#64 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#65 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#66 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#67 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#68 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#69 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 #70 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#71 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#72 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#73 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#74 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#75 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#76 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#77 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff86203c90) at ./arch/x86/include/asm/kmsan.h:82 torvalds#78 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff86203c90) at mm/kmsan/shadow.c:75 torvalds#79 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff86203c90, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#80 kmsan_get_shadow_origin_ptr (address=0xffffffff86203c90, size=8, store=false) at mm/kmsan/shadow.c:97 torvalds#81 0xffffffff81b1dc72 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=8, store=false) at mm/kmsan/instrumentation.c:36 torvalds#82 __msan_metadata_ptr_for_load_8 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:92 torvalds#83 0xffffffff814fdb9e in filter_irq_stacks (entries=<optimized out>, nr_entries=4) at kernel/stacktrace.c:397 torvalds#84 0xffffffff829520e8 in stack_depot_save_flags (entries=0xffffffff8620d974 <init_task+1012>, nr_entries=4, alloc_flags=0, depot_flags=0) at lib/stackdepot.c:500 torvalds#85 0xffffffff81b1e560 in __msan_poison_alloca (address=0xffffffff86203da0, size=24, descr=<optimized out>) at mm/kmsan/instrumentation.c:285 torvalds#86 0xffffffff8562821c in _printk (fmt=0xffffffff85f191a5 "\0016Attempting lock1") at kernel/printk/printk.c:2324 torvalds#87 0xffffffff81942aa2 in kmem_cache_create_usercopy (name=0xffffffff85f18903 "mm_struct", size=1296, align=0, flags=270336, useroffset=<optimized out>, usersize=<optimized out>, ctor=0x0 <fixed_percpu_data>) at mm/slab_common.c:296 torvalds#88 0xffffffff86f337a0 in mm_cache_init () at kernel/fork.c:3262 torvalds#89 0xffffffff86eacb8e in start_kernel () at init/main.c:932 torvalds#90 0xffffffff86ecdf94 in x86_64_start_reservations (real_mode_data=0x140e0 <exception_stacks+28896> <error: Cannot access memory at address 0x140e0>) at arch/x86/kernel/head64.c:555 torvalds#91 0xffffffff86ecde9b in x86_64_start_kernel (real_mode_data=0x140e0 <exception_stacks+28896> <error: Cannot access memory at address 0x140e0>) at arch/x86/kernel/head64.c:536 torvalds#92 0xffffffff810001d3 in secondary_startup_64 () at /pool/workspace/linux/arch/x86/kernel/head_64.S:461 torvalds#93 0x0000000000000000 in ??
torvalds
pushed a commit
that referenced
this pull request
Mar 11, 2024
Commit 3fcb9d1 ("io_uring/sqpoll: statistics of the true utilization of sq threads"), currently in Jens for-next branch, peeks at io_sq_data->thread to report utilization statistics. But, If io_uring_show_fdinfo races with sqpoll terminating, even though we hold the ctx lock, sqd->thread might be NULL and we hit the Oops below. Note that we could technically just protect the getrusage() call and the sq total/work time calculations. But showing some sq information (pid/cpu) and not other information (utilization) is more confusing than not reporting anything, IMO. So let's hide it all if we happen to race with a dying sqpoll. This can be triggered consistently in my vm setup running sqpoll-cancel-hang.t in a loop. BUG: kernel NULL pointer dereference, address: 00000000000007b0 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 16587 Comm: systemd-coredum Not tainted 6.8.0-rc3-g3fcb9d17206e-dirty #69 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022 RIP: 0010:getrusage+0x21/0x3e0 Code: 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 d1 48 89 e5 41 57 41 56 41 55 41 54 49 89 fe 41 52 53 48 89 d3 48 83 ec 30 <4c> 8b a7 b0 07 00 00 48 8d 7a 08 65 48 8b 04 25 28 00 00 00 48 89 RSP: 0018:ffffa166c671bb80 EFLAGS: 00010282 RAX: 00000000000040ca RBX: ffffa166c671bc60 RCX: ffffa166c671bc60 RDX: ffffa166c671bc60 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffa166c671bbe0 R08: ffff9448cc3930c0 R09: 0000000000000000 R10: ffffa166c671bd50 R11: ffffffff9ee89260 R12: 0000000000000000 R13: ffff9448ce099480 R14: 0000000000000000 R15: ffff9448cff5b000 FS: 00007f786e225900(0000) GS:ffff94493bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000007b0 CR3: 000000010d39c000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? __die_body+0x1a/0x60 ? page_fault_oops+0x154/0x440 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_user_addr_fault+0x174/0x7c0 ? srso_alias_return_thunk+0x5/0xfbef5 ? exc_page_fault+0x63/0x140 ? asm_exc_page_fault+0x22/0x30 ? getrusage+0x21/0x3e0 ? seq_printf+0x4e/0x70 io_uring_show_fdinfo+0x9db/0xa10 ? srso_alias_return_thunk+0x5/0xfbef5 ? vsnprintf+0x101/0x4d0 ? srso_alias_return_thunk+0x5/0xfbef5 ? seq_vprintf+0x34/0x50 ? srso_alias_return_thunk+0x5/0xfbef5 ? seq_printf+0x4e/0x70 ? seq_show+0x16b/0x1d0 ? __pfx_io_uring_show_fdinfo+0x10/0x10 seq_show+0x16b/0x1d0 seq_read_iter+0xd7/0x440 seq_read+0x102/0x140 vfs_read+0xae/0x320 ? srso_alias_return_thunk+0x5/0xfbef5 ? __do_sys_newfstat+0x35/0x60 ksys_read+0xa5/0xe0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7f786ec1db4d Code: e8 46 e3 01 00 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 80 3d d9 ce 0e 00 00 74 17 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5b c3 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec RSP: 002b:00007ffcb361a4b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 000055a4c8fe42f0 RCX: 00007f786ec1db4d RDX: 0000000000000400 RSI: 000055a4c8fe48a0 RDI: 0000000000000006 RBP: 00007f786ecfb0b0 R08: 00007f786ecfb2a8 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f786ecfaf60 R13: 000055a4c8fe42f0 R14: 0000000000000000 R15: 00007ffcb361a628 </TASK> Modules linked in: CR2: 00000000000007b0 ---[ end trace 0000000000000000 ]--- RIP: 0010:getrusage+0x21/0x3e0 Code: 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 d1 48 89 e5 41 57 41 56 41 55 41 54 49 89 fe 41 52 53 48 89 d3 48 83 ec 30 <4c> 8b a7 b0 07 00 00 48 8d 7a 08 65 48 8b 04 25 28 00 00 00 48 89 RSP: 0018:ffffa166c671bb80 EFLAGS: 00010282 RAX: 00000000000040ca RBX: ffffa166c671bc60 RCX: ffffa166c671bc60 RDX: ffffa166c671bc60 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffa166c671bbe0 R08: ffff9448cc3930c0 R09: 0000000000000000 R10: ffffa166c671bd50 R11: ffffffff9ee89260 R12: 0000000000000000 R13: ffff9448ce099480 R14: 0000000000000000 R15: ffff9448cff5b000 FS: 00007f786e225900(0000) GS:ffff94493bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000007b0 CR3: 000000010d39c000 CR4: 0000000000750ef0 PKRU: 55555554 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x1ce00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Fixes: 3fcb9d1 ("io_uring/sqpoll: statistics of the true utilization of sq threads") Signed-off-by: Gabriel Krisman Bertazi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Jun 6, 2024
Alexei reported that send_signal test may fail with nested CONFIG_PARAVIRT configs. In this particular case, the base VM is AMD with 166 cpus, and I run selftests with regular qemu on top of that and indeed send_signal test failed. I also tried with an Intel box with 80 cpus and there is no issue. The main qemu command line includes: -enable-kvm -smp 16 -cpu host The failure log looks like: $ ./test_progs -t send_signal [ 48.501588] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [test_progs:2225] [ 48.503622] Modules linked in: bpf_testmod(O) [ 48.503622] CPU: 9 PID: 2225 Comm: test_progs Tainted: G O 6.9.0-08561-g2c1713a8f1c9-dirty torvalds#69 [ 48.507629] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 [ 48.511635] RIP: 0010:handle_softirqs+0x71/0x290 [ 48.511635] Code: [...] 10 0a 00 00 00 31 c0 65 66 89 05 d5 f4 fa 7e fb bb ff ff ff ff <49> c7 c2 cb [ 48.518527] RSP: 0018:ffffc90000310fa0 EFLAGS: 00000246 [ 48.519579] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 00000000000006e0 [ 48.522526] RDX: 0000000000000006 RSI: ffff88810791ae80 RDI: 0000000000000000 [ 48.523587] RBP: ffffc90000fabc88 R08: 00000005a0af4f7f R09: 0000000000000000 [ 48.525525] R10: 0000000561d2f29c R11: 0000000000006534 R12: 0000000000000280 [ 48.528525] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 48.528525] FS: 00007f2f2885cd00(0000) GS:ffff888237c40000(0000) knlGS:0000000000000000 [ 48.531600] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 48.535520] CR2: 00007f2f287059f0 CR3: 0000000106a28002 CR4: 00000000003706f0 [ 48.537538] Call Trace: [ 48.537538] <IRQ> [ 48.537538] ? watchdog_timer_fn+0x1cd/0x250 [ 48.539590] ? lockup_detector_update_enable+0x50/0x50 [ 48.539590] ? __hrtimer_run_queues+0xff/0x280 [ 48.542520] ? hrtimer_interrupt+0x103/0x230 [ 48.544524] ? __sysvec_apic_timer_interrupt+0x4f/0x140 [ 48.545522] ? sysvec_apic_timer_interrupt+0x3a/0x90 [ 48.547612] ? asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.547612] ? handle_softirqs+0x71/0x290 [ 48.547612] irq_exit_rcu+0x63/0x80 [ 48.551585] sysvec_apic_timer_interrupt+0x75/0x90 [ 48.552521] </IRQ> [ 48.553529] <TASK> [ 48.553529] asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.555609] RIP: 0010:finish_task_switch.isra.0+0x90/0x260 [ 48.556526] Code: [...] 9f 58 0a 00 00 48 85 db 0f 85 89 01 00 00 4c 89 ff e8 53 d9 bd 00 fb 66 90 <4d> 85 ed 74 [ 48.562524] RSP: 0018:ffffc90000fabd38 EFLAGS: 00000282 [ 48.563589] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83385620 [ 48.563589] RDX: ffff888237c73ae4 RSI: 0000000000000000 RDI: ffff888237c6fd00 [ 48.568521] RBP: ffffc90000fabd68 R08: 0000000000000000 R09: 0000000000000000 [ 48.569528] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8881009d0000 [ 48.573525] R13: ffff8881024e5400 R14: ffff88810791ae80 R15: ffff888237c6fd00 [ 48.575614] ? finish_task_switch.isra.0+0x8d/0x260 [ 48.576523] __schedule+0x364/0xac0 [ 48.577535] schedule+0x2e/0x110 [ 48.578555] pipe_read+0x301/0x400 [ 48.579589] ? destroy_sched_domains_rcu+0x30/0x30 [ 48.579589] vfs_read+0x2b3/0x2f0 [ 48.579589] ksys_read+0x8b/0xc0 [ 48.583590] do_syscall_64+0x3d/0xc0 [ 48.583590] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 48.586525] RIP: 0033:0x7f2f28703fa1 [ 48.587592] Code: [...] 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 80 3d c5 23 14 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 [ 48.593534] RSP: 002b:00007ffd90f8cf88 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 48.595589] RAX: ffffffffffffffda RBX: 00007ffd90f8d5e8 RCX: 00007f2f28703fa1 [ 48.595589] RDX: 0000000000000001 RSI: 00007ffd90f8cfb0 RDI: 0000000000000006 [ 48.599592] RBP: 00007ffd90f8d2f0 R08: 0000000000000064 R09: 0000000000000000 [ 48.602527] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 48.603589] R13: 00007ffd90f8d608 R14: 00007f2f288d8000 R15: 0000000000f6bdb0 [ 48.605527] </TASK> In the test, two processes are communicating through pipe. Further debugging with strace found that the above splat is triggered as read() syscall could not receive the data even if the corresponding write() syscall in another process successfully wrote data into the pipe. The failed subtest is "send_signal_perf". The corresponding perf event has sample_period 1 and config PERF_COUNT_SW_CPU_CLOCK. sample_period 1 means every overflow event will trigger a call to the BPF program. So I suspect this may overwhelm the system. So I increased the sample_period to 100,000 and the test passed. The sample_period 10,000 still has the test failed. In other parts of selftest, e.g., [1], sample_freq is used instead. So I decided to use sample_freq = 1,000 since the test can pass as well. [1] https://lore.kernel.org/bpf/[email protected]/ Reported-by: Alexei Starovoitov <[email protected]> Signed-off-by: Yonghong Song <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Aug 12, 2024
[ Upstream commit 7015843 ] Alexei reported that send_signal test may fail with nested CONFIG_PARAVIRT configs. In this particular case, the base VM is AMD with 166 cpus, and I run selftests with regular qemu on top of that and indeed send_signal test failed. I also tried with an Intel box with 80 cpus and there is no issue. The main qemu command line includes: -enable-kvm -smp 16 -cpu host The failure log looks like: $ ./test_progs -t send_signal [ 48.501588] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [test_progs:2225] [ 48.503622] Modules linked in: bpf_testmod(O) [ 48.503622] CPU: 9 PID: 2225 Comm: test_progs Tainted: G O 6.9.0-08561-g2c1713a8f1c9-dirty torvalds#69 [ 48.507629] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 [ 48.511635] RIP: 0010:handle_softirqs+0x71/0x290 [ 48.511635] Code: [...] 10 0a 00 00 00 31 c0 65 66 89 05 d5 f4 fa 7e fb bb ff ff ff ff <49> c7 c2 cb [ 48.518527] RSP: 0018:ffffc90000310fa0 EFLAGS: 00000246 [ 48.519579] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 00000000000006e0 [ 48.522526] RDX: 0000000000000006 RSI: ffff88810791ae80 RDI: 0000000000000000 [ 48.523587] RBP: ffffc90000fabc88 R08: 00000005a0af4f7f R09: 0000000000000000 [ 48.525525] R10: 0000000561d2f29c R11: 0000000000006534 R12: 0000000000000280 [ 48.528525] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 48.528525] FS: 00007f2f2885cd00(0000) GS:ffff888237c40000(0000) knlGS:0000000000000000 [ 48.531600] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 48.535520] CR2: 00007f2f287059f0 CR3: 0000000106a28002 CR4: 00000000003706f0 [ 48.537538] Call Trace: [ 48.537538] <IRQ> [ 48.537538] ? watchdog_timer_fn+0x1cd/0x250 [ 48.539590] ? lockup_detector_update_enable+0x50/0x50 [ 48.539590] ? __hrtimer_run_queues+0xff/0x280 [ 48.542520] ? hrtimer_interrupt+0x103/0x230 [ 48.544524] ? __sysvec_apic_timer_interrupt+0x4f/0x140 [ 48.545522] ? sysvec_apic_timer_interrupt+0x3a/0x90 [ 48.547612] ? asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.547612] ? handle_softirqs+0x71/0x290 [ 48.547612] irq_exit_rcu+0x63/0x80 [ 48.551585] sysvec_apic_timer_interrupt+0x75/0x90 [ 48.552521] </IRQ> [ 48.553529] <TASK> [ 48.553529] asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.555609] RIP: 0010:finish_task_switch.isra.0+0x90/0x260 [ 48.556526] Code: [...] 9f 58 0a 00 00 48 85 db 0f 85 89 01 00 00 4c 89 ff e8 53 d9 bd 00 fb 66 90 <4d> 85 ed 74 [ 48.562524] RSP: 0018:ffffc90000fabd38 EFLAGS: 00000282 [ 48.563589] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83385620 [ 48.563589] RDX: ffff888237c73ae4 RSI: 0000000000000000 RDI: ffff888237c6fd00 [ 48.568521] RBP: ffffc90000fabd68 R08: 0000000000000000 R09: 0000000000000000 [ 48.569528] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8881009d0000 [ 48.573525] R13: ffff8881024e5400 R14: ffff88810791ae80 R15: ffff888237c6fd00 [ 48.575614] ? finish_task_switch.isra.0+0x8d/0x260 [ 48.576523] __schedule+0x364/0xac0 [ 48.577535] schedule+0x2e/0x110 [ 48.578555] pipe_read+0x301/0x400 [ 48.579589] ? destroy_sched_domains_rcu+0x30/0x30 [ 48.579589] vfs_read+0x2b3/0x2f0 [ 48.579589] ksys_read+0x8b/0xc0 [ 48.583590] do_syscall_64+0x3d/0xc0 [ 48.583590] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 48.586525] RIP: 0033:0x7f2f28703fa1 [ 48.587592] Code: [...] 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 80 3d c5 23 14 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 [ 48.593534] RSP: 002b:00007ffd90f8cf88 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 48.595589] RAX: ffffffffffffffda RBX: 00007ffd90f8d5e8 RCX: 00007f2f28703fa1 [ 48.595589] RDX: 0000000000000001 RSI: 00007ffd90f8cfb0 RDI: 0000000000000006 [ 48.599592] RBP: 00007ffd90f8d2f0 R08: 0000000000000064 R09: 0000000000000000 [ 48.602527] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 48.603589] R13: 00007ffd90f8d608 R14: 00007f2f288d8000 R15: 0000000000f6bdb0 [ 48.605527] </TASK> In the test, two processes are communicating through pipe. Further debugging with strace found that the above splat is triggered as read() syscall could not receive the data even if the corresponding write() syscall in another process successfully wrote data into the pipe. The failed subtest is "send_signal_perf". The corresponding perf event has sample_period 1 and config PERF_COUNT_SW_CPU_CLOCK. sample_period 1 means every overflow event will trigger a call to the BPF program. So I suspect this may overwhelm the system. So I increased the sample_period to 100,000 and the test passed. The sample_period 10,000 still has the test failed. In other parts of selftest, e.g., [1], sample_freq is used instead. So I decided to use sample_freq = 1,000 since the test can pass as well. [1] https://lore.kernel.org/bpf/[email protected]/ Reported-by: Alexei Starovoitov <[email protected]> Signed-off-by: Yonghong Song <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Aug 12, 2024
[ Upstream commit 7015843 ] Alexei reported that send_signal test may fail with nested CONFIG_PARAVIRT configs. In this particular case, the base VM is AMD with 166 cpus, and I run selftests with regular qemu on top of that and indeed send_signal test failed. I also tried with an Intel box with 80 cpus and there is no issue. The main qemu command line includes: -enable-kvm -smp 16 -cpu host The failure log looks like: $ ./test_progs -t send_signal [ 48.501588] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [test_progs:2225] [ 48.503622] Modules linked in: bpf_testmod(O) [ 48.503622] CPU: 9 PID: 2225 Comm: test_progs Tainted: G O 6.9.0-08561-g2c1713a8f1c9-dirty torvalds#69 [ 48.507629] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 [ 48.511635] RIP: 0010:handle_softirqs+0x71/0x290 [ 48.511635] Code: [...] 10 0a 00 00 00 31 c0 65 66 89 05 d5 f4 fa 7e fb bb ff ff ff ff <49> c7 c2 cb [ 48.518527] RSP: 0018:ffffc90000310fa0 EFLAGS: 00000246 [ 48.519579] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 00000000000006e0 [ 48.522526] RDX: 0000000000000006 RSI: ffff88810791ae80 RDI: 0000000000000000 [ 48.523587] RBP: ffffc90000fabc88 R08: 00000005a0af4f7f R09: 0000000000000000 [ 48.525525] R10: 0000000561d2f29c R11: 0000000000006534 R12: 0000000000000280 [ 48.528525] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 48.528525] FS: 00007f2f2885cd00(0000) GS:ffff888237c40000(0000) knlGS:0000000000000000 [ 48.531600] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 48.535520] CR2: 00007f2f287059f0 CR3: 0000000106a28002 CR4: 00000000003706f0 [ 48.537538] Call Trace: [ 48.537538] <IRQ> [ 48.537538] ? watchdog_timer_fn+0x1cd/0x250 [ 48.539590] ? lockup_detector_update_enable+0x50/0x50 [ 48.539590] ? __hrtimer_run_queues+0xff/0x280 [ 48.542520] ? hrtimer_interrupt+0x103/0x230 [ 48.544524] ? __sysvec_apic_timer_interrupt+0x4f/0x140 [ 48.545522] ? sysvec_apic_timer_interrupt+0x3a/0x90 [ 48.547612] ? asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.547612] ? handle_softirqs+0x71/0x290 [ 48.547612] irq_exit_rcu+0x63/0x80 [ 48.551585] sysvec_apic_timer_interrupt+0x75/0x90 [ 48.552521] </IRQ> [ 48.553529] <TASK> [ 48.553529] asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.555609] RIP: 0010:finish_task_switch.isra.0+0x90/0x260 [ 48.556526] Code: [...] 9f 58 0a 00 00 48 85 db 0f 85 89 01 00 00 4c 89 ff e8 53 d9 bd 00 fb 66 90 <4d> 85 ed 74 [ 48.562524] RSP: 0018:ffffc90000fabd38 EFLAGS: 00000282 [ 48.563589] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83385620 [ 48.563589] RDX: ffff888237c73ae4 RSI: 0000000000000000 RDI: ffff888237c6fd00 [ 48.568521] RBP: ffffc90000fabd68 R08: 0000000000000000 R09: 0000000000000000 [ 48.569528] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8881009d0000 [ 48.573525] R13: ffff8881024e5400 R14: ffff88810791ae80 R15: ffff888237c6fd00 [ 48.575614] ? finish_task_switch.isra.0+0x8d/0x260 [ 48.576523] __schedule+0x364/0xac0 [ 48.577535] schedule+0x2e/0x110 [ 48.578555] pipe_read+0x301/0x400 [ 48.579589] ? destroy_sched_domains_rcu+0x30/0x30 [ 48.579589] vfs_read+0x2b3/0x2f0 [ 48.579589] ksys_read+0x8b/0xc0 [ 48.583590] do_syscall_64+0x3d/0xc0 [ 48.583590] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 48.586525] RIP: 0033:0x7f2f28703fa1 [ 48.587592] Code: [...] 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 80 3d c5 23 14 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 [ 48.593534] RSP: 002b:00007ffd90f8cf88 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 48.595589] RAX: ffffffffffffffda RBX: 00007ffd90f8d5e8 RCX: 00007f2f28703fa1 [ 48.595589] RDX: 0000000000000001 RSI: 00007ffd90f8cfb0 RDI: 0000000000000006 [ 48.599592] RBP: 00007ffd90f8d2f0 R08: 0000000000000064 R09: 0000000000000000 [ 48.602527] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 48.603589] R13: 00007ffd90f8d608 R14: 00007f2f288d8000 R15: 0000000000f6bdb0 [ 48.605527] </TASK> In the test, two processes are communicating through pipe. Further debugging with strace found that the above splat is triggered as read() syscall could not receive the data even if the corresponding write() syscall in another process successfully wrote data into the pipe. The failed subtest is "send_signal_perf". The corresponding perf event has sample_period 1 and config PERF_COUNT_SW_CPU_CLOCK. sample_period 1 means every overflow event will trigger a call to the BPF program. So I suspect this may overwhelm the system. So I increased the sample_period to 100,000 and the test passed. The sample_period 10,000 still has the test failed. In other parts of selftest, e.g., [1], sample_freq is used instead. So I decided to use sample_freq = 1,000 since the test can pass as well. [1] https://lore.kernel.org/bpf/[email protected]/ Reported-by: Alexei Starovoitov <[email protected]> Signed-off-by: Yonghong Song <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Aug 12, 2024
[ Upstream commit 7015843 ] Alexei reported that send_signal test may fail with nested CONFIG_PARAVIRT configs. In this particular case, the base VM is AMD with 166 cpus, and I run selftests with regular qemu on top of that and indeed send_signal test failed. I also tried with an Intel box with 80 cpus and there is no issue. The main qemu command line includes: -enable-kvm -smp 16 -cpu host The failure log looks like: $ ./test_progs -t send_signal [ 48.501588] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [test_progs:2225] [ 48.503622] Modules linked in: bpf_testmod(O) [ 48.503622] CPU: 9 PID: 2225 Comm: test_progs Tainted: G O 6.9.0-08561-g2c1713a8f1c9-dirty torvalds#69 [ 48.507629] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 [ 48.511635] RIP: 0010:handle_softirqs+0x71/0x290 [ 48.511635] Code: [...] 10 0a 00 00 00 31 c0 65 66 89 05 d5 f4 fa 7e fb bb ff ff ff ff <49> c7 c2 cb [ 48.518527] RSP: 0018:ffffc90000310fa0 EFLAGS: 00000246 [ 48.519579] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 00000000000006e0 [ 48.522526] RDX: 0000000000000006 RSI: ffff88810791ae80 RDI: 0000000000000000 [ 48.523587] RBP: ffffc90000fabc88 R08: 00000005a0af4f7f R09: 0000000000000000 [ 48.525525] R10: 0000000561d2f29c R11: 0000000000006534 R12: 0000000000000280 [ 48.528525] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 48.528525] FS: 00007f2f2885cd00(0000) GS:ffff888237c40000(0000) knlGS:0000000000000000 [ 48.531600] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 48.535520] CR2: 00007f2f287059f0 CR3: 0000000106a28002 CR4: 00000000003706f0 [ 48.537538] Call Trace: [ 48.537538] <IRQ> [ 48.537538] ? watchdog_timer_fn+0x1cd/0x250 [ 48.539590] ? lockup_detector_update_enable+0x50/0x50 [ 48.539590] ? __hrtimer_run_queues+0xff/0x280 [ 48.542520] ? hrtimer_interrupt+0x103/0x230 [ 48.544524] ? __sysvec_apic_timer_interrupt+0x4f/0x140 [ 48.545522] ? sysvec_apic_timer_interrupt+0x3a/0x90 [ 48.547612] ? asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.547612] ? handle_softirqs+0x71/0x290 [ 48.547612] irq_exit_rcu+0x63/0x80 [ 48.551585] sysvec_apic_timer_interrupt+0x75/0x90 [ 48.552521] </IRQ> [ 48.553529] <TASK> [ 48.553529] asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.555609] RIP: 0010:finish_task_switch.isra.0+0x90/0x260 [ 48.556526] Code: [...] 9f 58 0a 00 00 48 85 db 0f 85 89 01 00 00 4c 89 ff e8 53 d9 bd 00 fb 66 90 <4d> 85 ed 74 [ 48.562524] RSP: 0018:ffffc90000fabd38 EFLAGS: 00000282 [ 48.563589] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83385620 [ 48.563589] RDX: ffff888237c73ae4 RSI: 0000000000000000 RDI: ffff888237c6fd00 [ 48.568521] RBP: ffffc90000fabd68 R08: 0000000000000000 R09: 0000000000000000 [ 48.569528] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8881009d0000 [ 48.573525] R13: ffff8881024e5400 R14: ffff88810791ae80 R15: ffff888237c6fd00 [ 48.575614] ? finish_task_switch.isra.0+0x8d/0x260 [ 48.576523] __schedule+0x364/0xac0 [ 48.577535] schedule+0x2e/0x110 [ 48.578555] pipe_read+0x301/0x400 [ 48.579589] ? destroy_sched_domains_rcu+0x30/0x30 [ 48.579589] vfs_read+0x2b3/0x2f0 [ 48.579589] ksys_read+0x8b/0xc0 [ 48.583590] do_syscall_64+0x3d/0xc0 [ 48.583590] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 48.586525] RIP: 0033:0x7f2f28703fa1 [ 48.587592] Code: [...] 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 80 3d c5 23 14 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 [ 48.593534] RSP: 002b:00007ffd90f8cf88 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 48.595589] RAX: ffffffffffffffda RBX: 00007ffd90f8d5e8 RCX: 00007f2f28703fa1 [ 48.595589] RDX: 0000000000000001 RSI: 00007ffd90f8cfb0 RDI: 0000000000000006 [ 48.599592] RBP: 00007ffd90f8d2f0 R08: 0000000000000064 R09: 0000000000000000 [ 48.602527] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 48.603589] R13: 00007ffd90f8d608 R14: 00007f2f288d8000 R15: 0000000000f6bdb0 [ 48.605527] </TASK> In the test, two processes are communicating through pipe. Further debugging with strace found that the above splat is triggered as read() syscall could not receive the data even if the corresponding write() syscall in another process successfully wrote data into the pipe. The failed subtest is "send_signal_perf". The corresponding perf event has sample_period 1 and config PERF_COUNT_SW_CPU_CLOCK. sample_period 1 means every overflow event will trigger a call to the BPF program. So I suspect this may overwhelm the system. So I increased the sample_period to 100,000 and the test passed. The sample_period 10,000 still has the test failed. In other parts of selftest, e.g., [1], sample_freq is used instead. So I decided to use sample_freq = 1,000 since the test can pass as well. [1] https://lore.kernel.org/bpf/[email protected]/ Reported-by: Alexei Starovoitov <[email protected]> Signed-off-by: Yonghong Song <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Aug 12, 2024
[ Upstream commit 7015843 ] Alexei reported that send_signal test may fail with nested CONFIG_PARAVIRT configs. In this particular case, the base VM is AMD with 166 cpus, and I run selftests with regular qemu on top of that and indeed send_signal test failed. I also tried with an Intel box with 80 cpus and there is no issue. The main qemu command line includes: -enable-kvm -smp 16 -cpu host The failure log looks like: $ ./test_progs -t send_signal [ 48.501588] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [test_progs:2225] [ 48.503622] Modules linked in: bpf_testmod(O) [ 48.503622] CPU: 9 PID: 2225 Comm: test_progs Tainted: G O 6.9.0-08561-g2c1713a8f1c9-dirty torvalds#69 [ 48.507629] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 [ 48.511635] RIP: 0010:handle_softirqs+0x71/0x290 [ 48.511635] Code: [...] 10 0a 00 00 00 31 c0 65 66 89 05 d5 f4 fa 7e fb bb ff ff ff ff <49> c7 c2 cb [ 48.518527] RSP: 0018:ffffc90000310fa0 EFLAGS: 00000246 [ 48.519579] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 00000000000006e0 [ 48.522526] RDX: 0000000000000006 RSI: ffff88810791ae80 RDI: 0000000000000000 [ 48.523587] RBP: ffffc90000fabc88 R08: 00000005a0af4f7f R09: 0000000000000000 [ 48.525525] R10: 0000000561d2f29c R11: 0000000000006534 R12: 0000000000000280 [ 48.528525] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 48.528525] FS: 00007f2f2885cd00(0000) GS:ffff888237c40000(0000) knlGS:0000000000000000 [ 48.531600] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 48.535520] CR2: 00007f2f287059f0 CR3: 0000000106a28002 CR4: 00000000003706f0 [ 48.537538] Call Trace: [ 48.537538] <IRQ> [ 48.537538] ? watchdog_timer_fn+0x1cd/0x250 [ 48.539590] ? lockup_detector_update_enable+0x50/0x50 [ 48.539590] ? __hrtimer_run_queues+0xff/0x280 [ 48.542520] ? hrtimer_interrupt+0x103/0x230 [ 48.544524] ? __sysvec_apic_timer_interrupt+0x4f/0x140 [ 48.545522] ? sysvec_apic_timer_interrupt+0x3a/0x90 [ 48.547612] ? asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.547612] ? handle_softirqs+0x71/0x290 [ 48.547612] irq_exit_rcu+0x63/0x80 [ 48.551585] sysvec_apic_timer_interrupt+0x75/0x90 [ 48.552521] </IRQ> [ 48.553529] <TASK> [ 48.553529] asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.555609] RIP: 0010:finish_task_switch.isra.0+0x90/0x260 [ 48.556526] Code: [...] 9f 58 0a 00 00 48 85 db 0f 85 89 01 00 00 4c 89 ff e8 53 d9 bd 00 fb 66 90 <4d> 85 ed 74 [ 48.562524] RSP: 0018:ffffc90000fabd38 EFLAGS: 00000282 [ 48.563589] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83385620 [ 48.563589] RDX: ffff888237c73ae4 RSI: 0000000000000000 RDI: ffff888237c6fd00 [ 48.568521] RBP: ffffc90000fabd68 R08: 0000000000000000 R09: 0000000000000000 [ 48.569528] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8881009d0000 [ 48.573525] R13: ffff8881024e5400 R14: ffff88810791ae80 R15: ffff888237c6fd00 [ 48.575614] ? finish_task_switch.isra.0+0x8d/0x260 [ 48.576523] __schedule+0x364/0xac0 [ 48.577535] schedule+0x2e/0x110 [ 48.578555] pipe_read+0x301/0x400 [ 48.579589] ? destroy_sched_domains_rcu+0x30/0x30 [ 48.579589] vfs_read+0x2b3/0x2f0 [ 48.579589] ksys_read+0x8b/0xc0 [ 48.583590] do_syscall_64+0x3d/0xc0 [ 48.583590] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 48.586525] RIP: 0033:0x7f2f28703fa1 [ 48.587592] Code: [...] 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 80 3d c5 23 14 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 [ 48.593534] RSP: 002b:00007ffd90f8cf88 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 48.595589] RAX: ffffffffffffffda RBX: 00007ffd90f8d5e8 RCX: 00007f2f28703fa1 [ 48.595589] RDX: 0000000000000001 RSI: 00007ffd90f8cfb0 RDI: 0000000000000006 [ 48.599592] RBP: 00007ffd90f8d2f0 R08: 0000000000000064 R09: 0000000000000000 [ 48.602527] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 48.603589] R13: 00007ffd90f8d608 R14: 00007f2f288d8000 R15: 0000000000f6bdb0 [ 48.605527] </TASK> In the test, two processes are communicating through pipe. Further debugging with strace found that the above splat is triggered as read() syscall could not receive the data even if the corresponding write() syscall in another process successfully wrote data into the pipe. The failed subtest is "send_signal_perf". The corresponding perf event has sample_period 1 and config PERF_COUNT_SW_CPU_CLOCK. sample_period 1 means every overflow event will trigger a call to the BPF program. So I suspect this may overwhelm the system. So I increased the sample_period to 100,000 and the test passed. The sample_period 10,000 still has the test failed. In other parts of selftest, e.g., [1], sample_freq is used instead. So I decided to use sample_freq = 1,000 since the test can pass as well. [1] https://lore.kernel.org/bpf/[email protected]/ Reported-by: Alexei Starovoitov <[email protected]> Signed-off-by: Yonghong Song <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Aug 13, 2024
[ Upstream commit 7015843 ] Alexei reported that send_signal test may fail with nested CONFIG_PARAVIRT configs. In this particular case, the base VM is AMD with 166 cpus, and I run selftests with regular qemu on top of that and indeed send_signal test failed. I also tried with an Intel box with 80 cpus and there is no issue. The main qemu command line includes: -enable-kvm -smp 16 -cpu host The failure log looks like: $ ./test_progs -t send_signal [ 48.501588] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [test_progs:2225] [ 48.503622] Modules linked in: bpf_testmod(O) [ 48.503622] CPU: 9 PID: 2225 Comm: test_progs Tainted: G O 6.9.0-08561-g2c1713a8f1c9-dirty torvalds#69 [ 48.507629] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 [ 48.511635] RIP: 0010:handle_softirqs+0x71/0x290 [ 48.511635] Code: [...] 10 0a 00 00 00 31 c0 65 66 89 05 d5 f4 fa 7e fb bb ff ff ff ff <49> c7 c2 cb [ 48.518527] RSP: 0018:ffffc90000310fa0 EFLAGS: 00000246 [ 48.519579] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 00000000000006e0 [ 48.522526] RDX: 0000000000000006 RSI: ffff88810791ae80 RDI: 0000000000000000 [ 48.523587] RBP: ffffc90000fabc88 R08: 00000005a0af4f7f R09: 0000000000000000 [ 48.525525] R10: 0000000561d2f29c R11: 0000000000006534 R12: 0000000000000280 [ 48.528525] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 48.528525] FS: 00007f2f2885cd00(0000) GS:ffff888237c40000(0000) knlGS:0000000000000000 [ 48.531600] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 48.535520] CR2: 00007f2f287059f0 CR3: 0000000106a28002 CR4: 00000000003706f0 [ 48.537538] Call Trace: [ 48.537538] <IRQ> [ 48.537538] ? watchdog_timer_fn+0x1cd/0x250 [ 48.539590] ? lockup_detector_update_enable+0x50/0x50 [ 48.539590] ? __hrtimer_run_queues+0xff/0x280 [ 48.542520] ? hrtimer_interrupt+0x103/0x230 [ 48.544524] ? __sysvec_apic_timer_interrupt+0x4f/0x140 [ 48.545522] ? sysvec_apic_timer_interrupt+0x3a/0x90 [ 48.547612] ? asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.547612] ? handle_softirqs+0x71/0x290 [ 48.547612] irq_exit_rcu+0x63/0x80 [ 48.551585] sysvec_apic_timer_interrupt+0x75/0x90 [ 48.552521] </IRQ> [ 48.553529] <TASK> [ 48.553529] asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.555609] RIP: 0010:finish_task_switch.isra.0+0x90/0x260 [ 48.556526] Code: [...] 9f 58 0a 00 00 48 85 db 0f 85 89 01 00 00 4c 89 ff e8 53 d9 bd 00 fb 66 90 <4d> 85 ed 74 [ 48.562524] RSP: 0018:ffffc90000fabd38 EFLAGS: 00000282 [ 48.563589] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83385620 [ 48.563589] RDX: ffff888237c73ae4 RSI: 0000000000000000 RDI: ffff888237c6fd00 [ 48.568521] RBP: ffffc90000fabd68 R08: 0000000000000000 R09: 0000000000000000 [ 48.569528] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8881009d0000 [ 48.573525] R13: ffff8881024e5400 R14: ffff88810791ae80 R15: ffff888237c6fd00 [ 48.575614] ? finish_task_switch.isra.0+0x8d/0x260 [ 48.576523] __schedule+0x364/0xac0 [ 48.577535] schedule+0x2e/0x110 [ 48.578555] pipe_read+0x301/0x400 [ 48.579589] ? destroy_sched_domains_rcu+0x30/0x30 [ 48.579589] vfs_read+0x2b3/0x2f0 [ 48.579589] ksys_read+0x8b/0xc0 [ 48.583590] do_syscall_64+0x3d/0xc0 [ 48.583590] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 48.586525] RIP: 0033:0x7f2f28703fa1 [ 48.587592] Code: [...] 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 80 3d c5 23 14 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 [ 48.593534] RSP: 002b:00007ffd90f8cf88 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 48.595589] RAX: ffffffffffffffda RBX: 00007ffd90f8d5e8 RCX: 00007f2f28703fa1 [ 48.595589] RDX: 0000000000000001 RSI: 00007ffd90f8cfb0 RDI: 0000000000000006 [ 48.599592] RBP: 00007ffd90f8d2f0 R08: 0000000000000064 R09: 0000000000000000 [ 48.602527] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 48.603589] R13: 00007ffd90f8d608 R14: 00007f2f288d8000 R15: 0000000000f6bdb0 [ 48.605527] </TASK> In the test, two processes are communicating through pipe. Further debugging with strace found that the above splat is triggered as read() syscall could not receive the data even if the corresponding write() syscall in another process successfully wrote data into the pipe. The failed subtest is "send_signal_perf". The corresponding perf event has sample_period 1 and config PERF_COUNT_SW_CPU_CLOCK. sample_period 1 means every overflow event will trigger a call to the BPF program. So I suspect this may overwhelm the system. So I increased the sample_period to 100,000 and the test passed. The sample_period 10,000 still has the test failed. In other parts of selftest, e.g., [1], sample_freq is used instead. So I decided to use sample_freq = 1,000 since the test can pass as well. [1] https://lore.kernel.org/bpf/[email protected]/ Reported-by: Alexei Starovoitov <[email protected]> Signed-off-by: Yonghong Song <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Kaz205
pushed a commit
to Kaz205/linux
that referenced
this pull request
Aug 14, 2024
[ Upstream commit 7015843 ] Alexei reported that send_signal test may fail with nested CONFIG_PARAVIRT configs. In this particular case, the base VM is AMD with 166 cpus, and I run selftests with regular qemu on top of that and indeed send_signal test failed. I also tried with an Intel box with 80 cpus and there is no issue. The main qemu command line includes: -enable-kvm -smp 16 -cpu host The failure log looks like: $ ./test_progs -t send_signal [ 48.501588] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [test_progs:2225] [ 48.503622] Modules linked in: bpf_testmod(O) [ 48.503622] CPU: 9 PID: 2225 Comm: test_progs Tainted: G O 6.9.0-08561-g2c1713a8f1c9-dirty torvalds#69 [ 48.507629] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 [ 48.511635] RIP: 0010:handle_softirqs+0x71/0x290 [ 48.511635] Code: [...] 10 0a 00 00 00 31 c0 65 66 89 05 d5 f4 fa 7e fb bb ff ff ff ff <49> c7 c2 cb [ 48.518527] RSP: 0018:ffffc90000310fa0 EFLAGS: 00000246 [ 48.519579] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 00000000000006e0 [ 48.522526] RDX: 0000000000000006 RSI: ffff88810791ae80 RDI: 0000000000000000 [ 48.523587] RBP: ffffc90000fabc88 R08: 00000005a0af4f7f R09: 0000000000000000 [ 48.525525] R10: 0000000561d2f29c R11: 0000000000006534 R12: 0000000000000280 [ 48.528525] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 48.528525] FS: 00007f2f2885cd00(0000) GS:ffff888237c40000(0000) knlGS:0000000000000000 [ 48.531600] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 48.535520] CR2: 00007f2f287059f0 CR3: 0000000106a28002 CR4: 00000000003706f0 [ 48.537538] Call Trace: [ 48.537538] <IRQ> [ 48.537538] ? watchdog_timer_fn+0x1cd/0x250 [ 48.539590] ? lockup_detector_update_enable+0x50/0x50 [ 48.539590] ? __hrtimer_run_queues+0xff/0x280 [ 48.542520] ? hrtimer_interrupt+0x103/0x230 [ 48.544524] ? __sysvec_apic_timer_interrupt+0x4f/0x140 [ 48.545522] ? sysvec_apic_timer_interrupt+0x3a/0x90 [ 48.547612] ? asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.547612] ? handle_softirqs+0x71/0x290 [ 48.547612] irq_exit_rcu+0x63/0x80 [ 48.551585] sysvec_apic_timer_interrupt+0x75/0x90 [ 48.552521] </IRQ> [ 48.553529] <TASK> [ 48.553529] asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.555609] RIP: 0010:finish_task_switch.isra.0+0x90/0x260 [ 48.556526] Code: [...] 9f 58 0a 00 00 48 85 db 0f 85 89 01 00 00 4c 89 ff e8 53 d9 bd 00 fb 66 90 <4d> 85 ed 74 [ 48.562524] RSP: 0018:ffffc90000fabd38 EFLAGS: 00000282 [ 48.563589] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83385620 [ 48.563589] RDX: ffff888237c73ae4 RSI: 0000000000000000 RDI: ffff888237c6fd00 [ 48.568521] RBP: ffffc90000fabd68 R08: 0000000000000000 R09: 0000000000000000 [ 48.569528] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8881009d0000 [ 48.573525] R13: ffff8881024e5400 R14: ffff88810791ae80 R15: ffff888237c6fd00 [ 48.575614] ? finish_task_switch.isra.0+0x8d/0x260 [ 48.576523] __schedule+0x364/0xac0 [ 48.577535] schedule+0x2e/0x110 [ 48.578555] pipe_read+0x301/0x400 [ 48.579589] ? destroy_sched_domains_rcu+0x30/0x30 [ 48.579589] vfs_read+0x2b3/0x2f0 [ 48.579589] ksys_read+0x8b/0xc0 [ 48.583590] do_syscall_64+0x3d/0xc0 [ 48.583590] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 48.586525] RIP: 0033:0x7f2f28703fa1 [ 48.587592] Code: [...] 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 80 3d c5 23 14 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 [ 48.593534] RSP: 002b:00007ffd90f8cf88 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 48.595589] RAX: ffffffffffffffda RBX: 00007ffd90f8d5e8 RCX: 00007f2f28703fa1 [ 48.595589] RDX: 0000000000000001 RSI: 00007ffd90f8cfb0 RDI: 0000000000000006 [ 48.599592] RBP: 00007ffd90f8d2f0 R08: 0000000000000064 R09: 0000000000000000 [ 48.602527] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 48.603589] R13: 00007ffd90f8d608 R14: 00007f2f288d8000 R15: 0000000000f6bdb0 [ 48.605527] </TASK> In the test, two processes are communicating through pipe. Further debugging with strace found that the above splat is triggered as read() syscall could not receive the data even if the corresponding write() syscall in another process successfully wrote data into the pipe. The failed subtest is "send_signal_perf". The corresponding perf event has sample_period 1 and config PERF_COUNT_SW_CPU_CLOCK. sample_period 1 means every overflow event will trigger a call to the BPF program. So I suspect this may overwhelm the system. So I increased the sample_period to 100,000 and the test passed. The sample_period 10,000 still has the test failed. In other parts of selftest, e.g., [1], sample_freq is used instead. So I decided to use sample_freq = 1,000 since the test can pass as well. [1] https://lore.kernel.org/bpf/[email protected]/ Reported-by: Alexei Starovoitov <[email protected]> Signed-off-by: Yonghong Song <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Kaz205
pushed a commit
to Kaz205/linux
that referenced
this pull request
Aug 14, 2024
[ Upstream commit 7015843 ] Alexei reported that send_signal test may fail with nested CONFIG_PARAVIRT configs. In this particular case, the base VM is AMD with 166 cpus, and I run selftests with regular qemu on top of that and indeed send_signal test failed. I also tried with an Intel box with 80 cpus and there is no issue. The main qemu command line includes: -enable-kvm -smp 16 -cpu host The failure log looks like: $ ./test_progs -t send_signal [ 48.501588] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [test_progs:2225] [ 48.503622] Modules linked in: bpf_testmod(O) [ 48.503622] CPU: 9 PID: 2225 Comm: test_progs Tainted: G O 6.9.0-08561-g2c1713a8f1c9-dirty torvalds#69 [ 48.507629] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 [ 48.511635] RIP: 0010:handle_softirqs+0x71/0x290 [ 48.511635] Code: [...] 10 0a 00 00 00 31 c0 65 66 89 05 d5 f4 fa 7e fb bb ff ff ff ff <49> c7 c2 cb [ 48.518527] RSP: 0018:ffffc90000310fa0 EFLAGS: 00000246 [ 48.519579] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 00000000000006e0 [ 48.522526] RDX: 0000000000000006 RSI: ffff88810791ae80 RDI: 0000000000000000 [ 48.523587] RBP: ffffc90000fabc88 R08: 00000005a0af4f7f R09: 0000000000000000 [ 48.525525] R10: 0000000561d2f29c R11: 0000000000006534 R12: 0000000000000280 [ 48.528525] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 48.528525] FS: 00007f2f2885cd00(0000) GS:ffff888237c40000(0000) knlGS:0000000000000000 [ 48.531600] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 48.535520] CR2: 00007f2f287059f0 CR3: 0000000106a28002 CR4: 00000000003706f0 [ 48.537538] Call Trace: [ 48.537538] <IRQ> [ 48.537538] ? watchdog_timer_fn+0x1cd/0x250 [ 48.539590] ? lockup_detector_update_enable+0x50/0x50 [ 48.539590] ? __hrtimer_run_queues+0xff/0x280 [ 48.542520] ? hrtimer_interrupt+0x103/0x230 [ 48.544524] ? __sysvec_apic_timer_interrupt+0x4f/0x140 [ 48.545522] ? sysvec_apic_timer_interrupt+0x3a/0x90 [ 48.547612] ? asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.547612] ? handle_softirqs+0x71/0x290 [ 48.547612] irq_exit_rcu+0x63/0x80 [ 48.551585] sysvec_apic_timer_interrupt+0x75/0x90 [ 48.552521] </IRQ> [ 48.553529] <TASK> [ 48.553529] asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.555609] RIP: 0010:finish_task_switch.isra.0+0x90/0x260 [ 48.556526] Code: [...] 9f 58 0a 00 00 48 85 db 0f 85 89 01 00 00 4c 89 ff e8 53 d9 bd 00 fb 66 90 <4d> 85 ed 74 [ 48.562524] RSP: 0018:ffffc90000fabd38 EFLAGS: 00000282 [ 48.563589] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83385620 [ 48.563589] RDX: ffff888237c73ae4 RSI: 0000000000000000 RDI: ffff888237c6fd00 [ 48.568521] RBP: ffffc90000fabd68 R08: 0000000000000000 R09: 0000000000000000 [ 48.569528] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8881009d0000 [ 48.573525] R13: ffff8881024e5400 R14: ffff88810791ae80 R15: ffff888237c6fd00 [ 48.575614] ? finish_task_switch.isra.0+0x8d/0x260 [ 48.576523] __schedule+0x364/0xac0 [ 48.577535] schedule+0x2e/0x110 [ 48.578555] pipe_read+0x301/0x400 [ 48.579589] ? destroy_sched_domains_rcu+0x30/0x30 [ 48.579589] vfs_read+0x2b3/0x2f0 [ 48.579589] ksys_read+0x8b/0xc0 [ 48.583590] do_syscall_64+0x3d/0xc0 [ 48.583590] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 48.586525] RIP: 0033:0x7f2f28703fa1 [ 48.587592] Code: [...] 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 80 3d c5 23 14 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 [ 48.593534] RSP: 002b:00007ffd90f8cf88 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 48.595589] RAX: ffffffffffffffda RBX: 00007ffd90f8d5e8 RCX: 00007f2f28703fa1 [ 48.595589] RDX: 0000000000000001 RSI: 00007ffd90f8cfb0 RDI: 0000000000000006 [ 48.599592] RBP: 00007ffd90f8d2f0 R08: 0000000000000064 R09: 0000000000000000 [ 48.602527] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 48.603589] R13: 00007ffd90f8d608 R14: 00007f2f288d8000 R15: 0000000000f6bdb0 [ 48.605527] </TASK> In the test, two processes are communicating through pipe. Further debugging with strace found that the above splat is triggered as read() syscall could not receive the data even if the corresponding write() syscall in another process successfully wrote data into the pipe. The failed subtest is "send_signal_perf". The corresponding perf event has sample_period 1 and config PERF_COUNT_SW_CPU_CLOCK. sample_period 1 means every overflow event will trigger a call to the BPF program. So I suspect this may overwhelm the system. So I increased the sample_period to 100,000 and the test passed. The sample_period 10,000 still has the test failed. In other parts of selftest, e.g., [1], sample_freq is used instead. So I decided to use sample_freq = 1,000 since the test can pass as well. [1] https://lore.kernel.org/bpf/[email protected]/ Reported-by: Alexei Starovoitov <[email protected]> Signed-off-by: Yonghong Song <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
intersectRaven
pushed a commit
to intersectRaven/linux
that referenced
this pull request
Aug 14, 2024
[ Upstream commit 7015843 ] Alexei reported that send_signal test may fail with nested CONFIG_PARAVIRT configs. In this particular case, the base VM is AMD with 166 cpus, and I run selftests with regular qemu on top of that and indeed send_signal test failed. I also tried with an Intel box with 80 cpus and there is no issue. The main qemu command line includes: -enable-kvm -smp 16 -cpu host The failure log looks like: $ ./test_progs -t send_signal [ 48.501588] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [test_progs:2225] [ 48.503622] Modules linked in: bpf_testmod(O) [ 48.503622] CPU: 9 PID: 2225 Comm: test_progs Tainted: G O 6.9.0-08561-g2c1713a8f1c9-dirty torvalds#69 [ 48.507629] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 [ 48.511635] RIP: 0010:handle_softirqs+0x71/0x290 [ 48.511635] Code: [...] 10 0a 00 00 00 31 c0 65 66 89 05 d5 f4 fa 7e fb bb ff ff ff ff <49> c7 c2 cb [ 48.518527] RSP: 0018:ffffc90000310fa0 EFLAGS: 00000246 [ 48.519579] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 00000000000006e0 [ 48.522526] RDX: 0000000000000006 RSI: ffff88810791ae80 RDI: 0000000000000000 [ 48.523587] RBP: ffffc90000fabc88 R08: 00000005a0af4f7f R09: 0000000000000000 [ 48.525525] R10: 0000000561d2f29c R11: 0000000000006534 R12: 0000000000000280 [ 48.528525] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 48.528525] FS: 00007f2f2885cd00(0000) GS:ffff888237c40000(0000) knlGS:0000000000000000 [ 48.531600] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 48.535520] CR2: 00007f2f287059f0 CR3: 0000000106a28002 CR4: 00000000003706f0 [ 48.537538] Call Trace: [ 48.537538] <IRQ> [ 48.537538] ? watchdog_timer_fn+0x1cd/0x250 [ 48.539590] ? lockup_detector_update_enable+0x50/0x50 [ 48.539590] ? __hrtimer_run_queues+0xff/0x280 [ 48.542520] ? hrtimer_interrupt+0x103/0x230 [ 48.544524] ? __sysvec_apic_timer_interrupt+0x4f/0x140 [ 48.545522] ? sysvec_apic_timer_interrupt+0x3a/0x90 [ 48.547612] ? asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.547612] ? handle_softirqs+0x71/0x290 [ 48.547612] irq_exit_rcu+0x63/0x80 [ 48.551585] sysvec_apic_timer_interrupt+0x75/0x90 [ 48.552521] </IRQ> [ 48.553529] <TASK> [ 48.553529] asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.555609] RIP: 0010:finish_task_switch.isra.0+0x90/0x260 [ 48.556526] Code: [...] 9f 58 0a 00 00 48 85 db 0f 85 89 01 00 00 4c 89 ff e8 53 d9 bd 00 fb 66 90 <4d> 85 ed 74 [ 48.562524] RSP: 0018:ffffc90000fabd38 EFLAGS: 00000282 [ 48.563589] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83385620 [ 48.563589] RDX: ffff888237c73ae4 RSI: 0000000000000000 RDI: ffff888237c6fd00 [ 48.568521] RBP: ffffc90000fabd68 R08: 0000000000000000 R09: 0000000000000000 [ 48.569528] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8881009d0000 [ 48.573525] R13: ffff8881024e5400 R14: ffff88810791ae80 R15: ffff888237c6fd00 [ 48.575614] ? finish_task_switch.isra.0+0x8d/0x260 [ 48.576523] __schedule+0x364/0xac0 [ 48.577535] schedule+0x2e/0x110 [ 48.578555] pipe_read+0x301/0x400 [ 48.579589] ? destroy_sched_domains_rcu+0x30/0x30 [ 48.579589] vfs_read+0x2b3/0x2f0 [ 48.579589] ksys_read+0x8b/0xc0 [ 48.583590] do_syscall_64+0x3d/0xc0 [ 48.583590] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 48.586525] RIP: 0033:0x7f2f28703fa1 [ 48.587592] Code: [...] 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 80 3d c5 23 14 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 [ 48.593534] RSP: 002b:00007ffd90f8cf88 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 48.595589] RAX: ffffffffffffffda RBX: 00007ffd90f8d5e8 RCX: 00007f2f28703fa1 [ 48.595589] RDX: 0000000000000001 RSI: 00007ffd90f8cfb0 RDI: 0000000000000006 [ 48.599592] RBP: 00007ffd90f8d2f0 R08: 0000000000000064 R09: 0000000000000000 [ 48.602527] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 48.603589] R13: 00007ffd90f8d608 R14: 00007f2f288d8000 R15: 0000000000f6bdb0 [ 48.605527] </TASK> In the test, two processes are communicating through pipe. Further debugging with strace found that the above splat is triggered as read() syscall could not receive the data even if the corresponding write() syscall in another process successfully wrote data into the pipe. The failed subtest is "send_signal_perf". The corresponding perf event has sample_period 1 and config PERF_COUNT_SW_CPU_CLOCK. sample_period 1 means every overflow event will trigger a call to the BPF program. So I suspect this may overwhelm the system. So I increased the sample_period to 100,000 and the test passed. The sample_period 10,000 still has the test failed. In other parts of selftest, e.g., [1], sample_freq is used instead. So I decided to use sample_freq = 1,000 since the test can pass as well. [1] https://lore.kernel.org/bpf/[email protected]/ Reported-by: Alexei Starovoitov <[email protected]> Signed-off-by: Yonghong Song <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
staging-kernelci-org
pushed a commit
to kernelci/linux
that referenced
this pull request
Aug 14, 2024
[ Upstream commit 7015843 ] Alexei reported that send_signal test may fail with nested CONFIG_PARAVIRT configs. In this particular case, the base VM is AMD with 166 cpus, and I run selftests with regular qemu on top of that and indeed send_signal test failed. I also tried with an Intel box with 80 cpus and there is no issue. The main qemu command line includes: -enable-kvm -smp 16 -cpu host The failure log looks like: $ ./test_progs -t send_signal [ 48.501588] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [test_progs:2225] [ 48.503622] Modules linked in: bpf_testmod(O) [ 48.503622] CPU: 9 PID: 2225 Comm: test_progs Tainted: G O 6.9.0-08561-g2c1713a8f1c9-dirty torvalds#69 [ 48.507629] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 [ 48.511635] RIP: 0010:handle_softirqs+0x71/0x290 [ 48.511635] Code: [...] 10 0a 00 00 00 31 c0 65 66 89 05 d5 f4 fa 7e fb bb ff ff ff ff <49> c7 c2 cb [ 48.518527] RSP: 0018:ffffc90000310fa0 EFLAGS: 00000246 [ 48.519579] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 00000000000006e0 [ 48.522526] RDX: 0000000000000006 RSI: ffff88810791ae80 RDI: 0000000000000000 [ 48.523587] RBP: ffffc90000fabc88 R08: 00000005a0af4f7f R09: 0000000000000000 [ 48.525525] R10: 0000000561d2f29c R11: 0000000000006534 R12: 0000000000000280 [ 48.528525] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 48.528525] FS: 00007f2f2885cd00(0000) GS:ffff888237c40000(0000) knlGS:0000000000000000 [ 48.531600] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 48.535520] CR2: 00007f2f287059f0 CR3: 0000000106a28002 CR4: 00000000003706f0 [ 48.537538] Call Trace: [ 48.537538] <IRQ> [ 48.537538] ? watchdog_timer_fn+0x1cd/0x250 [ 48.539590] ? lockup_detector_update_enable+0x50/0x50 [ 48.539590] ? __hrtimer_run_queues+0xff/0x280 [ 48.542520] ? hrtimer_interrupt+0x103/0x230 [ 48.544524] ? __sysvec_apic_timer_interrupt+0x4f/0x140 [ 48.545522] ? sysvec_apic_timer_interrupt+0x3a/0x90 [ 48.547612] ? asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.547612] ? handle_softirqs+0x71/0x290 [ 48.547612] irq_exit_rcu+0x63/0x80 [ 48.551585] sysvec_apic_timer_interrupt+0x75/0x90 [ 48.552521] </IRQ> [ 48.553529] <TASK> [ 48.553529] asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.555609] RIP: 0010:finish_task_switch.isra.0+0x90/0x260 [ 48.556526] Code: [...] 9f 58 0a 00 00 48 85 db 0f 85 89 01 00 00 4c 89 ff e8 53 d9 bd 00 fb 66 90 <4d> 85 ed 74 [ 48.562524] RSP: 0018:ffffc90000fabd38 EFLAGS: 00000282 [ 48.563589] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83385620 [ 48.563589] RDX: ffff888237c73ae4 RSI: 0000000000000000 RDI: ffff888237c6fd00 [ 48.568521] RBP: ffffc90000fabd68 R08: 0000000000000000 R09: 0000000000000000 [ 48.569528] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8881009d0000 [ 48.573525] R13: ffff8881024e5400 R14: ffff88810791ae80 R15: ffff888237c6fd00 [ 48.575614] ? finish_task_switch.isra.0+0x8d/0x260 [ 48.576523] __schedule+0x364/0xac0 [ 48.577535] schedule+0x2e/0x110 [ 48.578555] pipe_read+0x301/0x400 [ 48.579589] ? destroy_sched_domains_rcu+0x30/0x30 [ 48.579589] vfs_read+0x2b3/0x2f0 [ 48.579589] ksys_read+0x8b/0xc0 [ 48.583590] do_syscall_64+0x3d/0xc0 [ 48.583590] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 48.586525] RIP: 0033:0x7f2f28703fa1 [ 48.587592] Code: [...] 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 80 3d c5 23 14 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 [ 48.593534] RSP: 002b:00007ffd90f8cf88 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 48.595589] RAX: ffffffffffffffda RBX: 00007ffd90f8d5e8 RCX: 00007f2f28703fa1 [ 48.595589] RDX: 0000000000000001 RSI: 00007ffd90f8cfb0 RDI: 0000000000000006 [ 48.599592] RBP: 00007ffd90f8d2f0 R08: 0000000000000064 R09: 0000000000000000 [ 48.602527] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 48.603589] R13: 00007ffd90f8d608 R14: 00007f2f288d8000 R15: 0000000000f6bdb0 [ 48.605527] </TASK> In the test, two processes are communicating through pipe. Further debugging with strace found that the above splat is triggered as read() syscall could not receive the data even if the corresponding write() syscall in another process successfully wrote data into the pipe. The failed subtest is "send_signal_perf". The corresponding perf event has sample_period 1 and config PERF_COUNT_SW_CPU_CLOCK. sample_period 1 means every overflow event will trigger a call to the BPF program. So I suspect this may overwhelm the system. So I increased the sample_period to 100,000 and the test passed. The sample_period 10,000 still has the test failed. In other parts of selftest, e.g., [1], sample_freq is used instead. So I decided to use sample_freq = 1,000 since the test can pass as well. [1] https://lore.kernel.org/bpf/[email protected]/ Reported-by: Alexei Starovoitov <[email protected]> Signed-off-by: Yonghong Song <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Aug 15, 2024
[ Upstream commit 7015843 ] Alexei reported that send_signal test may fail with nested CONFIG_PARAVIRT configs. In this particular case, the base VM is AMD with 166 cpus, and I run selftests with regular qemu on top of that and indeed send_signal test failed. I also tried with an Intel box with 80 cpus and there is no issue. The main qemu command line includes: -enable-kvm -smp 16 -cpu host The failure log looks like: $ ./test_progs -t send_signal [ 48.501588] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [test_progs:2225] [ 48.503622] Modules linked in: bpf_testmod(O) [ 48.503622] CPU: 9 PID: 2225 Comm: test_progs Tainted: G O 6.9.0-08561-g2c1713a8f1c9-dirty torvalds#69 [ 48.507629] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 [ 48.511635] RIP: 0010:handle_softirqs+0x71/0x290 [ 48.511635] Code: [...] 10 0a 00 00 00 31 c0 65 66 89 05 d5 f4 fa 7e fb bb ff ff ff ff <49> c7 c2 cb [ 48.518527] RSP: 0018:ffffc90000310fa0 EFLAGS: 00000246 [ 48.519579] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 00000000000006e0 [ 48.522526] RDX: 0000000000000006 RSI: ffff88810791ae80 RDI: 0000000000000000 [ 48.523587] RBP: ffffc90000fabc88 R08: 00000005a0af4f7f R09: 0000000000000000 [ 48.525525] R10: 0000000561d2f29c R11: 0000000000006534 R12: 0000000000000280 [ 48.528525] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 48.528525] FS: 00007f2f2885cd00(0000) GS:ffff888237c40000(0000) knlGS:0000000000000000 [ 48.531600] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 48.535520] CR2: 00007f2f287059f0 CR3: 0000000106a28002 CR4: 00000000003706f0 [ 48.537538] Call Trace: [ 48.537538] <IRQ> [ 48.537538] ? watchdog_timer_fn+0x1cd/0x250 [ 48.539590] ? lockup_detector_update_enable+0x50/0x50 [ 48.539590] ? __hrtimer_run_queues+0xff/0x280 [ 48.542520] ? hrtimer_interrupt+0x103/0x230 [ 48.544524] ? __sysvec_apic_timer_interrupt+0x4f/0x140 [ 48.545522] ? sysvec_apic_timer_interrupt+0x3a/0x90 [ 48.547612] ? asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.547612] ? handle_softirqs+0x71/0x290 [ 48.547612] irq_exit_rcu+0x63/0x80 [ 48.551585] sysvec_apic_timer_interrupt+0x75/0x90 [ 48.552521] </IRQ> [ 48.553529] <TASK> [ 48.553529] asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.555609] RIP: 0010:finish_task_switch.isra.0+0x90/0x260 [ 48.556526] Code: [...] 9f 58 0a 00 00 48 85 db 0f 85 89 01 00 00 4c 89 ff e8 53 d9 bd 00 fb 66 90 <4d> 85 ed 74 [ 48.562524] RSP: 0018:ffffc90000fabd38 EFLAGS: 00000282 [ 48.563589] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83385620 [ 48.563589] RDX: ffff888237c73ae4 RSI: 0000000000000000 RDI: ffff888237c6fd00 [ 48.568521] RBP: ffffc90000fabd68 R08: 0000000000000000 R09: 0000000000000000 [ 48.569528] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8881009d0000 [ 48.573525] R13: ffff8881024e5400 R14: ffff88810791ae80 R15: ffff888237c6fd00 [ 48.575614] ? finish_task_switch.isra.0+0x8d/0x260 [ 48.576523] __schedule+0x364/0xac0 [ 48.577535] schedule+0x2e/0x110 [ 48.578555] pipe_read+0x301/0x400 [ 48.579589] ? destroy_sched_domains_rcu+0x30/0x30 [ 48.579589] vfs_read+0x2b3/0x2f0 [ 48.579589] ksys_read+0x8b/0xc0 [ 48.583590] do_syscall_64+0x3d/0xc0 [ 48.583590] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 48.586525] RIP: 0033:0x7f2f28703fa1 [ 48.587592] Code: [...] 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 80 3d c5 23 14 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 [ 48.593534] RSP: 002b:00007ffd90f8cf88 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 48.595589] RAX: ffffffffffffffda RBX: 00007ffd90f8d5e8 RCX: 00007f2f28703fa1 [ 48.595589] RDX: 0000000000000001 RSI: 00007ffd90f8cfb0 RDI: 0000000000000006 [ 48.599592] RBP: 00007ffd90f8d2f0 R08: 0000000000000064 R09: 0000000000000000 [ 48.602527] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 48.603589] R13: 00007ffd90f8d608 R14: 00007f2f288d8000 R15: 0000000000f6bdb0 [ 48.605527] </TASK> In the test, two processes are communicating through pipe. Further debugging with strace found that the above splat is triggered as read() syscall could not receive the data even if the corresponding write() syscall in another process successfully wrote data into the pipe. The failed subtest is "send_signal_perf". The corresponding perf event has sample_period 1 and config PERF_COUNT_SW_CPU_CLOCK. sample_period 1 means every overflow event will trigger a call to the BPF program. So I suspect this may overwhelm the system. So I increased the sample_period to 100,000 and the test passed. The sample_period 10,000 still has the test failed. In other parts of selftest, e.g., [1], sample_freq is used instead. So I decided to use sample_freq = 1,000 since the test can pass as well. [1] https://lore.kernel.org/bpf/[email protected]/ Reported-by: Alexei Starovoitov <[email protected]> Signed-off-by: Yonghong Song <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Sep 4, 2024
The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 torvalds#69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------ Signed-off-by: Haibo Chen <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Sep 4, 2024
[ Upstream commit 7015843 ] Alexei reported that send_signal test may fail with nested CONFIG_PARAVIRT configs. In this particular case, the base VM is AMD with 166 cpus, and I run selftests with regular qemu on top of that and indeed send_signal test failed. I also tried with an Intel box with 80 cpus and there is no issue. The main qemu command line includes: -enable-kvm -smp 16 -cpu host The failure log looks like: $ ./test_progs -t send_signal [ 48.501588] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [test_progs:2225] [ 48.503622] Modules linked in: bpf_testmod(O) [ 48.503622] CPU: 9 PID: 2225 Comm: test_progs Tainted: G O 6.9.0-08561-g2c1713a8f1c9-dirty torvalds#69 [ 48.507629] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 [ 48.511635] RIP: 0010:handle_softirqs+0x71/0x290 [ 48.511635] Code: [...] 10 0a 00 00 00 31 c0 65 66 89 05 d5 f4 fa 7e fb bb ff ff ff ff <49> c7 c2 cb [ 48.518527] RSP: 0018:ffffc90000310fa0 EFLAGS: 00000246 [ 48.519579] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 00000000000006e0 [ 48.522526] RDX: 0000000000000006 RSI: ffff88810791ae80 RDI: 0000000000000000 [ 48.523587] RBP: ffffc90000fabc88 R08: 00000005a0af4f7f R09: 0000000000000000 [ 48.525525] R10: 0000000561d2f29c R11: 0000000000006534 R12: 0000000000000280 [ 48.528525] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 48.528525] FS: 00007f2f2885cd00(0000) GS:ffff888237c40000(0000) knlGS:0000000000000000 [ 48.531600] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 48.535520] CR2: 00007f2f287059f0 CR3: 0000000106a28002 CR4: 00000000003706f0 [ 48.537538] Call Trace: [ 48.537538] <IRQ> [ 48.537538] ? watchdog_timer_fn+0x1cd/0x250 [ 48.539590] ? lockup_detector_update_enable+0x50/0x50 [ 48.539590] ? __hrtimer_run_queues+0xff/0x280 [ 48.542520] ? hrtimer_interrupt+0x103/0x230 [ 48.544524] ? __sysvec_apic_timer_interrupt+0x4f/0x140 [ 48.545522] ? sysvec_apic_timer_interrupt+0x3a/0x90 [ 48.547612] ? asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.547612] ? handle_softirqs+0x71/0x290 [ 48.547612] irq_exit_rcu+0x63/0x80 [ 48.551585] sysvec_apic_timer_interrupt+0x75/0x90 [ 48.552521] </IRQ> [ 48.553529] <TASK> [ 48.553529] asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.555609] RIP: 0010:finish_task_switch.isra.0+0x90/0x260 [ 48.556526] Code: [...] 9f 58 0a 00 00 48 85 db 0f 85 89 01 00 00 4c 89 ff e8 53 d9 bd 00 fb 66 90 <4d> 85 ed 74 [ 48.562524] RSP: 0018:ffffc90000fabd38 EFLAGS: 00000282 [ 48.563589] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83385620 [ 48.563589] RDX: ffff888237c73ae4 RSI: 0000000000000000 RDI: ffff888237c6fd00 [ 48.568521] RBP: ffffc90000fabd68 R08: 0000000000000000 R09: 0000000000000000 [ 48.569528] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8881009d0000 [ 48.573525] R13: ffff8881024e5400 R14: ffff88810791ae80 R15: ffff888237c6fd00 [ 48.575614] ? finish_task_switch.isra.0+0x8d/0x260 [ 48.576523] __schedule+0x364/0xac0 [ 48.577535] schedule+0x2e/0x110 [ 48.578555] pipe_read+0x301/0x400 [ 48.579589] ? destroy_sched_domains_rcu+0x30/0x30 [ 48.579589] vfs_read+0x2b3/0x2f0 [ 48.579589] ksys_read+0x8b/0xc0 [ 48.583590] do_syscall_64+0x3d/0xc0 [ 48.583590] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 48.586525] RIP: 0033:0x7f2f28703fa1 [ 48.587592] Code: [...] 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 80 3d c5 23 14 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 [ 48.593534] RSP: 002b:00007ffd90f8cf88 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 48.595589] RAX: ffffffffffffffda RBX: 00007ffd90f8d5e8 RCX: 00007f2f28703fa1 [ 48.595589] RDX: 0000000000000001 RSI: 00007ffd90f8cfb0 RDI: 0000000000000006 [ 48.599592] RBP: 00007ffd90f8d2f0 R08: 0000000000000064 R09: 0000000000000000 [ 48.602527] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 48.603589] R13: 00007ffd90f8d608 R14: 00007f2f288d8000 R15: 0000000000f6bdb0 [ 48.605527] </TASK> In the test, two processes are communicating through pipe. Further debugging with strace found that the above splat is triggered as read() syscall could not receive the data even if the corresponding write() syscall in another process successfully wrote data into the pipe. The failed subtest is "send_signal_perf". The corresponding perf event has sample_period 1 and config PERF_COUNT_SW_CPU_CLOCK. sample_period 1 means every overflow event will trigger a call to the BPF program. So I suspect this may overwhelm the system. So I increased the sample_period to 100,000 and the test passed. The sample_period 10,000 still has the test failed. In other parts of selftest, e.g., [1], sample_freq is used instead. So I decided to use sample_freq = 1,000 since the test can pass as well. [1] https://lore.kernel.org/bpf/[email protected]/ Reported-by: Alexei Starovoitov <[email protected]> Signed-off-by: Yonghong Song <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Sep 5, 2024
The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 torvalds#69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------ Signed-off-by: Haibo Chen <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Sep 5, 2024
The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 torvalds#69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------ Fixes: ef89fd5 ("arm64: dts: imx8ulp: add flexspi node") Cc: [email protected] Signed-off-by: Haibo Chen <[email protected]>
1054009064
pushed a commit
to 1054009064/linux
that referenced
this pull request
Sep 9, 2024
[ Upstream commit 7015843 ] Alexei reported that send_signal test may fail with nested CONFIG_PARAVIRT configs. In this particular case, the base VM is AMD with 166 cpus, and I run selftests with regular qemu on top of that and indeed send_signal test failed. I also tried with an Intel box with 80 cpus and there is no issue. The main qemu command line includes: -enable-kvm -smp 16 -cpu host The failure log looks like: $ ./test_progs -t send_signal [ 48.501588] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [test_progs:2225] [ 48.503622] Modules linked in: bpf_testmod(O) [ 48.503622] CPU: 9 PID: 2225 Comm: test_progs Tainted: G O 6.9.0-08561-g2c1713a8f1c9-dirty torvalds#69 [ 48.507629] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 [ 48.511635] RIP: 0010:handle_softirqs+0x71/0x290 [ 48.511635] Code: [...] 10 0a 00 00 00 31 c0 65 66 89 05 d5 f4 fa 7e fb bb ff ff ff ff <49> c7 c2 cb [ 48.518527] RSP: 0018:ffffc90000310fa0 EFLAGS: 00000246 [ 48.519579] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 00000000000006e0 [ 48.522526] RDX: 0000000000000006 RSI: ffff88810791ae80 RDI: 0000000000000000 [ 48.523587] RBP: ffffc90000fabc88 R08: 00000005a0af4f7f R09: 0000000000000000 [ 48.525525] R10: 0000000561d2f29c R11: 0000000000006534 R12: 0000000000000280 [ 48.528525] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 48.528525] FS: 00007f2f2885cd00(0000) GS:ffff888237c40000(0000) knlGS:0000000000000000 [ 48.531600] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 48.535520] CR2: 00007f2f287059f0 CR3: 0000000106a28002 CR4: 00000000003706f0 [ 48.537538] Call Trace: [ 48.537538] <IRQ> [ 48.537538] ? watchdog_timer_fn+0x1cd/0x250 [ 48.539590] ? lockup_detector_update_enable+0x50/0x50 [ 48.539590] ? __hrtimer_run_queues+0xff/0x280 [ 48.542520] ? hrtimer_interrupt+0x103/0x230 [ 48.544524] ? __sysvec_apic_timer_interrupt+0x4f/0x140 [ 48.545522] ? sysvec_apic_timer_interrupt+0x3a/0x90 [ 48.547612] ? asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.547612] ? handle_softirqs+0x71/0x290 [ 48.547612] irq_exit_rcu+0x63/0x80 [ 48.551585] sysvec_apic_timer_interrupt+0x75/0x90 [ 48.552521] </IRQ> [ 48.553529] <TASK> [ 48.553529] asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.555609] RIP: 0010:finish_task_switch.isra.0+0x90/0x260 [ 48.556526] Code: [...] 9f 58 0a 00 00 48 85 db 0f 85 89 01 00 00 4c 89 ff e8 53 d9 bd 00 fb 66 90 <4d> 85 ed 74 [ 48.562524] RSP: 0018:ffffc90000fabd38 EFLAGS: 00000282 [ 48.563589] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83385620 [ 48.563589] RDX: ffff888237c73ae4 RSI: 0000000000000000 RDI: ffff888237c6fd00 [ 48.568521] RBP: ffffc90000fabd68 R08: 0000000000000000 R09: 0000000000000000 [ 48.569528] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8881009d0000 [ 48.573525] R13: ffff8881024e5400 R14: ffff88810791ae80 R15: ffff888237c6fd00 [ 48.575614] ? finish_task_switch.isra.0+0x8d/0x260 [ 48.576523] __schedule+0x364/0xac0 [ 48.577535] schedule+0x2e/0x110 [ 48.578555] pipe_read+0x301/0x400 [ 48.579589] ? destroy_sched_domains_rcu+0x30/0x30 [ 48.579589] vfs_read+0x2b3/0x2f0 [ 48.579589] ksys_read+0x8b/0xc0 [ 48.583590] do_syscall_64+0x3d/0xc0 [ 48.583590] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 48.586525] RIP: 0033:0x7f2f28703fa1 [ 48.587592] Code: [...] 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 80 3d c5 23 14 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 [ 48.593534] RSP: 002b:00007ffd90f8cf88 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 48.595589] RAX: ffffffffffffffda RBX: 00007ffd90f8d5e8 RCX: 00007f2f28703fa1 [ 48.595589] RDX: 0000000000000001 RSI: 00007ffd90f8cfb0 RDI: 0000000000000006 [ 48.599592] RBP: 00007ffd90f8d2f0 R08: 0000000000000064 R09: 0000000000000000 [ 48.602527] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 48.603589] R13: 00007ffd90f8d608 R14: 00007f2f288d8000 R15: 0000000000f6bdb0 [ 48.605527] </TASK> In the test, two processes are communicating through pipe. Further debugging with strace found that the above splat is triggered as read() syscall could not receive the data even if the corresponding write() syscall in another process successfully wrote data into the pipe. The failed subtest is "send_signal_perf". The corresponding perf event has sample_period 1 and config PERF_COUNT_SW_CPU_CLOCK. sample_period 1 means every overflow event will trigger a call to the BPF program. So I suspect this may overwhelm the system. So I increased the sample_period to 100,000 and the test passed. The sample_period 10,000 still has the test failed. In other parts of selftest, e.g., [1], sample_freq is used instead. So I decided to use sample_freq = 1,000 since the test can pass as well. [1] https://lore.kernel.org/bpf/[email protected]/ Reported-by: Alexei Starovoitov <[email protected]> Signed-off-by: Yonghong Song <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
1054009064
pushed a commit
to 1054009064/linux
that referenced
this pull request
Sep 9, 2024
[ Upstream commit 7015843 ] Alexei reported that send_signal test may fail with nested CONFIG_PARAVIRT configs. In this particular case, the base VM is AMD with 166 cpus, and I run selftests with regular qemu on top of that and indeed send_signal test failed. I also tried with an Intel box with 80 cpus and there is no issue. The main qemu command line includes: -enable-kvm -smp 16 -cpu host The failure log looks like: $ ./test_progs -t send_signal [ 48.501588] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [test_progs:2225] [ 48.503622] Modules linked in: bpf_testmod(O) [ 48.503622] CPU: 9 PID: 2225 Comm: test_progs Tainted: G O 6.9.0-08561-g2c1713a8f1c9-dirty torvalds#69 [ 48.507629] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 [ 48.511635] RIP: 0010:handle_softirqs+0x71/0x290 [ 48.511635] Code: [...] 10 0a 00 00 00 31 c0 65 66 89 05 d5 f4 fa 7e fb bb ff ff ff ff <49> c7 c2 cb [ 48.518527] RSP: 0018:ffffc90000310fa0 EFLAGS: 00000246 [ 48.519579] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 00000000000006e0 [ 48.522526] RDX: 0000000000000006 RSI: ffff88810791ae80 RDI: 0000000000000000 [ 48.523587] RBP: ffffc90000fabc88 R08: 00000005a0af4f7f R09: 0000000000000000 [ 48.525525] R10: 0000000561d2f29c R11: 0000000000006534 R12: 0000000000000280 [ 48.528525] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 48.528525] FS: 00007f2f2885cd00(0000) GS:ffff888237c40000(0000) knlGS:0000000000000000 [ 48.531600] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 48.535520] CR2: 00007f2f287059f0 CR3: 0000000106a28002 CR4: 00000000003706f0 [ 48.537538] Call Trace: [ 48.537538] <IRQ> [ 48.537538] ? watchdog_timer_fn+0x1cd/0x250 [ 48.539590] ? lockup_detector_update_enable+0x50/0x50 [ 48.539590] ? __hrtimer_run_queues+0xff/0x280 [ 48.542520] ? hrtimer_interrupt+0x103/0x230 [ 48.544524] ? __sysvec_apic_timer_interrupt+0x4f/0x140 [ 48.545522] ? sysvec_apic_timer_interrupt+0x3a/0x90 [ 48.547612] ? asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.547612] ? handle_softirqs+0x71/0x290 [ 48.547612] irq_exit_rcu+0x63/0x80 [ 48.551585] sysvec_apic_timer_interrupt+0x75/0x90 [ 48.552521] </IRQ> [ 48.553529] <TASK> [ 48.553529] asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 48.555609] RIP: 0010:finish_task_switch.isra.0+0x90/0x260 [ 48.556526] Code: [...] 9f 58 0a 00 00 48 85 db 0f 85 89 01 00 00 4c 89 ff e8 53 d9 bd 00 fb 66 90 <4d> 85 ed 74 [ 48.562524] RSP: 0018:ffffc90000fabd38 EFLAGS: 00000282 [ 48.563589] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83385620 [ 48.563589] RDX: ffff888237c73ae4 RSI: 0000000000000000 RDI: ffff888237c6fd00 [ 48.568521] RBP: ffffc90000fabd68 R08: 0000000000000000 R09: 0000000000000000 [ 48.569528] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8881009d0000 [ 48.573525] R13: ffff8881024e5400 R14: ffff88810791ae80 R15: ffff888237c6fd00 [ 48.575614] ? finish_task_switch.isra.0+0x8d/0x260 [ 48.576523] __schedule+0x364/0xac0 [ 48.577535] schedule+0x2e/0x110 [ 48.578555] pipe_read+0x301/0x400 [ 48.579589] ? destroy_sched_domains_rcu+0x30/0x30 [ 48.579589] vfs_read+0x2b3/0x2f0 [ 48.579589] ksys_read+0x8b/0xc0 [ 48.583590] do_syscall_64+0x3d/0xc0 [ 48.583590] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 48.586525] RIP: 0033:0x7f2f28703fa1 [ 48.587592] Code: [...] 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 80 3d c5 23 14 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 [ 48.593534] RSP: 002b:00007ffd90f8cf88 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 48.595589] RAX: ffffffffffffffda RBX: 00007ffd90f8d5e8 RCX: 00007f2f28703fa1 [ 48.595589] RDX: 0000000000000001 RSI: 00007ffd90f8cfb0 RDI: 0000000000000006 [ 48.599592] RBP: 00007ffd90f8d2f0 R08: 0000000000000064 R09: 0000000000000000 [ 48.602527] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 48.603589] R13: 00007ffd90f8d608 R14: 00007f2f288d8000 R15: 0000000000f6bdb0 [ 48.605527] </TASK> In the test, two processes are communicating through pipe. Further debugging with strace found that the above splat is triggered as read() syscall could not receive the data even if the corresponding write() syscall in another process successfully wrote data into the pipe. The failed subtest is "send_signal_perf". The corresponding perf event has sample_period 1 and config PERF_COUNT_SW_CPU_CLOCK. sample_period 1 means every overflow event will trigger a call to the BPF program. So I suspect this may overwhelm the system. So I increased the sample_period to 100,000 and the test passed. The sample_period 10,000 still has the test failed. In other parts of selftest, e.g., [1], sample_freq is used instead. So I decided to use sample_freq = 1,000 since the test can pass as well. [1] https://lore.kernel.org/bpf/[email protected]/ Reported-by: Alexei Starovoitov <[email protected]> Signed-off-by: Yonghong Song <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Oct 17, 2024
The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 torvalds#69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------ Fixes: ef89fd5 ("arm64: dts: imx8ulp: add flexspi node") Cc: [email protected] Signed-off-by: Haibo Chen <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Nov 6, 2024
commit 409dc51 upstream. The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 torvalds#69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------ Fixes: ef89fd5 ("arm64: dts: imx8ulp: add flexspi node") Cc: [email protected] Signed-off-by: Haibo Chen <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Nov 6, 2024
commit 409dc51 upstream. The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 torvalds#69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------ Fixes: ef89fd5 ("arm64: dts: imx8ulp: add flexspi node") Cc: [email protected] Signed-off-by: Haibo Chen <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Nov 6, 2024
commit 409dc51 upstream. The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 torvalds#69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------ Fixes: ef89fd5 ("arm64: dts: imx8ulp: add flexspi node") Cc: [email protected] Signed-off-by: Haibo Chen <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Nov 6, 2024
commit 409dc51 upstream. The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 torvalds#69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------ Fixes: ef89fd5 ("arm64: dts: imx8ulp: add flexspi node") Cc: [email protected] Signed-off-by: Haibo Chen <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Nov 7, 2024
commit 409dc51 upstream. The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 torvalds#69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------ Fixes: ef89fd5 ("arm64: dts: imx8ulp: add flexspi node") Cc: [email protected] Signed-off-by: Haibo Chen <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
hellsgod
pushed a commit
to hellsgod/linux
that referenced
this pull request
Nov 8, 2024
commit 409dc51 upstream. The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 torvalds#69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------ Fixes: ef89fd5 ("arm64: dts: imx8ulp: add flexspi node") Cc: [email protected] Signed-off-by: Haibo Chen <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
1054009064
pushed a commit
to 1054009064/linux
that referenced
this pull request
Nov 8, 2024
commit 409dc51 upstream. The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 torvalds#69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------ Fixes: ef89fd5 ("arm64: dts: imx8ulp: add flexspi node") Cc: [email protected] Signed-off-by: Haibo Chen <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
MingcongBai
pushed a commit
to AOSC-Tracking/linux
that referenced
this pull request
Nov 13, 2024
commit 409dc51 upstream. The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 torvalds#69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------ Fixes: ef89fd5 ("arm64: dts: imx8ulp: add flexspi node") Cc: [email protected] Signed-off-by: Haibo Chen <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.