Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

. #69

Closed
wants to merge 1 commit into from

1 participant

@arjun024

No description provided.

@shr-buildhost shr-buildhost referenced this pull request from a commit in shr-distribution/linux
Tejun Heo cgroup: fix cgroup_create() error handling path
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+ #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 <tj@kernel.org>
Acked-by: Li Zefan <lizefan@huawei.com>
Reported-by: Vladimir Davydov <vdavydov@parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
7b8a321
@antonblanchard antonblanchard referenced this pull request from a commit in antonblanchard/linux
Borislav Petkov x86/boot: Further compress CPUs bootup message
Turn it into (for example):

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

and drop useless elements.

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

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: huawei.libin@huawei.com
Cc: wangyijing@huawei.com
Cc: fenghua.yu@intel.com
Cc: guohanjun@huawei.com
Cc: paul.gortmaker@windriver.com
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20130930095624.GB16383@pd.tnic
Signed-off-by: Ingo Molnar <mingo@kernel.org>
a17bce4
@antonblanchard antonblanchard referenced this pull request from a commit in antonblanchard/linux
Tejun Heo cgroup: fix cgroup_create() error handling path
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+ #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 <tj@kernel.org>
Acked-by: Li Zefan <lizefan@huawei.com>
Reported-by: Vladimir Davydov <vdavydov@parallels.com>
Cc: stable@vger.kernel.org # v3.12+
266ccd5
@tobiasjakobi tobiasjakobi referenced this pull request from a commit in tobiasjakobi/linux-odroid
Martin Peschke [SCSI] zfcp: fix schedule-inside-lock in scsi_device list loops
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+ #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 <borntraeger@de.ibm.com>
Signed-off-by: Martin Peschke <mpeschke@linux.vnet.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
d520d63
@hansendc hansendc referenced this pull request from a commit in hansendc/linux
@bebarino bebarino EDAC: Don't try to cancel workqueue when it's never setup
We only setup a workqueue for edac devices that use the polling
method. We still try to cancel the workqueue if an edac_device
uses the irq method though. This causes a warning from debug
objects when we remove an edac device:

WARNING: CPU: 0 PID: 56 at lib/debugobjects.c:260 debug_print_object+0x98/0xc0()
ODEBUG: assert_init not available (active state 0) object type: timer_list hint: stub_timer+0x0/0x28
Modules linked in: krait_edac(-)
CPU: 0 PID: 56 Comm: rmmod Not tainted 3.12.0-rc2-00035-g15292a0 #69
(unwind_backtrace+0x0/0x144)
(show_stack+0x20/0x24)
(dump_stack+0x74/0xb4)
(warn_slowpath_common+0x78/0x9c)
(warn_slowpath_fmt+0x40/0x48)
(debug_print_object+0x98/0xc0)
(debug_object_assert_init+0xdc/0xec)
(del_timer+0x24/0x7c)
(try_to_grab_pending+0xc0/0x1b0)
(cancel_delayed_work+0x2c/0xa0)
(edac_device_workq_teardown+0x1c/0x38)
(edac_device_del_device+0xb8/0xe4)
(krait_edac_remove+0x50/0x70 [krait_edac])
(platform_drv_remove+0x24/0x28)
(__device_release_driver+0x68/0xc0)
(driver_detach+0xc4/0xc8)
(bus_remove_driver+0xac/0x114)
(driver_unregister+0x38/0x58)
(platform_driver_unregister+0x1c/0x20)
(krait_edac_driver_exit+0x14/0x1c [krait_edac])
(SyS_delete_module+0x178/0x2b4)

Fix it by skipping the workqueue teardown for such devices.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Link: http://lkml.kernel.org/r/1388434457-4194-2-git-send-email-sboyd@codeaurora.org
Signed-off-by: Borislav Petkov <bp@suse.de>
881f0fc
@jlelli jlelli referenced this pull request from a commit in jlelli/linux
Martin Peschke [SCSI] zfcp: fix schedule-inside-lock in scsi_device list loops
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+ #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 <borntraeger@de.ibm.com>
Signed-off-by: Martin Peschke <mpeschke@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org #2.6.37+
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
924dd58
@huangrui huangrui referenced this pull request from a commit in huangrui/linux
Martin Peschke SCSI: zfcp: fix schedule-inside-lock in scsi_device list loops
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+ #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 <borntraeger@de.ibm.com>
Signed-off-by: Martin Peschke <mpeschke@linux.vnet.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
e1a289e
@swarren swarren referenced this pull request from a commit in swarren/linux-tegra
Andrew Morton kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2-checkpa…
…tch-fixes

WARNING: line over 80 characters
#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
#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 <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
93ba3a4
@swarren swarren referenced this pull request from a commit in swarren/linux-tegra
Andrew Morton kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2-checkpa…
…tch-fixes

WARNING: line over 80 characters
#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
#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 <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
1962be7
@swarren swarren referenced this pull request from a commit in swarren/linux-tegra
Andrew Morton kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2-checkpa…
…tch-fixes

WARNING: line over 80 characters
#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
#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 <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
f80e1c7
@Naoya-Horiguchi Naoya-Horiguchi referenced this pull request from a commit
Andrew Morton kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2-checkpa…
…tch-fixes

WARNING: line over 80 characters
#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
#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 <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
5388713
@niwamatsu niwamatsu referenced this pull request from a commit in renesas-devel/linux
Martin Peschke SCSI: zfcp: fix schedule-inside-lock in scsi_device list loops
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+ #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 <borntraeger@de.ibm.com>
Signed-off-by: Martin Peschke <mpeschke@linux.vnet.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
3c30535
@zeitgeist87 zeitgeist87 referenced this pull request from a commit in zeitgeist87/linux
Andrew Morton kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2-checkpa…
…tch-fixes

WARNING: line over 80 characters
#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
#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 <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
9a49037
@swarren swarren referenced this pull request from a commit in swarren/linux-tegra
Andrew Morton kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2-checkpa…
…tch-fixes

WARNING: line over 80 characters
#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
#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 <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
c334b7f
@zeitgeist87 zeitgeist87 referenced this pull request from a commit in zeitgeist87/linux
Andrew Morton kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2-checkpa…
…tch-fixes

WARNING: line over 80 characters
#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
#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 <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
6655e58
@ddstreet ddstreet referenced this pull request from a commit in ddstreet/linux
Andrew Morton kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2-checkpa…
…tch-fixes

WARNING: line over 80 characters
#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
#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 <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ee2bbd7
@gregnietsky gregnietsky referenced this pull request from a commit in Distrotech/linux
Martin Peschke zfcp: fix schedule-inside-lock in scsi_device list loops
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+ #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 <borntraeger@de.ibm.com>
Signed-off-by: Martin Peschke <mpeschke@linux.vnet.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
456dc00
@gregnietsky gregnietsky referenced this pull request from a commit in Distrotech/linux
Martin Peschke SCSI: zfcp: fix schedule-inside-lock in scsi_device list loops
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+ #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 <borntraeger@de.ibm.com>
Signed-off-by: Martin Peschke <mpeschke@linux.vnet.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
43bbe37
@Gnurou Gnurou referenced this pull request from a commit in Gnurou/linux
@ezequielgarcia ezequielgarcia usb: musb: Fix panic upon musb_am335x module removal
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/linux-omap@vger.kernel.org/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")
Cc: <stable@vger.kernel.org> # v3.12+
Acked-by: George Cherian <george.cherian@ti.com>
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Felipe Balbi <balbi@ti.com>
7adb5c8
@heftig heftig referenced this pull request from a commit in zen-kernel/zen-kernel
@ezequielgarcia ezequielgarcia usb: musb: Fix panic upon musb_am335x module removal
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/linux-omap@vger.kernel.org/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 <george.cherian@ti.com>
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ee5263f
@sunny256 sunny256 referenced this pull request from a commit in sunny256/linux
@ezequielgarcia ezequielgarcia usb: musb: Fix panic upon musb_am335x module removal
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/linux-omap@vger.kernel.org/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 <george.cherian@ti.com>
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6ea07d9
@sunny256 sunny256 referenced this pull request from a commit in sunny256/linux
@ezequielgarcia ezequielgarcia usb: musb: Fix panic upon musb_am335x module removal
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/linux-omap@vger.kernel.org/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 <george.cherian@ti.com>
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
a92e6f7
@jsarha jsarha referenced this pull request from a commit in jsarha/linux
@ezequielgarcia ezequielgarcia usb: musb: Fix panic upon musb_am335x module removal
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/linux-omap@vger.kernel.org/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")
Cc: <stable@vger.kernel.org> # v3.12+
Acked-by: George Cherian <george.cherian@ti.com>
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
02f1163
@pstglia pstglia referenced this pull request from a commit in pstglia/linux
@ezequielgarcia ezequielgarcia usb: musb: Fix panic upon musb_am335x module removal
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/linux-omap@vger.kernel.org/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")
Cc: <stable@vger.kernel.org> # v3.12+
Acked-by: George Cherian <george.cherian@ti.com>
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Felipe Balbi <balbi@ti.com>
772acc3
@kees kees referenced this pull request from a commit in kees/linux
@ezequielgarcia ezequielgarcia usb: musb: Fix panic upon musb_am335x module removal
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/linux-omap@vger.kernel.org/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 <george.cherian@ti.com>
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
9a26eea
@prahal prahal referenced this pull request from a commit in prahal/linux
@prahal prahal drm: exynos: Fix vblank refcount
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 #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 #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 #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 #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)
f5cd324
@alexandrebelloni alexandrebelloni referenced this pull request from a commit in alexandrebelloni/linux
@bebarino bebarino tty: serial: msm: Fix sysrq spinlock recursion on non-DM
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 #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 <frank.rowand@sonymobile.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
660beb0
@aryabinin aryabinin referenced this pull request from a commit in aryabinin/linux
mmotm auto import