Do you have any stand-alone drm/msm source/patch? #2
Comments
|
from a quick look at that branch, it looks like a 2.6.35 based kernel. I have backported the upstream driver as far back as 3.4 (which I haven't done for a while since there is already considerable difference between 3.4 (pre-devicetree) and upstream (devicetree, common clock framework, etc).. You could look, for example, at 3.4 based ifc6410-drm branch.. that has drm backport plus a bunch of other dependencies backported. But I guess it would be quite some work since 2.6.35 is even older and you'd have to work out what other dependent patches need to be backported.. |
|
hmm, I guess I should also note that the upstream driver does not have any adreno a2xx support currently. Mostly for lack of any device with a2xx that could run a modern kernel and time. |
|
Thanks for you help. I'll soon bump to an APQ8060 device( yep,this Galaxy SII HD). I may use hybris to drive U8800. But should I do a 'git diff' between your kernel tree with and without drm? It seems that the upstream kernel of SHV-E120s provided by Samsung is also too old... from Galaxy SII HD -------- 原始邮件 -------- hmm, I guess I should also note that the upstream driver does not have any adreno a2xx support currently. Mostly for lack of any device with a2xx that could run a modern kernel and time. — |
|
@robclark I recently got a 3.4 for U8800. (https://github.com/Blefish/android_kernel_huawei_msm7x30) How can I port freedreno on it? |
|
well, if you have a 3.4 based kernel, you could probably cherry-pick patches from the 3.4 based ifc6410-drm branch.. there would still be the matter of adding support for a2xx (which should be another subclass of adreno_gpu in the way that a3xx_gpu and a4xx_gpu are). Note however that a2xx is using an mmu inside the gpu block (rather than an external iommu) so support for that would also need to be added. There is the msm_mmu base class in drm/msm and the intention was that the a2xx mmu would be another subclass of that.. I assume that 7x30 is using the mdp4 display controller block.. although you'd have to add appropriate config bits in mdp4_get_config(). There is a branch somewhere w/ DSI support for mdp4 although 7x30 probably has a different dsi phy compared to 8x64.. |
|
Yes, it uses mdp4. Can I get enough infomation from the stock drivers/gpu/msm and drivers/video/msm? Applying the patch is very easy, far beyond my expectation! However, I found memset.S and dma-attrs.h already patched in the msm7x30 kernel by Blefish.Patching on the board-xxx.c failed, but Huawei devices uses a different board-xxx.c to other devices. (board-hw7x30*.c), so it means nothingHowever, I remembered that freedreno is first declared to support the adreno220 GPU shipped in msm8x60. (The current mobile phone which I use every day is a Galaxy SII HD, which uses APQ8060, so I noticed that) Date: Thu, 18 Jun 2015 16:35:02 -0700 well, if you have a 3.4 based kernel, you could probably cherry-pick patches from the 3.4 based ifc6410-drm branch.. there would still be the matter of adding support for a2xx (which should be another subclass of adreno_gpu in the way that a3xx_gpu and a4xx_gpu are). Note however that a2xx is using an mmu inside the gpu block (rather than an external iommu) so support for that would also need to be added. There is the msm_mmu base class in drm/msm and the intention was that the a2xx mmu would be another subclass of that.. I assume that 7x30 is using the mdp4 display controller block.. although you'd have to add appropriate config bits in mdp4_get_config(). There is a branch somewhere w/ DSI support for mdp4 although 7x30 probably has a different dsi phy compared to 8x64.. ― |
|
yeah, you should be able to figure out enough from the downstream android fbdev/gpu drivers.. I did find that the mdp4 code especially was a bit, umm, spaghetti code, so I found it easier to figure out how it worked by tracing the register reads/writes, etc.. see https://github.com/freedreno/kernel-msm/commits/ifc6410-vidre for the hacks I used. In https://github.com/freedreno/envytools/ there is a demsm tool to decode the registers into bitfields which will possibly be useful (note: iirc you might have to edit the log to s/MDP/MDP4/ or something approximately like that for demsm to work.. at some point when I started working on mdp5 I renamed MDP to MDP4 in the xml files which have the register definitions).. the gpu code in drivers/gpu/msm wasn't quite as messy as the drivers/video/msm code, so it should hopefully be easier to understand (but I still did similar trick for logging readl/writel).. fwiw, the first freedreno gpu support was a2xx, but at that time I was using the kgsl (drivers/gpu/msm) kernel code.. I wanted to add a2xx support in drivers/gpu/drm/msm but never found time (and lack of modern kernel supporting a2xx devices plus huge amount of work needed for a3xx didn't help for finding free time to work on drm/msm a2xx support) |
|
https://github.com/msm7x30/android_kernel_qcom_msm7x30Someone is working for a 3.10 kernel on msm7x30 Maybe Huawei devices are recommended, as it's maintained by LegacyHuawei's authors. Date: Thu, 18 Jun 2015 18:33:07 -0700 yeah, you should be able to figure out enough from the downstream android fbdev/gpu drivers.. I did find that the mdp4 code especially was a bit, umm, spaghetti code, so I found it easier to figure out how it worked by tracing the register reads/writes, etc.. see https://github.com/freedreno/kernel-msm/commits/ifc6410-vidre for the hacks I used. In https://github.com/freedreno/envytools/ there is a demsm tool to decode the registers into bitfields which will possibly be useful (note: iirc you might have to edit the log to s/MDP/MDP4/ or something approximately like that for demsm to work.. at some point when I started working on mdp5 I renamed MDP to MDP4 in the xml files which have the register definitions).. the gpu code in drivers/gpu/msm wasn't quite as messy as the drivers/video/msm code, so it should hopefully be easier to understand (but I still did similar trick for logging readl/writel).. fwiw, the first freedreno gpu support was a2xx, but at that time I was using the kgsl (drivers/gpu/msm) kernel code.. I wanted to add a2xx support in drivers/gpu/drm/msm but never found time (and lack of modern kernel supporting a2xx devices plus huge amount of work needed for a3xx didn't help for finding free time to work on drm/msm a2xx support) ― |
robclark
pushed a commit
that referenced
this issue
Jul 21, 2015
Repeated calls to begin_crtc_commit can cause warnings like this:
[ 169.127746] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:616
[ 169.127835] in_atomic(): 0, irqs_disabled(): 1, pid: 1947, name: kms_flip
[ 169.127840] 3 locks held by kms_flip/1947:
[ 169.127843] #0: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffff814774bc>] __drm_modeset_lock_all+0x9c/0x130
[ 169.127860] #1: (crtc_ww_class_acquire){+.+.+.}, at: [<ffffffff814774cd>] __drm_modeset_lock_all+0xad/0x130
[ 169.127870] #2: (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffff81477178>] drm_modeset_lock+0x38/0x110
[ 169.127879] irq event stamp: 665690
[ 169.127882] hardirqs last enabled at (665689): [<ffffffff817ffdb5>] _raw_spin_unlock_irqrestore+0x55/0x70
[ 169.127889] hardirqs last disabled at (665690): [<ffffffffc0197a23>] intel_pipe_update_start+0x113/0x5c0 [i915]
[ 169.127936] softirqs last enabled at (665470): [<ffffffff8108a766>] __do_softirq+0x236/0x650
[ 169.127942] softirqs last disabled at (665465): [<ffffffff8108ae75>] irq_exit+0xc5/0xd0
[ 169.127951] CPU: 1 PID: 1947 Comm: kms_flip Not tainted 4.1.0-rc4-patser+ #4039
[ 169.127954] Hardware name: LENOVO 2349AV8/2349AV8, BIOS G1ETA5WW (2.65 ) 04/15/2014
[ 169.127957] ffff8800c49036f0 ffff8800cde5fa28 ffffffff817f6907 0000000080000001
[ 169.127964] 0000000000000000 ffff8800cde5fa58 ffffffff810aebed 0000000000000046
[ 169.127970] ffffffff81c5d518 0000000000000268 0000000000000000 ffff8800cde5fa88
[ 169.127981] Call Trace:
[ 169.127992] [<ffffffff817f6907>] dump_stack+0x4f/0x7b
[ 169.128001] [<ffffffff810aebed>] ___might_sleep+0x16d/0x270
[ 169.128008] [<ffffffff810aed38>] __might_sleep+0x48/0x90
[ 169.128017] [<ffffffff817fc359>] mutex_lock_nested+0x29/0x410
[ 169.128073] [<ffffffffc01635f0>] ? vgpu_write64+0x220/0x220 [i915]
[ 169.128138] [<ffffffffc017fddf>] ? ironlake_update_primary_plane+0x2ff/0x410 [i915]
[ 169.128198] [<ffffffffc0190e75>] intel_frontbuffer_flush+0x25/0x70 [i915]
[ 169.128253] [<ffffffffc01831ac>] intel_finish_crtc_commit+0x4c/0x180 [i915]
[ 169.128279] [<ffffffffc00784ac>] drm_atomic_helper_commit_planes+0x12c/0x240 [drm_kms_helper]
[ 169.128338] [<ffffffffc0184264>] __intel_set_mode+0x684/0x830 [i915]
[ 169.128378] [<ffffffffc018a84a>] intel_crtc_set_config+0x49a/0x620 [i915]
[ 169.128385] [<ffffffff817fdd39>] ? mutex_unlock+0x9/0x10
[ 169.128391] [<ffffffff81467b69>] drm_mode_set_config_internal+0x69/0x120
[ 169.128398] [<ffffffff8119b547>] ? might_fault+0x57/0xb0
[ 169.128403] [<ffffffff8146bf93>] drm_mode_setcrtc+0x253/0x620
[ 169.128409] [<ffffffff8145c600>] drm_ioctl+0x1a0/0x6a0
[ 169.128415] [<ffffffff810b3b41>] ? get_parent_ip+0x11/0x50
[ 169.128424] [<ffffffff811e9ab8>] do_vfs_ioctl+0x2f8/0x530
[ 169.128429] [<ffffffff810d0fcd>] ? trace_hardirqs_on+0xd/0x10
[ 169.128435] [<ffffffff812e7676>] ? selinux_file_ioctl+0x56/0x100
[ 169.128439] [<ffffffff811e9d71>] SyS_ioctl+0x81/0xa0
[ 169.128445] [<ffffffff81800697>] system_call_fastpath+0x12/0x6f
Solve it by using the newly introduced drm_atomic_helper_commit_planes_on_crtc.
The problem here was that the drm_atomic_helper_commit_planes() helper
we were using was basically designed to do
begin_crtc_commit(crtc #1)
begin_crtc_commit(crtc #2)
...
commit all planes
finish_crtc_commit(crtc #1)
finish_crtc_commit(crtc #2)
The problem here is that since our hardware relies on vblank evasion,
our CRTC 'begin' function waits until we're out of the danger zone in
which register writes might wind up straddling the vblank, then disables
interrupts; our 'finish' function re-enables interrupts after the
registers have been written. The expectation is that the operations between
'begin' and 'end' must be performed without sleeping (since interrupts
are disabled) and should happen as quickly as possible. By clumping all
of the 'begin' calls together, we introducing a couple problems:
* Subsequent 'begin' invocations might sleep (which is illegal)
* The first 'begin' ensured that we were far enough from the vblank that
we could write our registers safely and ensure they all fell within
the same frame. Adding extra delay waiting for subsequent CRTC's
wasn't accounted for and could put us back into the 'danger zone' for
CRTC #1.
This commit solves the problem by using a new helper that allows an
order of operations like:
for each crtc {
begin_crtc_commit(crtc) // sleep (maybe), then disable interrupts
commit planes for this specific CRTC
end_crtc_commit(crtc) // reenable interrupts
}
so that sleeps will only be performed while interrupts are enabled and
we can be sure that registers for a CRTC will be written immediately
once we know we're in the safe zone.
The crtc->config->base.crtc update may seem unrelated, but the helper
will use it to obtain the crtc for the state. Without the update it
will dereference NULL and crash.
Changes since v1:
- Use Matt Roper's commit message.
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
robclark
pushed a commit
that referenced
this issue
Jul 21, 2015
Orabug: 20189959 PID: 614 TASK: ffff882a739da580 CPU: 3 COMMAND: "ocfs2dc" #0 [ffff882ecc3759b0] machine_kexec at ffffffff8103b35d #1 [ffff882ecc375a20] crash_kexec at ffffffff810b95b5 #2 [ffff882ecc375af0] oops_end at ffffffff815091d8 #3 [ffff882ecc375b20] die at ffffffff8101868b #4 [ffff882ecc375b50] do_trap at ffffffff81508bb0 #5 [ffff882ecc375ba0] do_invalid_op at ffffffff810165e5 #6 [ffff882ecc375c40] invalid_op at ffffffff815116fb [exception RIP: ocfs2_ci_checkpointed+208] RIP: ffffffffa0a7e940 RSP: ffff882ecc375cf0 RFLAGS: 00010002 RAX: 0000000000000001 RBX: 000000000000654b RCX: ffff8812dc83f1f8 RDX: 00000000000017d9 RSI: ffff8812dc83f1f8 RDI: ffffffffa0b2c318 RBP: ffff882ecc375d20 R8: ffff882ef6ecfa60 R9: ffff88301f272200 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffffffffff R13: ffff8812dc83f4f0 R14: 0000000000000000 R15: ffff8812dc83f1f8 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffff882ecc375d28] ocfs2_check_meta_downconvert at ffffffffa0a7edbd [ocfs2] #8 [ffff882ecc375d38] ocfs2_unblock_lock at ffffffffa0a84af8 [ocfs2] #9 [ffff882ecc375dc8] ocfs2_process_blocked_lock at ffffffffa0a85285 [ocfs2] #10 [ffff882ecc375e18] ocfs2_downconvert_thread_do_work at ffffffffa0a85445 [ocfs2] #11 [ffff882ecc375e68] ocfs2_downconvert_thread at ffffffffa0a854de [ocfs2] #12 [ffff882ecc375ee8] kthread at ffffffff81090da7 #13 [ffff882ecc375f48] kernel_thread_helper at ffffffff81511884 assert is tripped because the tran is not checkpointed and the lock level is PR. Some time ago, chmod command had been executed. As result, the following call chain left the inode cluster lock in PR state, latter on causing the assert. system_call_fastpath -> my_chmod -> sys_chmod -> sys_fchmodat -> notify_change -> ocfs2_setattr -> posix_acl_chmod -> ocfs2_iop_set_acl -> ocfs2_set_acl -> ocfs2_acl_set_mode Here is how. 1119 int ocfs2_setattr(struct dentry *dentry, struct iattr *attr) 1120 { 1247 ocfs2_inode_unlock(inode, 1); <<< WRONG thing to do. .. 1258 if (!status && attr->ia_valid & ATTR_MODE) { 1259 status = posix_acl_chmod(inode, inode->i_mode); 519 posix_acl_chmod(struct inode *inode, umode_t mode) 520 { .. 539 ret = inode->i_op->set_acl(inode, acl, ACL_TYPE_ACCESS); 287 int ocfs2_iop_set_acl(struct inode *inode, struct posix_acl *acl, ... 288 { 289 return ocfs2_set_acl(NULL, inode, NULL, type, acl, NULL, NULL); 224 int ocfs2_set_acl(handle_t *handle, 225 struct inode *inode, ... 231 { .. 252 ret = ocfs2_acl_set_mode(inode, di_bh, 253 handle, mode); 168 static int ocfs2_acl_set_mode(struct inode *inode, struct buffer_head ... 170 { 183 if (handle == NULL) { >>> BUG: inode lock not held in ex at this point <<< 184 handle = ocfs2_start_trans(OCFS2_SB(inode->i_sb), 185 OCFS2_INODE_UPDATE_CREDITS); ocfs2_setattr.#1247 we unlock and at #1259 call posix_acl_chmod. When we reach ocfs2_acl_set_mode.#181 and do trans, the inode cluster lock is not held in EX mode (it should be). How this could have happended? We are the lock master, were holding lock EX and have released it in ocfs2_setattr.#1247. Note that there are no holders of this lock at this point. Another node needs the lock in PR, and we downconvert from EX to PR. So the inode lock is PR when do the trans in ocfs2_acl_set_mode.#184. The trans stays in core (not flushed to disc). Now another node want the lock in EX, downconvert thread gets kicked (the one that tripped assert abovt), finds an unflushed trans but the lock is not EX (it is PR). If the lock was at EX, it would have flushed the trans ocfs2_ci_checkpointed -> ocfs2_start_checkpoint before downconverting (to NULL) for the request. ocfs2_setattr must not drop inode lock ex in this code path. If it does, takes it again before the trans, say in ocfs2_set_acl, another cluster node can get in between, execute another setattr, overwriting the one in progress on this node, resulting in a mode acl size combo that is a mix of the two. Signed-off-by: Tariq Saeed <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Joel Becker <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
robclark
pushed a commit
that referenced
this issue
Jul 21, 2015
Normally opening a file, unlinking it and then closing will have
the inode freed upon close() (provided that it's not otherwise busy and
has no remaining links, of course). However, there's one case where that
does *not* happen. Namely, if you open it by fhandle with cold dcache,
then unlink() and close().
In normal case you get d_delete() in unlink(2) notice that dentry
is busy and unhash it; on the final dput() it will be forcibly evicted from
dcache, triggering iput() and inode removal. In this case, though, we end
up with *two* dentries - disconnected (created by open-by-fhandle) and
regular one (used by unlink()). The latter will have its reference to inode
dropped just fine, but the former will not - it's considered hashed (it
is on the ->s_anon list), so it will stay around until the memory pressure
will finally do it in. As the result, we have the final iput() delayed
indefinitely. It's trivial to reproduce -
void flush_dcache(void)
{
system("mount -o remount,rw /");
}
static char buf[20 * 1024 * 1024];
main()
{
int fd;
union {
struct file_handle f;
char buf[MAX_HANDLE_SZ];
} x;
int m;
x.f.handle_bytes = sizeof(x);
chdir("/root");
mkdir("foo", 0700);
fd = open("foo/bar", O_CREAT | O_RDWR, 0600);
close(fd);
name_to_handle_at(AT_FDCWD, "foo/bar", &x.f, &m, 0);
flush_dcache();
fd = open_by_handle_at(AT_FDCWD, &x.f, O_RDWR);
unlink("foo/bar");
write(fd, buf, sizeof(buf));
system("df ."); /* 20Mb eaten */
close(fd);
system("df ."); /* should've freed those 20Mb */
flush_dcache();
system("df ."); /* should be the same as #2 */
}
will spit out something like
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 322023 303843 1131 100% /
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 322023 303843 1131 100% /
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 322023 283282 21692 93% /
- inode gets freed only when dentry is finally evicted (here we trigger
than by remount; normally it would've happened in response to memory
pressure hell knows when).
Cc: [email protected] # v2.6.38+; earlier ones need s/kill_it/unhash_it/
Acked-by: J. Bruce Fields <[email protected]>
Signed-off-by: Al Viro <[email protected]>
robclark
added a commit
that referenced
this issue
Oct 17, 2016
======================================================
[ INFO: RECLAIM_FS-safe -> RECLAIM_FS-unsafe lock order detected ]
4.7.0-rc7+ #520 Not tainted
------------------------------------------------------
bootanimation/2068 [HC0[0]:SC0[0]:HE1:SE1] is trying to acquire:
(prepare_lock){+.+.+.}, at: [<ffff0000087e6538>] clk_prepare_lock+0x48/0xe0
and this task is already holding:
(msm_iommu_lock){+.+.-.}, at: [<ffff0000084e9d44>] msm_iommu_unmap+0x34/0x130
which would create a new lock dependency:
(msm_iommu_lock){+.+.-.} -> (prepare_lock){+.+.+.}
but this new dependency connects a RECLAIM_FS-irq-safe lock:
(msm_iommu_lock){+.+.-.}
... which became RECLAIM_FS-irq-safe at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff000008107700>] __lock_acquire+0x518/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000084e9d44>] msm_iommu_unmap+0x34/0x130
[<ffff0000084e4c30>] iommu_unmap+0x98/0xf0
[<ffff000008546ac8>] msm_iommu_unmap+0x70/0xa8
[<ffff0000085422d4>] put_iova+0x7c/0x90
[<ffff000008543048>] msm_gem_purge+0x40/0xf0
[<ffff000008544170>] msm_gem_shrinker_scan+0xc8/0x160
[<ffff0000081883f8>] shrink_slab.part.5+0x190/0x2d0
[<ffff00000818ba04>] shrink_zone+0x324/0x328
[<ffff00000818c4f4>] kswapd+0x534/0x810
[<ffff0000080da134>] kthread+0xcc/0xe0
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
to a RECLAIM_FS-irq-unsafe lock:
(prepare_lock){+.+.+.}
... which became RECLAIM_FS-irq-unsafe at:
... [<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff000008105ce8>] mark_held_locks+0x70/0xb0
[<ffff000008106360>] lockdep_trace_alloc+0x70/0xc8
[<ffff0000081cc718>] __kmalloc+0x50/0x260
[<ffff000008479438>] qcom_rpm_smd_write+0x50/0x168
[<ffff0000087f5790>] clk_smd_rpm_set_rate_active+0x58/0x60
[<ffff0000087f5938>] clk_smd_rpm_prepare+0x78/0x108
[<ffff0000087e68d4>] clk_core_prepare+0x9c/0xc0
[<ffff0000087e8c68>] clk_prepare+0x20/0x50
[<ffff00000847fb34>] enable_nodeclk.isra.4.part.5+0x1c/0x98
[<ffff0000084805fc>] msm_bus_dev_init_qos+0x13c/0x308
[<ffff00000855a6a0>] bus_for_each_dev+0x60/0xa0
[<ffff000008480138>] msm_bus_device_probe+0x478/0x800
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c724>] __driver_attach+0xb4/0xb8
[<ffff00000855a6a0>] bus_for_each_dev+0x60/0xa0
[<ffff00000855c860>] driver_attach+0x20/0x28
[<ffff00000855b098>] bus_add_driver+0x110/0x228
[<ffff00000855cfb0>] driver_register+0x60/0xf8
[<ffff00000855e884>] __platform_driver_register+0x44/0x50
[<ffff000008e36bf8>] msm_bus_device_init_driver+0x2c/0x64
[<ffff000008e10c7c>] do_one_initcall+0x84/0x118
[<ffff000008e10e54>] kernel_init_freeable+0x144/0x1e8
[<ffff000008abe188>] kernel_init+0x10/0x100
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(prepare_lock);
local_irq_disable();
lock(msm_iommu_lock);
lock(prepare_lock);
<Interrupt>
lock(msm_iommu_lock);
*** DEADLOCK ***
3 locks held by bootanimation/2068:
#0: (drm_global_mutex){+.+.+.}, at: [<ffff000008503e88>] drm_release+0x40/0x348
#1: (&dev->struct_mutex){+.+.+.}, at: [<ffff000008504ee0>] drm_gem_object_unreference_unlocked+0x140/0x178
#2: (msm_iommu_lock){+.+.-.}, at: [<ffff0000084e9d44>] msm_iommu_unmap+0x34/0x130
the dependencies between RECLAIM_FS-irq-safe lock and the holding lock:
-> (msm_iommu_lock){+.+.-.} ops: 19991 {
HARDIRQ-ON-W at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff0000081076c0>] __lock_acquire+0x4d8/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000084ea17c>] msm_iommu_attach_dev+0x34/0x738
[<ffff0000084e4988>] iommu_attach_device+0xa0/0xd8
[<ffff00000854699c>] msm_iommu_attach+0x54/0x110
[<ffff00000853a780>] mdp5_kms_init+0x150/0x790
[<ffff0000085413cc>] msm_drm_bind+0x234/0x528
[<ffff000008556cd4>] try_to_bring_up_master+0x144/0x1a8
[<ffff0000085573c0>] component_add+0x98/0x160
[<ffff000008549dd4>] dsi_dev_probe+0x1c/0x28
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c7bc>] __device_attach_driver+0x94/0xd8
[<ffff00000855abe0>] bus_for_each_drv+0x58/0x98
[<ffff00000855c284>] __device_attach+0xcc/0x140
[<ffff00000855c838>] device_initial_probe+0x10/0x18
[<ffff00000855ae64>] bus_probe_device+0x94/0xa0
[<ffff00000855bb68>] deferred_probe_work_func+0x78/0xb0
[<ffff0000080d3064>] process_one_work+0x22c/0x440
[<ffff0000080d32c0>] worker_thread+0x48/0x498
[<ffff0000080da134>] kthread+0xcc/0xe0
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
SOFTIRQ-ON-W at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff0000081076e4>] __lock_acquire+0x4fc/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000084ea17c>] msm_iommu_attach_dev+0x34/0x738
[<ffff0000084e4988>] iommu_attach_device+0xa0/0xd8
[<ffff00000854699c>] msm_iommu_attach+0x54/0x110
[<ffff00000853a780>] mdp5_kms_init+0x150/0x790
[<ffff0000085413cc>] msm_drm_bind+0x234/0x528
[<ffff000008556cd4>] try_to_bring_up_master+0x144/0x1a8
[<ffff0000085573c0>] component_add+0x98/0x160
[<ffff000008549dd4>] dsi_dev_probe+0x1c/0x28
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c7bc>] __device_attach_driver+0x94/0xd8
[<ffff00000855abe0>] bus_for_each_drv+0x58/0x98
[<ffff00000855c284>] __device_attach+0xcc/0x140
[<ffff00000855c838>] device_initial_probe+0x10/0x18
[<ffff00000855ae64>] bus_probe_device+0x94/0xa0
[<ffff00000855bb68>] deferred_probe_work_func+0x78/0xb0
[<ffff0000080d3064>] process_one_work+0x22c/0x440
[<ffff0000080d32c0>] worker_thread+0x48/0x498
[<ffff0000080da134>] kthread+0xcc/0xe0
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
IN-RECLAIM_FS-W at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff000008107700>] __lock_acquire+0x518/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000084e9d44>] msm_iommu_unmap+0x34/0x130
[<ffff0000084e4c30>] iommu_unmap+0x98/0xf0
[<ffff000008546ac8>] msm_iommu_unmap+0x70/0xa8
[<ffff0000085422d4>] put_iova+0x7c/0x90
[<ffff000008543048>] msm_gem_purge+0x40/0xf0
[<ffff000008544170>] msm_gem_shrinker_scan+0xc8/0x160
[<ffff0000081883f8>] shrink_slab.part.5+0x190/0x2d0
[<ffff00000818ba04>] shrink_zone+0x324/0x328
[<ffff00000818c4f4>] kswapd+0x534/0x810
[<ffff0000080da134>] kthread+0xcc/0xe0
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
INITIAL USE at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff0000081074b4>] __lock_acquire+0x2cc/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000084ea17c>] msm_iommu_attach_dev+0x34/0x738
[<ffff0000084e4988>] iommu_attach_device+0xa0/0xd8
[<ffff00000854699c>] msm_iommu_attach+0x54/0x110
[<ffff00000853a780>] mdp5_kms_init+0x150/0x790
[<ffff0000085413cc>] msm_drm_bind+0x234/0x528
[<ffff000008556cd4>] try_to_bring_up_master+0x144/0x1a8
[<ffff0000085573c0>] component_add+0x98/0x160
[<ffff000008549dd4>] dsi_dev_probe+0x1c/0x28
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c7bc>] __device_attach_driver+0x94/0xd8
[<ffff00000855abe0>] bus_for_each_drv+0x58/0x98
[<ffff00000855c284>] __device_attach+0xcc/0x140
[<ffff00000855c838>] device_initial_probe+0x10/0x18
[<ffff00000855ae64>] bus_probe_device+0x94/0xa0
[<ffff00000855bb68>] deferred_probe_work_func+0x78/0xb0
[<ffff0000080d3064>] process_one_work+0x22c/0x440
[<ffff0000080d32c0>] worker_thread+0x48/0x498
[<ffff0000080da134>] kthread+0xcc/0xe0
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
}
... key at: [<ffff000008f22120>] msm_iommu_lock+0x60/0x80
... acquired at:
[<ffff000008105250>] check_usage+0x408/0x5c0
[<ffff000008105460>] check_irq_usage+0x58/0xc8
[<ffff000008108230>] __lock_acquire+0x1048/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000087e6538>] clk_prepare_lock+0x48/0xe0
[<ffff0000087e8c60>] clk_prepare+0x18/0x50
[<ffff0000084e98b8>] __enable_clocks+0x20/0xc0
[<ffff0000084e9d94>] msm_iommu_unmap+0x84/0x130
[<ffff0000084e4c30>] iommu_unmap+0x98/0xf0
[<ffff000008546ac8>] msm_iommu_unmap+0x70/0xa8
[<ffff0000085422d4>] put_iova+0x7c/0x90
[<ffff000008543888>] msm_gem_free_object+0x58/0x1c8
[<ffff000008504d64>] drm_gem_object_free+0x1c/0x58
[<ffff000008504f04>] drm_gem_object_unreference_unlocked+0x164/0x178
[<ffff000008504f7c>] drm_gem_object_handle_unreference_unlocked+0x64/0xb0
[<ffff00000850501c>] drm_gem_object_release_handle+0x54/0x98
[<ffff0000083b9e08>] idr_for_each+0xd0/0x130
[<ffff000008504cec>] drm_gem_release+0x24/0x38
[<ffff0000085040a4>] drm_release+0x25c/0x348
[<ffff0000081e9874>] __fput+0x84/0x1b0
[<ffff0000081e9a04>] ____fput+0xc/0x18
[<ffff0000080d8bf0>] task_work_run+0xc8/0xe8
[<ffff0000080bdba8>] do_exit+0x2d8/0xa00
[<ffff0000080be338>] do_group_exit+0x38/0xa0
[<ffff0000080be3b0>] __wake_up_parent+0x0/0x28
[<ffff000008084f30>] el0_svc_naked+0x24/0x28
the dependencies between the lock to be acquired and RECLAIM_FS-irq-unsafe lock:
-> (prepare_lock){+.+.+.} ops: 11866 {
HARDIRQ-ON-W at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff000008105ce8>] mark_held_locks+0x70/0xb0
[<ffff000008105db8>] trace_hardirqs_on_caller+0x90/0x180
[<ffff000008105eb8>] trace_hardirqs_on+0x10/0x18
[<ffff000008ac55bc>] mutex_trylock+0x124/0x1f0
[<ffff0000087e6510>] clk_prepare_lock+0x20/0xe0
[<ffff0000087e8958>] __clk_create_clk.part.12+0x50/0xa0
[<ffff0000087e9510>] clk_register+0x190/0x5f8
[<ffff0000087e9be0>] devm_clk_register+0x48/0xa0
[<ffff0000087eeacc>] _qcom_cc_register_board_clk+0xc4/0x128
[<ffff0000087eece4>] qcom_cc_register_board_clk+0x54/0x68
[<ffff0000087f49c4>] gcc_msm8916_probe+0x34/0x70
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c7bc>] __device_attach_driver+0x94/0xd8
[<ffff00000855abe0>] bus_for_each_drv+0x58/0x98
[<ffff00000855c284>] __device_attach+0xcc/0x140
[<ffff00000855c838>] device_initial_probe+0x10/0x18
[<ffff00000855ae64>] bus_probe_device+0x94/0xa0
[<ffff000008559a2c>] device_add+0x354/0x548
[<ffff0000087da5a4>] of_device_add+0x5c/0x70
[<ffff0000087db000>] of_platform_device_create_pdata+0x90/0xf0
[<ffff0000087db12c>] of_platform_bus_create+0xcc/0x328
[<ffff0000087db16c>] of_platform_bus_create+0x10c/0x328
[<ffff0000087db4d4>] of_platform_populate+0x4c/0xb0
[<ffff000008e1345c>] arm64_device_init+0x30/0x58
[<ffff000008e10c7c>] do_one_initcall+0x84/0x118
[<ffff000008e10e54>] kernel_init_freeable+0x144/0x1e8
[<ffff000008abe188>] kernel_init+0x10/0x100
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
SOFTIRQ-ON-W at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff000008105ce8>] mark_held_locks+0x70/0xb0
[<ffff000008105e0c>] trace_hardirqs_on_caller+0xe4/0x180
[<ffff000008105eb8>] trace_hardirqs_on+0x10/0x18
[<ffff000008ac55bc>] mutex_trylock+0x124/0x1f0
[<ffff0000087e6510>] clk_prepare_lock+0x20/0xe0
[<ffff0000087e8958>] __clk_create_clk.part.12+0x50/0xa0
[<ffff0000087e9510>] clk_register+0x190/0x5f8
[<ffff0000087e9be0>] devm_clk_register+0x48/0xa0
[<ffff0000087eeacc>] _qcom_cc_register_board_clk+0xc4/0x128
[<ffff0000087eece4>] qcom_cc_register_board_clk+0x54/0x68
[<ffff0000087f49c4>] gcc_msm8916_probe+0x34/0x70
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c7bc>] __device_attach_driver+0x94/0xd8
[<ffff00000855abe0>] bus_for_each_drv+0x58/0x98
[<ffff00000855c284>] __device_attach+0xcc/0x140
[<ffff00000855c838>] device_initial_probe+0x10/0x18
[<ffff00000855ae64>] bus_probe_device+0x94/0xa0
[<ffff000008559a2c>] device_add+0x354/0x548
[<ffff0000087da5a4>] of_device_add+0x5c/0x70
[<ffff0000087db000>] of_platform_device_create_pdata+0x90/0xf0
[<ffff0000087db12c>] of_platform_bus_create+0xcc/0x328
[<ffff0000087db16c>] of_platform_bus_create+0x10c/0x328
[<ffff0000087db4d4>] of_platform_populate+0x4c/0xb0
[<ffff000008e1345c>] arm64_device_init+0x30/0x58
[<ffff000008e10c7c>] do_one_initcall+0x84/0x118
[<ffff000008e10e54>] kernel_init_freeable+0x144/0x1e8
[<ffff000008abe188>] kernel_init+0x10/0x100
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
RECLAIM_FS-ON-W at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff000008105ce8>] mark_held_locks+0x70/0xb0
[<ffff000008106360>] lockdep_trace_alloc+0x70/0xc8
[<ffff0000081cc718>] __kmalloc+0x50/0x260
[<ffff000008479438>] qcom_rpm_smd_write+0x50/0x168
[<ffff0000087f5790>] clk_smd_rpm_set_rate_active+0x58/0x60
[<ffff0000087f5938>] clk_smd_rpm_prepare+0x78/0x108
[<ffff0000087e68d4>] clk_core_prepare+0x9c/0xc0
[<ffff0000087e8c68>] clk_prepare+0x20/0x50
[<ffff00000847fb34>] enable_nodeclk.isra.4.part.5+0x1c/0x98
[<ffff0000084805fc>] msm_bus_dev_init_qos+0x13c/0x308
[<ffff00000855a6a0>] bus_for_each_dev+0x60/0xa0
[<ffff000008480138>] msm_bus_device_probe+0x478/0x800
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c724>] __driver_attach+0xb4/0xb8
[<ffff00000855a6a0>] bus_for_each_dev+0x60/0xa0
[<ffff00000855c860>] driver_attach+0x20/0x28
[<ffff00000855b098>] bus_add_driver+0x110/0x228
[<ffff00000855cfb0>] driver_register+0x60/0xf8
[<ffff00000855e884>] __platform_driver_register+0x44/0x50
[<ffff000008e36bf8>] msm_bus_device_init_driver+0x2c/0x64
[<ffff000008e10c7c>] do_one_initcall+0x84/0x118
[<ffff000008e10e54>] kernel_init_freeable+0x144/0x1e8
[<ffff000008abe188>] kernel_init+0x10/0x100
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
INITIAL USE at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff0000081074b4>] __lock_acquire+0x2cc/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac5590>] mutex_trylock+0xf8/0x1f0
[<ffff0000087e6510>] clk_prepare_lock+0x20/0xe0
[<ffff0000087e8958>] __clk_create_clk.part.12+0x50/0xa0
[<ffff0000087e9510>] clk_register+0x190/0x5f8
[<ffff0000087e9984>] clk_hw_register+0xc/0x20
[<ffff0000087eb76c>] clk_hw_register_fixed_rate_with_accuracy+0x94/0xe0
[<ffff0000087eb83c>] of_fixed_clk_setup+0x84/0xb8
[<ffff000008e48858>] of_clk_init+0x154/0x1e4
[<ffff000008e139f4>] time_init+0x10/0x44
[<ffff000008e10ab0>] start_kernel+0x254/0x39c
[<ffff000008e101bc>] __primary_switched+0x30/0x6c
}
... key at: [<ffff000008f59d78>] prepare_lock+0x60/0x80
... acquired at:
[<ffff000008105284>] check_usage+0x43c/0x5c0
[<ffff000008105460>] check_irq_usage+0x58/0xc8
[<ffff000008108230>] __lock_acquire+0x1048/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000087e6538>] clk_prepare_lock+0x48/0xe0
[<ffff0000087e8c60>] clk_prepare+0x18/0x50
[<ffff0000084e98b8>] __enable_clocks+0x20/0xc0
[<ffff0000084e9d94>] msm_iommu_unmap+0x84/0x130
[<ffff0000084e4c30>] iommu_unmap+0x98/0xf0
[<ffff000008546ac8>] msm_iommu_unmap+0x70/0xa8
[<ffff0000085422d4>] put_iova+0x7c/0x90
[<ffff000008543888>] msm_gem_free_object+0x58/0x1c8
[<ffff000008504d64>] drm_gem_object_free+0x1c/0x58
[<ffff000008504f04>] drm_gem_object_unreference_unlocked+0x164/0x178
[<ffff000008504f7c>] drm_gem_object_handle_unreference_unlocked+0x64/0xb0
[<ffff00000850501c>] drm_gem_object_release_handle+0x54/0x98
[<ffff0000083b9e08>] idr_for_each+0xd0/0x130
[<ffff000008504cec>] drm_gem_release+0x24/0x38
[<ffff0000085040a4>] drm_release+0x25c/0x348
[<ffff0000081e9874>] __fput+0x84/0x1b0
[<ffff0000081e9a04>] ____fput+0xc/0x18
[<ffff0000080d8bf0>] task_work_run+0xc8/0xe8
[<ffff0000080bdba8>] do_exit+0x2d8/0xa00
[<ffff0000080be338>] do_group_exit+0x38/0xa0
[<ffff0000080be3b0>] __wake_up_parent+0x0/0x28
[<ffff000008084f30>] el0_svc_naked+0x24/0x28
stack backtrace:
CPU: 1 PID: 2068 Comm: bootanimation Not tainted 4.7.0-rc7+ #520
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
Call trace:
[<ffff000008088be8>] dump_backtrace+0x0/0x1a8
[<ffff000008088da4>] show_stack+0x14/0x20
[<ffff0000083b8234>] dump_stack+0xb4/0xf0
[<ffff0000081052a4>] check_usage+0x45c/0x5c0
[<ffff000008105460>] check_irq_usage+0x58/0xc8
[<ffff000008108230>] __lock_acquire+0x1048/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000087e6538>] clk_prepare_lock+0x48/0xe0
[<ffff0000087e8c60>] clk_prepare+0x18/0x50
[<ffff0000084e98b8>] __enable_clocks+0x20/0xc0
[<ffff0000084e9d94>] msm_iommu_unmap+0x84/0x130
[<ffff0000084e4c30>] iommu_unmap+0x98/0xf0
[<ffff000008546ac8>] msm_iommu_unmap+0x70/0xa8
[<ffff0000085422d4>] put_iova+0x7c/0x90
[<ffff000008543888>] msm_gem_free_object+0x58/0x1c8
[<ffff000008504d64>] drm_gem_object_free+0x1c/0x58
[<ffff000008504f04>] drm_gem_object_unreference_unlocked+0x164/0x178
[<ffff000008504f7c>] drm_gem_object_handle_unreference_unlocked+0x64/0xb0
[<ffff00000850501c>] drm_gem_object_release_handle+0x54/0x98
[<ffff0000083b9e08>] idr_for_each+0xd0/0x130
[<ffff000008504cec>] drm_gem_release+0x24/0x38
[<ffff0000085040a4>] drm_release+0x25c/0x348
[<ffff0000081e9874>] __fput+0x84/0x1b0
[<ffff0000081e9a04>] ____fput+0xc/0x18
[<ffff0000080d8bf0>] task_work_run+0xc8/0xe8
[<ffff0000080bdba8>] do_exit+0x2d8/0xa00
[<ffff0000080be338>] do_group_exit+0x38/0xa0
[<ffff0000080be3b0>] __wake_up_parent+0x0/0x28
[<ffff000008084f30>] el0_svc_naked+0x24/0x28
Signed-off-by: Rob Clark <[email protected]>
robclark
added a commit
that referenced
this issue
Oct 27, 2016
======================================================
[ INFO: RECLAIM_FS-safe -> RECLAIM_FS-unsafe lock order detected ]
4.7.0-rc7+ #520 Not tainted
------------------------------------------------------
bootanimation/2068 [HC0[0]:SC0[0]:HE1:SE1] is trying to acquire:
(prepare_lock){+.+.+.}, at: [<ffff0000087e6538>] clk_prepare_lock+0x48/0xe0
and this task is already holding:
(msm_iommu_lock){+.+.-.}, at: [<ffff0000084e9d44>] msm_iommu_unmap+0x34/0x130
which would create a new lock dependency:
(msm_iommu_lock){+.+.-.} -> (prepare_lock){+.+.+.}
but this new dependency connects a RECLAIM_FS-irq-safe lock:
(msm_iommu_lock){+.+.-.}
... which became RECLAIM_FS-irq-safe at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff000008107700>] __lock_acquire+0x518/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000084e9d44>] msm_iommu_unmap+0x34/0x130
[<ffff0000084e4c30>] iommu_unmap+0x98/0xf0
[<ffff000008546ac8>] msm_iommu_unmap+0x70/0xa8
[<ffff0000085422d4>] put_iova+0x7c/0x90
[<ffff000008543048>] msm_gem_purge+0x40/0xf0
[<ffff000008544170>] msm_gem_shrinker_scan+0xc8/0x160
[<ffff0000081883f8>] shrink_slab.part.5+0x190/0x2d0
[<ffff00000818ba04>] shrink_zone+0x324/0x328
[<ffff00000818c4f4>] kswapd+0x534/0x810
[<ffff0000080da134>] kthread+0xcc/0xe0
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
to a RECLAIM_FS-irq-unsafe lock:
(prepare_lock){+.+.+.}
... which became RECLAIM_FS-irq-unsafe at:
... [<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff000008105ce8>] mark_held_locks+0x70/0xb0
[<ffff000008106360>] lockdep_trace_alloc+0x70/0xc8
[<ffff0000081cc718>] __kmalloc+0x50/0x260
[<ffff000008479438>] qcom_rpm_smd_write+0x50/0x168
[<ffff0000087f5790>] clk_smd_rpm_set_rate_active+0x58/0x60
[<ffff0000087f5938>] clk_smd_rpm_prepare+0x78/0x108
[<ffff0000087e68d4>] clk_core_prepare+0x9c/0xc0
[<ffff0000087e8c68>] clk_prepare+0x20/0x50
[<ffff00000847fb34>] enable_nodeclk.isra.4.part.5+0x1c/0x98
[<ffff0000084805fc>] msm_bus_dev_init_qos+0x13c/0x308
[<ffff00000855a6a0>] bus_for_each_dev+0x60/0xa0
[<ffff000008480138>] msm_bus_device_probe+0x478/0x800
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c724>] __driver_attach+0xb4/0xb8
[<ffff00000855a6a0>] bus_for_each_dev+0x60/0xa0
[<ffff00000855c860>] driver_attach+0x20/0x28
[<ffff00000855b098>] bus_add_driver+0x110/0x228
[<ffff00000855cfb0>] driver_register+0x60/0xf8
[<ffff00000855e884>] __platform_driver_register+0x44/0x50
[<ffff000008e36bf8>] msm_bus_device_init_driver+0x2c/0x64
[<ffff000008e10c7c>] do_one_initcall+0x84/0x118
[<ffff000008e10e54>] kernel_init_freeable+0x144/0x1e8
[<ffff000008abe188>] kernel_init+0x10/0x100
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(prepare_lock);
local_irq_disable();
lock(msm_iommu_lock);
lock(prepare_lock);
<Interrupt>
lock(msm_iommu_lock);
*** DEADLOCK ***
3 locks held by bootanimation/2068:
#0: (drm_global_mutex){+.+.+.}, at: [<ffff000008503e88>] drm_release+0x40/0x348
#1: (&dev->struct_mutex){+.+.+.}, at: [<ffff000008504ee0>] drm_gem_object_unreference_unlocked+0x140/0x178
#2: (msm_iommu_lock){+.+.-.}, at: [<ffff0000084e9d44>] msm_iommu_unmap+0x34/0x130
the dependencies between RECLAIM_FS-irq-safe lock and the holding lock:
-> (msm_iommu_lock){+.+.-.} ops: 19991 {
HARDIRQ-ON-W at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff0000081076c0>] __lock_acquire+0x4d8/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000084ea17c>] msm_iommu_attach_dev+0x34/0x738
[<ffff0000084e4988>] iommu_attach_device+0xa0/0xd8
[<ffff00000854699c>] msm_iommu_attach+0x54/0x110
[<ffff00000853a780>] mdp5_kms_init+0x150/0x790
[<ffff0000085413cc>] msm_drm_bind+0x234/0x528
[<ffff000008556cd4>] try_to_bring_up_master+0x144/0x1a8
[<ffff0000085573c0>] component_add+0x98/0x160
[<ffff000008549dd4>] dsi_dev_probe+0x1c/0x28
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c7bc>] __device_attach_driver+0x94/0xd8
[<ffff00000855abe0>] bus_for_each_drv+0x58/0x98
[<ffff00000855c284>] __device_attach+0xcc/0x140
[<ffff00000855c838>] device_initial_probe+0x10/0x18
[<ffff00000855ae64>] bus_probe_device+0x94/0xa0
[<ffff00000855bb68>] deferred_probe_work_func+0x78/0xb0
[<ffff0000080d3064>] process_one_work+0x22c/0x440
[<ffff0000080d32c0>] worker_thread+0x48/0x498
[<ffff0000080da134>] kthread+0xcc/0xe0
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
SOFTIRQ-ON-W at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff0000081076e4>] __lock_acquire+0x4fc/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000084ea17c>] msm_iommu_attach_dev+0x34/0x738
[<ffff0000084e4988>] iommu_attach_device+0xa0/0xd8
[<ffff00000854699c>] msm_iommu_attach+0x54/0x110
[<ffff00000853a780>] mdp5_kms_init+0x150/0x790
[<ffff0000085413cc>] msm_drm_bind+0x234/0x528
[<ffff000008556cd4>] try_to_bring_up_master+0x144/0x1a8
[<ffff0000085573c0>] component_add+0x98/0x160
[<ffff000008549dd4>] dsi_dev_probe+0x1c/0x28
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c7bc>] __device_attach_driver+0x94/0xd8
[<ffff00000855abe0>] bus_for_each_drv+0x58/0x98
[<ffff00000855c284>] __device_attach+0xcc/0x140
[<ffff00000855c838>] device_initial_probe+0x10/0x18
[<ffff00000855ae64>] bus_probe_device+0x94/0xa0
[<ffff00000855bb68>] deferred_probe_work_func+0x78/0xb0
[<ffff0000080d3064>] process_one_work+0x22c/0x440
[<ffff0000080d32c0>] worker_thread+0x48/0x498
[<ffff0000080da134>] kthread+0xcc/0xe0
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
IN-RECLAIM_FS-W at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff000008107700>] __lock_acquire+0x518/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000084e9d44>] msm_iommu_unmap+0x34/0x130
[<ffff0000084e4c30>] iommu_unmap+0x98/0xf0
[<ffff000008546ac8>] msm_iommu_unmap+0x70/0xa8
[<ffff0000085422d4>] put_iova+0x7c/0x90
[<ffff000008543048>] msm_gem_purge+0x40/0xf0
[<ffff000008544170>] msm_gem_shrinker_scan+0xc8/0x160
[<ffff0000081883f8>] shrink_slab.part.5+0x190/0x2d0
[<ffff00000818ba04>] shrink_zone+0x324/0x328
[<ffff00000818c4f4>] kswapd+0x534/0x810
[<ffff0000080da134>] kthread+0xcc/0xe0
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
INITIAL USE at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff0000081074b4>] __lock_acquire+0x2cc/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000084ea17c>] msm_iommu_attach_dev+0x34/0x738
[<ffff0000084e4988>] iommu_attach_device+0xa0/0xd8
[<ffff00000854699c>] msm_iommu_attach+0x54/0x110
[<ffff00000853a780>] mdp5_kms_init+0x150/0x790
[<ffff0000085413cc>] msm_drm_bind+0x234/0x528
[<ffff000008556cd4>] try_to_bring_up_master+0x144/0x1a8
[<ffff0000085573c0>] component_add+0x98/0x160
[<ffff000008549dd4>] dsi_dev_probe+0x1c/0x28
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c7bc>] __device_attach_driver+0x94/0xd8
[<ffff00000855abe0>] bus_for_each_drv+0x58/0x98
[<ffff00000855c284>] __device_attach+0xcc/0x140
[<ffff00000855c838>] device_initial_probe+0x10/0x18
[<ffff00000855ae64>] bus_probe_device+0x94/0xa0
[<ffff00000855bb68>] deferred_probe_work_func+0x78/0xb0
[<ffff0000080d3064>] process_one_work+0x22c/0x440
[<ffff0000080d32c0>] worker_thread+0x48/0x498
[<ffff0000080da134>] kthread+0xcc/0xe0
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
}
... key at: [<ffff000008f22120>] msm_iommu_lock+0x60/0x80
... acquired at:
[<ffff000008105250>] check_usage+0x408/0x5c0
[<ffff000008105460>] check_irq_usage+0x58/0xc8
[<ffff000008108230>] __lock_acquire+0x1048/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000087e6538>] clk_prepare_lock+0x48/0xe0
[<ffff0000087e8c60>] clk_prepare+0x18/0x50
[<ffff0000084e98b8>] __enable_clocks+0x20/0xc0
[<ffff0000084e9d94>] msm_iommu_unmap+0x84/0x130
[<ffff0000084e4c30>] iommu_unmap+0x98/0xf0
[<ffff000008546ac8>] msm_iommu_unmap+0x70/0xa8
[<ffff0000085422d4>] put_iova+0x7c/0x90
[<ffff000008543888>] msm_gem_free_object+0x58/0x1c8
[<ffff000008504d64>] drm_gem_object_free+0x1c/0x58
[<ffff000008504f04>] drm_gem_object_unreference_unlocked+0x164/0x178
[<ffff000008504f7c>] drm_gem_object_handle_unreference_unlocked+0x64/0xb0
[<ffff00000850501c>] drm_gem_object_release_handle+0x54/0x98
[<ffff0000083b9e08>] idr_for_each+0xd0/0x130
[<ffff000008504cec>] drm_gem_release+0x24/0x38
[<ffff0000085040a4>] drm_release+0x25c/0x348
[<ffff0000081e9874>] __fput+0x84/0x1b0
[<ffff0000081e9a04>] ____fput+0xc/0x18
[<ffff0000080d8bf0>] task_work_run+0xc8/0xe8
[<ffff0000080bdba8>] do_exit+0x2d8/0xa00
[<ffff0000080be338>] do_group_exit+0x38/0xa0
[<ffff0000080be3b0>] __wake_up_parent+0x0/0x28
[<ffff000008084f30>] el0_svc_naked+0x24/0x28
the dependencies between the lock to be acquired and RECLAIM_FS-irq-unsafe lock:
-> (prepare_lock){+.+.+.} ops: 11866 {
HARDIRQ-ON-W at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff000008105ce8>] mark_held_locks+0x70/0xb0
[<ffff000008105db8>] trace_hardirqs_on_caller+0x90/0x180
[<ffff000008105eb8>] trace_hardirqs_on+0x10/0x18
[<ffff000008ac55bc>] mutex_trylock+0x124/0x1f0
[<ffff0000087e6510>] clk_prepare_lock+0x20/0xe0
[<ffff0000087e8958>] __clk_create_clk.part.12+0x50/0xa0
[<ffff0000087e9510>] clk_register+0x190/0x5f8
[<ffff0000087e9be0>] devm_clk_register+0x48/0xa0
[<ffff0000087eeacc>] _qcom_cc_register_board_clk+0xc4/0x128
[<ffff0000087eece4>] qcom_cc_register_board_clk+0x54/0x68
[<ffff0000087f49c4>] gcc_msm8916_probe+0x34/0x70
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c7bc>] __device_attach_driver+0x94/0xd8
[<ffff00000855abe0>] bus_for_each_drv+0x58/0x98
[<ffff00000855c284>] __device_attach+0xcc/0x140
[<ffff00000855c838>] device_initial_probe+0x10/0x18
[<ffff00000855ae64>] bus_probe_device+0x94/0xa0
[<ffff000008559a2c>] device_add+0x354/0x548
[<ffff0000087da5a4>] of_device_add+0x5c/0x70
[<ffff0000087db000>] of_platform_device_create_pdata+0x90/0xf0
[<ffff0000087db12c>] of_platform_bus_create+0xcc/0x328
[<ffff0000087db16c>] of_platform_bus_create+0x10c/0x328
[<ffff0000087db4d4>] of_platform_populate+0x4c/0xb0
[<ffff000008e1345c>] arm64_device_init+0x30/0x58
[<ffff000008e10c7c>] do_one_initcall+0x84/0x118
[<ffff000008e10e54>] kernel_init_freeable+0x144/0x1e8
[<ffff000008abe188>] kernel_init+0x10/0x100
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
SOFTIRQ-ON-W at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff000008105ce8>] mark_held_locks+0x70/0xb0
[<ffff000008105e0c>] trace_hardirqs_on_caller+0xe4/0x180
[<ffff000008105eb8>] trace_hardirqs_on+0x10/0x18
[<ffff000008ac55bc>] mutex_trylock+0x124/0x1f0
[<ffff0000087e6510>] clk_prepare_lock+0x20/0xe0
[<ffff0000087e8958>] __clk_create_clk.part.12+0x50/0xa0
[<ffff0000087e9510>] clk_register+0x190/0x5f8
[<ffff0000087e9be0>] devm_clk_register+0x48/0xa0
[<ffff0000087eeacc>] _qcom_cc_register_board_clk+0xc4/0x128
[<ffff0000087eece4>] qcom_cc_register_board_clk+0x54/0x68
[<ffff0000087f49c4>] gcc_msm8916_probe+0x34/0x70
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c7bc>] __device_attach_driver+0x94/0xd8
[<ffff00000855abe0>] bus_for_each_drv+0x58/0x98
[<ffff00000855c284>] __device_attach+0xcc/0x140
[<ffff00000855c838>] device_initial_probe+0x10/0x18
[<ffff00000855ae64>] bus_probe_device+0x94/0xa0
[<ffff000008559a2c>] device_add+0x354/0x548
[<ffff0000087da5a4>] of_device_add+0x5c/0x70
[<ffff0000087db000>] of_platform_device_create_pdata+0x90/0xf0
[<ffff0000087db12c>] of_platform_bus_create+0xcc/0x328
[<ffff0000087db16c>] of_platform_bus_create+0x10c/0x328
[<ffff0000087db4d4>] of_platform_populate+0x4c/0xb0
[<ffff000008e1345c>] arm64_device_init+0x30/0x58
[<ffff000008e10c7c>] do_one_initcall+0x84/0x118
[<ffff000008e10e54>] kernel_init_freeable+0x144/0x1e8
[<ffff000008abe188>] kernel_init+0x10/0x100
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
RECLAIM_FS-ON-W at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff000008105ce8>] mark_held_locks+0x70/0xb0
[<ffff000008106360>] lockdep_trace_alloc+0x70/0xc8
[<ffff0000081cc718>] __kmalloc+0x50/0x260
[<ffff000008479438>] qcom_rpm_smd_write+0x50/0x168
[<ffff0000087f5790>] clk_smd_rpm_set_rate_active+0x58/0x60
[<ffff0000087f5938>] clk_smd_rpm_prepare+0x78/0x108
[<ffff0000087e68d4>] clk_core_prepare+0x9c/0xc0
[<ffff0000087e8c68>] clk_prepare+0x20/0x50
[<ffff00000847fb34>] enable_nodeclk.isra.4.part.5+0x1c/0x98
[<ffff0000084805fc>] msm_bus_dev_init_qos+0x13c/0x308
[<ffff00000855a6a0>] bus_for_each_dev+0x60/0xa0
[<ffff000008480138>] msm_bus_device_probe+0x478/0x800
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c724>] __driver_attach+0xb4/0xb8
[<ffff00000855a6a0>] bus_for_each_dev+0x60/0xa0
[<ffff00000855c860>] driver_attach+0x20/0x28
[<ffff00000855b098>] bus_add_driver+0x110/0x228
[<ffff00000855cfb0>] driver_register+0x60/0xf8
[<ffff00000855e884>] __platform_driver_register+0x44/0x50
[<ffff000008e36bf8>] msm_bus_device_init_driver+0x2c/0x64
[<ffff000008e10c7c>] do_one_initcall+0x84/0x118
[<ffff000008e10e54>] kernel_init_freeable+0x144/0x1e8
[<ffff000008abe188>] kernel_init+0x10/0x100
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
INITIAL USE at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff0000081074b4>] __lock_acquire+0x2cc/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac5590>] mutex_trylock+0xf8/0x1f0
[<ffff0000087e6510>] clk_prepare_lock+0x20/0xe0
[<ffff0000087e8958>] __clk_create_clk.part.12+0x50/0xa0
[<ffff0000087e9510>] clk_register+0x190/0x5f8
[<ffff0000087e9984>] clk_hw_register+0xc/0x20
[<ffff0000087eb76c>] clk_hw_register_fixed_rate_with_accuracy+0x94/0xe0
[<ffff0000087eb83c>] of_fixed_clk_setup+0x84/0xb8
[<ffff000008e48858>] of_clk_init+0x154/0x1e4
[<ffff000008e139f4>] time_init+0x10/0x44
[<ffff000008e10ab0>] start_kernel+0x254/0x39c
[<ffff000008e101bc>] __primary_switched+0x30/0x6c
}
... key at: [<ffff000008f59d78>] prepare_lock+0x60/0x80
... acquired at:
[<ffff000008105284>] check_usage+0x43c/0x5c0
[<ffff000008105460>] check_irq_usage+0x58/0xc8
[<ffff000008108230>] __lock_acquire+0x1048/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000087e6538>] clk_prepare_lock+0x48/0xe0
[<ffff0000087e8c60>] clk_prepare+0x18/0x50
[<ffff0000084e98b8>] __enable_clocks+0x20/0xc0
[<ffff0000084e9d94>] msm_iommu_unmap+0x84/0x130
[<ffff0000084e4c30>] iommu_unmap+0x98/0xf0
[<ffff000008546ac8>] msm_iommu_unmap+0x70/0xa8
[<ffff0000085422d4>] put_iova+0x7c/0x90
[<ffff000008543888>] msm_gem_free_object+0x58/0x1c8
[<ffff000008504d64>] drm_gem_object_free+0x1c/0x58
[<ffff000008504f04>] drm_gem_object_unreference_unlocked+0x164/0x178
[<ffff000008504f7c>] drm_gem_object_handle_unreference_unlocked+0x64/0xb0
[<ffff00000850501c>] drm_gem_object_release_handle+0x54/0x98
[<ffff0000083b9e08>] idr_for_each+0xd0/0x130
[<ffff000008504cec>] drm_gem_release+0x24/0x38
[<ffff0000085040a4>] drm_release+0x25c/0x348
[<ffff0000081e9874>] __fput+0x84/0x1b0
[<ffff0000081e9a04>] ____fput+0xc/0x18
[<ffff0000080d8bf0>] task_work_run+0xc8/0xe8
[<ffff0000080bdba8>] do_exit+0x2d8/0xa00
[<ffff0000080be338>] do_group_exit+0x38/0xa0
[<ffff0000080be3b0>] __wake_up_parent+0x0/0x28
[<ffff000008084f30>] el0_svc_naked+0x24/0x28
stack backtrace:
CPU: 1 PID: 2068 Comm: bootanimation Not tainted 4.7.0-rc7+ #520
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
Call trace:
[<ffff000008088be8>] dump_backtrace+0x0/0x1a8
[<ffff000008088da4>] show_stack+0x14/0x20
[<ffff0000083b8234>] dump_stack+0xb4/0xf0
[<ffff0000081052a4>] check_usage+0x45c/0x5c0
[<ffff000008105460>] check_irq_usage+0x58/0xc8
[<ffff000008108230>] __lock_acquire+0x1048/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000087e6538>] clk_prepare_lock+0x48/0xe0
[<ffff0000087e8c60>] clk_prepare+0x18/0x50
[<ffff0000084e98b8>] __enable_clocks+0x20/0xc0
[<ffff0000084e9d94>] msm_iommu_unmap+0x84/0x130
[<ffff0000084e4c30>] iommu_unmap+0x98/0xf0
[<ffff000008546ac8>] msm_iommu_unmap+0x70/0xa8
[<ffff0000085422d4>] put_iova+0x7c/0x90
[<ffff000008543888>] msm_gem_free_object+0x58/0x1c8
[<ffff000008504d64>] drm_gem_object_free+0x1c/0x58
[<ffff000008504f04>] drm_gem_object_unreference_unlocked+0x164/0x178
[<ffff000008504f7c>] drm_gem_object_handle_unreference_unlocked+0x64/0xb0
[<ffff00000850501c>] drm_gem_object_release_handle+0x54/0x98
[<ffff0000083b9e08>] idr_for_each+0xd0/0x130
[<ffff000008504cec>] drm_gem_release+0x24/0x38
[<ffff0000085040a4>] drm_release+0x25c/0x348
[<ffff0000081e9874>] __fput+0x84/0x1b0
[<ffff0000081e9a04>] ____fput+0xc/0x18
[<ffff0000080d8bf0>] task_work_run+0xc8/0xe8
[<ffff0000080bdba8>] do_exit+0x2d8/0xa00
[<ffff0000080be338>] do_group_exit+0x38/0xa0
[<ffff0000080be3b0>] __wake_up_parent+0x0/0x28
[<ffff000008084f30>] el0_svc_naked+0x24/0x28
Signed-off-by: Rob Clark <[email protected]>
robclark
added a commit
that referenced
this issue
Nov 2, 2016
======================================================
[ INFO: RECLAIM_FS-safe -> RECLAIM_FS-unsafe lock order detected ]
4.7.0-rc7+ #520 Not tainted
------------------------------------------------------
bootanimation/2068 [HC0[0]:SC0[0]:HE1:SE1] is trying to acquire:
(prepare_lock){+.+.+.}, at: [<ffff0000087e6538>] clk_prepare_lock+0x48/0xe0
and this task is already holding:
(msm_iommu_lock){+.+.-.}, at: [<ffff0000084e9d44>] msm_iommu_unmap+0x34/0x130
which would create a new lock dependency:
(msm_iommu_lock){+.+.-.} -> (prepare_lock){+.+.+.}
but this new dependency connects a RECLAIM_FS-irq-safe lock:
(msm_iommu_lock){+.+.-.}
... which became RECLAIM_FS-irq-safe at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff000008107700>] __lock_acquire+0x518/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000084e9d44>] msm_iommu_unmap+0x34/0x130
[<ffff0000084e4c30>] iommu_unmap+0x98/0xf0
[<ffff000008546ac8>] msm_iommu_unmap+0x70/0xa8
[<ffff0000085422d4>] put_iova+0x7c/0x90
[<ffff000008543048>] msm_gem_purge+0x40/0xf0
[<ffff000008544170>] msm_gem_shrinker_scan+0xc8/0x160
[<ffff0000081883f8>] shrink_slab.part.5+0x190/0x2d0
[<ffff00000818ba04>] shrink_zone+0x324/0x328
[<ffff00000818c4f4>] kswapd+0x534/0x810
[<ffff0000080da134>] kthread+0xcc/0xe0
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
to a RECLAIM_FS-irq-unsafe lock:
(prepare_lock){+.+.+.}
... which became RECLAIM_FS-irq-unsafe at:
... [<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff000008105ce8>] mark_held_locks+0x70/0xb0
[<ffff000008106360>] lockdep_trace_alloc+0x70/0xc8
[<ffff0000081cc718>] __kmalloc+0x50/0x260
[<ffff000008479438>] qcom_rpm_smd_write+0x50/0x168
[<ffff0000087f5790>] clk_smd_rpm_set_rate_active+0x58/0x60
[<ffff0000087f5938>] clk_smd_rpm_prepare+0x78/0x108
[<ffff0000087e68d4>] clk_core_prepare+0x9c/0xc0
[<ffff0000087e8c68>] clk_prepare+0x20/0x50
[<ffff00000847fb34>] enable_nodeclk.isra.4.part.5+0x1c/0x98
[<ffff0000084805fc>] msm_bus_dev_init_qos+0x13c/0x308
[<ffff00000855a6a0>] bus_for_each_dev+0x60/0xa0
[<ffff000008480138>] msm_bus_device_probe+0x478/0x800
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c724>] __driver_attach+0xb4/0xb8
[<ffff00000855a6a0>] bus_for_each_dev+0x60/0xa0
[<ffff00000855c860>] driver_attach+0x20/0x28
[<ffff00000855b098>] bus_add_driver+0x110/0x228
[<ffff00000855cfb0>] driver_register+0x60/0xf8
[<ffff00000855e884>] __platform_driver_register+0x44/0x50
[<ffff000008e36bf8>] msm_bus_device_init_driver+0x2c/0x64
[<ffff000008e10c7c>] do_one_initcall+0x84/0x118
[<ffff000008e10e54>] kernel_init_freeable+0x144/0x1e8
[<ffff000008abe188>] kernel_init+0x10/0x100
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(prepare_lock);
local_irq_disable();
lock(msm_iommu_lock);
lock(prepare_lock);
<Interrupt>
lock(msm_iommu_lock);
*** DEADLOCK ***
3 locks held by bootanimation/2068:
#0: (drm_global_mutex){+.+.+.}, at: [<ffff000008503e88>] drm_release+0x40/0x348
#1: (&dev->struct_mutex){+.+.+.}, at: [<ffff000008504ee0>] drm_gem_object_unreference_unlocked+0x140/0x178
#2: (msm_iommu_lock){+.+.-.}, at: [<ffff0000084e9d44>] msm_iommu_unmap+0x34/0x130
the dependencies between RECLAIM_FS-irq-safe lock and the holding lock:
-> (msm_iommu_lock){+.+.-.} ops: 19991 {
HARDIRQ-ON-W at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff0000081076c0>] __lock_acquire+0x4d8/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000084ea17c>] msm_iommu_attach_dev+0x34/0x738
[<ffff0000084e4988>] iommu_attach_device+0xa0/0xd8
[<ffff00000854699c>] msm_iommu_attach+0x54/0x110
[<ffff00000853a780>] mdp5_kms_init+0x150/0x790
[<ffff0000085413cc>] msm_drm_bind+0x234/0x528
[<ffff000008556cd4>] try_to_bring_up_master+0x144/0x1a8
[<ffff0000085573c0>] component_add+0x98/0x160
[<ffff000008549dd4>] dsi_dev_probe+0x1c/0x28
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c7bc>] __device_attach_driver+0x94/0xd8
[<ffff00000855abe0>] bus_for_each_drv+0x58/0x98
[<ffff00000855c284>] __device_attach+0xcc/0x140
[<ffff00000855c838>] device_initial_probe+0x10/0x18
[<ffff00000855ae64>] bus_probe_device+0x94/0xa0
[<ffff00000855bb68>] deferred_probe_work_func+0x78/0xb0
[<ffff0000080d3064>] process_one_work+0x22c/0x440
[<ffff0000080d32c0>] worker_thread+0x48/0x498
[<ffff0000080da134>] kthread+0xcc/0xe0
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
SOFTIRQ-ON-W at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff0000081076e4>] __lock_acquire+0x4fc/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000084ea17c>] msm_iommu_attach_dev+0x34/0x738
[<ffff0000084e4988>] iommu_attach_device+0xa0/0xd8
[<ffff00000854699c>] msm_iommu_attach+0x54/0x110
[<ffff00000853a780>] mdp5_kms_init+0x150/0x790
[<ffff0000085413cc>] msm_drm_bind+0x234/0x528
[<ffff000008556cd4>] try_to_bring_up_master+0x144/0x1a8
[<ffff0000085573c0>] component_add+0x98/0x160
[<ffff000008549dd4>] dsi_dev_probe+0x1c/0x28
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c7bc>] __device_attach_driver+0x94/0xd8
[<ffff00000855abe0>] bus_for_each_drv+0x58/0x98
[<ffff00000855c284>] __device_attach+0xcc/0x140
[<ffff00000855c838>] device_initial_probe+0x10/0x18
[<ffff00000855ae64>] bus_probe_device+0x94/0xa0
[<ffff00000855bb68>] deferred_probe_work_func+0x78/0xb0
[<ffff0000080d3064>] process_one_work+0x22c/0x440
[<ffff0000080d32c0>] worker_thread+0x48/0x498
[<ffff0000080da134>] kthread+0xcc/0xe0
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
IN-RECLAIM_FS-W at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff000008107700>] __lock_acquire+0x518/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000084e9d44>] msm_iommu_unmap+0x34/0x130
[<ffff0000084e4c30>] iommu_unmap+0x98/0xf0
[<ffff000008546ac8>] msm_iommu_unmap+0x70/0xa8
[<ffff0000085422d4>] put_iova+0x7c/0x90
[<ffff000008543048>] msm_gem_purge+0x40/0xf0
[<ffff000008544170>] msm_gem_shrinker_scan+0xc8/0x160
[<ffff0000081883f8>] shrink_slab.part.5+0x190/0x2d0
[<ffff00000818ba04>] shrink_zone+0x324/0x328
[<ffff00000818c4f4>] kswapd+0x534/0x810
[<ffff0000080da134>] kthread+0xcc/0xe0
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
INITIAL USE at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff0000081074b4>] __lock_acquire+0x2cc/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000084ea17c>] msm_iommu_attach_dev+0x34/0x738
[<ffff0000084e4988>] iommu_attach_device+0xa0/0xd8
[<ffff00000854699c>] msm_iommu_attach+0x54/0x110
[<ffff00000853a780>] mdp5_kms_init+0x150/0x790
[<ffff0000085413cc>] msm_drm_bind+0x234/0x528
[<ffff000008556cd4>] try_to_bring_up_master+0x144/0x1a8
[<ffff0000085573c0>] component_add+0x98/0x160
[<ffff000008549dd4>] dsi_dev_probe+0x1c/0x28
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c7bc>] __device_attach_driver+0x94/0xd8
[<ffff00000855abe0>] bus_for_each_drv+0x58/0x98
[<ffff00000855c284>] __device_attach+0xcc/0x140
[<ffff00000855c838>] device_initial_probe+0x10/0x18
[<ffff00000855ae64>] bus_probe_device+0x94/0xa0
[<ffff00000855bb68>] deferred_probe_work_func+0x78/0xb0
[<ffff0000080d3064>] process_one_work+0x22c/0x440
[<ffff0000080d32c0>] worker_thread+0x48/0x498
[<ffff0000080da134>] kthread+0xcc/0xe0
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
}
... key at: [<ffff000008f22120>] msm_iommu_lock+0x60/0x80
... acquired at:
[<ffff000008105250>] check_usage+0x408/0x5c0
[<ffff000008105460>] check_irq_usage+0x58/0xc8
[<ffff000008108230>] __lock_acquire+0x1048/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000087e6538>] clk_prepare_lock+0x48/0xe0
[<ffff0000087e8c60>] clk_prepare+0x18/0x50
[<ffff0000084e98b8>] __enable_clocks+0x20/0xc0
[<ffff0000084e9d94>] msm_iommu_unmap+0x84/0x130
[<ffff0000084e4c30>] iommu_unmap+0x98/0xf0
[<ffff000008546ac8>] msm_iommu_unmap+0x70/0xa8
[<ffff0000085422d4>] put_iova+0x7c/0x90
[<ffff000008543888>] msm_gem_free_object+0x58/0x1c8
[<ffff000008504d64>] drm_gem_object_free+0x1c/0x58
[<ffff000008504f04>] drm_gem_object_unreference_unlocked+0x164/0x178
[<ffff000008504f7c>] drm_gem_object_handle_unreference_unlocked+0x64/0xb0
[<ffff00000850501c>] drm_gem_object_release_handle+0x54/0x98
[<ffff0000083b9e08>] idr_for_each+0xd0/0x130
[<ffff000008504cec>] drm_gem_release+0x24/0x38
[<ffff0000085040a4>] drm_release+0x25c/0x348
[<ffff0000081e9874>] __fput+0x84/0x1b0
[<ffff0000081e9a04>] ____fput+0xc/0x18
[<ffff0000080d8bf0>] task_work_run+0xc8/0xe8
[<ffff0000080bdba8>] do_exit+0x2d8/0xa00
[<ffff0000080be338>] do_group_exit+0x38/0xa0
[<ffff0000080be3b0>] __wake_up_parent+0x0/0x28
[<ffff000008084f30>] el0_svc_naked+0x24/0x28
the dependencies between the lock to be acquired and RECLAIM_FS-irq-unsafe lock:
-> (prepare_lock){+.+.+.} ops: 11866 {
HARDIRQ-ON-W at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff000008105ce8>] mark_held_locks+0x70/0xb0
[<ffff000008105db8>] trace_hardirqs_on_caller+0x90/0x180
[<ffff000008105eb8>] trace_hardirqs_on+0x10/0x18
[<ffff000008ac55bc>] mutex_trylock+0x124/0x1f0
[<ffff0000087e6510>] clk_prepare_lock+0x20/0xe0
[<ffff0000087e8958>] __clk_create_clk.part.12+0x50/0xa0
[<ffff0000087e9510>] clk_register+0x190/0x5f8
[<ffff0000087e9be0>] devm_clk_register+0x48/0xa0
[<ffff0000087eeacc>] _qcom_cc_register_board_clk+0xc4/0x128
[<ffff0000087eece4>] qcom_cc_register_board_clk+0x54/0x68
[<ffff0000087f49c4>] gcc_msm8916_probe+0x34/0x70
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c7bc>] __device_attach_driver+0x94/0xd8
[<ffff00000855abe0>] bus_for_each_drv+0x58/0x98
[<ffff00000855c284>] __device_attach+0xcc/0x140
[<ffff00000855c838>] device_initial_probe+0x10/0x18
[<ffff00000855ae64>] bus_probe_device+0x94/0xa0
[<ffff000008559a2c>] device_add+0x354/0x548
[<ffff0000087da5a4>] of_device_add+0x5c/0x70
[<ffff0000087db000>] of_platform_device_create_pdata+0x90/0xf0
[<ffff0000087db12c>] of_platform_bus_create+0xcc/0x328
[<ffff0000087db16c>] of_platform_bus_create+0x10c/0x328
[<ffff0000087db4d4>] of_platform_populate+0x4c/0xb0
[<ffff000008e1345c>] arm64_device_init+0x30/0x58
[<ffff000008e10c7c>] do_one_initcall+0x84/0x118
[<ffff000008e10e54>] kernel_init_freeable+0x144/0x1e8
[<ffff000008abe188>] kernel_init+0x10/0x100
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
SOFTIRQ-ON-W at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff000008105ce8>] mark_held_locks+0x70/0xb0
[<ffff000008105e0c>] trace_hardirqs_on_caller+0xe4/0x180
[<ffff000008105eb8>] trace_hardirqs_on+0x10/0x18
[<ffff000008ac55bc>] mutex_trylock+0x124/0x1f0
[<ffff0000087e6510>] clk_prepare_lock+0x20/0xe0
[<ffff0000087e8958>] __clk_create_clk.part.12+0x50/0xa0
[<ffff0000087e9510>] clk_register+0x190/0x5f8
[<ffff0000087e9be0>] devm_clk_register+0x48/0xa0
[<ffff0000087eeacc>] _qcom_cc_register_board_clk+0xc4/0x128
[<ffff0000087eece4>] qcom_cc_register_board_clk+0x54/0x68
[<ffff0000087f49c4>] gcc_msm8916_probe+0x34/0x70
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c7bc>] __device_attach_driver+0x94/0xd8
[<ffff00000855abe0>] bus_for_each_drv+0x58/0x98
[<ffff00000855c284>] __device_attach+0xcc/0x140
[<ffff00000855c838>] device_initial_probe+0x10/0x18
[<ffff00000855ae64>] bus_probe_device+0x94/0xa0
[<ffff000008559a2c>] device_add+0x354/0x548
[<ffff0000087da5a4>] of_device_add+0x5c/0x70
[<ffff0000087db000>] of_platform_device_create_pdata+0x90/0xf0
[<ffff0000087db12c>] of_platform_bus_create+0xcc/0x328
[<ffff0000087db16c>] of_platform_bus_create+0x10c/0x328
[<ffff0000087db4d4>] of_platform_populate+0x4c/0xb0
[<ffff000008e1345c>] arm64_device_init+0x30/0x58
[<ffff000008e10c7c>] do_one_initcall+0x84/0x118
[<ffff000008e10e54>] kernel_init_freeable+0x144/0x1e8
[<ffff000008abe188>] kernel_init+0x10/0x100
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
RECLAIM_FS-ON-W at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff000008105ce8>] mark_held_locks+0x70/0xb0
[<ffff000008106360>] lockdep_trace_alloc+0x70/0xc8
[<ffff0000081cc718>] __kmalloc+0x50/0x260
[<ffff000008479438>] qcom_rpm_smd_write+0x50/0x168
[<ffff0000087f5790>] clk_smd_rpm_set_rate_active+0x58/0x60
[<ffff0000087f5938>] clk_smd_rpm_prepare+0x78/0x108
[<ffff0000087e68d4>] clk_core_prepare+0x9c/0xc0
[<ffff0000087e8c68>] clk_prepare+0x20/0x50
[<ffff00000847fb34>] enable_nodeclk.isra.4.part.5+0x1c/0x98
[<ffff0000084805fc>] msm_bus_dev_init_qos+0x13c/0x308
[<ffff00000855a6a0>] bus_for_each_dev+0x60/0xa0
[<ffff000008480138>] msm_bus_device_probe+0x478/0x800
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c724>] __driver_attach+0xb4/0xb8
[<ffff00000855a6a0>] bus_for_each_dev+0x60/0xa0
[<ffff00000855c860>] driver_attach+0x20/0x28
[<ffff00000855b098>] bus_add_driver+0x110/0x228
[<ffff00000855cfb0>] driver_register+0x60/0xf8
[<ffff00000855e884>] __platform_driver_register+0x44/0x50
[<ffff000008e36bf8>] msm_bus_device_init_driver+0x2c/0x64
[<ffff000008e10c7c>] do_one_initcall+0x84/0x118
[<ffff000008e10e54>] kernel_init_freeable+0x144/0x1e8
[<ffff000008abe188>] kernel_init+0x10/0x100
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
INITIAL USE at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff0000081074b4>] __lock_acquire+0x2cc/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac5590>] mutex_trylock+0xf8/0x1f0
[<ffff0000087e6510>] clk_prepare_lock+0x20/0xe0
[<ffff0000087e8958>] __clk_create_clk.part.12+0x50/0xa0
[<ffff0000087e9510>] clk_register+0x190/0x5f8
[<ffff0000087e9984>] clk_hw_register+0xc/0x20
[<ffff0000087eb76c>] clk_hw_register_fixed_rate_with_accuracy+0x94/0xe0
[<ffff0000087eb83c>] of_fixed_clk_setup+0x84/0xb8
[<ffff000008e48858>] of_clk_init+0x154/0x1e4
[<ffff000008e139f4>] time_init+0x10/0x44
[<ffff000008e10ab0>] start_kernel+0x254/0x39c
[<ffff000008e101bc>] __primary_switched+0x30/0x6c
}
... key at: [<ffff000008f59d78>] prepare_lock+0x60/0x80
... acquired at:
[<ffff000008105284>] check_usage+0x43c/0x5c0
[<ffff000008105460>] check_irq_usage+0x58/0xc8
[<ffff000008108230>] __lock_acquire+0x1048/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000087e6538>] clk_prepare_lock+0x48/0xe0
[<ffff0000087e8c60>] clk_prepare+0x18/0x50
[<ffff0000084e98b8>] __enable_clocks+0x20/0xc0
[<ffff0000084e9d94>] msm_iommu_unmap+0x84/0x130
[<ffff0000084e4c30>] iommu_unmap+0x98/0xf0
[<ffff000008546ac8>] msm_iommu_unmap+0x70/0xa8
[<ffff0000085422d4>] put_iova+0x7c/0x90
[<ffff000008543888>] msm_gem_free_object+0x58/0x1c8
[<ffff000008504d64>] drm_gem_object_free+0x1c/0x58
[<ffff000008504f04>] drm_gem_object_unreference_unlocked+0x164/0x178
[<ffff000008504f7c>] drm_gem_object_handle_unreference_unlocked+0x64/0xb0
[<ffff00000850501c>] drm_gem_object_release_handle+0x54/0x98
[<ffff0000083b9e08>] idr_for_each+0xd0/0x130
[<ffff000008504cec>] drm_gem_release+0x24/0x38
[<ffff0000085040a4>] drm_release+0x25c/0x348
[<ffff0000081e9874>] __fput+0x84/0x1b0
[<ffff0000081e9a04>] ____fput+0xc/0x18
[<ffff0000080d8bf0>] task_work_run+0xc8/0xe8
[<ffff0000080bdba8>] do_exit+0x2d8/0xa00
[<ffff0000080be338>] do_group_exit+0x38/0xa0
[<ffff0000080be3b0>] __wake_up_parent+0x0/0x28
[<ffff000008084f30>] el0_svc_naked+0x24/0x28
stack backtrace:
CPU: 1 PID: 2068 Comm: bootanimation Not tainted 4.7.0-rc7+ #520
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
Call trace:
[<ffff000008088be8>] dump_backtrace+0x0/0x1a8
[<ffff000008088da4>] show_stack+0x14/0x20
[<ffff0000083b8234>] dump_stack+0xb4/0xf0
[<ffff0000081052a4>] check_usage+0x45c/0x5c0
[<ffff000008105460>] check_irq_usage+0x58/0xc8
[<ffff000008108230>] __lock_acquire+0x1048/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000087e6538>] clk_prepare_lock+0x48/0xe0
[<ffff0000087e8c60>] clk_prepare+0x18/0x50
[<ffff0000084e98b8>] __enable_clocks+0x20/0xc0
[<ffff0000084e9d94>] msm_iommu_unmap+0x84/0x130
[<ffff0000084e4c30>] iommu_unmap+0x98/0xf0
[<ffff000008546ac8>] msm_iommu_unmap+0x70/0xa8
[<ffff0000085422d4>] put_iova+0x7c/0x90
[<ffff000008543888>] msm_gem_free_object+0x58/0x1c8
[<ffff000008504d64>] drm_gem_object_free+0x1c/0x58
[<ffff000008504f04>] drm_gem_object_unreference_unlocked+0x164/0x178
[<ffff000008504f7c>] drm_gem_object_handle_unreference_unlocked+0x64/0xb0
[<ffff00000850501c>] drm_gem_object_release_handle+0x54/0x98
[<ffff0000083b9e08>] idr_for_each+0xd0/0x130
[<ffff000008504cec>] drm_gem_release+0x24/0x38
[<ffff0000085040a4>] drm_release+0x25c/0x348
[<ffff0000081e9874>] __fput+0x84/0x1b0
[<ffff0000081e9a04>] ____fput+0xc/0x18
[<ffff0000080d8bf0>] task_work_run+0xc8/0xe8
[<ffff0000080bdba8>] do_exit+0x2d8/0xa00
[<ffff0000080be338>] do_group_exit+0x38/0xa0
[<ffff0000080be3b0>] __wake_up_parent+0x0/0x28
[<ffff000008084f30>] el0_svc_naked+0x24/0x28
Signed-off-by: Rob Clark <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Nov 29, 2016
======================================================
[ INFO: RECLAIM_FS-safe -> RECLAIM_FS-unsafe lock order detected ]
4.7.0-rc7+ #520 Not tainted
------------------------------------------------------
bootanimation/2068 [HC0[0]:SC0[0]:HE1:SE1] is trying to acquire:
(prepare_lock){+.+.+.}, at: [<ffff0000087e6538>] clk_prepare_lock+0x48/0xe0
and this task is already holding:
(msm_iommu_lock){+.+.-.}, at: [<ffff0000084e9d44>] msm_iommu_unmap+0x34/0x130
which would create a new lock dependency:
(msm_iommu_lock){+.+.-.} -> (prepare_lock){+.+.+.}
but this new dependency connects a RECLAIM_FS-irq-safe lock:
(msm_iommu_lock){+.+.-.}
... which became RECLAIM_FS-irq-safe at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff000008107700>] __lock_acquire+0x518/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000084e9d44>] msm_iommu_unmap+0x34/0x130
[<ffff0000084e4c30>] iommu_unmap+0x98/0xf0
[<ffff000008546ac8>] msm_iommu_unmap+0x70/0xa8
[<ffff0000085422d4>] put_iova+0x7c/0x90
[<ffff000008543048>] msm_gem_purge+0x40/0xf0
[<ffff000008544170>] msm_gem_shrinker_scan+0xc8/0x160
[<ffff0000081883f8>] shrink_slab.part.5+0x190/0x2d0
[<ffff00000818ba04>] shrink_zone+0x324/0x328
[<ffff00000818c4f4>] kswapd+0x534/0x810
[<ffff0000080da134>] kthread+0xcc/0xe0
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
to a RECLAIM_FS-irq-unsafe lock:
(prepare_lock){+.+.+.}
... which became RECLAIM_FS-irq-unsafe at:
... [<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff000008105ce8>] mark_held_locks+0x70/0xb0
[<ffff000008106360>] lockdep_trace_alloc+0x70/0xc8
[<ffff0000081cc718>] __kmalloc+0x50/0x260
[<ffff000008479438>] qcom_rpm_smd_write+0x50/0x168
[<ffff0000087f5790>] clk_smd_rpm_set_rate_active+0x58/0x60
[<ffff0000087f5938>] clk_smd_rpm_prepare+0x78/0x108
[<ffff0000087e68d4>] clk_core_prepare+0x9c/0xc0
[<ffff0000087e8c68>] clk_prepare+0x20/0x50
[<ffff00000847fb34>] enable_nodeclk.isra.4.part.5+0x1c/0x98
[<ffff0000084805fc>] msm_bus_dev_init_qos+0x13c/0x308
[<ffff00000855a6a0>] bus_for_each_dev+0x60/0xa0
[<ffff000008480138>] msm_bus_device_probe+0x478/0x800
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c724>] __driver_attach+0xb4/0xb8
[<ffff00000855a6a0>] bus_for_each_dev+0x60/0xa0
[<ffff00000855c860>] driver_attach+0x20/0x28
[<ffff00000855b098>] bus_add_driver+0x110/0x228
[<ffff00000855cfb0>] driver_register+0x60/0xf8
[<ffff00000855e884>] __platform_driver_register+0x44/0x50
[<ffff000008e36bf8>] msm_bus_device_init_driver+0x2c/0x64
[<ffff000008e10c7c>] do_one_initcall+0x84/0x118
[<ffff000008e10e54>] kernel_init_freeable+0x144/0x1e8
[<ffff000008abe188>] kernel_init+0x10/0x100
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(prepare_lock);
local_irq_disable();
lock(msm_iommu_lock);
lock(prepare_lock);
<Interrupt>
lock(msm_iommu_lock);
*** DEADLOCK ***
3 locks held by bootanimation/2068:
#0: (drm_global_mutex){+.+.+.}, at: [<ffff000008503e88>] drm_release+0x40/0x348
freedreno-zz#1: (&dev->struct_mutex){+.+.+.}, at: [<ffff000008504ee0>] drm_gem_object_unreference_unlocked+0x140/0x178
freedreno-zz#2: (msm_iommu_lock){+.+.-.}, at: [<ffff0000084e9d44>] msm_iommu_unmap+0x34/0x130
the dependencies between RECLAIM_FS-irq-safe lock and the holding lock:
-> (msm_iommu_lock){+.+.-.} ops: 19991 {
HARDIRQ-ON-W at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff0000081076c0>] __lock_acquire+0x4d8/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000084ea17c>] msm_iommu_attach_dev+0x34/0x738
[<ffff0000084e4988>] iommu_attach_device+0xa0/0xd8
[<ffff00000854699c>] msm_iommu_attach+0x54/0x110
[<ffff00000853a780>] mdp5_kms_init+0x150/0x790
[<ffff0000085413cc>] msm_drm_bind+0x234/0x528
[<ffff000008556cd4>] try_to_bring_up_master+0x144/0x1a8
[<ffff0000085573c0>] component_add+0x98/0x160
[<ffff000008549dd4>] dsi_dev_probe+0x1c/0x28
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c7bc>] __device_attach_driver+0x94/0xd8
[<ffff00000855abe0>] bus_for_each_drv+0x58/0x98
[<ffff00000855c284>] __device_attach+0xcc/0x140
[<ffff00000855c838>] device_initial_probe+0x10/0x18
[<ffff00000855ae64>] bus_probe_device+0x94/0xa0
[<ffff00000855bb68>] deferred_probe_work_func+0x78/0xb0
[<ffff0000080d3064>] process_one_work+0x22c/0x440
[<ffff0000080d32c0>] worker_thread+0x48/0x498
[<ffff0000080da134>] kthread+0xcc/0xe0
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
SOFTIRQ-ON-W at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff0000081076e4>] __lock_acquire+0x4fc/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000084ea17c>] msm_iommu_attach_dev+0x34/0x738
[<ffff0000084e4988>] iommu_attach_device+0xa0/0xd8
[<ffff00000854699c>] msm_iommu_attach+0x54/0x110
[<ffff00000853a780>] mdp5_kms_init+0x150/0x790
[<ffff0000085413cc>] msm_drm_bind+0x234/0x528
[<ffff000008556cd4>] try_to_bring_up_master+0x144/0x1a8
[<ffff0000085573c0>] component_add+0x98/0x160
[<ffff000008549dd4>] dsi_dev_probe+0x1c/0x28
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c7bc>] __device_attach_driver+0x94/0xd8
[<ffff00000855abe0>] bus_for_each_drv+0x58/0x98
[<ffff00000855c284>] __device_attach+0xcc/0x140
[<ffff00000855c838>] device_initial_probe+0x10/0x18
[<ffff00000855ae64>] bus_probe_device+0x94/0xa0
[<ffff00000855bb68>] deferred_probe_work_func+0x78/0xb0
[<ffff0000080d3064>] process_one_work+0x22c/0x440
[<ffff0000080d32c0>] worker_thread+0x48/0x498
[<ffff0000080da134>] kthread+0xcc/0xe0
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
IN-RECLAIM_FS-W at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff000008107700>] __lock_acquire+0x518/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000084e9d44>] msm_iommu_unmap+0x34/0x130
[<ffff0000084e4c30>] iommu_unmap+0x98/0xf0
[<ffff000008546ac8>] msm_iommu_unmap+0x70/0xa8
[<ffff0000085422d4>] put_iova+0x7c/0x90
[<ffff000008543048>] msm_gem_purge+0x40/0xf0
[<ffff000008544170>] msm_gem_shrinker_scan+0xc8/0x160
[<ffff0000081883f8>] shrink_slab.part.5+0x190/0x2d0
[<ffff00000818ba04>] shrink_zone+0x324/0x328
[<ffff00000818c4f4>] kswapd+0x534/0x810
[<ffff0000080da134>] kthread+0xcc/0xe0
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
INITIAL USE at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff0000081074b4>] __lock_acquire+0x2cc/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000084ea17c>] msm_iommu_attach_dev+0x34/0x738
[<ffff0000084e4988>] iommu_attach_device+0xa0/0xd8
[<ffff00000854699c>] msm_iommu_attach+0x54/0x110
[<ffff00000853a780>] mdp5_kms_init+0x150/0x790
[<ffff0000085413cc>] msm_drm_bind+0x234/0x528
[<ffff000008556cd4>] try_to_bring_up_master+0x144/0x1a8
[<ffff0000085573c0>] component_add+0x98/0x160
[<ffff000008549dd4>] dsi_dev_probe+0x1c/0x28
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c7bc>] __device_attach_driver+0x94/0xd8
[<ffff00000855abe0>] bus_for_each_drv+0x58/0x98
[<ffff00000855c284>] __device_attach+0xcc/0x140
[<ffff00000855c838>] device_initial_probe+0x10/0x18
[<ffff00000855ae64>] bus_probe_device+0x94/0xa0
[<ffff00000855bb68>] deferred_probe_work_func+0x78/0xb0
[<ffff0000080d3064>] process_one_work+0x22c/0x440
[<ffff0000080d32c0>] worker_thread+0x48/0x498
[<ffff0000080da134>] kthread+0xcc/0xe0
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
}
... key at: [<ffff000008f22120>] msm_iommu_lock+0x60/0x80
... acquired at:
[<ffff000008105250>] check_usage+0x408/0x5c0
[<ffff000008105460>] check_irq_usage+0x58/0xc8
[<ffff000008108230>] __lock_acquire+0x1048/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000087e6538>] clk_prepare_lock+0x48/0xe0
[<ffff0000087e8c60>] clk_prepare+0x18/0x50
[<ffff0000084e98b8>] __enable_clocks+0x20/0xc0
[<ffff0000084e9d94>] msm_iommu_unmap+0x84/0x130
[<ffff0000084e4c30>] iommu_unmap+0x98/0xf0
[<ffff000008546ac8>] msm_iommu_unmap+0x70/0xa8
[<ffff0000085422d4>] put_iova+0x7c/0x90
[<ffff000008543888>] msm_gem_free_object+0x58/0x1c8
[<ffff000008504d64>] drm_gem_object_free+0x1c/0x58
[<ffff000008504f04>] drm_gem_object_unreference_unlocked+0x164/0x178
[<ffff000008504f7c>] drm_gem_object_handle_unreference_unlocked+0x64/0xb0
[<ffff00000850501c>] drm_gem_object_release_handle+0x54/0x98
[<ffff0000083b9e08>] idr_for_each+0xd0/0x130
[<ffff000008504cec>] drm_gem_release+0x24/0x38
[<ffff0000085040a4>] drm_release+0x25c/0x348
[<ffff0000081e9874>] __fput+0x84/0x1b0
[<ffff0000081e9a04>] ____fput+0xc/0x18
[<ffff0000080d8bf0>] task_work_run+0xc8/0xe8
[<ffff0000080bdba8>] do_exit+0x2d8/0xa00
[<ffff0000080be338>] do_group_exit+0x38/0xa0
[<ffff0000080be3b0>] __wake_up_parent+0x0/0x28
[<ffff000008084f30>] el0_svc_naked+0x24/0x28
the dependencies between the lock to be acquired and RECLAIM_FS-irq-unsafe lock:
-> (prepare_lock){+.+.+.} ops: 11866 {
HARDIRQ-ON-W at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff000008105ce8>] mark_held_locks+0x70/0xb0
[<ffff000008105db8>] trace_hardirqs_on_caller+0x90/0x180
[<ffff000008105eb8>] trace_hardirqs_on+0x10/0x18
[<ffff000008ac55bc>] mutex_trylock+0x124/0x1f0
[<ffff0000087e6510>] clk_prepare_lock+0x20/0xe0
[<ffff0000087e8958>] __clk_create_clk.part.12+0x50/0xa0
[<ffff0000087e9510>] clk_register+0x190/0x5f8
[<ffff0000087e9be0>] devm_clk_register+0x48/0xa0
[<ffff0000087eeacc>] _qcom_cc_register_board_clk+0xc4/0x128
[<ffff0000087eece4>] qcom_cc_register_board_clk+0x54/0x68
[<ffff0000087f49c4>] gcc_msm8916_probe+0x34/0x70
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c7bc>] __device_attach_driver+0x94/0xd8
[<ffff00000855abe0>] bus_for_each_drv+0x58/0x98
[<ffff00000855c284>] __device_attach+0xcc/0x140
[<ffff00000855c838>] device_initial_probe+0x10/0x18
[<ffff00000855ae64>] bus_probe_device+0x94/0xa0
[<ffff000008559a2c>] device_add+0x354/0x548
[<ffff0000087da5a4>] of_device_add+0x5c/0x70
[<ffff0000087db000>] of_platform_device_create_pdata+0x90/0xf0
[<ffff0000087db12c>] of_platform_bus_create+0xcc/0x328
[<ffff0000087db16c>] of_platform_bus_create+0x10c/0x328
[<ffff0000087db4d4>] of_platform_populate+0x4c/0xb0
[<ffff000008e1345c>] arm64_device_init+0x30/0x58
[<ffff000008e10c7c>] do_one_initcall+0x84/0x118
[<ffff000008e10e54>] kernel_init_freeable+0x144/0x1e8
[<ffff000008abe188>] kernel_init+0x10/0x100
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
SOFTIRQ-ON-W at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff000008105ce8>] mark_held_locks+0x70/0xb0
[<ffff000008105e0c>] trace_hardirqs_on_caller+0xe4/0x180
[<ffff000008105eb8>] trace_hardirqs_on+0x10/0x18
[<ffff000008ac55bc>] mutex_trylock+0x124/0x1f0
[<ffff0000087e6510>] clk_prepare_lock+0x20/0xe0
[<ffff0000087e8958>] __clk_create_clk.part.12+0x50/0xa0
[<ffff0000087e9510>] clk_register+0x190/0x5f8
[<ffff0000087e9be0>] devm_clk_register+0x48/0xa0
[<ffff0000087eeacc>] _qcom_cc_register_board_clk+0xc4/0x128
[<ffff0000087eece4>] qcom_cc_register_board_clk+0x54/0x68
[<ffff0000087f49c4>] gcc_msm8916_probe+0x34/0x70
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c7bc>] __device_attach_driver+0x94/0xd8
[<ffff00000855abe0>] bus_for_each_drv+0x58/0x98
[<ffff00000855c284>] __device_attach+0xcc/0x140
[<ffff00000855c838>] device_initial_probe+0x10/0x18
[<ffff00000855ae64>] bus_probe_device+0x94/0xa0
[<ffff000008559a2c>] device_add+0x354/0x548
[<ffff0000087da5a4>] of_device_add+0x5c/0x70
[<ffff0000087db000>] of_platform_device_create_pdata+0x90/0xf0
[<ffff0000087db12c>] of_platform_bus_create+0xcc/0x328
[<ffff0000087db16c>] of_platform_bus_create+0x10c/0x328
[<ffff0000087db4d4>] of_platform_populate+0x4c/0xb0
[<ffff000008e1345c>] arm64_device_init+0x30/0x58
[<ffff000008e10c7c>] do_one_initcall+0x84/0x118
[<ffff000008e10e54>] kernel_init_freeable+0x144/0x1e8
[<ffff000008abe188>] kernel_init+0x10/0x100
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
RECLAIM_FS-ON-W at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff000008105ce8>] mark_held_locks+0x70/0xb0
[<ffff000008106360>] lockdep_trace_alloc+0x70/0xc8
[<ffff0000081cc718>] __kmalloc+0x50/0x260
[<ffff000008479438>] qcom_rpm_smd_write+0x50/0x168
[<ffff0000087f5790>] clk_smd_rpm_set_rate_active+0x58/0x60
[<ffff0000087f5938>] clk_smd_rpm_prepare+0x78/0x108
[<ffff0000087e68d4>] clk_core_prepare+0x9c/0xc0
[<ffff0000087e8c68>] clk_prepare+0x20/0x50
[<ffff00000847fb34>] enable_nodeclk.isra.4.part.5+0x1c/0x98
[<ffff0000084805fc>] msm_bus_dev_init_qos+0x13c/0x308
[<ffff00000855a6a0>] bus_for_each_dev+0x60/0xa0
[<ffff000008480138>] msm_bus_device_probe+0x478/0x800
[<ffff00000855dc0c>] platform_drv_probe+0x74/0xe0
[<ffff00000855c5c4>] driver_probe_device+0x1fc/0x2a8
[<ffff00000855c724>] __driver_attach+0xb4/0xb8
[<ffff00000855a6a0>] bus_for_each_dev+0x60/0xa0
[<ffff00000855c860>] driver_attach+0x20/0x28
[<ffff00000855b098>] bus_add_driver+0x110/0x228
[<ffff00000855cfb0>] driver_register+0x60/0xf8
[<ffff00000855e884>] __platform_driver_register+0x44/0x50
[<ffff000008e36bf8>] msm_bus_device_init_driver+0x2c/0x64
[<ffff000008e10c7c>] do_one_initcall+0x84/0x118
[<ffff000008e10e54>] kernel_init_freeable+0x144/0x1e8
[<ffff000008abe188>] kernel_init+0x10/0x100
[<ffff000008084ed0>] ret_from_fork+0x10/0x40
INITIAL USE at:
[<ffff000008105778>] mark_lock+0x1c0/0x6c0
[<ffff0000081074b4>] __lock_acquire+0x2cc/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac5590>] mutex_trylock+0xf8/0x1f0
[<ffff0000087e6510>] clk_prepare_lock+0x20/0xe0
[<ffff0000087e8958>] __clk_create_clk.part.12+0x50/0xa0
[<ffff0000087e9510>] clk_register+0x190/0x5f8
[<ffff0000087e9984>] clk_hw_register+0xc/0x20
[<ffff0000087eb76c>] clk_hw_register_fixed_rate_with_accuracy+0x94/0xe0
[<ffff0000087eb83c>] of_fixed_clk_setup+0x84/0xb8
[<ffff000008e48858>] of_clk_init+0x154/0x1e4
[<ffff000008e139f4>] time_init+0x10/0x44
[<ffff000008e10ab0>] start_kernel+0x254/0x39c
[<ffff000008e101bc>] __primary_switched+0x30/0x6c
}
... key at: [<ffff000008f59d78>] prepare_lock+0x60/0x80
... acquired at:
[<ffff000008105284>] check_usage+0x43c/0x5c0
[<ffff000008105460>] check_irq_usage+0x58/0xc8
[<ffff000008108230>] __lock_acquire+0x1048/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000087e6538>] clk_prepare_lock+0x48/0xe0
[<ffff0000087e8c60>] clk_prepare+0x18/0x50
[<ffff0000084e98b8>] __enable_clocks+0x20/0xc0
[<ffff0000084e9d94>] msm_iommu_unmap+0x84/0x130
[<ffff0000084e4c30>] iommu_unmap+0x98/0xf0
[<ffff000008546ac8>] msm_iommu_unmap+0x70/0xa8
[<ffff0000085422d4>] put_iova+0x7c/0x90
[<ffff000008543888>] msm_gem_free_object+0x58/0x1c8
[<ffff000008504d64>] drm_gem_object_free+0x1c/0x58
[<ffff000008504f04>] drm_gem_object_unreference_unlocked+0x164/0x178
[<ffff000008504f7c>] drm_gem_object_handle_unreference_unlocked+0x64/0xb0
[<ffff00000850501c>] drm_gem_object_release_handle+0x54/0x98
[<ffff0000083b9e08>] idr_for_each+0xd0/0x130
[<ffff000008504cec>] drm_gem_release+0x24/0x38
[<ffff0000085040a4>] drm_release+0x25c/0x348
[<ffff0000081e9874>] __fput+0x84/0x1b0
[<ffff0000081e9a04>] ____fput+0xc/0x18
[<ffff0000080d8bf0>] task_work_run+0xc8/0xe8
[<ffff0000080bdba8>] do_exit+0x2d8/0xa00
[<ffff0000080be338>] do_group_exit+0x38/0xa0
[<ffff0000080be3b0>] __wake_up_parent+0x0/0x28
[<ffff000008084f30>] el0_svc_naked+0x24/0x28
stack backtrace:
CPU: 1 PID: 2068 Comm: bootanimation Not tainted 4.7.0-rc7+ #520
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
Call trace:
[<ffff000008088be8>] dump_backtrace+0x0/0x1a8
[<ffff000008088da4>] show_stack+0x14/0x20
[<ffff0000083b8234>] dump_stack+0xb4/0xf0
[<ffff0000081052a4>] check_usage+0x45c/0x5c0
[<ffff000008105460>] check_irq_usage+0x58/0xc8
[<ffff000008108230>] __lock_acquire+0x1048/0x18d8
[<ffff000008108e0c>] lock_acquire+0x4c/0x68
[<ffff000008ac36d4>] mutex_lock_nested+0x54/0x390
[<ffff0000087e6538>] clk_prepare_lock+0x48/0xe0
[<ffff0000087e8c60>] clk_prepare+0x18/0x50
[<ffff0000084e98b8>] __enable_clocks+0x20/0xc0
[<ffff0000084e9d94>] msm_iommu_unmap+0x84/0x130
[<ffff0000084e4c30>] iommu_unmap+0x98/0xf0
[<ffff000008546ac8>] msm_iommu_unmap+0x70/0xa8
[<ffff0000085422d4>] put_iova+0x7c/0x90
[<ffff000008543888>] msm_gem_free_object+0x58/0x1c8
[<ffff000008504d64>] drm_gem_object_free+0x1c/0x58
[<ffff000008504f04>] drm_gem_object_unreference_unlocked+0x164/0x178
[<ffff000008504f7c>] drm_gem_object_handle_unreference_unlocked+0x64/0xb0
[<ffff00000850501c>] drm_gem_object_release_handle+0x54/0x98
[<ffff0000083b9e08>] idr_for_each+0xd0/0x130
[<ffff000008504cec>] drm_gem_release+0x24/0x38
[<ffff0000085040a4>] drm_release+0x25c/0x348
[<ffff0000081e9874>] __fput+0x84/0x1b0
[<ffff0000081e9a04>] ____fput+0xc/0x18
[<ffff0000080d8bf0>] task_work_run+0xc8/0xe8
[<ffff0000080bdba8>] do_exit+0x2d8/0xa00
[<ffff0000080be338>] do_group_exit+0x38/0xa0
[<ffff0000080be3b0>] __wake_up_parent+0x0/0x28
[<ffff000008084f30>] el0_svc_naked+0x24/0x28
Signed-off-by: Rob Clark <[email protected]>
Signed-off-by: Archit Taneja <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Mar 1, 2017
Yuval Mintz says: ==================== qed: Bug fixes Patch freedreno-zz#1 addresses a day-one race which is dependent on the number of Vfs [I.e., more child VFs from a single PF make it more probable]. Patch freedreno-zz#2 corrects a race that got introduced in the last set of fixes for qed, one that would happen each time PF transitions to UP state. I've built & tested those against current net-next. Please consider applying the series there. ==================== Signed-off-by: David S. Miller <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Apr 28, 2017
This is a story about 4 distinct (and very old) btrfs bugs. Commit c8b9781 ("Btrfs: Add zlib compression support") added three data corruption bugs for inline extents (bugs freedreno-zz#1-3). Commit 93c82d5 ("Btrfs: zero page past end of inline file items") fixed bug freedreno-zz#1: uncompressed inline extents followed by a hole and more extents could get non-zero data in the hole as they were read. The fix was to add a memset in btrfs_get_extent to zero out the hole. Commit 166ae5a ("btrfs: fix inline compressed read err corruption") fixed bug freedreno-zz#2: compressed inline extents which contained non-zero bytes might be replaced with zero bytes in some cases. This patch removed an unhelpful memset from uncompress_inline, but the case where memset is required was missed. There is also a memset in the decompression code, but this only covers decompressed data that is shorter than the ram_bytes from the extent ref record. This memset doesn't cover the region between the end of the decompressed data and the end of the page. It has also moved around a few times over the years, so there's no single patch to refer to. This patch fixes bug freedreno-zz#3: compressed inline extents followed by a hole and more extents could get non-zero data in the hole as they were read (i.e. bug freedreno-zz#3 is the same as bug freedreno-zz#1, but s/uncompressed/compressed/). The fix is the same: zero out the hole in the compressed case too, by putting a memset back in uncompress_inline, but this time with correct parameters. The last and oldest bug, bug #0, is the cause of the offending inline extent/hole/extent pattern. Bug #0 is a subtle and mostly-harmless quirk of behavior somewhere in the btrfs write code. In a few special cases, an inline extent and hole are allowed to persist where they normally would be combined with later extents in the file. A fast reproducer for bug #0 is presented below. A few offending extents are also created in the wild during large rsync transfers with the -S flag. A Linux kernel build (git checkout; make allyesconfig; make -j8) will produce a handful of offending files as well. Once an offending file is created, it can present different content to userspace each time it is read. Bug #0 is at least 4 and possibly 8 years old. I verified every vX.Y kernel back to v3.5 has this behavior. There are fossil records of this bug's effects in commits all the way back to v2.6.32. I have no reason to believe bug #0 wasn't present at the beginning of btrfs compression support in v2.6.29, but I can't easily test kernels that old to be sure. It is not clear whether bug #0 is worth fixing. A fix would likely require injecting extra reads into currently write-only paths, and most of the exceptional cases caused by bug #0 are already handled now. Whether we like them or not, bug #0's inline extents followed by holes are part of the btrfs de-facto disk format now, and we need to be able to read them without data corruption or an infoleak. So enough about bug #0, let's get back to bug freedreno-zz#3 (this patch). An example of on-disk structure leading to data corruption found in the wild: item 61 key (606890 INODE_ITEM 0) itemoff 9662 itemsize 160 inode generation 50 transid 50 size 47424 nbytes 49141 block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0 flags 0x0(none) item 62 key (606890 INODE_REF 603050) itemoff 9642 itemsize 20 inode ref index 3 namelen 10 name: DB_File.so item 63 key (606890 EXTENT_DATA 0) itemoff 8280 itemsize 1362 inline extent data size 1341 ram 4085 compress(zlib) item 64 key (606890 EXTENT_DATA 4096) itemoff 8227 itemsize 53 extent data disk byte 5367308288 nr 20480 extent data offset 0 nr 45056 ram 45056 extent compression(zlib) Different data appears in userspace during each read of the 11 bytes between 4085 and 4096. The extent in item 63 is not long enough to fill the first page of the file, so a memset is required to fill the space between item 63 (ending at 4085) and item 64 (beginning at 4096) with zero. Here is a reproducer from Liu Bo, which demonstrates another method of creating the same inline extent and hole pattern: Using 'page_poison=on' kernel command line (or enable CONFIG_PAGE_POISONING) run the following: # touch foo # chattr +c foo # xfs_io -f -c "pwrite -W 0 1000" foo # xfs_io -f -c "falloc 4 8188" foo # od -x foo # echo 3 >/proc/sys/vm/drop_caches # od -x foo This produce the following on my box: Correct output: file contains 1000 data bytes followed by zeros: 0000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 0001740 cdcd cdcd cdcd cdcd 0000 0000 0000 0000 0001760 0000 0000 0000 0000 0000 0000 0000 0000 * 0020000 Actual output: the data after the first 1000 bytes will be different each run: 0000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 0001740 cdcd cdcd cdcd cdcd 6c63 7400 635f 006d 0001760 5f74 6f43 7400 435f 0053 5f74 7363 7400 0002000 435f 0056 5f74 6164 7400 645f 0062 5f74 (...) Signed-off-by: Zygo Blaxell <[email protected]> Reviewed-by: Liu Bo <[email protected]> Reviewed-by: Chris Mason <[email protected]> Signed-off-by: Chris Mason <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Apr 28, 2017
The rcu_barrier() takes the cpu_hotplug mutex which itself is not reclaim-safe, and so rcu_barrier() is illegal from inside the shrinker. [ 309.661373] ========================================================= [ 309.661376] [ INFO: possible irq lock inversion dependency detected ] [ 309.661380] 4.11.0-rc1-CI-CI_DRM_2333+ freedreno-zz#1 Tainted: G W [ 309.661383] --------------------------------------------------------- [ 309.661386] gem_exec_gttfil/6435 just changed the state of lock: [ 309.661389] (rcu_preempt_state.barrier_mutex){+.+.-.}, at: [<ffffffff81100731>] _rcu_barrier+0x31/0x160 [ 309.661399] but this lock took another, RECLAIM_FS-unsafe lock in the past: [ 309.661402] (cpu_hotplug.lock){+.+.+.} [ 309.661404] and interrupts could create inverse lock ordering between them. [ 309.661410] other info that might help us debug this: [ 309.661414] Possible interrupt unsafe locking scenario: [ 309.661417] CPU0 CPU1 [ 309.661419] ---- ---- [ 309.661421] lock(cpu_hotplug.lock); [ 309.661425] local_irq_disable(); [ 309.661432] lock(rcu_preempt_state.barrier_mutex); [ 309.661441] lock(cpu_hotplug.lock); [ 309.661446] <Interrupt> [ 309.661448] lock(rcu_preempt_state.barrier_mutex); [ 309.661453] *** DEADLOCK *** [ 309.661460] 4 locks held by gem_exec_gttfil/6435: [ 309.661464] #0: (sb_writers#10){.+.+.+}, at: [<ffffffff8120d83d>] vfs_write+0x17d/0x1f0 [ 309.661475] freedreno-zz#1: (debugfs_srcu){......}, at: [<ffffffff81320491>] debugfs_use_file_start+0x41/0xa0 [ 309.661486] freedreno-zz#2: (&attr->mutex){+.+.+.}, at: [<ffffffff8123a3e7>] simple_attr_write+0x37/0xe0 [ 309.661495] freedreno-zz#3: (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa0091b4a>] i915_drop_caches_set+0x3a/0x150 [i915] [ 309.661540] the shortest dependencies between 2nd lock and 1st lock: [ 309.661547] -> (cpu_hotplug.lock){+.+.+.} ops: 829 { [ 309.661553] HARDIRQ-ON-W at: [ 309.661560] __lock_acquire+0x5e5/0x1b50 [ 309.661565] lock_acquire+0xc9/0x220 [ 309.661572] __mutex_lock+0x6e/0x990 [ 309.661576] mutex_lock_nested+0x16/0x20 [ 309.661583] get_online_cpus+0x61/0x80 [ 309.661590] kmem_cache_create+0x25/0x1d0 [ 309.661596] debug_objects_mem_init+0x30/0x249 [ 309.661602] start_kernel+0x341/0x3fe [ 309.661607] x86_64_start_reservations+0x2a/0x2c [ 309.661612] x86_64_start_kernel+0x173/0x186 [ 309.661619] verify_cpu+0x0/0xfc [ 309.661622] SOFTIRQ-ON-W at: [ 309.661627] __lock_acquire+0x611/0x1b50 [ 309.661632] lock_acquire+0xc9/0x220 [ 309.661636] __mutex_lock+0x6e/0x990 [ 309.661641] mutex_lock_nested+0x16/0x20 [ 309.661646] get_online_cpus+0x61/0x80 [ 309.661650] kmem_cache_create+0x25/0x1d0 [ 309.661655] debug_objects_mem_init+0x30/0x249 [ 309.661660] start_kernel+0x341/0x3fe [ 309.661664] x86_64_start_reservations+0x2a/0x2c [ 309.661669] x86_64_start_kernel+0x173/0x186 [ 309.661674] verify_cpu+0x0/0xfc [ 309.661677] RECLAIM_FS-ON-W at: [ 309.661682] mark_held_locks+0x6f/0xa0 [ 309.661687] lockdep_trace_alloc+0xb3/0x100 [ 309.661693] kmem_cache_alloc_trace+0x31/0x2e0 [ 309.661699] __smpboot_create_thread.part.1+0x27/0xe0 [ 309.661704] smpboot_create_threads+0x61/0x90 [ 309.661709] cpuhp_invoke_callback+0x9c/0x8a0 [ 309.661713] cpuhp_up_callbacks+0x31/0xb0 [ 309.661718] _cpu_up+0x7a/0xc0 [ 309.661723] do_cpu_up+0x5f/0x80 [ 309.661727] cpu_up+0xe/0x10 [ 309.661734] smp_init+0x71/0xb3 [ 309.661738] kernel_init_freeable+0x94/0x19e [ 309.661743] kernel_init+0x9/0xf0 [ 309.661748] ret_from_fork+0x2e/0x40 [ 309.661752] INITIAL USE at: [ 309.661757] __lock_acquire+0x234/0x1b50 [ 309.661761] lock_acquire+0xc9/0x220 [ 309.661766] __mutex_lock+0x6e/0x990 [ 309.661771] mutex_lock_nested+0x16/0x20 [ 309.661775] get_online_cpus+0x61/0x80 [ 309.661780] __cpuhp_setup_state+0x44/0x170 [ 309.661785] page_alloc_init+0x23/0x3a [ 309.661790] start_kernel+0x124/0x3fe [ 309.661794] x86_64_start_reservations+0x2a/0x2c [ 309.661799] x86_64_start_kernel+0x173/0x186 [ 309.661804] verify_cpu+0x0/0xfc [ 309.661807] } [ 309.661813] ... key at: [<ffffffff81e37690>] cpu_hotplug+0xb0/0x100 [ 309.661817] ... acquired at: [ 309.661821] lock_acquire+0xc9/0x220 [ 309.661825] __mutex_lock+0x6e/0x990 [ 309.661829] mutex_lock_nested+0x16/0x20 [ 309.661833] get_online_cpus+0x61/0x80 [ 309.661837] _rcu_barrier+0x9f/0x160 [ 309.661841] rcu_barrier+0x10/0x20 [ 309.661847] netdev_run_todo+0x5f/0x310 [ 309.661852] rtnl_unlock+0x9/0x10 [ 309.661856] default_device_exit_batch+0x133/0x150 [ 309.661862] ops_exit_list.isra.0+0x4d/0x60 [ 309.661866] cleanup_net+0x1d8/0x2c0 [ 309.661872] process_one_work+0x1f4/0x6d0 [ 309.661876] worker_thread+0x49/0x4a0 [ 309.661881] kthread+0x107/0x140 [ 309.661884] ret_from_fork+0x2e/0x40 [ 309.661890] -> (rcu_preempt_state.barrier_mutex){+.+.-.} ops: 179 { [ 309.661896] HARDIRQ-ON-W at: [ 309.661901] __lock_acquire+0x5e5/0x1b50 [ 309.661905] lock_acquire+0xc9/0x220 [ 309.661910] __mutex_lock+0x6e/0x990 [ 309.661914] mutex_lock_nested+0x16/0x20 [ 309.661919] _rcu_barrier+0x31/0x160 [ 309.661923] rcu_barrier+0x10/0x20 [ 309.661928] netdev_run_todo+0x5f/0x310 [ 309.661932] rtnl_unlock+0x9/0x10 [ 309.661936] default_device_exit_batch+0x133/0x150 [ 309.661941] ops_exit_list.isra.0+0x4d/0x60 [ 309.661946] cleanup_net+0x1d8/0x2c0 [ 309.661951] process_one_work+0x1f4/0x6d0 [ 309.661955] worker_thread+0x49/0x4a0 [ 309.661960] kthread+0x107/0x140 [ 309.661964] ret_from_fork+0x2e/0x40 [ 309.661968] SOFTIRQ-ON-W at: [ 309.661972] __lock_acquire+0x611/0x1b50 [ 309.661977] lock_acquire+0xc9/0x220 [ 309.661981] __mutex_lock+0x6e/0x990 [ 309.661986] mutex_lock_nested+0x16/0x20 [ 309.661990] _rcu_barrier+0x31/0x160 [ 309.661995] rcu_barrier+0x10/0x20 [ 309.661999] netdev_run_todo+0x5f/0x310 [ 309.662003] rtnl_unlock+0x9/0x10 [ 309.662008] default_device_exit_batch+0x133/0x150 [ 309.662013] ops_exit_list.isra.0+0x4d/0x60 [ 309.662017] cleanup_net+0x1d8/0x2c0 [ 309.662022] process_one_work+0x1f4/0x6d0 [ 309.662027] worker_thread+0x49/0x4a0 [ 309.662031] kthread+0x107/0x140 [ 309.662035] ret_from_fork+0x2e/0x40 [ 309.662039] IN-RECLAIM_FS-W at: [ 309.662043] __lock_acquire+0x638/0x1b50 [ 309.662048] lock_acquire+0xc9/0x220 [ 309.662053] __mutex_lock+0x6e/0x990 [ 309.662058] mutex_lock_nested+0x16/0x20 [ 309.662062] _rcu_barrier+0x31/0x160 [ 309.662067] rcu_barrier+0x10/0x20 [ 309.662089] i915_gem_shrink_all+0x33/0x40 [i915] [ 309.662109] i915_drop_caches_set+0x141/0x150 [i915] [ 309.662114] simple_attr_write+0xc7/0xe0 [ 309.662119] full_proxy_write+0x4f/0x70 [ 309.662124] __vfs_write+0x23/0x120 [ 309.662128] vfs_write+0xc6/0x1f0 [ 309.662133] SyS_write+0x44/0xb0 [ 309.662138] entry_SYSCALL_64_fastpath+0x1c/0xb1 [ 309.662142] INITIAL USE at: [ 309.662147] __lock_acquire+0x234/0x1b50 [ 309.662151] lock_acquire+0xc9/0x220 [ 309.662156] __mutex_lock+0x6e/0x990 [ 309.662160] mutex_lock_nested+0x16/0x20 [ 309.662165] _rcu_barrier+0x31/0x160 [ 309.662169] rcu_barrier+0x10/0x20 [ 309.662174] netdev_run_todo+0x5f/0x310 [ 309.662178] rtnl_unlock+0x9/0x10 [ 309.662183] default_device_exit_batch+0x133/0x150 [ 309.662188] ops_exit_list.isra.0+0x4d/0x60 [ 309.662192] cleanup_net+0x1d8/0x2c0 [ 309.662197] process_one_work+0x1f4/0x6d0 [ 309.662202] worker_thread+0x49/0x4a0 [ 309.662206] kthread+0x107/0x140 [ 309.662210] ret_from_fork+0x2e/0x40 [ 309.662214] } [ 309.662220] ... key at: [<ffffffff81e4e1c8>] rcu_preempt_state+0x508/0x780 [ 309.662225] ... acquired at: [ 309.662229] check_usage_forwards+0x12b/0x130 [ 309.662233] mark_lock+0x360/0x6f0 [ 309.662237] __lock_acquire+0x638/0x1b50 [ 309.662241] lock_acquire+0xc9/0x220 [ 309.662245] __mutex_lock+0x6e/0x990 [ 309.662249] mutex_lock_nested+0x16/0x20 [ 309.662253] _rcu_barrier+0x31/0x160 [ 309.662257] rcu_barrier+0x10/0x20 [ 309.662279] i915_gem_shrink_all+0x33/0x40 [i915] [ 309.662298] i915_drop_caches_set+0x141/0x150 [i915] [ 309.662303] simple_attr_write+0xc7/0xe0 [ 309.662307] full_proxy_write+0x4f/0x70 [ 309.662311] __vfs_write+0x23/0x120 [ 309.662315] vfs_write+0xc6/0x1f0 [ 309.662319] SyS_write+0x44/0xb0 [ 309.662323] entry_SYSCALL_64_fastpath+0x1c/0xb1 [ 309.662329] stack backtrace: [ 309.662335] CPU: 1 PID: 6435 Comm: gem_exec_gttfil Tainted: G W 4.11.0-rc1-CI-CI_DRM_2333+ freedreno-zz#1 [ 309.662342] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 786H1 v01.13 07/14/2011 [ 309.662348] Call Trace: [ 309.662354] dump_stack+0x67/0x92 [ 309.662359] print_irq_inversion_bug.part.19+0x1a4/0x1b0 [ 309.662365] check_usage_forwards+0x12b/0x130 [ 309.662369] mark_lock+0x360/0x6f0 [ 309.662374] ? print_shortest_lock_dependencies+0x1a0/0x1a0 [ 309.662379] __lock_acquire+0x638/0x1b50 [ 309.662383] ? __mutex_unlock_slowpath+0x3e/0x2e0 [ 309.662388] ? trace_hardirqs_on+0xd/0x10 [ 309.662392] ? _rcu_barrier+0x31/0x160 [ 309.662396] lock_acquire+0xc9/0x220 [ 309.662400] ? _rcu_barrier+0x31/0x160 [ 309.662404] ? _rcu_barrier+0x31/0x160 [ 309.662409] __mutex_lock+0x6e/0x990 [ 309.662412] ? _rcu_barrier+0x31/0x160 [ 309.662416] ? _rcu_barrier+0x31/0x160 [ 309.662421] ? synchronize_rcu_expedited+0x35/0xb0 [ 309.662426] ? _raw_spin_unlock_irqrestore+0x52/0x60 [ 309.662434] mutex_lock_nested+0x16/0x20 [ 309.662438] _rcu_barrier+0x31/0x160 [ 309.662442] rcu_barrier+0x10/0x20 [ 309.662464] i915_gem_shrink_all+0x33/0x40 [i915] [ 309.662484] i915_drop_caches_set+0x141/0x150 [i915] [ 309.662489] simple_attr_write+0xc7/0xe0 [ 309.662494] full_proxy_write+0x4f/0x70 [ 309.662498] __vfs_write+0x23/0x120 [ 309.662503] ? rcu_read_lock_sched_held+0x75/0x80 [ 309.662507] ? rcu_sync_lockdep_assert+0x2a/0x50 [ 309.662512] ? __sb_start_write+0x102/0x210 [ 309.662516] ? vfs_write+0x17d/0x1f0 [ 309.662520] vfs_write+0xc6/0x1f0 [ 309.662524] ? trace_hardirqs_on_caller+0xe7/0x200 [ 309.662529] SyS_write+0x44/0xb0 [ 309.662533] entry_SYSCALL_64_fastpath+0x1c/0xb1 [ 309.662537] RIP: 0033:0x7f507eac24a0 [ 309.662541] RSP: 002b:00007fffda8720e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 309.662548] RAX: ffffffffffffffda RBX: ffffffff81482bd3 RCX: 00007f507eac24a0 [ 309.662552] RDX: 0000000000000005 RSI: 00007fffda8720f0 RDI: 0000000000000005 [ 309.662557] RBP: ffffc9000048bf88 R08: 0000000000000000 R09: 000000000000002c [ 309.662561] R10: 0000000000000014 R11: 0000000000000246 R12: 00007fffda872230 [ 309.662566] R13: 00007fffda872228 R14: 0000000000000201 R15: 00007fffda8720f0 [ 309.662572] ? __this_cpu_preempt_check+0x13/0x20 Fixes: 0eafec6 ("drm/i915: Enable lockless lookup of request tracking via RCU") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100192 Signed-off-by: Chris Wilson <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: <[email protected]> # v4.9+ Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Daniel Vetter <[email protected]> (cherry picked from commit bd784b7) Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Apr 28, 2017
Dmitry reported a lockdep splat [1] (false positive) that we can fix
by releasing the spinlock before calling icmp_send() from ip_expire()
This is a false positive because sending an ICMP message can not
possibly re-enter the IP frag engine.
[1]
[ INFO: possible circular locking dependency detected ]
4.10.0+ #29 Not tainted
-------------------------------------------------------
modprobe/12392 is trying to acquire lock:
(_xmit_ETHER#2){+.-...}, at: [<ffffffff837a8182>] spin_lock
include/linux/spinlock.h:299 [inline]
(_xmit_ETHER#2){+.-...}, at: [<ffffffff837a8182>] __netif_tx_lock
include/linux/netdevice.h:3486 [inline]
(_xmit_ETHER#2){+.-...}, at: [<ffffffff837a8182>]
sch_direct_xmit+0x282/0x6d0 net/sched/sch_generic.c:180
but task is already holding lock:
(&(&q->lock)->rlock){+.-...}, at: [<ffffffff8389a4d1>] spin_lock
include/linux/spinlock.h:299 [inline]
(&(&q->lock)->rlock){+.-...}, at: [<ffffffff8389a4d1>]
ip_expire+0x51/0x6c0 net/ipv4/ip_fragment.c:201
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> freedreno-zz#1 (&(&q->lock)->rlock){+.-...}:
validate_chain kernel/locking/lockdep.c:2267 [inline]
__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x33/0x50 kernel/locking/spinlock.c:151
spin_lock include/linux/spinlock.h:299 [inline]
ip_defrag+0x3a2/0x4130 net/ipv4/ip_fragment.c:669
ip_check_defrag+0x4e3/0x8b0 net/ipv4/ip_fragment.c:713
packet_rcv_fanout+0x282/0x800 net/packet/af_packet.c:1459
deliver_skb net/core/dev.c:1834 [inline]
dev_queue_xmit_nit+0x294/0xa90 net/core/dev.c:1890
xmit_one net/core/dev.c:2903 [inline]
dev_hard_start_xmit+0x16b/0xab0 net/core/dev.c:2923
sch_direct_xmit+0x31f/0x6d0 net/sched/sch_generic.c:182
__dev_xmit_skb net/core/dev.c:3092 [inline]
__dev_queue_xmit+0x13e5/0x1e60 net/core/dev.c:3358
dev_queue_xmit+0x17/0x20 net/core/dev.c:3423
neigh_resolve_output+0x6b9/0xb10 net/core/neighbour.c:1308
neigh_output include/net/neighbour.h:478 [inline]
ip_finish_output2+0x8b8/0x15a0 net/ipv4/ip_output.c:228
ip_do_fragment+0x1d93/0x2720 net/ipv4/ip_output.c:672
ip_fragment.constprop.54+0x145/0x200 net/ipv4/ip_output.c:545
ip_finish_output+0x82d/0xe10 net/ipv4/ip_output.c:314
NF_HOOK_COND include/linux/netfilter.h:246 [inline]
ip_output+0x1f0/0x7a0 net/ipv4/ip_output.c:404
dst_output include/net/dst.h:486 [inline]
ip_local_out+0x95/0x170 net/ipv4/ip_output.c:124
ip_send_skb+0x3c/0xc0 net/ipv4/ip_output.c:1492
ip_push_pending_frames+0x64/0x80 net/ipv4/ip_output.c:1512
raw_sendmsg+0x26de/0x3a00 net/ipv4/raw.c:655
inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:761
sock_sendmsg_nosec net/socket.c:633 [inline]
sock_sendmsg+0xca/0x110 net/socket.c:643
___sys_sendmsg+0x4a3/0x9f0 net/socket.c:1985
__sys_sendmmsg+0x25c/0x750 net/socket.c:2075
SYSC_sendmmsg net/socket.c:2106 [inline]
SyS_sendmmsg+0x35/0x60 net/socket.c:2101
do_syscall_64+0x2e8/0x930 arch/x86/entry/common.c:281
return_from_SYSCALL_64+0x0/0x7a
-> #0 (_xmit_ETHER#2){+.-...}:
check_prev_add kernel/locking/lockdep.c:1830 [inline]
check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1940
validate_chain kernel/locking/lockdep.c:2267 [inline]
__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x33/0x50 kernel/locking/spinlock.c:151
spin_lock include/linux/spinlock.h:299 [inline]
__netif_tx_lock include/linux/netdevice.h:3486 [inline]
sch_direct_xmit+0x282/0x6d0 net/sched/sch_generic.c:180
__dev_xmit_skb net/core/dev.c:3092 [inline]
__dev_queue_xmit+0x13e5/0x1e60 net/core/dev.c:3358
dev_queue_xmit+0x17/0x20 net/core/dev.c:3423
neigh_hh_output include/net/neighbour.h:468 [inline]
neigh_output include/net/neighbour.h:476 [inline]
ip_finish_output2+0xf6c/0x15a0 net/ipv4/ip_output.c:228
ip_finish_output+0xa29/0xe10 net/ipv4/ip_output.c:316
NF_HOOK_COND include/linux/netfilter.h:246 [inline]
ip_output+0x1f0/0x7a0 net/ipv4/ip_output.c:404
dst_output include/net/dst.h:486 [inline]
ip_local_out+0x95/0x170 net/ipv4/ip_output.c:124
ip_send_skb+0x3c/0xc0 net/ipv4/ip_output.c:1492
ip_push_pending_frames+0x64/0x80 net/ipv4/ip_output.c:1512
icmp_push_reply+0x372/0x4d0 net/ipv4/icmp.c:394
icmp_send+0x156c/0x1c80 net/ipv4/icmp.c:754
ip_expire+0x40e/0x6c0 net/ipv4/ip_fragment.c:239
call_timer_fn+0x241/0x820 kernel/time/timer.c:1268
expire_timers kernel/time/timer.c:1307 [inline]
__run_timers+0x960/0xcf0 kernel/time/timer.c:1601
run_timer_softirq+0x21/0x80 kernel/time/timer.c:1614
__do_softirq+0x31f/0xbe7 kernel/softirq.c:284
invoke_softirq kernel/softirq.c:364 [inline]
irq_exit+0x1cc/0x200 kernel/softirq.c:405
exiting_irq arch/x86/include/asm/apic.h:657 [inline]
smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:962
apic_timer_interrupt+0x93/0xa0 arch/x86/entry/entry_64.S:707
__read_once_size include/linux/compiler.h:254 [inline]
atomic_read arch/x86/include/asm/atomic.h:26 [inline]
rcu_dynticks_curr_cpu_in_eqs kernel/rcu/tree.c:350 [inline]
__rcu_is_watching kernel/rcu/tree.c:1133 [inline]
rcu_is_watching+0x83/0x110 kernel/rcu/tree.c:1147
rcu_read_lock_held+0x87/0xc0 kernel/rcu/update.c:293
radix_tree_deref_slot include/linux/radix-tree.h:238 [inline]
filemap_map_pages+0x6d4/0x1570 mm/filemap.c:2335
do_fault_around mm/memory.c:3231 [inline]
do_read_fault mm/memory.c:3265 [inline]
do_fault+0xbd5/0x2080 mm/memory.c:3370
handle_pte_fault mm/memory.c:3600 [inline]
__handle_mm_fault+0x1062/0x2cb0 mm/memory.c:3714
handle_mm_fault+0x1e2/0x480 mm/memory.c:3751
__do_page_fault+0x4f6/0xb60 arch/x86/mm/fault.c:1397
do_page_fault+0x54/0x70 arch/x86/mm/fault.c:1460
page_fault+0x28/0x30 arch/x86/entry/entry_64.S:1011
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&(&q->lock)->rlock);
lock(_xmit_ETHER#2);
lock(&(&q->lock)->rlock);
lock(_xmit_ETHER#2);
*** DEADLOCK ***
10 locks held by modprobe/12392:
#0: (&mm->mmap_sem){++++++}, at: [<ffffffff81329758>]
__do_page_fault+0x2b8/0xb60 arch/x86/mm/fault.c:1336
freedreno-zz#1: (rcu_read_lock){......}, at: [<ffffffff8188cab6>]
filemap_map_pages+0x1e6/0x1570 mm/filemap.c:2324
freedreno-zz#2: (&(ptlock_ptr(page))->rlock#2){+.+...}, at: [<ffffffff81984a78>]
spin_lock include/linux/spinlock.h:299 [inline]
freedreno-zz#2: (&(ptlock_ptr(page))->rlock#2){+.+...}, at: [<ffffffff81984a78>]
pte_alloc_one_map mm/memory.c:2944 [inline]
freedreno-zz#2: (&(ptlock_ptr(page))->rlock#2){+.+...}, at: [<ffffffff81984a78>]
alloc_set_pte+0x13b8/0x1b90 mm/memory.c:3072
freedreno-zz#3: (((&q->timer))){+.-...}, at: [<ffffffff81627e72>]
lockdep_copy_map include/linux/lockdep.h:175 [inline]
freedreno-zz#3: (((&q->timer))){+.-...}, at: [<ffffffff81627e72>]
call_timer_fn+0x1c2/0x820 kernel/time/timer.c:1258
#4: (&(&q->lock)->rlock){+.-...}, at: [<ffffffff8389a4d1>] spin_lock
include/linux/spinlock.h:299 [inline]
#4: (&(&q->lock)->rlock){+.-...}, at: [<ffffffff8389a4d1>]
ip_expire+0x51/0x6c0 net/ipv4/ip_fragment.c:201
#5: (rcu_read_lock){......}, at: [<ffffffff8389a633>]
ip_expire+0x1b3/0x6c0 net/ipv4/ip_fragment.c:216
#6: (slock-AF_INET){+.-...}, at: [<ffffffff839b3313>] spin_trylock
include/linux/spinlock.h:309 [inline]
#6: (slock-AF_INET){+.-...}, at: [<ffffffff839b3313>] icmp_xmit_lock
net/ipv4/icmp.c:219 [inline]
#6: (slock-AF_INET){+.-...}, at: [<ffffffff839b3313>]
icmp_send+0x803/0x1c80 net/ipv4/icmp.c:681
#7: (rcu_read_lock_bh){......}, at: [<ffffffff838ab9a1>]
ip_finish_output2+0x2c1/0x15a0 net/ipv4/ip_output.c:198
#8: (rcu_read_lock_bh){......}, at: [<ffffffff836d1dee>]
__dev_queue_xmit+0x23e/0x1e60 net/core/dev.c:3324
#9: (dev->qdisc_running_key ?: &qdisc_running_key){+.....}, at:
[<ffffffff836d3a27>] dev_queue_xmit+0x17/0x20 net/core/dev.c:3423
stack backtrace:
CPU: 0 PID: 12392 Comm: modprobe Not tainted 4.10.0+ #29
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0x2ee/0x3ef lib/dump_stack.c:52
print_circular_bug+0x307/0x3b0 kernel/locking/lockdep.c:1204
check_prev_add kernel/locking/lockdep.c:1830 [inline]
check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1940
validate_chain kernel/locking/lockdep.c:2267 [inline]
__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x33/0x50 kernel/locking/spinlock.c:151
spin_lock include/linux/spinlock.h:299 [inline]
__netif_tx_lock include/linux/netdevice.h:3486 [inline]
sch_direct_xmit+0x282/0x6d0 net/sched/sch_generic.c:180
__dev_xmit_skb net/core/dev.c:3092 [inline]
__dev_queue_xmit+0x13e5/0x1e60 net/core/dev.c:3358
dev_queue_xmit+0x17/0x20 net/core/dev.c:3423
neigh_hh_output include/net/neighbour.h:468 [inline]
neigh_output include/net/neighbour.h:476 [inline]
ip_finish_output2+0xf6c/0x15a0 net/ipv4/ip_output.c:228
ip_finish_output+0xa29/0xe10 net/ipv4/ip_output.c:316
NF_HOOK_COND include/linux/netfilter.h:246 [inline]
ip_output+0x1f0/0x7a0 net/ipv4/ip_output.c:404
dst_output include/net/dst.h:486 [inline]
ip_local_out+0x95/0x170 net/ipv4/ip_output.c:124
ip_send_skb+0x3c/0xc0 net/ipv4/ip_output.c:1492
ip_push_pending_frames+0x64/0x80 net/ipv4/ip_output.c:1512
icmp_push_reply+0x372/0x4d0 net/ipv4/icmp.c:394
icmp_send+0x156c/0x1c80 net/ipv4/icmp.c:754
ip_expire+0x40e/0x6c0 net/ipv4/ip_fragment.c:239
call_timer_fn+0x241/0x820 kernel/time/timer.c:1268
expire_timers kernel/time/timer.c:1307 [inline]
__run_timers+0x960/0xcf0 kernel/time/timer.c:1601
run_timer_softirq+0x21/0x80 kernel/time/timer.c:1614
__do_softirq+0x31f/0xbe7 kernel/softirq.c:284
invoke_softirq kernel/softirq.c:364 [inline]
irq_exit+0x1cc/0x200 kernel/softirq.c:405
exiting_irq arch/x86/include/asm/apic.h:657 [inline]
smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:962
apic_timer_interrupt+0x93/0xa0 arch/x86/entry/entry_64.S:707
RIP: 0010:__read_once_size include/linux/compiler.h:254 [inline]
RIP: 0010:atomic_read arch/x86/include/asm/atomic.h:26 [inline]
RIP: 0010:rcu_dynticks_curr_cpu_in_eqs kernel/rcu/tree.c:350 [inline]
RIP: 0010:__rcu_is_watching kernel/rcu/tree.c:1133 [inline]
RIP: 0010:rcu_is_watching+0x83/0x110 kernel/rcu/tree.c:1147
RSP: 0000:ffff8801c391f120 EFLAGS: 00000a03 ORIG_RAX: ffffffffffffff10
RAX: dffffc0000000000 RBX: ffff8801c391f148 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 000055edd4374000 RDI: ffff8801dbe1ae0c
RBP: ffff8801c391f1a0 R08: 0000000000000002 R09: 0000000000000000
R10: dffffc0000000000 R11: 0000000000000002 R12: 1ffff10038723e25
R13: ffff8801dbe1ae00 R14: ffff8801c391f680 R15: dffffc0000000000
</IRQ>
rcu_read_lock_held+0x87/0xc0 kernel/rcu/update.c:293
radix_tree_deref_slot include/linux/radix-tree.h:238 [inline]
filemap_map_pages+0x6d4/0x1570 mm/filemap.c:2335
do_fault_around mm/memory.c:3231 [inline]
do_read_fault mm/memory.c:3265 [inline]
do_fault+0xbd5/0x2080 mm/memory.c:3370
handle_pte_fault mm/memory.c:3600 [inline]
__handle_mm_fault+0x1062/0x2cb0 mm/memory.c:3714
handle_mm_fault+0x1e2/0x480 mm/memory.c:3751
__do_page_fault+0x4f6/0xb60 arch/x86/mm/fault.c:1397
do_page_fault+0x54/0x70 arch/x86/mm/fault.c:1460
page_fault+0x28/0x30 arch/x86/entry/entry_64.S:1011
RIP: 0033:0x7f83172f2786
RSP: 002b:00007fffe859ae80 EFLAGS: 00010293
RAX: 000055edd4373040 RBX: 00007f83175111c8 RCX: 000055edd4373238
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007f8317510970
RBP: 00007fffe859afd0 R08: 0000000000000009 R09: 0000000000000000
R10: 0000000000000064 R11: 0000000000000000 R12: 000055edd4373040
R13: 0000000000000000 R14: 00007fffe859afe8 R15: 0000000000000000
Signed-off-by: Eric Dumazet <[email protected]>
Reported-by: Dmitry Vyukov <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Apr 28, 2017
xhci needs to take care of four scenarios when asked to cancel a URB. 1 URB is not queued or already given back. usb_hcd_check_unlink_urb() will return an error, we pass the error on 2 We fail to find xhci internal structures from urb private data such as virtual device and endpoint ring. Give back URB immediately, can't do anything about internal structures. 3 URB private data has valid pointers to xhci internal data, but host is not responding. give back URB immedately and remove the URB from the endpoint lists. 4 Everyting is working add URB to cancel list, queue a command to stop the endpoint, after which the URB can be turned to no-op or skipped, removed from lists, and given back. We failed to give back the urb in case 2 where the correct device and endpoint pointers could not be retrieved from URB private data. This caused a hang on Dell Inspiron 5558/0VNM2T at resume from suspend as urb was never returned. [ 245.270505] INFO: task rtsx_usb_ms_1:254 blocked for more than 120 seconds. [ 245.272244] Tainted: G W 4.11.0-rc3-ARCH freedreno-zz#2 [ 245.273983] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 245.275737] rtsx_usb_ms_1 D 0 254 2 0x00000000 [ 245.277524] Call Trace: [ 245.279278] __schedule+0x2d3/0x8a0 [ 245.281077] schedule+0x3d/0x90 [ 245.281961] usb_kill_urb.part.3+0x6c/0xa0 [usbcore] [ 245.282861] ? wake_atomic_t_function+0x60/0x60 [ 245.283760] usb_kill_urb+0x21/0x30 [usbcore] [ 245.284649] usb_start_wait_urb+0xe5/0x170 [usbcore] [ 245.285541] ? try_to_del_timer_sync+0x53/0x80 [ 245.286434] usb_bulk_msg+0xbd/0x160 [usbcore] [ 245.287326] rtsx_usb_send_cmd+0x63/0x90 [rtsx_usb] Reported-by: [email protected] Tested-by: [email protected] Cc: [email protected] Signed-off-by: Mathias Nyman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Apr 28, 2017
…e_pmd()
I found the race condition which triggers the following bug when
move_pages() and soft offline are called on a single hugetlb page
concurrently.
Soft offlining page 0x119400 at 0x700000000000
BUG: unable to handle kernel paging request at ffffea0011943820
IP: follow_huge_pmd+0x143/0x190
PGD 7ffd2067
PUD 7ffd1067
PMD 0
[61163.582052] Oops: 0000 [freedreno-zz#1] SMP
Modules linked in: binfmt_misc ppdev virtio_balloon parport_pc pcspkr i2c_piix4 parport i2c_core acpi_cpufreq ip_tables xfs libcrc32c ata_generic pata_acpi virtio_blk 8139too crc32c_intel ata_piix serio_raw libata virtio_pci 8139cp virtio_ring virtio mii floppy dm_mirror dm_region_hash dm_log dm_mod [last unloaded: cap_check]
CPU: 0 PID: 22573 Comm: iterate_numa_mo Tainted: P OE 4.11.0-rc2-mm1+ freedreno-zz#2
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
RIP: 0010:follow_huge_pmd+0x143/0x190
RSP: 0018:ffffc90004bdbcd0 EFLAGS: 00010202
RAX: 0000000465003e80 RBX: ffffea0004e34d30 RCX: 00003ffffffff000
RDX: 0000000011943800 RSI: 0000000000080001 RDI: 0000000465003e80
RBP: ffffc90004bdbd18 R08: 0000000000000000 R09: ffff880138d34000
R10: ffffea0004650000 R11: 0000000000c363b0 R12: ffffea0011943800
R13: ffff8801b8d34000 R14: ffffea0000000000 R15: 000077ff80000000
FS: 00007fc977710740(0000) GS:ffff88007dc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffea0011943820 CR3: 000000007a746000 CR4: 00000000001406f0
Call Trace:
follow_page_mask+0x270/0x550
SYSC_move_pages+0x4ea/0x8f0
SyS_move_pages+0xe/0x10
do_syscall_64+0x67/0x180
entry_SYSCALL64_slow_path+0x25/0x25
RIP: 0033:0x7fc976e03949
RSP: 002b:00007ffe72221d88 EFLAGS: 00000246 ORIG_RAX: 0000000000000117
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc976e03949
RDX: 0000000000c22390 RSI: 0000000000001400 RDI: 0000000000005827
RBP: 00007ffe72221e00 R08: 0000000000c2c3a0 R09: 0000000000000004
R10: 0000000000c363b0 R11: 0000000000000246 R12: 0000000000400650
R13: 00007ffe72221ee0 R14: 0000000000000000 R15: 0000000000000000
Code: 81 e4 ff ff 1f 00 48 21 c2 49 c1 ec 0c 48 c1 ea 0c 4c 01 e2 49 bc 00 00 00 00 00 ea ff ff 48 c1 e2 06 49 01 d4 f6 45 bc 04 74 90 <49> 8b 7c 24 20 40 f6 c7 01 75 2b 4c 89 e7 8b 47 1c 85 c0 7e 2a
RIP: follow_huge_pmd+0x143/0x190 RSP: ffffc90004bdbcd0
CR2: ffffea0011943820
---[ end trace e4f81353a2d23232 ]---
Kernel panic - not syncing: Fatal exception
Kernel Offset: disabled
This bug is triggered when pmd_present() returns true for non-present
hugetlb, so fixing the present check in follow_huge_pmd() prevents it.
Using pmd_present() to determine present/non-present for hugetlb is not
correct, because pmd_present() checks multiple bits (not only
_PAGE_PRESENT) for historical reason and it can misjudge hugetlb state.
Fixes: e66f17f ("mm/hugetlb: take page table lock in follow_huge_pmd()")
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Naoya Horiguchi <[email protected]>
Acked-by: Hillf Danton <[email protected]>
Cc: Hugh Dickins <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: "Kirill A. Shutemov" <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Christian Borntraeger <[email protected]>
Cc: Gerald Schaefer <[email protected]>
Cc: <[email protected]> [4.0+]
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Apr 28, 2017
mipsxx_pmu_handle_shared_irq() calls irq_work_run() while holding the pmuint_rwlock for read. irq_work_run() can, via perf_pending_event(), call try_to_wake_up() which can try to take rq->lock. However, perf can also call perf_pmu_enable() (and thus take the pmuint_rwlock for write) while holding the rq->lock, from finish_task_switch() via perf_event_context_sched_in(). This leads to an ABBA deadlock: PID: 3855 TASK: 8f7ce288 CPU: 2 COMMAND: "process" #0 [89c39ac8] __delay at 803b5be4 freedreno-zz#1 [89c39ac8] do_raw_spin_lock at 8008fdcc freedreno-zz#2 [89c39af8] try_to_wake_up at 8006e47c freedreno-zz#3 [89c39b38] pollwake at 8018eab0 #4 [89c39b68] __wake_up_common at 800879f4 #5 [89c39b98] __wake_up at 800880e4 #6 [89c39bc8] perf_event_wakeup at 8012109c #7 [89c39be8] perf_pending_event at 80121184 #8 [89c39c08] irq_work_run_list at 801151f0 #9 [89c39c38] irq_work_run at 80115274 #10 [89c39c50] mipsxx_pmu_handle_shared_irq at 8002cc7c PID: 1481 TASK: 8eaac6a8 CPU: 3 COMMAND: "process" #0 [8de7f900] do_raw_write_lock at 800900e0 freedreno-zz#1 [8de7f918] perf_event_context_sched_in at 80122310 freedreno-zz#2 [8de7f938] __perf_event_task_sched_in at 80122608 freedreno-zz#3 [8de7f958] finish_task_switch at 8006b8a4 #4 [8de7f998] __schedule at 805e4dc4 #5 [8de7f9f8] schedule at 805e5558 #6 [8de7fa10] schedule_hrtimeout_range_clock at 805e9984 #7 [8de7fa70] poll_schedule_timeout at 8018e8f8 #8 [8de7fa88] do_select at 8018f338 #9 [8de7fd88] core_sys_select at 8018f5cc #10 [8de7fee0] sys_select at 8018f854 #11 [8de7ff28] syscall_common at 80028fc8 The lock seems to be there to protect the hardware counters so there is no need to hold it across irq_work_run(). Signed-off-by: Rabin Vincent <[email protected]> Signed-off-by: Ralf Baechle <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Apr 28, 2017
Holding the reconfig_mutex over a potential userspace fault sets up a
lockdep dependency chain between filesystem-DAX and the libnvdimm ioctl
path. Move the user access outside of the lock.
[ INFO: possible circular locking dependency detected ]
4.11.0-rc3+ #13 Tainted: G W O
-------------------------------------------------------
fallocate/16656 is trying to acquire lock:
(&nvdimm_bus->reconfig_mutex){+.+.+.}, at: [<ffffffffa00080b1>] nvdimm_bus_lock+0x21/0x30 [libnvdimm]
but task is already holding lock:
(jbd2_handle){++++..}, at: [<ffffffff813b4944>] start_this_handle+0x104/0x460
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> freedreno-zz#2 (jbd2_handle){++++..}:
lock_acquire+0xbd/0x200
start_this_handle+0x16a/0x460
jbd2__journal_start+0xe9/0x2d0
__ext4_journal_start_sb+0x89/0x1c0
ext4_dirty_inode+0x32/0x70
__mark_inode_dirty+0x235/0x670
generic_update_time+0x87/0xd0
touch_atime+0xa9/0xd0
ext4_file_mmap+0x90/0xb0
mmap_region+0x370/0x5b0
do_mmap+0x415/0x4f0
vm_mmap_pgoff+0xd7/0x120
SyS_mmap_pgoff+0x1c5/0x290
SyS_mmap+0x22/0x30
entry_SYSCALL_64_fastpath+0x1f/0xc2
-> freedreno-zz#1 (&mm->mmap_sem){++++++}:
lock_acquire+0xbd/0x200
__might_fault+0x70/0xa0
__nd_ioctl+0x683/0x720 [libnvdimm]
nvdimm_ioctl+0x8b/0xe0 [libnvdimm]
do_vfs_ioctl+0xa8/0x740
SyS_ioctl+0x79/0x90
do_syscall_64+0x6c/0x200
return_from_SYSCALL_64+0x0/0x7a
-> #0 (&nvdimm_bus->reconfig_mutex){+.+.+.}:
__lock_acquire+0x16b6/0x1730
lock_acquire+0xbd/0x200
__mutex_lock+0x88/0x9b0
mutex_lock_nested+0x1b/0x20
nvdimm_bus_lock+0x21/0x30 [libnvdimm]
nvdimm_forget_poison+0x25/0x50 [libnvdimm]
nvdimm_clear_poison+0x106/0x140 [libnvdimm]
pmem_do_bvec+0x1c2/0x2b0 [nd_pmem]
pmem_make_request+0xf9/0x270 [nd_pmem]
generic_make_request+0x118/0x3b0
submit_bio+0x75/0x150
Cc: <[email protected]>
Fixes: 62232e4 ("libnvdimm: control (ioctl) messages for nvdimm_bus and nvdimm devices")
Cc: Dave Jiang <[email protected]>
Reported-by: Vishal Verma <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
May 2, 2017
The rcu_barrier() takes the cpu_hotplug mutex which itself is not reclaim-safe, and so rcu_barrier() is illegal from inside the shrinker. [ 309.661373] ========================================================= [ 309.661376] [ INFO: possible irq lock inversion dependency detected ] [ 309.661380] 4.11.0-rc1-CI-CI_DRM_2333+ freedreno-zz#1 Tainted: G W [ 309.661383] --------------------------------------------------------- [ 309.661386] gem_exec_gttfil/6435 just changed the state of lock: [ 309.661389] (rcu_preempt_state.barrier_mutex){+.+.-.}, at: [<ffffffff81100731>] _rcu_barrier+0x31/0x160 [ 309.661399] but this lock took another, RECLAIM_FS-unsafe lock in the past: [ 309.661402] (cpu_hotplug.lock){+.+.+.} [ 309.661404] and interrupts could create inverse lock ordering between them. [ 309.661410] other info that might help us debug this: [ 309.661414] Possible interrupt unsafe locking scenario: [ 309.661417] CPU0 CPU1 [ 309.661419] ---- ---- [ 309.661421] lock(cpu_hotplug.lock); [ 309.661425] local_irq_disable(); [ 309.661432] lock(rcu_preempt_state.barrier_mutex); [ 309.661441] lock(cpu_hotplug.lock); [ 309.661446] <Interrupt> [ 309.661448] lock(rcu_preempt_state.barrier_mutex); [ 309.661453] *** DEADLOCK *** [ 309.661460] 4 locks held by gem_exec_gttfil/6435: [ 309.661464] #0: (sb_writers#10){.+.+.+}, at: [<ffffffff8120d83d>] vfs_write+0x17d/0x1f0 [ 309.661475] freedreno-zz#1: (debugfs_srcu){......}, at: [<ffffffff81320491>] debugfs_use_file_start+0x41/0xa0 [ 309.661486] freedreno-zz#2: (&attr->mutex){+.+.+.}, at: [<ffffffff8123a3e7>] simple_attr_write+0x37/0xe0 [ 309.661495] freedreno-zz#3: (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa0091b4a>] i915_drop_caches_set+0x3a/0x150 [i915] [ 309.661540] the shortest dependencies between 2nd lock and 1st lock: [ 309.661547] -> (cpu_hotplug.lock){+.+.+.} ops: 829 { [ 309.661553] HARDIRQ-ON-W at: [ 309.661560] __lock_acquire+0x5e5/0x1b50 [ 309.661565] lock_acquire+0xc9/0x220 [ 309.661572] __mutex_lock+0x6e/0x990 [ 309.661576] mutex_lock_nested+0x16/0x20 [ 309.661583] get_online_cpus+0x61/0x80 [ 309.661590] kmem_cache_create+0x25/0x1d0 [ 309.661596] debug_objects_mem_init+0x30/0x249 [ 309.661602] start_kernel+0x341/0x3fe [ 309.661607] x86_64_start_reservations+0x2a/0x2c [ 309.661612] x86_64_start_kernel+0x173/0x186 [ 309.661619] verify_cpu+0x0/0xfc [ 309.661622] SOFTIRQ-ON-W at: [ 309.661627] __lock_acquire+0x611/0x1b50 [ 309.661632] lock_acquire+0xc9/0x220 [ 309.661636] __mutex_lock+0x6e/0x990 [ 309.661641] mutex_lock_nested+0x16/0x20 [ 309.661646] get_online_cpus+0x61/0x80 [ 309.661650] kmem_cache_create+0x25/0x1d0 [ 309.661655] debug_objects_mem_init+0x30/0x249 [ 309.661660] start_kernel+0x341/0x3fe [ 309.661664] x86_64_start_reservations+0x2a/0x2c [ 309.661669] x86_64_start_kernel+0x173/0x186 [ 309.661674] verify_cpu+0x0/0xfc [ 309.661677] RECLAIM_FS-ON-W at: [ 309.661682] mark_held_locks+0x6f/0xa0 [ 309.661687] lockdep_trace_alloc+0xb3/0x100 [ 309.661693] kmem_cache_alloc_trace+0x31/0x2e0 [ 309.661699] __smpboot_create_thread.part.1+0x27/0xe0 [ 309.661704] smpboot_create_threads+0x61/0x90 [ 309.661709] cpuhp_invoke_callback+0x9c/0x8a0 [ 309.661713] cpuhp_up_callbacks+0x31/0xb0 [ 309.661718] _cpu_up+0x7a/0xc0 [ 309.661723] do_cpu_up+0x5f/0x80 [ 309.661727] cpu_up+0xe/0x10 [ 309.661734] smp_init+0x71/0xb3 [ 309.661738] kernel_init_freeable+0x94/0x19e [ 309.661743] kernel_init+0x9/0xf0 [ 309.661748] ret_from_fork+0x2e/0x40 [ 309.661752] INITIAL USE at: [ 309.661757] __lock_acquire+0x234/0x1b50 [ 309.661761] lock_acquire+0xc9/0x220 [ 309.661766] __mutex_lock+0x6e/0x990 [ 309.661771] mutex_lock_nested+0x16/0x20 [ 309.661775] get_online_cpus+0x61/0x80 [ 309.661780] __cpuhp_setup_state+0x44/0x170 [ 309.661785] page_alloc_init+0x23/0x3a [ 309.661790] start_kernel+0x124/0x3fe [ 309.661794] x86_64_start_reservations+0x2a/0x2c [ 309.661799] x86_64_start_kernel+0x173/0x186 [ 309.661804] verify_cpu+0x0/0xfc [ 309.661807] } [ 309.661813] ... key at: [<ffffffff81e37690>] cpu_hotplug+0xb0/0x100 [ 309.661817] ... acquired at: [ 309.661821] lock_acquire+0xc9/0x220 [ 309.661825] __mutex_lock+0x6e/0x990 [ 309.661829] mutex_lock_nested+0x16/0x20 [ 309.661833] get_online_cpus+0x61/0x80 [ 309.661837] _rcu_barrier+0x9f/0x160 [ 309.661841] rcu_barrier+0x10/0x20 [ 309.661847] netdev_run_todo+0x5f/0x310 [ 309.661852] rtnl_unlock+0x9/0x10 [ 309.661856] default_device_exit_batch+0x133/0x150 [ 309.661862] ops_exit_list.isra.0+0x4d/0x60 [ 309.661866] cleanup_net+0x1d8/0x2c0 [ 309.661872] process_one_work+0x1f4/0x6d0 [ 309.661876] worker_thread+0x49/0x4a0 [ 309.661881] kthread+0x107/0x140 [ 309.661884] ret_from_fork+0x2e/0x40 [ 309.661890] -> (rcu_preempt_state.barrier_mutex){+.+.-.} ops: 179 { [ 309.661896] HARDIRQ-ON-W at: [ 309.661901] __lock_acquire+0x5e5/0x1b50 [ 309.661905] lock_acquire+0xc9/0x220 [ 309.661910] __mutex_lock+0x6e/0x990 [ 309.661914] mutex_lock_nested+0x16/0x20 [ 309.661919] _rcu_barrier+0x31/0x160 [ 309.661923] rcu_barrier+0x10/0x20 [ 309.661928] netdev_run_todo+0x5f/0x310 [ 309.661932] rtnl_unlock+0x9/0x10 [ 309.661936] default_device_exit_batch+0x133/0x150 [ 309.661941] ops_exit_list.isra.0+0x4d/0x60 [ 309.661946] cleanup_net+0x1d8/0x2c0 [ 309.661951] process_one_work+0x1f4/0x6d0 [ 309.661955] worker_thread+0x49/0x4a0 [ 309.661960] kthread+0x107/0x140 [ 309.661964] ret_from_fork+0x2e/0x40 [ 309.661968] SOFTIRQ-ON-W at: [ 309.661972] __lock_acquire+0x611/0x1b50 [ 309.661977] lock_acquire+0xc9/0x220 [ 309.661981] __mutex_lock+0x6e/0x990 [ 309.661986] mutex_lock_nested+0x16/0x20 [ 309.661990] _rcu_barrier+0x31/0x160 [ 309.661995] rcu_barrier+0x10/0x20 [ 309.661999] netdev_run_todo+0x5f/0x310 [ 309.662003] rtnl_unlock+0x9/0x10 [ 309.662008] default_device_exit_batch+0x133/0x150 [ 309.662013] ops_exit_list.isra.0+0x4d/0x60 [ 309.662017] cleanup_net+0x1d8/0x2c0 [ 309.662022] process_one_work+0x1f4/0x6d0 [ 309.662027] worker_thread+0x49/0x4a0 [ 309.662031] kthread+0x107/0x140 [ 309.662035] ret_from_fork+0x2e/0x40 [ 309.662039] IN-RECLAIM_FS-W at: [ 309.662043] __lock_acquire+0x638/0x1b50 [ 309.662048] lock_acquire+0xc9/0x220 [ 309.662053] __mutex_lock+0x6e/0x990 [ 309.662058] mutex_lock_nested+0x16/0x20 [ 309.662062] _rcu_barrier+0x31/0x160 [ 309.662067] rcu_barrier+0x10/0x20 [ 309.662089] i915_gem_shrink_all+0x33/0x40 [i915] [ 309.662109] i915_drop_caches_set+0x141/0x150 [i915] [ 309.662114] simple_attr_write+0xc7/0xe0 [ 309.662119] full_proxy_write+0x4f/0x70 [ 309.662124] __vfs_write+0x23/0x120 [ 309.662128] vfs_write+0xc6/0x1f0 [ 309.662133] SyS_write+0x44/0xb0 [ 309.662138] entry_SYSCALL_64_fastpath+0x1c/0xb1 [ 309.662142] INITIAL USE at: [ 309.662147] __lock_acquire+0x234/0x1b50 [ 309.662151] lock_acquire+0xc9/0x220 [ 309.662156] __mutex_lock+0x6e/0x990 [ 309.662160] mutex_lock_nested+0x16/0x20 [ 309.662165] _rcu_barrier+0x31/0x160 [ 309.662169] rcu_barrier+0x10/0x20 [ 309.662174] netdev_run_todo+0x5f/0x310 [ 309.662178] rtnl_unlock+0x9/0x10 [ 309.662183] default_device_exit_batch+0x133/0x150 [ 309.662188] ops_exit_list.isra.0+0x4d/0x60 [ 309.662192] cleanup_net+0x1d8/0x2c0 [ 309.662197] process_one_work+0x1f4/0x6d0 [ 309.662202] worker_thread+0x49/0x4a0 [ 309.662206] kthread+0x107/0x140 [ 309.662210] ret_from_fork+0x2e/0x40 [ 309.662214] } [ 309.662220] ... key at: [<ffffffff81e4e1c8>] rcu_preempt_state+0x508/0x780 [ 309.662225] ... acquired at: [ 309.662229] check_usage_forwards+0x12b/0x130 [ 309.662233] mark_lock+0x360/0x6f0 [ 309.662237] __lock_acquire+0x638/0x1b50 [ 309.662241] lock_acquire+0xc9/0x220 [ 309.662245] __mutex_lock+0x6e/0x990 [ 309.662249] mutex_lock_nested+0x16/0x20 [ 309.662253] _rcu_barrier+0x31/0x160 [ 309.662257] rcu_barrier+0x10/0x20 [ 309.662279] i915_gem_shrink_all+0x33/0x40 [i915] [ 309.662298] i915_drop_caches_set+0x141/0x150 [i915] [ 309.662303] simple_attr_write+0xc7/0xe0 [ 309.662307] full_proxy_write+0x4f/0x70 [ 309.662311] __vfs_write+0x23/0x120 [ 309.662315] vfs_write+0xc6/0x1f0 [ 309.662319] SyS_write+0x44/0xb0 [ 309.662323] entry_SYSCALL_64_fastpath+0x1c/0xb1 [ 309.662329] stack backtrace: [ 309.662335] CPU: 1 PID: 6435 Comm: gem_exec_gttfil Tainted: G W 4.11.0-rc1-CI-CI_DRM_2333+ freedreno-zz#1 [ 309.662342] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 786H1 v01.13 07/14/2011 [ 309.662348] Call Trace: [ 309.662354] dump_stack+0x67/0x92 [ 309.662359] print_irq_inversion_bug.part.19+0x1a4/0x1b0 [ 309.662365] check_usage_forwards+0x12b/0x130 [ 309.662369] mark_lock+0x360/0x6f0 [ 309.662374] ? print_shortest_lock_dependencies+0x1a0/0x1a0 [ 309.662379] __lock_acquire+0x638/0x1b50 [ 309.662383] ? __mutex_unlock_slowpath+0x3e/0x2e0 [ 309.662388] ? trace_hardirqs_on+0xd/0x10 [ 309.662392] ? _rcu_barrier+0x31/0x160 [ 309.662396] lock_acquire+0xc9/0x220 [ 309.662400] ? _rcu_barrier+0x31/0x160 [ 309.662404] ? _rcu_barrier+0x31/0x160 [ 309.662409] __mutex_lock+0x6e/0x990 [ 309.662412] ? _rcu_barrier+0x31/0x160 [ 309.662416] ? _rcu_barrier+0x31/0x160 [ 309.662421] ? synchronize_rcu_expedited+0x35/0xb0 [ 309.662426] ? _raw_spin_unlock_irqrestore+0x52/0x60 [ 309.662434] mutex_lock_nested+0x16/0x20 [ 309.662438] _rcu_barrier+0x31/0x160 [ 309.662442] rcu_barrier+0x10/0x20 [ 309.662464] i915_gem_shrink_all+0x33/0x40 [i915] [ 309.662484] i915_drop_caches_set+0x141/0x150 [i915] [ 309.662489] simple_attr_write+0xc7/0xe0 [ 309.662494] full_proxy_write+0x4f/0x70 [ 309.662498] __vfs_write+0x23/0x120 [ 309.662503] ? rcu_read_lock_sched_held+0x75/0x80 [ 309.662507] ? rcu_sync_lockdep_assert+0x2a/0x50 [ 309.662512] ? __sb_start_write+0x102/0x210 [ 309.662516] ? vfs_write+0x17d/0x1f0 [ 309.662520] vfs_write+0xc6/0x1f0 [ 309.662524] ? trace_hardirqs_on_caller+0xe7/0x200 [ 309.662529] SyS_write+0x44/0xb0 [ 309.662533] entry_SYSCALL_64_fastpath+0x1c/0xb1 [ 309.662537] RIP: 0033:0x7f507eac24a0 [ 309.662541] RSP: 002b:00007fffda8720e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 309.662548] RAX: ffffffffffffffda RBX: ffffffff81482bd3 RCX: 00007f507eac24a0 [ 309.662552] RDX: 0000000000000005 RSI: 00007fffda8720f0 RDI: 0000000000000005 [ 309.662557] RBP: ffffc9000048bf88 R08: 0000000000000000 R09: 000000000000002c [ 309.662561] R10: 0000000000000014 R11: 0000000000000246 R12: 00007fffda872230 [ 309.662566] R13: 00007fffda872228 R14: 0000000000000201 R15: 00007fffda8720f0 [ 309.662572] ? __this_cpu_preempt_check+0x13/0x20 Fixes: 0eafec6 ("drm/i915: Enable lockless lookup of request tracking via RCU") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100192 Signed-off-by: Chris Wilson <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: <[email protected]> # v4.9+ Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Daniel Vetter <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
May 27, 2017
This can be triggered by hot-unplug one cpu.
======================================================
[ INFO: possible circular locking dependency detected ]
4.11.0+ #17 Not tainted
-------------------------------------------------------
step_after_susp/2640 is trying to acquire lock:
(all_q_mutex){+.+...}, at: [<ffffffffb33f95b8>] blk_mq_queue_reinit_work+0x18/0x110
but task is already holding lock:
(cpu_hotplug.lock){+.+.+.}, at: [<ffffffffb306d04f>] cpu_hotplug_begin+0x7f/0xe0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> freedreno-zz#1 (cpu_hotplug.lock){+.+.+.}:
lock_acquire+0x11c/0x230
__mutex_lock+0x92/0x990
mutex_lock_nested+0x1b/0x20
get_online_cpus+0x64/0x80
blk_mq_init_allocated_queue+0x3a0/0x4e0
blk_mq_init_queue+0x3a/0x60
loop_add+0xe5/0x280
loop_init+0x124/0x177
do_one_initcall+0x53/0x1c0
kernel_init_freeable+0x1e3/0x27f
kernel_init+0xe/0x100
ret_from_fork+0x31/0x40
-> #0 (all_q_mutex){+.+...}:
__lock_acquire+0x189a/0x18a0
lock_acquire+0x11c/0x230
__mutex_lock+0x92/0x990
mutex_lock_nested+0x1b/0x20
blk_mq_queue_reinit_work+0x18/0x110
blk_mq_queue_reinit_dead+0x1c/0x20
cpuhp_invoke_callback+0x1f2/0x810
cpuhp_down_callbacks+0x42/0x80
_cpu_down+0xb2/0xe0
freeze_secondary_cpus+0xb6/0x390
suspend_devices_and_enter+0x3b3/0xa40
pm_suspend+0x129/0x490
state_store+0x82/0xf0
kobj_attr_store+0xf/0x20
sysfs_kf_write+0x45/0x60
kernfs_fop_write+0x135/0x1c0
__vfs_write+0x37/0x160
vfs_write+0xcd/0x1d0
SyS_write+0x58/0xc0
do_syscall_64+0x8f/0x710
return_from_SYSCALL_64+0x0/0x7a
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(cpu_hotplug.lock);
lock(all_q_mutex);
lock(cpu_hotplug.lock);
lock(all_q_mutex);
*** DEADLOCK ***
8 locks held by step_after_susp/2640:
#0: (sb_writers#6){.+.+.+}, at: [<ffffffffb3244aed>] vfs_write+0x1ad/0x1d0
freedreno-zz#1: (&of->mutex){+.+.+.}, at: [<ffffffffb32d3a51>] kernfs_fop_write+0x101/0x1c0
freedreno-zz#2: (s_active#166){.+.+.+}, at: [<ffffffffb32d3a59>] kernfs_fop_write+0x109/0x1c0
freedreno-zz#3: (pm_mutex){+.+...}, at: [<ffffffffb30d2ecd>] pm_suspend+0x21d/0x490
#4: (acpi_scan_lock){+.+.+.}, at: [<ffffffffb34dc3d7>] acpi_scan_lock_acquire+0x17/0x20
#5: (cpu_add_remove_lock){+.+.+.}, at: [<ffffffffb306d6d7>] freeze_secondary_cpus+0x27/0x390
#6: (cpu_hotplug.dep_map){++++++}, at: [<ffffffffb306cfd5>] cpu_hotplug_begin+0x5/0xe0
#7: (cpu_hotplug.lock){+.+.+.}, at: [<ffffffffb306d04f>] cpu_hotplug_begin+0x7f/0xe0
stack backtrace:
CPU: 3 PID: 2640 Comm: step_after_susp Not tainted 4.11.0+ #17
Hardware name: Dell Inc. OptiPlex 7040/0JCTF8, BIOS 1.4.9 09/12/2016
Call Trace:
dump_stack+0x99/0xce
print_circular_bug+0x1fa/0x270
__lock_acquire+0x189a/0x18a0
lock_acquire+0x11c/0x230
? lock_acquire+0x11c/0x230
? blk_mq_queue_reinit_work+0x18/0x110
? blk_mq_queue_reinit_work+0x18/0x110
__mutex_lock+0x92/0x990
? blk_mq_queue_reinit_work+0x18/0x110
? kmem_cache_free+0x2cb/0x330
? anon_transport_class_unregister+0x20/0x20
? blk_mq_queue_reinit_work+0x110/0x110
mutex_lock_nested+0x1b/0x20
? mutex_lock_nested+0x1b/0x20
blk_mq_queue_reinit_work+0x18/0x110
blk_mq_queue_reinit_dead+0x1c/0x20
cpuhp_invoke_callback+0x1f2/0x810
? __flow_cache_shrink+0x160/0x160
cpuhp_down_callbacks+0x42/0x80
_cpu_down+0xb2/0xe0
freeze_secondary_cpus+0xb6/0x390
suspend_devices_and_enter+0x3b3/0xa40
? rcu_read_lock_sched_held+0x79/0x80
pm_suspend+0x129/0x490
state_store+0x82/0xf0
kobj_attr_store+0xf/0x20
sysfs_kf_write+0x45/0x60
kernfs_fop_write+0x135/0x1c0
__vfs_write+0x37/0x160
? rcu_read_lock_sched_held+0x79/0x80
? rcu_sync_lockdep_assert+0x2f/0x60
? __sb_start_write+0xd9/0x1c0
? vfs_write+0x1ad/0x1d0
vfs_write+0xcd/0x1d0
SyS_write+0x58/0xc0
? rcu_read_lock_sched_held+0x79/0x80
do_syscall_64+0x8f/0x710
? trace_hardirqs_on_thunk+0x1a/0x1c
entry_SYSCALL64_slow_path+0x25/0x25
The cpu hotplug path will hold cpu_hotplug.lock and then reinit all exiting
queues for blk mq w/ all_q_mutex, however, blk_mq_init_allocated_queue() will
contend these two locks in the inversion order. This is due to commit eabe065
(blk/mq: Cure cpu hotplug lock inversion), it fixes a cpu hotplug lock inversion
issue because of hotplug rework, however the hotplug rework is still work-in-progress
and lives in a -tip branch and mainline cannot yet trigger that splat. The commit
breaks the linus's tree in the merge window, so this patch reverts the lock order
and avoids to splat linus's tree.
Cc: Jens Axboe <[email protected]>
Cc: Peter Zijlstra (Intel) <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Signed-off-by: Wanpeng Li <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
May 27, 2017
Yuval Mintz says: ==================== qed*: General fixes This series contain several fixes for qed and qede. - freedreno-zz#1 [and ~#5] relate to XDP cleanups - freedreno-zz#2 and #5 correct VF behavior - freedreno-zz#3 and #4 fix and add missing configurations needed for RoCE & storage ==================== Signed-off-by: David S. Miller <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Jun 9, 2017
[ Upstream commit ddc665a ] When the instruction right before the branch destination is a 64 bit load immediate, we currently calculate the wrong jump offset in the ctx->offset[] array as we only account one instruction slot for the 64 bit load immediate although it uses two BPF instructions. Fix it up by setting the offset into the right slot after we incremented the index. Before (ldimm64 test 1): [...] 00000020: 52800007 mov w7, #0x0 // #0 00000024: d2800060 mov x0, #0x3 // freedreno-zz#3 00000028: d2800041 mov x1, #0x2 // freedreno-zz#2 0000002c: eb01001f cmp x0, x1 00000030: 54ffff82 b.cs 0x00000020 00000034: d29fffe7 mov x7, #0xffff // #65535 00000038: f2bfffe7 movk x7, #0xffff, lsl #16 0000003c: f2dfffe7 movk x7, #0xffff, lsl #32 00000040: f2ffffe7 movk x7, #0xffff, lsl #48 00000044: d29dddc7 mov x7, #0xeeee // #61166 00000048: f2bdddc7 movk x7, #0xeeee, lsl #16 0000004c: f2ddddc7 movk x7, #0xeeee, lsl #32 00000050: f2fdddc7 movk x7, #0xeeee, lsl #48 [...] After (ldimm64 test 1): [...] 00000020: 52800007 mov w7, #0x0 // #0 00000024: d2800060 mov x0, #0x3 // freedreno-zz#3 00000028: d2800041 mov x1, #0x2 // freedreno-zz#2 0000002c: eb01001f cmp x0, x1 00000030: 540000a2 b.cs 0x00000044 00000034: d29fffe7 mov x7, #0xffff // #65535 00000038: f2bfffe7 movk x7, #0xffff, lsl #16 0000003c: f2dfffe7 movk x7, #0xffff, lsl #32 00000040: f2ffffe7 movk x7, #0xffff, lsl #48 00000044: d29dddc7 mov x7, #0xeeee // #61166 00000048: f2bdddc7 movk x7, #0xeeee, lsl #16 0000004c: f2ddddc7 movk x7, #0xeeee, lsl #32 00000050: f2fdddc7 movk x7, #0xeeee, lsl #48 [...] Also, add a couple of test cases to make sure JITs pass this test. Tested on Cavium ThunderX ARMv8. The added test cases all pass after the fix. Fixes: 8eee539 ("arm64: bpf: fix out-of-bounds read in bpf2a64_offset()") Reported-by: David S. Miller <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Alexei Starovoitov <[email protected]> Cc: Xi Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Jun 12, 2017
…nt() In case oldtrig == trig == NULL (which happens when we set none trigger, when there is already none set) there is a NULL pointer dereference during iio_trigger_put(trig). Below is kernel output when this occurs: [ 26.741790] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 26.750179] pgd = cacc0000 [ 26.752936] [00000000] *pgd=8adc6835, *pte=00000000, *ppte=00000000 [ 26.759531] Internal error: Oops: 17 [freedreno-zz#1] SMP ARM [ 26.764261] Modules linked in: usb_f_ncm u_ether usb_f_acm u_serial usb_f_fs libcomposite configfs evbug [ 26.773844] CPU: 0 PID: 152 Comm: synchro Not tainted 4.12.0-rc1 freedreno-zz#2 [ 26.780128] Hardware name: Freescale i.MX6 Ultralite (Device Tree) [ 26.786329] task: cb1de200 task.stack: cac92000 [ 26.790892] PC is at iio_trigger_write_current+0x188/0x1f4 [ 26.796403] LR is at lock_release+0xf8/0x20c [ 26.800696] pc : [<c0736f34>] lr : [<c016efb0>] psr: 600d0013 [ 26.800696] sp : cac93e30 ip : cac93db0 fp : cac93e5c [ 26.812193] r10: c0e64fe8 r9 : 00000000 r8 : 00000001 [ 26.817436] r7 : cb190810 r6 : 00000010 r5 : 00000001 r4 : 00000000 [ 26.823982] r3 : 00000000 r2 : 00000000 r1 : cb1de200 r0 : 00000000 [ 26.830528] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 26.837683] Control: 10c5387d Table: 8acc006a DAC: 00000051 [ 26.843448] Process synchro (pid: 152, stack limit = 0xcac92210) [ 26.849475] Stack: (0xcac93e30 to 0xcac94000) [ 26.853857] 3e20: 00000001 c0736dac c054033c cae6b680 [ 26.862060] 3e40: cae6b680 00000000 00000001 cb3f8610 cac93e74 cac93e60 c054035c c0736db8 [ 26.870264] 3e60: 00000001 c054033c cac93e94 cac93e78 c029bf34 c0540348 00000000 00000000 [ 26.878469] 3e80: cb3f8600 cae6b680 cac93ed4 cac93e98 c029b320 c029bef0 00000000 00000000 [ 26.886672] 3ea0: 00000000 cac93f78 cb2d41fc caed3280 c029b214 cac93f78 00000001 000e20f8 [ 26.894874] 3ec0: 00000001 00000000 cac93f44 cac93ed8 c0221dcc c029b220 c0e1ca39 cb2d41fc [ 26.903079] 3ee0: cac93f04 cac93ef0 c0183ef0 c0183ab0 cb2d41fc 00000000 cac93f44 cac93f08 [ 26.911282] 3f00: c0225eec c0183ebc 00000001 00000000 c0223728 00000000 c0245454 00000001 [ 26.919485] 3f20: 00000001 caed3280 000e20f8 cac93f78 000e20f8 00000001 cac93f74 cac93f48 [ 26.927690] 3f40: c0223680 c0221da4 c0246520 c0245460 caed3283 caed3280 00000000 00000000 [ 26.935893] 3f60: 000e20f8 00000001 cac93fa4 cac93f78 c0224520 c02235e4 00000000 00000000 [ 26.944096] 3f80: 00000001 000e20f8 00000001 00000004 c0107f84 cac92000 00000000 cac93fa8 [ 26.952299] 3fa0: c0107de0 c02244e8 00000001 000e20f8 0000000e 000e20f8 00000001 fbad2484 [ 26.960502] 3fc0: 00000001 000e20f8 00000001 00000004 beb6b698 00064260 0006421c beb6b4b4 [ 26.968705] 3fe0: 00000000 beb6b450 b6f219a0 b6e2f268 800d0010 0000000e cac93ff4 cac93ffc [ 26.976896] Backtrace: [ 26.979388] [<c0736dac>] (iio_trigger_write_current) from [<c054035c>] (dev_attr_store+0x20/0x2c) [ 26.988289] r10:cb3f8610 r9:00000001 r8:00000000 r7:cae6b680 r6:cae6b680 r5:c054033c [ 26.996138] r4:c0736dac r3:00000001 [ 26.999747] [<c054033c>] (dev_attr_store) from [<c029bf34>] (sysfs_kf_write+0x50/0x54) [ 27.007686] r5:c054033c r4:00000001 [ 27.011290] [<c029bee4>] (sysfs_kf_write) from [<c029b320>] (kernfs_fop_write+0x10c/0x224) [ 27.019579] r7:cae6b680 r6:cb3f8600 r5:00000000 r4:00000000 [ 27.025271] [<c029b214>] (kernfs_fop_write) from [<c0221dcc>] (__vfs_write+0x34/0x120) [ 27.033214] r10:00000000 r9:00000001 r8:000e20f8 r7:00000001 r6:cac93f78 r5:c029b214 [ 27.041059] r4:caed3280 [ 27.043622] [<c0221d98>] (__vfs_write) from [<c0223680>] (vfs_write+0xa8/0x170) [ 27.050959] r9:00000001 r8:000e20f8 r7:cac93f78 r6:000e20f8 r5:caed3280 r4:00000001 [ 27.058731] [<c02235d8>] (vfs_write) from [<c0224520>] (SyS_write+0x44/0x98) [ 27.065806] r9:00000001 r8:000e20f8 r7:00000000 r6:00000000 r5:caed3280 r4:caed3283 [ 27.073582] [<c02244dc>] (SyS_write) from [<c0107de0>] (ret_fast_syscall+0x0/0x1c) [ 27.081179] r9:cac92000 r8:c0107f84 r7:00000004 r6:00000001 r5:000e20f8 r4:00000001 [ 27.088947] Code: 1a000009 e1a04009 e3a06010 e1a05008 (e5943000) [ 27.095244] ---[ end trace 06d1dab86d6e6bab ]--- To fix that problem call iio_trigger_put(trig) only when trig is not NULL. Fixes: d5d24bc ("iio: trigger: close race condition in acquiring trigger reference") Signed-off-by: Marcin Niestroj <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Jun 12, 2017
this bug happened when amdgpu load failed. [ 75.740951] BUG: unable to handle kernel paging request at 00000000000031c0 [ 75.748167] IP: [<ffffffffa064a0e0>] amdgpu_fbdev_restore_mode+0x20/0x60 [amdgpu] [ 75.755774] PGD 0 [ 75.759185] Oops: 0000 [freedreno-zz#1] SMP [ 75.762408] Modules linked in: amdgpu(OE-) ttm(OE) drm_kms_helper(OE) drm(OE) i2c_algo_bit(E) fb_sys_fops(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) rpcsec_gss_krb5(E) nfsv4(E) nfs(E) fscache(E) eeepc_wmi(E) asus_wmi(E) sparse_keymap(E) intel_rapl(E) snd_hda_codec_hdmi(E) snd_hda_codec_realtek(E) snd_hda_codec_generic(E) snd_hda_intel(E) snd_hda_codec(E) snd_hda_core(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) snd_hwdep(E) snd_pcm(E) snd_seq_midi(E) coretemp(E) kvm_intel(E) snd_seq_midi_event(E) snd_rawmidi(E) kvm(E) snd_seq(E) joydev(E) snd_seq_device(E) snd_timer(E) irqbypass(E) crct10dif_pclmul(E) crc32_pclmul(E) mei_me(E) ghash_clmulni_intel(E) snd(E) aesni_intel(E) mei(E) soundcore(E) aes_x86_64(E) shpchp(E) serio_raw(E) lrw(E) acpi_pad(E) gf128mul(E) glue_helper(E) ablk_helper(E) mac_hid(E) [ 75.835574] cryptd(E) parport_pc(E) ppdev(E) lp(E) nfsd(E) parport(E) auth_rpcgss(E) nfs_acl(E) lockd(E) grace(E) sunrpc(E) autofs4(E) hid_generic(E) usbhid(E) mxm_wmi(E) psmouse(E) e1000e(E) ptp(E) pps_core(E) ahci(E) libahci(E) wmi(E) video(E) i2c_hid(E) hid(E) [ 75.858489] CPU: 5 PID: 1603 Comm: rmmod Tainted: G OE 4.9.0-custom freedreno-zz#2 [ 75.866183] Hardware name: System manufacturer System Product Name/Z170-A, BIOS 0901 08/31/2015 [ 75.875050] task: ffff88045d1bbb80 task.stack: ffffc90002de4000 [ 75.881094] RIP: 0010:[<ffffffffa064a0e0>] [<ffffffffa064a0e0>] amdgpu_fbdev_restore_mode+0x20/0x60 [amdgpu] [ 75.891238] RSP: 0018:ffffc90002de7d48 EFLAGS: 00010286 [ 75.896648] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001 [ 75.903933] RDX: 0000000000000000 RSI: ffff88045d1bbb80 RDI: 0000000000000286 [ 75.911183] RBP: ffffc90002de7d50 R08: 0000000000000502 R09: 0000000000000004 [ 75.918449] R10: 0000000000000000 R11: 0000000000000001 R12: ffff880464bf0000 [ 75.925675] R13: ffffffffa0853000 R14: 0000000000000000 R15: 0000564e44f88210 [ 75.932980] FS: 00007f13d5400700(0000) GS:ffff880476540000(0000) knlGS:0000000000000000 [ 75.941238] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 75.947088] CR2: 00000000000031c0 CR3: 000000045fd0b000 CR4: 00000000003406e0 [ 75.954332] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 75.961566] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 75.968834] Stack: [ 75.970881] ffff880464bf0000 ffffc90002de7d60 ffffffffa0636592 ffffc90002de7d80 [ 75.978454] ffffffffa059015f ffff880464bf0000 ffff880464bf0000 ffffc90002de7da8 [ 75.986076] ffffffffa0595216 ffff880464bf0000 ffff880460f4d000 ffffffffa0853000 [ 75.993692] Call Trace: [ 75.996177] [<ffffffffa0636592>] amdgpu_driver_lastclose_kms+0x12/0x20 [amdgpu] [ 76.003700] [<ffffffffa059015f>] drm_lastclose+0x2f/0xd0 [drm] [ 76.009777] [<ffffffffa0595216>] drm_dev_unregister+0x16/0xd0 [drm] [ 76.016255] [<ffffffffa0595944>] drm_put_dev+0x34/0x70 [drm] [ 76.022139] [<ffffffffa062f365>] amdgpu_pci_remove+0x15/0x20 [amdgpu] [ 76.028800] [<ffffffff81416499>] pci_device_remove+0x39/0xc0 [ 76.034661] [<ffffffff81531caa>] __device_release_driver+0x9a/0x140 [ 76.041121] [<ffffffff81531e58>] driver_detach+0xb8/0xc0 [ 76.046575] [<ffffffff81530c95>] bus_remove_driver+0x55/0xd0 [ 76.052401] [<ffffffff815325fc>] driver_unregister+0x2c/0x50 [ 76.058244] [<ffffffff81416289>] pci_unregister_driver+0x29/0x90 [ 76.064466] [<ffffffffa0596c5e>] drm_pci_exit+0x9e/0xb0 [drm] [ 76.070507] [<ffffffffa0796d71>] amdgpu_exit+0x1c/0x32 [amdgpu] [ 76.076609] [<ffffffff81104810>] SyS_delete_module+0x1a0/0x200 [ 76.082627] [<ffffffff810e2b1a>] ? rcu_eqs_enter.isra.36+0x4a/0x50 [ 76.089001] [<ffffffff8100392e>] do_syscall_64+0x6e/0x180 [ 76.094583] [<ffffffff817e1d2f>] entry_SYSCALL64_slow_path+0x25/0x25 [ 76.101114] Code: 94 c0 c3 31 c0 5d c3 0f 1f 40 00 0f 1f 44 00 00 55 31 c0 48 89 e5 53 48 89 fb 48 c7 c7 1d 21 84 a0 e8 ab 77 b3 e0 e8 fc 8b d7 e0 <48> 8b bb c0 31 00 00 48 85 ff 74 09 e8 ff eb fc ff 85 c0 75 03 [ 76.121432] RIP [<ffffffffa064a0e0>] amdgpu_fbdev_restore_mode+0x20/0x60 [amdgpu] Signed-off-by: Rex Zhu <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Jun 12, 2017
… preemptibility bug With CONFIG_DEBUG_PREEMPT enabled, I get: BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1 caller is debug_smp_processor_id CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc2+ freedreno-zz#2 Call Trace: dump_stack check_preemption_disabled debug_smp_processor_id save_microcode_in_initrd_amd ? microcode_init save_microcode_in_initrd ... because, well, it says it above, we're using smp_processor_id() in preemptible code. But passing the CPU number is not really needed. It is only used to determine whether we're on the BSP, and, if so, to save the microcode patch for early loading. [ We don't absolutely need to do it on the BSP but we do that customarily there. ] Instead, convert that function parameter to a boolean which denotes whether the patch should be saved or not, thereby avoiding the use of smp_processor_id() in preemptible code. Signed-off-by: Borislav Petkov <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
robclark
added a commit
to freedreno/kernel-msm
that referenced
this issue
Aug 2, 2017
of_find_node_with_property() drops the reference to the 'from' node,
which eventually (after enough -EPROBE_DEFERs) drops the last reference
to the node causing all sorts of fun problems, and this nice splat.
BUG: sleeping function called from invalid context at ../kernel/locking/mutex.c:747
in_atomic(): 1, irqs_disabled(): 128, pid: 33, name: kworker/0:1
4 locks held by kworker/0:1/33:
#0: ("events"){.+.+.+}, at: [<ffff0000080fa91c>] process_one_work+0x1a4/0x728
freedreno-zz#1: (deferred_probe_work){+.+.+.}, at: [<ffff0000080fa91c>] process_one_work+0x1a4/0x728
freedreno-zz#2: (&dev->mutex){......}, at: [<ffff000008676078>] __device_attach+0x30/0x168
freedreno-zz#3: (devtree_lock){......}, at: [<ffff000008828fd0>] of_find_node_with_property+0x30/0xe0
irq event stamp: 18976
hardirqs last enabled at (18975): [<ffff00000815794c>] __down_trylock_console_sem+0x74/0xb8
hardirqs last disabled at (18976): [<ffff0000089e26d4>] _raw_spin_lock_irqsave+0x2c/0x78
softirqs last enabled at (16880): [<ffff0000080e0f00>] __do_softirq+0x580/0x640
softirqs last disabled at (16871): [<ffff0000080e13a4>] irq_exit+0xe4/0x138
CPU: 0 PID: 33 Comm: kworker/0:1 Tainted: G E 4.12.0-rc5+ #1455
Hardware name: qualcomm dragonboard410c/dragonboard410c, BIOS 2017.07-rc1-00234-g22fa70a-dirty 06/26/2017
Workqueue: events deferred_probe_work_func
Call trace:
[<ffff000008089ee0>] dump_backtrace+0x0/0x230
[<ffff00000808a134>] show_stack+0x24/0x30
[<ffff0000084e1944>] dump_stack+0xac/0xe8
[<ffff00000810d7e0>] ___might_sleep+0x150/0x230
[<ffff00000810d918>] __might_sleep+0x58/0x90
[<ffff0000089dde18>] __mutex_lock+0x50/0x870
[<ffff0000089de674>] mutex_lock_nested+0x3c/0x50
[<ffff000008388ae0>] kernfs_remove+0x30/0x50
[<ffff00000838b720>] sysfs_remove_dir+0x58/0x70
[<ffff0000084e393c>] kobject_del+0x1c/0x58
[<ffff0000084e374c>] kobject_put+0xb4/0x208
[<ffff00000882c364>] of_node_put+0x24/0x30
[<ffff000008829018>] of_find_node_with_property+0x78/0xe0
[<ffff000000aff5f4>] qcom_smsm_probe+0x194/0x720 [smsm]
[<ffff0000086793b4>] platform_drv_probe+0x74/0x110
[<ffff0000086765bc>] driver_probe_device+0x2b4/0x420
[<ffff000008676920>] __device_attach_driver+0xd0/0x150
[<ffff000008673e78>] bus_for_each_drv+0x68/0xa8
[<ffff00000867611c>] __device_attach+0xd4/0x168
[<ffff000008676a1c>] device_initial_probe+0x24/0x30
[<ffff000008675380>] bus_probe_device+0xa0/0xa8
[<ffff000008675948>] deferred_probe_work_func+0xb8/0xf8
[<ffff0000080fa9d4>] process_one_work+0x25c/0x728
[<ffff0000080faef4>] worker_thread+0x54/0x3d8
[<ffff0000081031d8>] kthread+0x110/0x140
[<ffff000008082d90>] ret_from_fork+0x10/0x40
OF: ERROR: Bad of_node_put() on /smsm
CPU: 0 PID: 33 Comm: kworker/0:1 Tainted: G W E 4.12.0-rc5+ #1455
Hardware name: qualcomm dragonboard410c/dragonboard410c, BIOS 2017.07-rc1-00234-g22fa70a-dirty 06/26/2017
Workqueue: events deferred_probe_work_func
Signed-off-by: Rob Clark <[email protected]>
robclark
added a commit
to freedreno/kernel-msm
that referenced
this issue
Aug 4, 2017
of_find_node_with_property() drops the reference to the 'from' node,
which eventually (after enough -EPROBE_DEFERs) drops the last reference
to the node causing all sorts of fun problems, and this nice splat.
BUG: sleeping function called from invalid context at ../kernel/locking/mutex.c:747
in_atomic(): 1, irqs_disabled(): 128, pid: 33, name: kworker/0:1
4 locks held by kworker/0:1/33:
#0: ("events"){.+.+.+}, at: [<ffff0000080fa91c>] process_one_work+0x1a4/0x728
freedreno-zz#1: (deferred_probe_work){+.+.+.}, at: [<ffff0000080fa91c>] process_one_work+0x1a4/0x728
freedreno-zz#2: (&dev->mutex){......}, at: [<ffff000008676078>] __device_attach+0x30/0x168
freedreno-zz#3: (devtree_lock){......}, at: [<ffff000008828fd0>] of_find_node_with_property+0x30/0xe0
irq event stamp: 18976
hardirqs last enabled at (18975): [<ffff00000815794c>] __down_trylock_console_sem+0x74/0xb8
hardirqs last disabled at (18976): [<ffff0000089e26d4>] _raw_spin_lock_irqsave+0x2c/0x78
softirqs last enabled at (16880): [<ffff0000080e0f00>] __do_softirq+0x580/0x640
softirqs last disabled at (16871): [<ffff0000080e13a4>] irq_exit+0xe4/0x138
CPU: 0 PID: 33 Comm: kworker/0:1 Tainted: G E 4.12.0-rc5+ #1455
Hardware name: qualcomm dragonboard410c/dragonboard410c, BIOS 2017.07-rc1-00234-g22fa70a-dirty 06/26/2017
Workqueue: events deferred_probe_work_func
Call trace:
[<ffff000008089ee0>] dump_backtrace+0x0/0x230
[<ffff00000808a134>] show_stack+0x24/0x30
[<ffff0000084e1944>] dump_stack+0xac/0xe8
[<ffff00000810d7e0>] ___might_sleep+0x150/0x230
[<ffff00000810d918>] __might_sleep+0x58/0x90
[<ffff0000089dde18>] __mutex_lock+0x50/0x870
[<ffff0000089de674>] mutex_lock_nested+0x3c/0x50
[<ffff000008388ae0>] kernfs_remove+0x30/0x50
[<ffff00000838b720>] sysfs_remove_dir+0x58/0x70
[<ffff0000084e393c>] kobject_del+0x1c/0x58
[<ffff0000084e374c>] kobject_put+0xb4/0x208
[<ffff00000882c364>] of_node_put+0x24/0x30
[<ffff000008829018>] of_find_node_with_property+0x78/0xe0
[<ffff000000aff5f4>] qcom_smsm_probe+0x194/0x720 [smsm]
[<ffff0000086793b4>] platform_drv_probe+0x74/0x110
[<ffff0000086765bc>] driver_probe_device+0x2b4/0x420
[<ffff000008676920>] __device_attach_driver+0xd0/0x150
[<ffff000008673e78>] bus_for_each_drv+0x68/0xa8
[<ffff00000867611c>] __device_attach+0xd4/0x168
[<ffff000008676a1c>] device_initial_probe+0x24/0x30
[<ffff000008675380>] bus_probe_device+0xa0/0xa8
[<ffff000008675948>] deferred_probe_work_func+0xb8/0xf8
[<ffff0000080fa9d4>] process_one_work+0x25c/0x728
[<ffff0000080faef4>] worker_thread+0x54/0x3d8
[<ffff0000081031d8>] kthread+0x110/0x140
[<ffff000008082d90>] ret_from_fork+0x10/0x40
OF: ERROR: Bad of_node_put() on /smsm
CPU: 0 PID: 33 Comm: kworker/0:1 Tainted: G W E 4.12.0-rc5+ #1455
Hardware name: qualcomm dragonboard410c/dragonboard410c, BIOS 2017.07-rc1-00234-g22fa70a-dirty 06/26/2017
Workqueue: events deferred_probe_work_func
Signed-off-by: Rob Clark <[email protected]>
robclark
added a commit
to freedreno/kernel-msm
that referenced
this issue
Aug 9, 2017
of_find_node_with_property() drops the reference to the 'from' node,
which eventually (after enough -EPROBE_DEFERs) drops the last reference
to the node causing all sorts of fun problems, and this nice splat.
BUG: sleeping function called from invalid context at ../kernel/locking/mutex.c:747
in_atomic(): 1, irqs_disabled(): 128, pid: 33, name: kworker/0:1
4 locks held by kworker/0:1/33:
#0: ("events"){.+.+.+}, at: [<ffff0000080fa91c>] process_one_work+0x1a4/0x728
freedreno-zz#1: (deferred_probe_work){+.+.+.}, at: [<ffff0000080fa91c>] process_one_work+0x1a4/0x728
freedreno-zz#2: (&dev->mutex){......}, at: [<ffff000008676078>] __device_attach+0x30/0x168
freedreno-zz#3: (devtree_lock){......}, at: [<ffff000008828fd0>] of_find_node_with_property+0x30/0xe0
irq event stamp: 18976
hardirqs last enabled at (18975): [<ffff00000815794c>] __down_trylock_console_sem+0x74/0xb8
hardirqs last disabled at (18976): [<ffff0000089e26d4>] _raw_spin_lock_irqsave+0x2c/0x78
softirqs last enabled at (16880): [<ffff0000080e0f00>] __do_softirq+0x580/0x640
softirqs last disabled at (16871): [<ffff0000080e13a4>] irq_exit+0xe4/0x138
CPU: 0 PID: 33 Comm: kworker/0:1 Tainted: G E 4.12.0-rc5+ #1455
Hardware name: qualcomm dragonboard410c/dragonboard410c, BIOS 2017.07-rc1-00234-g22fa70a-dirty 06/26/2017
Workqueue: events deferred_probe_work_func
Call trace:
[<ffff000008089ee0>] dump_backtrace+0x0/0x230
[<ffff00000808a134>] show_stack+0x24/0x30
[<ffff0000084e1944>] dump_stack+0xac/0xe8
[<ffff00000810d7e0>] ___might_sleep+0x150/0x230
[<ffff00000810d918>] __might_sleep+0x58/0x90
[<ffff0000089dde18>] __mutex_lock+0x50/0x870
[<ffff0000089de674>] mutex_lock_nested+0x3c/0x50
[<ffff000008388ae0>] kernfs_remove+0x30/0x50
[<ffff00000838b720>] sysfs_remove_dir+0x58/0x70
[<ffff0000084e393c>] kobject_del+0x1c/0x58
[<ffff0000084e374c>] kobject_put+0xb4/0x208
[<ffff00000882c364>] of_node_put+0x24/0x30
[<ffff000008829018>] of_find_node_with_property+0x78/0xe0
[<ffff000000aff5f4>] qcom_smsm_probe+0x194/0x720 [smsm]
[<ffff0000086793b4>] platform_drv_probe+0x74/0x110
[<ffff0000086765bc>] driver_probe_device+0x2b4/0x420
[<ffff000008676920>] __device_attach_driver+0xd0/0x150
[<ffff000008673e78>] bus_for_each_drv+0x68/0xa8
[<ffff00000867611c>] __device_attach+0xd4/0x168
[<ffff000008676a1c>] device_initial_probe+0x24/0x30
[<ffff000008675380>] bus_probe_device+0xa0/0xa8
[<ffff000008675948>] deferred_probe_work_func+0xb8/0xf8
[<ffff0000080fa9d4>] process_one_work+0x25c/0x728
[<ffff0000080faef4>] worker_thread+0x54/0x3d8
[<ffff0000081031d8>] kthread+0x110/0x140
[<ffff000008082d90>] ret_from_fork+0x10/0x40
OF: ERROR: Bad of_node_put() on /smsm
CPU: 0 PID: 33 Comm: kworker/0:1 Tainted: G W E 4.12.0-rc5+ #1455
Hardware name: qualcomm dragonboard410c/dragonboard410c, BIOS 2017.07-rc1-00234-g22fa70a-dirty 06/26/2017
Workqueue: events deferred_probe_work_func
Signed-off-by: Rob Clark <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Nov 13, 2017
v4.10 commit 6f2ce1c ("scsi: zfcp: fix rport unblock race with LUN recovery") extended accessing parent pointer fields of struct zfcp_erp_action for tracing. If an erp_action has never been enqueued before, these parent pointer fields are uninitialized and NULL. Examples are zfcp objects freshly added to the parent object's children list, before enqueueing their first recovery subsequently. In zfcp_erp_try_rport_unblock(), we iterate such list. Accessing erp_action fields can cause a NULL pointer dereference. Since the kernel can read from lowcore on s390, it does not immediately cause a kernel page fault. Instead it can cause hangs on trying to acquire the wrong erp_action->adapter->dbf->rec_lock in zfcp_dbf_rec_action_lvl() ^bogus^ while holding already other locks with IRQs disabled. Real life example from attaching lots of LUNs in parallel on many CPUs: crash> bt 17723 PID: 17723 TASK: ... CPU: 25 COMMAND: "zfcperp0.0.1800" LOWCORE INFO: -psw : 0x0404300180000000 0x000000000038e424 -function : _raw_spin_lock_wait_flags at 38e424 ... #0 [fdde8fc90] zfcp_dbf_rec_action_lvl at 3e0004e9862 [zfcp] freedreno-zz#1 [fdde8fce8] zfcp_erp_try_rport_unblock at 3e0004dfddc [zfcp] freedreno-zz#2 [fdde8fd38] zfcp_erp_strategy at 3e0004e0234 [zfcp] freedreno-zz#3 [fdde8fda8] zfcp_erp_thread at 3e0004e0a12 [zfcp] #4 [fdde8fe60] kthread at 173550 #5 [fdde8feb8] kernel_thread_starter at 10add2 zfcp_adapter zfcp_port zfcp_unit <address>, 0x404040d600000000 scsi_device NULL, returning early! zfcp_scsi_dev.status = 0x40000000 0x40000000 ZFCP_STATUS_COMMON_RUNNING crash> zfcp_unit <address> struct zfcp_unit { erp_action = { adapter = 0x0, port = 0x0, unit = 0x0, }, } zfcp_erp_action is always fully embedded into its container object. Such container object is never moved in its object tree (only add or delete). Hence, erp_action parent pointers can never change. To fix the issue, initialize the erp_action parent pointers before adding the erp_action container to any list and thus before it becomes accessible from outside of its initializing function. In order to also close the time window between zfcp_erp_setup_act() memsetting the entire erp_action to zero and setting the parent pointers again, drop the memset and instead explicitly initialize individually all erp_action fields except for parent pointers. To be extra careful not to introduce any other unintended side effect, even keep zeroing the erp_action fields for list and timer. Also double-check with WARN_ON_ONCE that erp_action parent pointers never change, so we get to know when we would deviate from previous behavior. Signed-off-by: Steffen Maier <[email protected]> Fixes: 6f2ce1c ("scsi: zfcp: fix rport unblock race with LUN recovery") Cc: <[email protected]> freedreno-zz#2.6.32+ Reviewed-by: Benjamin Block <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Nov 13, 2017
syzkaller with KASAN reported an out-of-bounds read in
asn1_ber_decoder(). It can be reproduced by the following command,
assuming CONFIG_X509_CERTIFICATE_PARSER=y and CONFIG_KASAN=y:
keyctl add asymmetric desc $'\x30\x30' @s
The bug is that the length of an ASN.1 data value isn't validated in the
case where it is encoded using the short form, causing the decoder to
read past the end of the input buffer. Fix it by validating the length.
The bug report was:
BUG: KASAN: slab-out-of-bounds in asn1_ber_decoder+0x10cb/0x1730 lib/asn1_decoder.c:233
Read of size 1 at addr ffff88003cccfa02 by task syz-executor0/6818
CPU: 1 PID: 6818 Comm: syz-executor0 Not tainted 4.14.0-rc7-00008-g5f479447d983 freedreno-zz#2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0xb3/0x10b lib/dump_stack.c:52
print_address_description+0x79/0x2a0 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x236/0x340 mm/kasan/report.c:409
__asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:427
asn1_ber_decoder+0x10cb/0x1730 lib/asn1_decoder.c:233
x509_cert_parse+0x1db/0x650 crypto/asymmetric_keys/x509_cert_parser.c:89
x509_key_preparse+0x64/0x7a0 crypto/asymmetric_keys/x509_public_key.c:174
asymmetric_key_preparse+0xcb/0x1a0 crypto/asymmetric_keys/asymmetric_type.c:388
key_create_or_update+0x347/0xb20 security/keys/key.c:855
SYSC_add_key security/keys/keyctl.c:122 [inline]
SyS_add_key+0x1cd/0x340 security/keys/keyctl.c:62
entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x447c89
RSP: 002b:00007fca7a5d3bd8 EFLAGS: 00000246 ORIG_RAX: 00000000000000f8
RAX: ffffffffffffffda RBX: 00007fca7a5d46cc RCX: 0000000000447c89
RDX: 0000000020006f4a RSI: 0000000020006000 RDI: 0000000020001ff5
RBP: 0000000000000046 R08: fffffffffffffffd R09: 0000000000000000
R10: 0000000000000002 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007fca7a5d49c0 R15: 00007fca7a5d4700
Fixes: 42d5ec2 ("X.509: Add an ASN.1 decoder")
Cc: <[email protected]> # v3.7+
Signed-off-by: Eric Biggers <[email protected]>
Signed-off-by: David Howells <[email protected]>
Signed-off-by: James Morris <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Nov 13, 2017
…o-zz#2] syzkaller reported a NULL pointer dereference in asn1_ber_decoder(). It can be reproduced by the following command, assuming CONFIG_PKCS7_TEST_KEY=y: keyctl add pkcs7_test desc '' @s The bug is that if the data buffer is empty, an integer underflow occurs in the following check: if (unlikely(dp >= datalen - 1)) goto data_overrun_error; This results in the NULL data pointer being dereferenced. Fix it by checking for 'datalen - dp < 2' instead. Also fix the similar check for 'dp >= datalen - n' later in the same function. That one possibly could result in a buffer overread. The NULL pointer dereference was reproducible using the "pkcs7_test" key type but not the "asymmetric" key type because the "asymmetric" key type checks for a 0-length payload before calling into the ASN.1 decoder but the "pkcs7_test" key type does not. The bug report was: BUG: unable to handle kernel NULL pointer dereference at (null) IP: asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233 PGD 7b708067 P4D 7b708067 PUD 7b6ee067 PMD 0 Oops: 0000 [freedreno-zz#1] SMP Modules linked in: CPU: 0 PID: 522 Comm: syz-executor1 Not tainted 4.14.0-rc8 #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.3-20171021_125229-anatol 04/01/2014 task: ffff9b6b3798c040 task.stack: ffff9b6b37970000 RIP: 0010:asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233 RSP: 0018:ffff9b6b37973c78 EFLAGS: 00010216 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000021c RDX: ffffffff814a04ed RSI: ffffb1524066e000 RDI: ffffffff910759e0 RBP: ffff9b6b37973d60 R08: 0000000000000001 R09: ffff9b6b3caa4180 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f10ed1f2700(0000) GS:ffff9b6b3ea00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000007b6f3000 CR4: 00000000000006f0 Call Trace: pkcs7_parse_message+0xee/0x240 crypto/asymmetric_keys/pkcs7_parser.c:139 verify_pkcs7_signature+0x33/0x180 certs/system_keyring.c:216 pkcs7_preparse+0x41/0x70 crypto/asymmetric_keys/pkcs7_key_type.c:63 key_create_or_update+0x180/0x530 security/keys/key.c:855 SYSC_add_key security/keys/keyctl.c:122 [inline] SyS_add_key+0xbf/0x250 security/keys/keyctl.c:62 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x4585c9 RSP: 002b:00007f10ed1f1bd8 EFLAGS: 00000216 ORIG_RAX: 00000000000000f8 RAX: ffffffffffffffda RBX: 00007f10ed1f2700 RCX: 00000000004585c9 RDX: 0000000020000000 RSI: 0000000020008ffb RDI: 0000000020008000 RBP: 0000000000000000 R08: ffffffffffffffff R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000216 R12: 00007fff1b2260ae R13: 00007fff1b2260af R14: 00007f10ed1f2700 R15: 0000000000000000 Code: dd ca ff 48 8b 45 88 48 83 e8 01 4c 39 f0 0f 86 a8 07 00 00 e8 53 dd ca ff 49 8d 46 01 48 89 85 58 ff ff ff 48 8b 85 60 ff ff ff <42> 0f b6 0c 30 89 c8 88 8d 75 ff ff ff 83 e0 1f 89 8d 28 ff ff RIP: asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233 RSP: ffff9b6b37973c78 CR2: 0000000000000000 Fixes: 42d5ec2 ("X.509: Add an ASN.1 decoder") Reported-by: syzbot <[email protected]> Cc: <[email protected]> # v3.7+ Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: David Howells <[email protected]> Signed-off-by: James Morris <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Nov 13, 2017
…kernel/git/jmorris/linux-security Pull key handling fix from James Morris: "Fix by Eric Biggers for the keys subsystem" * 'fixes-v4.14-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: KEYS: fix NULL pointer dereference during ASN.1 parsing [ver freedreno-zz#2]
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Aug 14, 2019
Ido Schimmel says: ==================== selftests: forwarding: GRE multipath fixes Patch freedreno-zz#1 ensures IPv4 forwarding is enabled during the test. Patch freedreno-zz#2 fixes the flower filters used to measure the distribution of the traffic between the two nexthops, so that the test will pass regardless if traffic is offloaded or not. ==================== Signed-off-by: David S. Miller <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Aug 14, 2019
If we hit an error while allocating the page tables, we have to unwind
the incomplete updates, and wish to free the unused pd. However, we are
not allowed to be hoding the spinlock at that point, and so must use the
later free to defer it until after we drop the lock.
<3> [414.363795] BUG: sleeping function called from invalid context at drivers/gpu/drm/i915/i915_gem_gtt.c:472
<3> [414.364167] in_atomic(): 1, irqs_disabled(): 0, pid: 3905, name: i915_selftest
<4> [414.364406] 3 locks held by i915_selftest/3905:
<4> [414.364408] #0: 0000000034fe8aa8 (&dev->mutex){....}, at: device_driver_attach+0x18/0x50
<4> [414.364415] freedreno-zz#1: 000000006bd8a560 (&dev->struct_mutex){+.+.}, at: igt_ctx_exec+0xb7/0x410 [i915]
<4> [414.364476] freedreno-zz#2: 000000003dfdc766 (&(&pd->lock)->rlock){+.+.}, at: gen8_ppgtt_alloc_pdp+0x448/0x540 [i915]
<3> [414.364529] Preemption disabled at:
<4> [414.364530] [<0000000000000000>] 0x0
<4> [414.364696] CPU: 0 PID: 3905 Comm: i915_selftest Tainted: G U 5.2.0-rc7-CI-CI_DRM_6403+ freedreno-zz#1
<4> [414.364698] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
<4> [414.364699] Call Trace:
<4> [414.364704] dump_stack+0x67/0x9b
<4> [414.364708] ___might_sleep+0x167/0x250
<4> [414.364777] vm_free_page+0x24/0xc0 [i915]
<4> [414.364852] free_pd+0xf/0x20 [i915]
<4> [414.364897] gen8_ppgtt_alloc_pdp+0x489/0x540 [i915]
<4> [414.364946] gen8_ppgtt_alloc_4lvl+0x8e/0x2e0 [i915]
<4> [414.364992] ppgtt_bind_vma+0x2e/0x60 [i915]
<4> [414.365039] i915_vma_bind+0xe8/0x2c0 [i915]
<4> [414.365088] __i915_vma_do_pin+0xa1/0xd20 [i915]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111050
Fixes: 1d1b549 ("drm/i915/gtt: Replace struct_mutex serialisation for allocation")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Matthew Auld <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 0686108)
Signed-off-by: Jani Nikula <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Aug 14, 2019
There is a potential deadlock in rxrpc_peer_keepalive_dispatch() whereby
rxrpc_put_peer() is called with the peer_hash_lock held, but if it reduces
the peer's refcount to 0, rxrpc_put_peer() calls __rxrpc_put_peer() - which
the tries to take the already held lock.
Fix this by providing a version of rxrpc_put_peer() that can be called in
situations where the lock is already held.
The bug may produce the following lockdep report:
============================================
WARNING: possible recursive locking detected
5.2.0-next-20190718 #41 Not tainted
--------------------------------------------
kworker/0:3/21678 is trying to acquire lock:
00000000aa5eecdf (&(&rxnet->peer_hash_lock)->rlock){+.-.}, at: spin_lock_bh
/./include/linux/spinlock.h:343 [inline]
00000000aa5eecdf (&(&rxnet->peer_hash_lock)->rlock){+.-.}, at:
__rxrpc_put_peer /net/rxrpc/peer_object.c:415 [inline]
00000000aa5eecdf (&(&rxnet->peer_hash_lock)->rlock){+.-.}, at:
rxrpc_put_peer+0x2d3/0x6a0 /net/rxrpc/peer_object.c:435
but task is already holding lock:
00000000aa5eecdf (&(&rxnet->peer_hash_lock)->rlock){+.-.}, at: spin_lock_bh
/./include/linux/spinlock.h:343 [inline]
00000000aa5eecdf (&(&rxnet->peer_hash_lock)->rlock){+.-.}, at:
rxrpc_peer_keepalive_dispatch /net/rxrpc/peer_event.c:378 [inline]
00000000aa5eecdf (&(&rxnet->peer_hash_lock)->rlock){+.-.}, at:
rxrpc_peer_keepalive_worker+0x6b3/0xd02 /net/rxrpc/peer_event.c:430
Fixes: 330bdcf ("rxrpc: Fix the keepalive generator [ver freedreno-zz#2]")
Reported-by: [email protected]
Signed-off-by: David Howells <[email protected]>
Reviewed-by: Marc Dionne <[email protected]>
Reviewed-by: Jeffrey Altman <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Aug 14, 2019
Commit abbbdf1 ("replace kill_bdev() with __invalidate_device()") once did this, but 29eaadc ("nbd: stop using the bdev everywhere") resurrected kill_bdev() and it has been there since then. So buffer_head mappings still get killed on a server disconnection, and we can still hit the BUG_ON on a filesystem on the top of the nbd device. EXT4-fs (nbd0): mounted filesystem with ordered data mode. Opts: (null) block nbd0: Receive control failed (result -32) block nbd0: shutting down sockets print_req_error: I/O error, dev nbd0, sector 66264 flags 3000 EXT4-fs warning (device nbd0): htree_dirblock_to_tree:979: inode freedreno-zz#2: lblock 0: comm ls: error -5 reading directory block print_req_error: I/O error, dev nbd0, sector 2264 flags 3000 EXT4-fs error (device nbd0): __ext4_get_inode_loc:4690: inode freedreno-zz#2: block 283: comm ls: unable to read itable block EXT4-fs error (device nbd0) in ext4_reserve_inode_write:5894: IO failure ------------[ cut here ]------------ kernel BUG at fs/buffer.c:3057! invalid opcode: 0000 [freedreno-zz#1] SMP PTI CPU: 7 PID: 40045 Comm: jbd2/nbd0-8 Not tainted 5.1.0-rc3+ #4 Hardware name: Amazon EC2 m5.12xlarge/, BIOS 1.0 10/16/2017 RIP: 0010:submit_bh_wbc+0x18b/0x190 ... Call Trace: jbd2_write_superblock+0xf1/0x230 [jbd2] ? account_entity_enqueue+0xc5/0xf0 jbd2_journal_update_sb_log_tail+0x94/0xe0 [jbd2] jbd2_journal_commit_transaction+0x12f/0x1d20 [jbd2] ? __switch_to_asm+0x40/0x70 ... ? lock_timer_base+0x67/0x80 kjournald2+0x121/0x360 [jbd2] ? remove_wait_queue+0x60/0x60 kthread+0xf8/0x130 ? commit_timeout+0x10/0x10 [jbd2] ? kthread_bind+0x10/0x10 ret_from_fork+0x35/0x40 With __invalidate_device(), I no longer hit the BUG_ON with sync or unmount on the disconnected device. Fixes: 29eaadc ("nbd: stop using the bdev everywhere") Cc: [email protected] Cc: Ratna Manoj Bolla <[email protected]> Cc: [email protected] Cc: [email protected] Cc: David Woodhouse <[email protected]> Reviewed-by: Josef Bacik <[email protected]> Signed-off-by: Munehisa Kamata <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Aug 14, 2019
Ido Schimmel says: ==================== mlxsw: Two small fixes Patch freedreno-zz#1 from Jiri fixes the error path of the module initialization function. Found during manual code inspection. Patch freedreno-zz#2 from Petr further reduces the default shared buffer pool sizes in order to work around a problem that was originally described in commit e891ce1 ("mlxsw: spectrum_buffers: Reduce pool size on Spectrum-2"). ==================== Signed-off-by: David S. Miller <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Aug 14, 2019
lockdep reports:
WARNING: possible circular locking dependency detected
modprobe/302 is trying to acquire lock:
0000000007c8919c ((wq_completion)ib_cm){+.+.}, at: flush_workqueue+0xdf/0x990
but task is already holding lock:
000000002d3d2ca9 (&device->client_data_rwsem){++++}, at: remove_client_context+0x79/0xd0 [ib_core]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> freedreno-zz#2 (&device->client_data_rwsem){++++}:
down_read+0x3f/0x160
ib_get_net_dev_by_params+0xd5/0x200 [ib_core]
cma_ib_req_handler+0x5f6/0x2090 [rdma_cm]
cm_process_work+0x29/0x110 [ib_cm]
cm_req_handler+0x10f5/0x1c00 [ib_cm]
cm_work_handler+0x54c/0x311d [ib_cm]
process_one_work+0x4aa/0xa30
worker_thread+0x62/0x5b0
kthread+0x1ca/0x1f0
ret_from_fork+0x24/0x30
-> freedreno-zz#1 ((work_completion)(&(&work->work)->work)){+.+.}:
process_one_work+0x45f/0xa30
worker_thread+0x62/0x5b0
kthread+0x1ca/0x1f0
ret_from_fork+0x24/0x30
-> #0 ((wq_completion)ib_cm){+.+.}:
lock_acquire+0xc8/0x1d0
flush_workqueue+0x102/0x990
cm_remove_one+0x30e/0x3c0 [ib_cm]
remove_client_context+0x94/0xd0 [ib_core]
disable_device+0x10a/0x1f0 [ib_core]
__ib_unregister_device+0x5a/0xe0 [ib_core]
ib_unregister_device+0x21/0x30 [ib_core]
mlx5_ib_stage_ib_reg_cleanup+0x9/0x10 [mlx5_ib]
__mlx5_ib_remove+0x3d/0x70 [mlx5_ib]
mlx5_ib_remove+0x12e/0x140 [mlx5_ib]
mlx5_remove_device+0x144/0x150 [mlx5_core]
mlx5_unregister_interface+0x3f/0xf0 [mlx5_core]
mlx5_ib_cleanup+0x10/0x3a [mlx5_ib]
__x64_sys_delete_module+0x227/0x350
do_syscall_64+0xc3/0x6a4
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Which is due to the read side of the client_data_rwsem being obtained
recursively through a work queue flush during cm client removal.
The lock is being held across the remove in remove_client_context() so
that the function is a fence, once it returns the client is removed. This
is required so that the two callers do not proceed with destruction until
the client completes removal.
Instead of using client_data_rwsem use the existing device unregistration
refcount and add a similar client unregistration (client->uses) refcount.
This will fence the two unregistration paths without holding any locks.
Cc: <[email protected]>
Fixes: 921eab1 ("RDMA/devices: Re-organize device.c locking")
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Doug Ledford <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Aug 14, 2019
msi.c is not a module on its own right and should not have the MODULE_[LICENSE|VERSION|AUTHOR|DESCRIPTION] definitions. This caused a regression noticed by lkp with the following back trace: WARNING: CPU: 0 PID: 1 at kernel/params.c:861 param_sysfs_init+0xb1/0x20a Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.0-rc1-00018-g26b3a37b928457 freedreno-zz#2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 RIP: 0010:param_sysfs_init+0xb1/0x20a Code: 24 38 e8 ec 17 2e fd 49 8b 7c 24 38 e8 76 fe ff ff 48 85 c0 48 89 c5 74 25 31 d2 4c 89 e6 48 89 c7 e8 6d 6f 3c fd 85 c0 74 02 <0f> 0b 48 89 ef 31 f6 e8 5d 70 a7 fe 48 89 ef e8 95 52 a7 fe 48 83 RSP: 0000:ffff88806b0ffe30 EFLAGS: 00010282 RAX: 00000000ffffffef RBX: ffffffff83774220 RCX: ffff88806a85e880 RDX: 00000000ffffffef RSI: ffff88806b000400 RDI: ffff88806a8608c0 RBP: ffff88806b392000 R08: ffffed100d61ff59 R09: ffffed100d61ff59 R10: 0000000000000001 R11: ffffed100d61ff58 R12: ffffffff83974bc0 R13: 0000000000000004 R14: 0000000000000028 R15: 00000000000003b9 FS: 0000000000000000(0000) GS:ffff88806b800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000000380e000 CR4: 00000000000406b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? file_caps_disable+0x10/0x10 ? locate_module_kobject+0xf2/0xf2 do_one_initcall+0x47/0x1f0 kernel_init_freeable+0x1b1/0x243 ? rest_init+0xd0/0xd0 kernel_init+0xa/0x130 ? calculate_sigpending+0x63/0x80 ? rest_init+0xd0/0xd0 ret_from_fork+0x1f/0x30 ---[ end trace 78201497ae74cc91 ]--- Reported-by: kernel test robot <[email protected]> Fixes: 26b3a37 ("NTB: Introduce MSI library") Signed-off-by: Logan Gunthorpe <[email protected]> Signed-off-by: Jon Mason <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Aug 14, 2019
A deadlock with this stacktrace was observed. The loop thread does a GFP_KERNEL allocation, it calls into dm-bufio shrinker and the shrinker depends on I/O completion in the dm-bufio subsystem. In order to fix the deadlock (and other similar ones), we set the flag PF_MEMALLOC_NOIO at loop thread entry. PID: 474 TASK: ffff8813e11f4600 CPU: 10 COMMAND: "kswapd0" #0 [ffff8813dedfb938] __schedule at ffffffff8173f405 freedreno-zz#1 [ffff8813dedfb990] schedule at ffffffff8173fa27 freedreno-zz#2 [ffff8813dedfb9b0] schedule_timeout at ffffffff81742fec freedreno-zz#3 [ffff8813dedfba60] io_schedule_timeout at ffffffff8173f186 #4 [ffff8813dedfbaa0] bit_wait_io at ffffffff8174034f #5 [ffff8813dedfbac0] __wait_on_bit at ffffffff8173fec8 #6 [ffff8813dedfbb10] out_of_line_wait_on_bit at ffffffff8173ff81 #7 [ffff8813dedfbb90] __make_buffer_clean at ffffffffa038736f [dm_bufio] #8 [ffff8813dedfbbb0] __try_evict_buffer at ffffffffa0387bb8 [dm_bufio] #9 [ffff8813dedfbbd0] dm_bufio_shrink_scan at ffffffffa0387cc3 [dm_bufio] #10 [ffff8813dedfbc40] shrink_slab at ffffffff811a87ce #11 [ffff8813dedfbd30] shrink_zone at ffffffff811ad778 #12 [ffff8813dedfbdc0] kswapd at ffffffff811ae92f #13 [ffff8813dedfbec0] kthread at ffffffff810a8428 #14 [ffff8813dedfbf50] ret_from_fork at ffffffff81745242 PID: 14127 TASK: ffff881455749c00 CPU: 11 COMMAND: "loop1" #0 [ffff88272f5af228] __schedule at ffffffff8173f405 freedreno-zz#1 [ffff88272f5af280] schedule at ffffffff8173fa27 freedreno-zz#2 [ffff88272f5af2a0] schedule_preempt_disabled at ffffffff8173fd5e freedreno-zz#3 [ffff88272f5af2b0] __mutex_lock_slowpath at ffffffff81741fb5 #4 [ffff88272f5af330] mutex_lock at ffffffff81742133 #5 [ffff88272f5af350] dm_bufio_shrink_count at ffffffffa03865f9 [dm_bufio] #6 [ffff88272f5af380] shrink_slab at ffffffff811a86bd #7 [ffff88272f5af470] shrink_zone at ffffffff811ad778 #8 [ffff88272f5af500] do_try_to_free_pages at ffffffff811adb34 #9 [ffff88272f5af590] try_to_free_pages at ffffffff811adef8 #10 [ffff88272f5af610] __alloc_pages_nodemask at ffffffff811a09c3 #11 [ffff88272f5af710] alloc_pages_current at ffffffff811e8b71 #12 [ffff88272f5af760] new_slab at ffffffff811f4523 #13 [ffff88272f5af7b0] __slab_alloc at ffffffff8173a1b5 #14 [ffff88272f5af880] kmem_cache_alloc at ffffffff811f484b #15 [ffff88272f5af8d0] do_blockdev_direct_IO at ffffffff812535b3 #16 [ffff88272f5afb00] __blockdev_direct_IO at ffffffff81255dc3 #17 [ffff88272f5afb30] xfs_vm_direct_IO at ffffffffa01fe3fc [xfs] #18 [ffff88272f5afb90] generic_file_read_iter at ffffffff81198994 #19 [ffff88272f5afc50] __dta_xfs_file_read_iter_2398 at ffffffffa020c970 [xfs] #20 [ffff88272f5afcc0] lo_rw_aio at ffffffffa0377042 [loop] #21 [ffff88272f5afd70] loop_queue_work at ffffffffa0377c3b [loop] #22 [ffff88272f5afe60] kthread_worker_fn at ffffffff810a8a0c #23 [ffff88272f5afec0] kthread at ffffffff810a8428 #24 [ffff88272f5aff50] ret_from_fork at ffffffff81745242 Signed-off-by: Mikulas Patocka <[email protected]> Cc: [email protected] Signed-off-by: Jens Axboe <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Aug 14, 2019
…nux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm fixes for 5.3, take freedreno-zz#2 - Fix our system register reset so that we stop writing non-sensical values to them, and track which registers get reset instead. - Sync VMCR back from the GIC on WFI so that KVM has an exact vue of PMR. - Reevaluate state of HW-mapped, level triggered interrupts on enable.
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Jul 16, 2020
xen_failsafe_callback() is invoked from XEN for two cases: 1. Fault while reloading DS, ES, FS or GS 2. Fault while executing IRET freedreno-zz#1 retries the IRET after XEN has fixed up the segments. freedreno-zz#2 injects a #GP which kills the task For freedreno-zz#1 there is no reason to go through the full exception return path because the tasks TIF state is still the same. So just going straight to the IRET path is good enough. Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Acked-by: Andy Lutomirski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Jul 16, 2020
The first version of Clang that supports -tsan-distinguish-volatile will
be able to support KCSAN. The first Clang release to do so, will be
Clang 11. This is due to satisfying all the following requirements:
1. Never emit calls to __tsan_func_{entry,exit}.
2. __no_kcsan functions should not call anything, not even
kcsan_{enable,disable}_current(), when using __{READ,WRITE}_ONCE => Requires
leaving them plain!
3. Support atomic_{read,set}*() with KCSAN, which rely on
arch_atomic_{read,set}*() using __{READ,WRITE}_ONCE() => Because of
freedreno-zz#2, rely on Clang 11's -tsan-distinguish-volatile support. We will
double-instrument atomic_{read,set}*(), but that's reasonable given
it's still lower cost than the data_race() variant due to avoiding 2
extra calls (kcsan_{en,dis}able_current() calls).
4. __always_inline functions inlined into __no_kcsan functions are never
instrumented.
5. __always_inline functions inlined into instrumented functions are
instrumented.
6. __no_kcsan_or_inline functions may be inlined into __no_kcsan functions =>
Implies leaving 'noinline' off of __no_kcsan_or_inline.
7. Because of #6, __no_kcsan and __no_kcsan_or_inline functions should never be
spuriously inlined into instrumented functions, causing the accesses of the
__no_kcsan function to be instrumented.
Older versions of Clang do not satisfy freedreno-zz#3. The latest GCC currently
doesn't support at least freedreno-zz#1, freedreno-zz#3, and #7.
Signed-off-by: Marco Elver <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Acked-by: Peter Zijlstra (Intel) <[email protected]>
Acked-by: Will Deacon <[email protected]>
Link: https://lkml.kernel.org/r/CANpmjNMTsY_8241bS7=XAfqvZHFLrVEkv_uM4aDUWE_kh3Rvbw@mail.gmail.com
Link: https://lkml.kernel.org/r/[email protected]
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Jul 16, 2020
The commits cd0e00c and 92d7223 broke boot on the Alpha Avanti platform. The patches move memory barriers after a write before the write. The result is that if there's iowrite followed by ioread, there is no barrier between them. The Alpha architecture allows reordering of the accesses to the I/O space, and the missing barrier between write and read causes hang with serial port and real time clock. This patch makes barriers confiorm to the specification. 1. We add mb() before readX_relaxed and writeX_relaxed - memory-barriers.txt claims that these functions must be ordered w.r.t. each other. Alpha doesn't order them, so we need an explicit barrier. 2. We add mb() before reads from the I/O space - so that if there's a write followed by a read, there should be a barrier between them. Signed-off-by: Mikulas Patocka <[email protected]> Fixes: cd0e00c ("alpha: io: reorder barriers to guarantee writeX() and iowriteX() ordering") Fixes: 92d7223 ("alpha: io: reorder barriers to guarantee writeX() and iowriteX() ordering freedreno-zz#2") Cc: [email protected] # v4.17+ Acked-by: Ivan Kokshaysky <[email protected]> Reviewed-by: Maciej W. Rozycki <[email protected]> Signed-off-by: Matt Turner <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Sep 4, 2020
Yonghong Song says: ==================== Andrii raised a concern that current uapi for bpf iterator map element is a little restrictive and not suitable for future potential complex customization. This is a valid suggestion, considering people may indeed add more complex custimization to the iterator, e.g., cgroup_id + user_id, etc. for task or task_file. Another example might be map_id plus additional control so that the bpf iterator may bail out a bucket earlier if a bucket has too many elements which may hold lock too long and impact other parts of systems. Patch freedreno-zz#1 modified uapi with kernel changes. Patch freedreno-zz#2 adjusted libbpf api accordingly. Changelogs: v3 -> v4: . add a forward declaration of bpf_iter_link_info in tools/lib/bpf/bpf.h in case that libbpf is built against not-latest uapi bpf.h. . target the patch set to "bpf" instead of "bpf-next" v2 -> v3: . undo "not reject iter_info.map.map_fd == 0" from v1. In the future map_fd may become optional, so let us use map_fd == 0 indicating the map_fd is not set by user space. . add link_info_len to bpf_iter_attach_opts to ensure always correct link_info_len from user. Otherwise, libbpf may deduce incorrect link_info_len if it uses different uapi header than the user app. v1 -> v2: . ensure link_create target_fd/flags == 0 since they are not used. (Andrii) . if either of iter_info ptr == 0 or iter_info_len == 0, but not both, return error to user space. (Andrii) . do not reject iter_info.map.map_fd == 0, go ahead to use it trying to get a map reference since the map_fd is required for map_elem iterator. . use bpf_iter_link_info in bpf_iter_attach_opts instead of map_fd. this way, user space is responsible to set up bpf_iter_link_info and libbpf just passes the data to the kernel, simplifying libbpf design. (Andrii) ==================== Signed-off-by: Alexei Starovoitov <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Sep 4, 2020
… set We received an error report that perf-record caused 'Segmentation fault' on a newly system (e.g. on the new installed ubuntu). (gdb) backtrace #0 __read_once_size (size=4, res=<synthetic pointer>, p=0x14) at /root/0-jinyao/acme/tools/include/linux/compiler.h:139 freedreno-zz#1 atomic_read (v=0x14) at /root/0-jinyao/acme/tools/include/asm/../../arch/x86/include/asm/atomic.h:28 freedreno-zz#2 refcount_read (r=0x14) at /root/0-jinyao/acme/tools/include/linux/refcount.h:65 freedreno-zz#3 perf_mmap__read_init (map=map@entry=0x0) at mmap.c:177 #4 0x0000561ce5c0de39 in perf_evlist__poll_thread (arg=0x561ce68584d0) at util/sideband_evlist.c:62 #5 0x00007fad78491609 in start_thread (arg=<optimized out>) at pthread_create.c:477 #6 0x00007fad7823c103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 The root cause is, evlist__add_bpf_sb_event() just returns 0 if HAVE_LIBBPF_SUPPORT is not defined (inline function path). So it will not create a valid evsel for side-band event. But perf-record still creates BPF side band thread to process the side-band event, then the error happpens. We can reproduce this issue by removing the libelf-dev. e.g. 1. apt-get remove libelf-dev 2. perf record -a -- sleep 1 root@test:~# ./perf record -a -- sleep 1 perf: Segmentation fault Obtained 6 stack frames. ./perf(+0x28eee8) [0x5562d6ef6ee8] /lib/x86_64-linux-gnu/libc.so.6(+0x46210) [0x7fbfdc65f210] ./perf(+0x342e74) [0x5562d6faae74] ./perf(+0x257e39) [0x5562d6ebfe39] /lib/x86_64-linux-gnu/libpthread.so.0(+0x9609) [0x7fbfdc990609] /lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7fbfdc73b103] Segmentation fault (core dumped) To fix this issue, 1. We either install the missing libraries to let HAVE_LIBBPF_SUPPORT be defined. e.g. apt-get install libelf-dev and install other related libraries. 2. Use this patch to skip the side-band event setup if HAVE_LIBBPF_SUPPORT is not set. Committer notes: The side band thread is not used just with BPF, it is also used with --switch-output-event, so narrow the ifdef to the BPF specific part. Fixes: 23cbb41 ("perf record: Move side band evlist setup to separate routine") Signed-off-by: Jin Yao <[email protected]> Acked-by: Jiri Olsa <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Jin Yao <[email protected]> Cc: Kan Liang <[email protected]> Cc: Peter Zijlstra <[email protected]> Link: http://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Sep 4, 2020
Freeing chip on error may lead to an Oops at the next time the system goes to resume. Fix this by removing all snd_echo_free() calls on error. Fixes: 47b5d02 ("ALSA: Echoaudio - Add suspend support freedreno-zz#2") Signed-off-by: Dinghao Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Sep 5, 2020
Ext4 uses blkdev_get_by_dev() to get the block_device for journal device which does check to see if the read-only block device was opened read-only. As a result ext4 will hapily proceed mounting the file system with external journal on read-only device. This is bad as we would not be able to use the journal leading to errors later on. Instead of simply failing to mount file system in this case, treat it in a similar way we treat internal journal on read-only device. Allow to mount with -o noload in read-only mode. This can be reproduced easily like this: mke2fs -F -O journal_dev $JOURNAL_DEV 100M mkfs.$FSTYPE -F -J device=$JOURNAL_DEV $FS_DEV blockdev --setro $JOURNAL_DEV mount $FS_DEV $MNT touch $MNT/file umount $MNT leading to error like this [ 1307.318713] ------------[ cut here ]------------ [ 1307.323362] generic_make_request: Trying to write to read-only block-device dm-2 (partno 0) [ 1307.331741] WARNING: CPU: 36 PID: 3224 at block/blk-core.c:855 generic_make_request_checks+0x2c3/0x580 [ 1307.341041] Modules linked in: ext4 mbcache jbd2 rfkill intel_rapl_msr intel_rapl_common isst_if_commd [ 1307.419445] CPU: 36 PID: 3224 Comm: jbd2/dm-2 Tainted: G W I 5.8.0-rc5 freedreno-zz#2 [ 1307.427359] Hardware name: Dell Inc. PowerEdge R740/01KPX8, BIOS 2.3.10 08/15/2019 [ 1307.434932] RIP: 0010:generic_make_request_checks+0x2c3/0x580 [ 1307.440676] Code: 94 03 00 00 48 89 df 48 8d 74 24 08 c6 05 cf 2b 18 01 01 e8 7f a4 ff ff 48 c7 c7 50e [ 1307.459420] RSP: 0018:ffffc0d70eb5fb48 EFLAGS: 00010286 [ 1307.464646] RAX: 0000000000000000 RBX: ffff9b33b2978300 RCX: 0000000000000000 [ 1307.471780] RDX: ffff9b33e12a81e0 RSI: ffff9b33e1298000 RDI: ffff9b33e1298000 [ 1307.478913] RBP: ffff9b7b9679e0c0 R08: 0000000000000837 R09: 0000000000000024 [ 1307.486044] R10: 0000000000000000 R11: ffffc0d70eb5f9f0 R12: 0000000000000400 [ 1307.493177] R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000000 [ 1307.500308] FS: 0000000000000000(0000) GS:ffff9b33e1280000(0000) knlGS:0000000000000000 [ 1307.508396] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1307.514142] CR2: 000055eaf4109000 CR3: 0000003dee40a006 CR4: 00000000007606e0 [ 1307.521273] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1307.528407] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1307.535538] PKRU: 55555554 [ 1307.538250] Call Trace: [ 1307.540708] generic_make_request+0x30/0x340 [ 1307.544985] submit_bio+0x43/0x190 [ 1307.548393] ? bio_add_page+0x62/0x90 [ 1307.552068] submit_bh_wbc+0x16a/0x190 [ 1307.555833] jbd2_write_superblock+0xec/0x200 [jbd2] [ 1307.560803] jbd2_journal_update_sb_log_tail+0x65/0xc0 [jbd2] [ 1307.566557] jbd2_journal_commit_transaction+0x2ae/0x1860 [jbd2] [ 1307.572566] ? check_preempt_curr+0x7a/0x90 [ 1307.576756] ? update_curr+0xe1/0x1d0 [ 1307.580421] ? account_entity_dequeue+0x7b/0xb0 [ 1307.584955] ? newidle_balance+0x231/0x3d0 [ 1307.589056] ? __switch_to_asm+0x42/0x70 [ 1307.592986] ? __switch_to_asm+0x36/0x70 [ 1307.596918] ? lock_timer_base+0x67/0x80 [ 1307.600851] kjournald2+0xbd/0x270 [jbd2] [ 1307.604873] ? finish_wait+0x80/0x80 [ 1307.608460] ? commit_timeout+0x10/0x10 [jbd2] [ 1307.612915] kthread+0x114/0x130 [ 1307.616152] ? kthread_park+0x80/0x80 [ 1307.619816] ret_from_fork+0x22/0x30 [ 1307.623400] ---[ end trace 27490236265b1630 ]--- Signed-off-by: Lukas Czerner <[email protected]> Reviewed-by: Andreas Dilger <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Sep 5, 2020
We have a number of "uart.port->desc.lock vs desc.lock->uart.port" lockdep reports coming from 8250 driver; this causes a bit of trouble to people, so let's fix it. The problem is reverse lock order in two different call paths: chain freedreno-zz#1: serial8250_do_startup() spin_lock_irqsave(&port->lock); disable_irq_nosync(port->irq); raw_spin_lock_irqsave(&desc->lock) chain freedreno-zz#2: __report_bad_irq() raw_spin_lock_irqsave(&desc->lock) for_each_action_of_desc() printk() spin_lock_irqsave(&port->lock); Fix this by changing the order of locks in serial8250_do_startup(): do disable_irq_nosync() first, which grabs desc->lock, and grab uart->port after that, so that chain freedreno-zz#1 and chain freedreno-zz#2 have same lock order. Full lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 5.4.39 #55 Not tainted ====================================================== swapper/0/0 is trying to acquire lock: ffffffffab65b6c0 (console_owner){-...}, at: console_lock_spinning_enable+0x31/0x57 but task is already holding lock: ffff88810a8e34c0 (&irq_desc_lock_class){-.-.}, at: __report_bad_irq+0x5b/0xba which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> freedreno-zz#2 (&irq_desc_lock_class){-.-.}: _raw_spin_lock_irqsave+0x61/0x8d __irq_get_desc_lock+0x65/0x89 __disable_irq_nosync+0x3b/0x93 serial8250_do_startup+0x451/0x75c uart_startup+0x1b4/0x2ff uart_port_activate+0x73/0xa0 tty_port_open+0xae/0x10a uart_open+0x1b/0x26 tty_open+0x24d/0x3a0 chrdev_open+0xd5/0x1cc do_dentry_open+0x299/0x3c8 path_openat+0x434/0x1100 do_filp_open+0x9b/0x10a do_sys_open+0x15f/0x3d7 kernel_init_freeable+0x157/0x1dd kernel_init+0xe/0x105 ret_from_fork+0x27/0x50 -> freedreno-zz#1 (&port_lock_key){-.-.}: _raw_spin_lock_irqsave+0x61/0x8d serial8250_console_write+0xa7/0x2a0 console_unlock+0x3b7/0x528 vprintk_emit+0x111/0x17f printk+0x59/0x73 register_console+0x336/0x3a4 uart_add_one_port+0x51b/0x5be serial8250_register_8250_port+0x454/0x55e dw8250_probe+0x4dc/0x5b9 platform_drv_probe+0x67/0x8b really_probe+0x14a/0x422 driver_probe_device+0x66/0x130 device_driver_attach+0x42/0x5b __driver_attach+0xca/0x139 bus_for_each_dev+0x97/0xc9 bus_add_driver+0x12b/0x228 driver_register+0x64/0xed do_one_initcall+0x20c/0x4a6 do_initcall_level+0xb5/0xc5 do_basic_setup+0x4c/0x58 kernel_init_freeable+0x13f/0x1dd kernel_init+0xe/0x105 ret_from_fork+0x27/0x50 -> #0 (console_owner){-...}: __lock_acquire+0x118d/0x2714 lock_acquire+0x203/0x258 console_lock_spinning_enable+0x51/0x57 console_unlock+0x25d/0x528 vprintk_emit+0x111/0x17f printk+0x59/0x73 __report_bad_irq+0xa3/0xba note_interrupt+0x19a/0x1d6 handle_irq_event_percpu+0x57/0x79 handle_irq_event+0x36/0x55 handle_fasteoi_irq+0xc2/0x18a do_IRQ+0xb3/0x157 ret_from_intr+0x0/0x1d cpuidle_enter_state+0x12f/0x1fd cpuidle_enter+0x2e/0x3d do_idle+0x1ce/0x2ce cpu_startup_entry+0x1d/0x1f start_kernel+0x406/0x46a secondary_startup_64+0xa4/0xb0 other info that might help us debug this: Chain exists of: console_owner --> &port_lock_key --> &irq_desc_lock_class Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&irq_desc_lock_class); lock(&port_lock_key); lock(&irq_desc_lock_class); lock(console_owner); *** DEADLOCK *** 2 locks held by swapper/0/0: #0: ffff88810a8e34c0 (&irq_desc_lock_class){-.-.}, at: __report_bad_irq+0x5b/0xba freedreno-zz#1: ffffffffab65b5c0 (console_lock){+.+.}, at: console_trylock_spinning+0x20/0x181 stack backtrace: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.39 #55 Hardware name: XXXXXX Call Trace: <IRQ> dump_stack+0xbf/0x133 ? print_circular_bug+0xd6/0xe9 check_noncircular+0x1b9/0x1c3 __lock_acquire+0x118d/0x2714 lock_acquire+0x203/0x258 ? console_lock_spinning_enable+0x31/0x57 console_lock_spinning_enable+0x51/0x57 ? console_lock_spinning_enable+0x31/0x57 console_unlock+0x25d/0x528 ? console_trylock+0x18/0x4e vprintk_emit+0x111/0x17f ? lock_acquire+0x203/0x258 printk+0x59/0x73 __report_bad_irq+0xa3/0xba note_interrupt+0x19a/0x1d6 handle_irq_event_percpu+0x57/0x79 handle_irq_event+0x36/0x55 handle_fasteoi_irq+0xc2/0x18a do_IRQ+0xb3/0x157 common_interrupt+0xf/0xf </IRQ> Signed-off-by: Sergey Senozhatsky <[email protected]> Fixes: 768aec0 ("serial: 8250: fix shared interrupts issues with SMP and RT kernels") Reported-by: Guenter Roeck <[email protected]> Reported-by: Raul Rangel <[email protected]> BugLink: https://bugs.chromium.org/p/chromium/issues/detail?id=1114800 Link: https://lore.kernel.org/lkml/CAHQZ30BnfX+gxjPm1DUd5psOTqbyDh4EJE=2=VAMW_VDafctkA@mail.gmail.com/T/#u Reviewed-by: Andy Shevchenko <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Tested-by: Guenter Roeck <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Sep 30, 2020
Allocating memory with regulator_list_mutex held makes lockdep unhappy
when memory pressure makes the system do fs_reclaim on eg. eMMC using
a regulator. Push the lock inside regulator_init_coupling() after the
allocation.
======================================================
WARNING: possible circular locking dependency detected
5.7.13+ #533 Not tainted
------------------------------------------------------
kswapd0/383 is trying to acquire lock:
cca78ca4 (&sbi->write_io[i][j].io_rwsem){++++}-{3:3}, at: __submit_merged_write_cond+0x104/0x154
but task is already holding lock:
c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> freedreno-zz#2 (fs_reclaim){+.+.}-{0:0}:
fs_reclaim_acquire.part.11+0x40/0x50
fs_reclaim_acquire+0x24/0x28
__kmalloc+0x54/0x218
regulator_register+0x860/0x1584
dummy_regulator_probe+0x60/0xa8
[...]
other info that might help us debug this:
Chain exists of:
&sbi->write_io[i][j].io_rwsem --> regulator_list_mutex --> fs_reclaim
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(fs_reclaim);
lock(regulator_list_mutex);
lock(fs_reclaim);
lock(&sbi->write_io[i][j].io_rwsem);
*** DEADLOCK ***
1 lock held by kswapd0/383:
#0: c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
[...]
Fixes: d8ca7d1 ("regulator: core: Introduce API for regulators coupling customization")
Signed-off-by: Michał Mirosław <[email protected]>
Reviewed-by: Dmitry Osipenko <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/1a889cf7f61c6429c9e6b34ddcdde99be77a26b6.1597195321.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Sep 30, 2020
With the conversion of the tree locks to rwsem I got the following
lockdep splat:
======================================================
WARNING: possible circular locking dependency detected
5.8.0-rc7-00165-g04ec4da5f45f-dirty #922 Not tainted
------------------------------------------------------
compsize/11122 is trying to acquire lock:
ffff889fabca8768 (&mm->mmap_lock#2){++++}-{3:3}, at: __might_fault+0x3e/0x90
but task is already holding lock:
ffff889fe720fe40 (btrfs-fs-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x39/0x180
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> freedreno-zz#2 (btrfs-fs-00){++++}-{3:3}:
down_write_nested+0x3b/0x70
__btrfs_tree_lock+0x24/0x120
btrfs_search_slot+0x756/0x990
btrfs_lookup_inode+0x3a/0xb4
__btrfs_update_delayed_inode+0x93/0x270
btrfs_async_run_delayed_root+0x168/0x230
btrfs_work_helper+0xd4/0x570
process_one_work+0x2ad/0x5f0
worker_thread+0x3a/0x3d0
kthread+0x133/0x150
ret_from_fork+0x1f/0x30
-> freedreno-zz#1 (&delayed_node->mutex){+.+.}-{3:3}:
__mutex_lock+0x9f/0x930
btrfs_delayed_update_inode+0x50/0x440
btrfs_update_inode+0x8a/0xf0
btrfs_dirty_inode+0x5b/0xd0
touch_atime+0xa1/0xd0
btrfs_file_mmap+0x3f/0x60
mmap_region+0x3a4/0x640
do_mmap+0x376/0x580
vm_mmap_pgoff+0xd5/0x120
ksys_mmap_pgoff+0x193/0x230
do_syscall_64+0x50/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xa9
-> #0 (&mm->mmap_lock#2){++++}-{3:3}:
__lock_acquire+0x1272/0x2310
lock_acquire+0x9e/0x360
__might_fault+0x68/0x90
_copy_to_user+0x1e/0x80
copy_to_sk.isra.32+0x121/0x300
search_ioctl+0x106/0x200
btrfs_ioctl_tree_search_v2+0x7b/0xf0
btrfs_ioctl+0x106f/0x30a0
ksys_ioctl+0x83/0xc0
__x64_sys_ioctl+0x16/0x20
do_syscall_64+0x50/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xa9
other info that might help us debug this:
Chain exists of:
&mm->mmap_lock#2 --> &delayed_node->mutex --> btrfs-fs-00
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(btrfs-fs-00);
lock(&delayed_node->mutex);
lock(btrfs-fs-00);
lock(&mm->mmap_lock#2);
*** DEADLOCK ***
1 lock held by compsize/11122:
#0: ffff889fe720fe40 (btrfs-fs-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x39/0x180
stack backtrace:
CPU: 17 PID: 11122 Comm: compsize Kdump: loaded Not tainted 5.8.0-rc7-00165-g04ec4da5f45f-dirty #922
Hardware name: Quanta Tioga Pass Single Side 01-0030993006/Tioga Pass Single Side, BIOS F08_3A18 12/20/2018
Call Trace:
dump_stack+0x78/0xa0
check_noncircular+0x165/0x180
__lock_acquire+0x1272/0x2310
lock_acquire+0x9e/0x360
? __might_fault+0x3e/0x90
? find_held_lock+0x72/0x90
__might_fault+0x68/0x90
? __might_fault+0x3e/0x90
_copy_to_user+0x1e/0x80
copy_to_sk.isra.32+0x121/0x300
? btrfs_search_forward+0x2a6/0x360
search_ioctl+0x106/0x200
btrfs_ioctl_tree_search_v2+0x7b/0xf0
btrfs_ioctl+0x106f/0x30a0
? __do_sys_newfstat+0x5a/0x70
? ksys_ioctl+0x83/0xc0
ksys_ioctl+0x83/0xc0
__x64_sys_ioctl+0x16/0x20
do_syscall_64+0x50/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xa9
The problem is we're doing a copy_to_user() while holding tree locks,
which can deadlock if we have to do a page fault for the copy_to_user().
This exists even without my locking changes, so it needs to be fixed.
Rework the search ioctl to do the pre-fault and then
copy_to_user_nofault for the copying.
CC: [email protected] # 4.4+
Reviewed-by: Filipe Manana <[email protected]>
Signed-off-by: Josef Bacik <[email protected]>
Reviewed-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Sep 30, 2020
I got the following lockdep splat while testing:
======================================================
WARNING: possible circular locking dependency detected
5.8.0-rc7-00172-g021118712e59 #932 Not tainted
------------------------------------------------------
btrfs/229626 is trying to acquire lock:
ffffffff828513f0 (cpu_hotplug_lock){++++}-{0:0}, at: alloc_workqueue+0x378/0x450
but task is already holding lock:
ffff889dd3889518 (&fs_info->scrub_lock){+.+.}-{3:3}, at: btrfs_scrub_dev+0x11c/0x630
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #7 (&fs_info->scrub_lock){+.+.}-{3:3}:
__mutex_lock+0x9f/0x930
btrfs_scrub_dev+0x11c/0x630
btrfs_dev_replace_by_ioctl.cold.21+0x10a/0x1d4
btrfs_ioctl+0x2799/0x30a0
ksys_ioctl+0x83/0xc0
__x64_sys_ioctl+0x16/0x20
do_syscall_64+0x50/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xa9
-> #6 (&fs_devs->device_list_mutex){+.+.}-{3:3}:
__mutex_lock+0x9f/0x930
btrfs_run_dev_stats+0x49/0x480
commit_cowonly_roots+0xb5/0x2a0
btrfs_commit_transaction+0x516/0xa60
sync_filesystem+0x6b/0x90
generic_shutdown_super+0x22/0x100
kill_anon_super+0xe/0x30
btrfs_kill_super+0x12/0x20
deactivate_locked_super+0x29/0x60
cleanup_mnt+0xb8/0x140
task_work_run+0x6d/0xb0
__prepare_exit_to_usermode+0x1cc/0x1e0
do_syscall_64+0x5c/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xa9
-> #5 (&fs_info->tree_log_mutex){+.+.}-{3:3}:
__mutex_lock+0x9f/0x930
btrfs_commit_transaction+0x4bb/0xa60
sync_filesystem+0x6b/0x90
generic_shutdown_super+0x22/0x100
kill_anon_super+0xe/0x30
btrfs_kill_super+0x12/0x20
deactivate_locked_super+0x29/0x60
cleanup_mnt+0xb8/0x140
task_work_run+0x6d/0xb0
__prepare_exit_to_usermode+0x1cc/0x1e0
do_syscall_64+0x5c/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xa9
-> #4 (&fs_info->reloc_mutex){+.+.}-{3:3}:
__mutex_lock+0x9f/0x930
btrfs_record_root_in_trans+0x43/0x70
start_transaction+0xd1/0x5d0
btrfs_dirty_inode+0x42/0xd0
touch_atime+0xa1/0xd0
btrfs_file_mmap+0x3f/0x60
mmap_region+0x3a4/0x640
do_mmap+0x376/0x580
vm_mmap_pgoff+0xd5/0x120
ksys_mmap_pgoff+0x193/0x230
do_syscall_64+0x50/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xa9
-> freedreno-zz#3 (&mm->mmap_lock#2){++++}-{3:3}:
__might_fault+0x68/0x90
_copy_to_user+0x1e/0x80
perf_read+0x141/0x2c0
vfs_read+0xad/0x1b0
ksys_read+0x5f/0xe0
do_syscall_64+0x50/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xa9
-> freedreno-zz#2 (&cpuctx_mutex){+.+.}-{3:3}:
__mutex_lock+0x9f/0x930
perf_event_init_cpu+0x88/0x150
perf_event_init+0x1db/0x20b
start_kernel+0x3ae/0x53c
secondary_startup_64+0xa4/0xb0
-> freedreno-zz#1 (pmus_lock){+.+.}-{3:3}:
__mutex_lock+0x9f/0x930
perf_event_init_cpu+0x4f/0x150
cpuhp_invoke_callback+0xb1/0x900
_cpu_up.constprop.26+0x9f/0x130
cpu_up+0x7b/0xc0
bringup_nonboot_cpus+0x4f/0x60
smp_init+0x26/0x71
kernel_init_freeable+0x110/0x258
kernel_init+0xa/0x103
ret_from_fork+0x1f/0x30
-> #0 (cpu_hotplug_lock){++++}-{0:0}:
__lock_acquire+0x1272/0x2310
lock_acquire+0x9e/0x360
cpus_read_lock+0x39/0xb0
alloc_workqueue+0x378/0x450
__btrfs_alloc_workqueue+0x15d/0x200
btrfs_alloc_workqueue+0x51/0x160
scrub_workers_get+0x5a/0x170
btrfs_scrub_dev+0x18c/0x630
btrfs_dev_replace_by_ioctl.cold.21+0x10a/0x1d4
btrfs_ioctl+0x2799/0x30a0
ksys_ioctl+0x83/0xc0
__x64_sys_ioctl+0x16/0x20
do_syscall_64+0x50/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xa9
other info that might help us debug this:
Chain exists of:
cpu_hotplug_lock --> &fs_devs->device_list_mutex --> &fs_info->scrub_lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&fs_info->scrub_lock);
lock(&fs_devs->device_list_mutex);
lock(&fs_info->scrub_lock);
lock(cpu_hotplug_lock);
*** DEADLOCK ***
2 locks held by btrfs/229626:
#0: ffff88bfe8bb86e0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: btrfs_scrub_dev+0xbd/0x630
freedreno-zz#1: ffff889dd3889518 (&fs_info->scrub_lock){+.+.}-{3:3}, at: btrfs_scrub_dev+0x11c/0x630
stack backtrace:
CPU: 15 PID: 229626 Comm: btrfs Kdump: loaded Not tainted 5.8.0-rc7-00172-g021118712e59 #932
Hardware name: Quanta Tioga Pass Single Side 01-0030993006/Tioga Pass Single Side, BIOS F08_3A18 12/20/2018
Call Trace:
dump_stack+0x78/0xa0
check_noncircular+0x165/0x180
__lock_acquire+0x1272/0x2310
lock_acquire+0x9e/0x360
? alloc_workqueue+0x378/0x450
cpus_read_lock+0x39/0xb0
? alloc_workqueue+0x378/0x450
alloc_workqueue+0x378/0x450
? rcu_read_lock_sched_held+0x52/0x80
__btrfs_alloc_workqueue+0x15d/0x200
btrfs_alloc_workqueue+0x51/0x160
scrub_workers_get+0x5a/0x170
btrfs_scrub_dev+0x18c/0x630
? start_transaction+0xd1/0x5d0
btrfs_dev_replace_by_ioctl.cold.21+0x10a/0x1d4
btrfs_ioctl+0x2799/0x30a0
? do_sigaction+0x102/0x250
? lockdep_hardirqs_on_prepare+0xca/0x160
? _raw_spin_unlock_irq+0x24/0x30
? trace_hardirqs_on+0x1c/0xe0
? _raw_spin_unlock_irq+0x24/0x30
? do_sigaction+0x102/0x250
? ksys_ioctl+0x83/0xc0
ksys_ioctl+0x83/0xc0
__x64_sys_ioctl+0x16/0x20
do_syscall_64+0x50/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xa9
This happens because we're allocating the scrub workqueues under the
scrub and device list mutex, which brings in a whole host of other
dependencies.
Because the work queue allocation is done with GFP_KERNEL, it can
trigger reclaim, which can lead to a transaction commit, which in turns
needs the device_list_mutex, it can lead to a deadlock. A different
problem for which this fix is a solution.
Fix this by moving the actual allocation outside of the
scrub lock, and then only take the lock once we're ready to actually
assign them to the fs_info. We'll now have to cleanup the workqueues in
a few more places, so I've added a helper to do the refcount dance to
safely free the workqueues.
CC: [email protected] # 5.4+
Reviewed-by: Filipe Manana <[email protected]>
Signed-off-by: Josef Bacik <[email protected]>
Reviewed-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Sep 30, 2020
…s metrics" test Linux 5.9 introduced perf test case "Parse and process metrics" and on s390 this test case always dumps core: [root@t35lp67 perf]# ./perf test -vvvv -F 67 67: Parse and process metrics : --- start --- metric expr inst_retired.any / cpu_clk_unhalted.thread for IPC parsing metric: inst_retired.any / cpu_clk_unhalted.thread Segmentation fault (core dumped) [root@t35lp67 perf]# I debugged this core dump and gdb shows this call chain: (gdb) where #0 0x000003ffabc3192a in __strnlen_c_1 () from /lib64/libc.so.6 freedreno-zz#1 0x000003ffabc293de in strcasestr () from /lib64/libc.so.6 freedreno-zz#2 0x0000000001102ba2 in match_metric(list=0x1e6ea20 "inst_retired.any", n=<optimized out>) at util/metricgroup.c:368 freedreno-zz#3 find_metric (map=<optimized out>, map=<optimized out>, metric=0x1e6ea20 "inst_retired.any") at util/metricgroup.c:765 #4 __resolve_metric (ids=0x0, map=<optimized out>, metric_list=0x0, metric_no_group=<optimized out>, m=<optimized out>) at util/metricgroup.c:844 #5 resolve_metric (ids=0x0, map=0x0, metric_list=0x0, metric_no_group=<optimized out>) at util/metricgroup.c:881 #6 metricgroup__add_metric (metric=<optimized out>, metric_no_group=metric_no_group@entry=false, events=<optimized out>, events@entry=0x3ffd84fb878, metric_list=0x0, metric_list@entry=0x3ffd84fb868, map=0x0) at util/metricgroup.c:943 #7 0x00000000011034ae in metricgroup__add_metric_list (map=0x13f9828 <map>, metric_list=0x3ffd84fb868, events=0x3ffd84fb878, metric_no_group=<optimized out>, list=<optimized out>) at util/metricgroup.c:988 #8 parse_groups (perf_evlist=perf_evlist@entry=0x1e70260, str=str@entry=0x12f34b2 "IPC", metric_no_group=<optimized out>, metric_no_merge=<optimized out>, fake_pmu=fake_pmu@entry=0x1462f18 <perf_pmu.fake>, metric_events=0x3ffd84fba58, map=0x1) at util/metricgroup.c:1040 #9 0x0000000001103eb2 in metricgroup__parse_groups_test( evlist=evlist@entry=0x1e70260, map=map@entry=0x13f9828 <map>, str=str@entry=0x12f34b2 "IPC", metric_no_group=metric_no_group@entry=false, metric_no_merge=metric_no_merge@entry=false, metric_events=0x3ffd84fba58) at util/metricgroup.c:1082 #10 0x00000000010c84d8 in __compute_metric (ratio2=0x0, name2=0x0, ratio1=<synthetic pointer>, name1=0x12f34b2 "IPC", vals=0x3ffd84fbad8, name=0x12f34b2 "IPC") at tests/parse-metric.c:159 #11 compute_metric (ratio=<synthetic pointer>, vals=0x3ffd84fbad8, name=0x12f34b2 "IPC") at tests/parse-metric.c:189 #12 test_ipc () at tests/parse-metric.c:208 ..... ..... omitted many more lines This test case was added with commit 218ca91 ("perf tests: Add parse metric test for frontend metric"). When I compile with make DEBUG=y it works fine and I do not get a core dump. It turned out that the above listed function call chain worked on a struct pmu_event array which requires a trailing element with zeroes which was missing. The marco map_for_each_event() loops over that array tests for members metric_expr/metric_name/metric_group being non-NULL. Adding this element fixes the issue. Output after: [root@t35lp46 perf]# ./perf test 67 67: Parse and process metrics : Ok [root@t35lp46 perf]# Committer notes: As Ian remarks, this is not s390 specific: <quote Ian> This also shows up with address sanitizer on all architectures (perhaps change the patch title) and perhaps add a "Fixes: <commit>" tag. ================================================================= ==4718==ERROR: AddressSanitizer: global-buffer-overflow on address 0x55c93b4d59e8 at pc 0x55c93a1541e2 bp 0x7ffd24327c60 sp 0x7ffd24327c58 READ of size 8 at 0x55c93b4d59e8 thread T0 #0 0x55c93a1541e1 in find_metric tools/perf/util/metricgroup.c:764:2 freedreno-zz#1 0x55c93a153e6c in __resolve_metric tools/perf/util/metricgroup.c:844:9 freedreno-zz#2 0x55c93a152f18 in resolve_metric tools/perf/util/metricgroup.c:881:9 freedreno-zz#3 0x55c93a1528db in metricgroup__add_metric tools/perf/util/metricgroup.c:943:9 #4 0x55c93a151996 in metricgroup__add_metric_list tools/perf/util/metricgroup.c:988:9 #5 0x55c93a1511b9 in parse_groups tools/perf/util/metricgroup.c:1040:8 #6 0x55c93a1513e1 in metricgroup__parse_groups_test tools/perf/util/metricgroup.c:1082:9 #7 0x55c93a0108ae in __compute_metric tools/perf/tests/parse-metric.c:159:8 #8 0x55c93a010744 in compute_metric tools/perf/tests/parse-metric.c:189:9 #9 0x55c93a00f5ee in test_ipc tools/perf/tests/parse-metric.c:208:2 #10 0x55c93a00f1e8 in test__parse_metric tools/perf/tests/parse-metric.c:345:2 #11 0x55c939fd7202 in run_test tools/perf/tests/builtin-test.c:410:9 #12 0x55c939fd6736 in test_and_print tools/perf/tests/builtin-test.c:440:9 #13 0x55c939fd58c3 in __cmd_test tools/perf/tests/builtin-test.c:661:4 #14 0x55c939fd4e02 in cmd_test tools/perf/tests/builtin-test.c:807:9 #15 0x55c939e4763d in run_builtin tools/perf/perf.c:313:11 #16 0x55c939e46475 in handle_internal_command tools/perf/perf.c:365:8 #17 0x55c939e4737e in run_argv tools/perf/perf.c:409:2 #18 0x55c939e45f7e in main tools/perf/perf.c:539:3 0x55c93b4d59e8 is located 0 bytes to the right of global variable 'pme_test' defined in 'tools/perf/tests/parse-metric.c:17:25' (0x55c93b4d54a0) of size 1352 SUMMARY: AddressSanitizer: global-buffer-overflow tools/perf/util/metricgroup.c:764:2 in find_metric Shadow bytes around the buggy address: 0x0ab9a7692ae0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ab9a7692af0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ab9a7692b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ab9a7692b10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ab9a7692b20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0ab9a7692b30: 00 00 00 00 00 00 00 00 00 00 00 00 00[f9]f9 f9 0x0ab9a7692b40: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 0x0ab9a7692b50: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 0x0ab9a7692b60: f9 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00 0x0ab9a7692b70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ab9a7692b80: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb Shadow gap: cc </quote> I'm also adding the missing "Fixes" tag and setting just .name to NULL, as doing it that way is more compact (the compiler will zero out everything else) and the table iterators look for .name being NULL as the sentinel marking the end of the table. Fixes: 0a507af ("perf tests: Add parse metric test for ipc metric") Signed-off-by: Thomas Richter <[email protected]> Reviewed-by: Sumanth Korikkar <[email protected]> Acked-by: Ian Rogers <[email protected]> Cc: Heiko Carstens <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Sven Schnelle <[email protected]> Cc: Vasily Gorbik <[email protected]> Link: http://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Sep 30, 2020
The dev_iommu_priv_set() must be called after probe_device(). This fixes a NULL pointer deference bug when booting a system with kernel cmdline "intel_iommu=on,igfx_off", where the dev_iommu_priv_set() is abused. The following stacktrace was produced: Command line: BOOT_IMAGE=/isolinux/bzImage console=tty1 intel_iommu=on,igfx_off ... DMAR: Host address width 39 DMAR: DRHD base: 0x000000fed90000 flags: 0x0 DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap 1c0000c40660462 ecap 19e2ff0505e DMAR: DRHD base: 0x000000fed91000 flags: 0x1 DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap d2008c40660462 ecap f050da DMAR: RMRR base: 0x0000009aa9f000 end: 0x0000009aabefff DMAR: RMRR base: 0x0000009d000000 end: 0x0000009f7fffff DMAR: No ATSR found BUG: kernel NULL pointer dereference, address: 0000000000000038 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [freedreno-zz#1] SMP PTI CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.9.0-devel+ freedreno-zz#2 Hardware name: LENOVO 20HGS0TW00/20HGS0TW00, BIOS N1WET46S (1.25s ) 03/30/2018 RIP: 0010:intel_iommu_init+0xed0/0x1136 Code: fe e9 61 02 00 00 bb f4 ff ff ff e9 57 02 00 00 48 63 d1 48 c1 e2 04 48 03 50 20 48 8b 12 48 85 d2 74 0b 48 8b 92 d0 02 00 00 48 89 7a 38 ff c1 e9 15 f5 ff ff 48 c7 c7 60 99 ac a7 49 c7 c7 a0 RSP: 0000:ffff96d180073dd0 EFLAGS: 00010282 RAX: ffff8c91037a7d20 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffffffffff RBP: ffff96d180073e90 R08: 0000000000000001 R09: ffff8c91039fe3c0 R10: 0000000000000226 R11: 0000000000000226 R12: 000000000000000b R13: ffff8c910367c650 R14: ffffffffa8426d60 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8c9107480000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000038 CR3: 00000004b100a001 CR4: 00000000003706e0 Call Trace: ? _raw_spin_unlock_irqrestore+0x1f/0x30 ? call_rcu+0x10e/0x320 ? trace_hardirqs_on+0x2c/0xd0 ? rdinit_setup+0x2c/0x2c ? e820__memblock_setup+0x8b/0x8b pci_iommu_init+0x16/0x3f do_one_initcall+0x46/0x1e4 kernel_init_freeable+0x169/0x1b2 ? rest_init+0x9f/0x9f kernel_init+0xa/0x101 ret_from_fork+0x22/0x30 Modules linked in: CR2: 0000000000000038 ---[ end trace 3653722a6f936f18 ]--- Fixes: 01b9d4e ("iommu/vt-d: Use dev_iommu_priv_get/set()") Reported-by: Torsten Hilbrich <[email protected]> Reported-by: Wendy Wang <[email protected]> Signed-off-by: Lu Baolu <[email protected]> Tested-by: Torsten Hilbrich <[email protected]> Link: https://lore.kernel.org/linux-iommu/[email protected]/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
robclark
pushed a commit
to freedreno/kernel-msm
that referenced
this issue
Sep 30, 2020
Nikolay reported a lockdep splat in generic/476 that I could reproduce with btrfs/187. ====================================================== WARNING: possible circular locking dependency detected 5.9.0-rc2+ freedreno-zz#1 Tainted: G W ------------------------------------------------------ kswapd0/100 is trying to acquire lock: ffff9e8ef38b6268 (&delayed_node->mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node.part.0+0x3f/0x330 but task is already holding lock: ffffffffa9d74700 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x5/0x30 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> freedreno-zz#2 (fs_reclaim){+.+.}-{0:0}: fs_reclaim_acquire+0x65/0x80 slab_pre_alloc_hook.constprop.0+0x20/0x200 kmem_cache_alloc_trace+0x3a/0x1a0 btrfs_alloc_device+0x43/0x210 add_missing_dev+0x20/0x90 read_one_chunk+0x301/0x430 btrfs_read_sys_array+0x17b/0x1b0 open_ctree+0xa62/0x1896 btrfs_mount_root.cold+0x12/0xea legacy_get_tree+0x30/0x50 vfs_get_tree+0x28/0xc0 vfs_kern_mount.part.0+0x71/0xb0 btrfs_mount+0x10d/0x379 legacy_get_tree+0x30/0x50 vfs_get_tree+0x28/0xc0 path_mount+0x434/0xc00 __x64_sys_mount+0xe3/0x120 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 -> freedreno-zz#1 (&fs_info->chunk_mutex){+.+.}-{3:3}: __mutex_lock+0x7e/0x7e0 btrfs_chunk_alloc+0x125/0x3a0 find_free_extent+0xdf6/0x1210 btrfs_reserve_extent+0xb3/0x1b0 btrfs_alloc_tree_block+0xb0/0x310 alloc_tree_block_no_bg_flush+0x4a/0x60 __btrfs_cow_block+0x11a/0x530 btrfs_cow_block+0x104/0x220 btrfs_search_slot+0x52e/0x9d0 btrfs_lookup_inode+0x2a/0x8f __btrfs_update_delayed_inode+0x80/0x240 btrfs_commit_inode_delayed_inode+0x119/0x120 btrfs_evict_inode+0x357/0x500 evict+0xcf/0x1f0 vfs_rmdir.part.0+0x149/0x160 do_rmdir+0x136/0x1a0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 -> #0 (&delayed_node->mutex){+.+.}-{3:3}: __lock_acquire+0x1184/0x1fa0 lock_acquire+0xa4/0x3d0 __mutex_lock+0x7e/0x7e0 __btrfs_release_delayed_node.part.0+0x3f/0x330 btrfs_evict_inode+0x24c/0x500 evict+0xcf/0x1f0 dispose_list+0x48/0x70 prune_icache_sb+0x44/0x50 super_cache_scan+0x161/0x1e0 do_shrink_slab+0x178/0x3c0 shrink_slab+0x17c/0x290 shrink_node+0x2b2/0x6d0 balance_pgdat+0x30a/0x670 kswapd+0x213/0x4c0 kthread+0x138/0x160 ret_from_fork+0x1f/0x30 other info that might help us debug this: Chain exists of: &delayed_node->mutex --> &fs_info->chunk_mutex --> fs_reclaim Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); lock(&fs_info->chunk_mutex); lock(fs_reclaim); lock(&delayed_node->mutex); *** DEADLOCK *** 3 locks held by kswapd0/100: #0: ffffffffa9d74700 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x5/0x30 freedreno-zz#1: ffffffffa9d65c50 (shrinker_rwsem){++++}-{3:3}, at: shrink_slab+0x115/0x290 freedreno-zz#2: ffff9e8e9da260e0 (&type->s_umount_key#48){++++}-{3:3}, at: super_cache_scan+0x38/0x1e0 stack backtrace: CPU: 1 PID: 100 Comm: kswapd0 Tainted: G W 5.9.0-rc2+ freedreno-zz#1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Call Trace: dump_stack+0x92/0xc8 check_noncircular+0x12d/0x150 __lock_acquire+0x1184/0x1fa0 lock_acquire+0xa4/0x3d0 ? __btrfs_release_delayed_node.part.0+0x3f/0x330 __mutex_lock+0x7e/0x7e0 ? __btrfs_release_delayed_node.part.0+0x3f/0x330 ? __btrfs_release_delayed_node.part.0+0x3f/0x330 ? lock_acquire+0xa4/0x3d0 ? btrfs_evict_inode+0x11e/0x500 ? find_held_lock+0x2b/0x80 __btrfs_release_delayed_node.part.0+0x3f/0x330 btrfs_evict_inode+0x24c/0x500 evict+0xcf/0x1f0 dispose_list+0x48/0x70 prune_icache_sb+0x44/0x50 super_cache_scan+0x161/0x1e0 do_shrink_slab+0x178/0x3c0 shrink_slab+0x17c/0x290 shrink_node+0x2b2/0x6d0 balance_pgdat+0x30a/0x670 kswapd+0x213/0x4c0 ? _raw_spin_unlock_irqrestore+0x46/0x60 ? add_wait_queue_exclusive+0x70/0x70 ? balance_pgdat+0x670/0x670 kthread+0x138/0x160 ? kthread_create_worker_on_cpu+0x40/0x40 ret_from_fork+0x1f/0x30 This is because we are holding the chunk_mutex when we call btrfs_alloc_device, which does a GFP_KERNEL allocation. We don't want to switch that to a GFP_NOFS lock because this is the only place where it matters. So instead use memalloc_nofs_save() around the allocation in order to avoid the lockdep splat. Reported-by: Nikolay Borisov <[email protected]> CC: [email protected] # 4.4+ Reviewed-by: Anand Jain <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I want to apply freedreno to a current kernel provided by the vendor (already fixed and hacked on https://github.com/Icenowy/linux-kernel-u8800-aosc-oses), but I don't think I'm able to port this repo (kernel-msm) to the device, but port the driver back to the kernel.
The text was updated successfully, but these errors were encountered: