| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <8b63c825-5149-1d5c-0895-c4a6f5525712@osg.samsung.com>
Date: Fri, 8 Dec 2017 15:58:33 -0700
From: Shuah Khan <shuahkh@....samsung.com>
To: Hans Verkuil <hverkuil@...all.nl>, mchehab@...nel.org,
hansverk@...co.com, kgene@...nel.org, krzk@...nel.org,
s.nawrocki@...sung.com, shailendra.v@...sung.com, shuah@...nel.org,
Julia.Lawall@...6.fr, kyungmin.park@...sung.com, kamil@...as.org,
jtp.park@...sung.com, a.hajda@...sung.com
Cc: linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
Shuah Khan <shuahkh@....samsung.com>
Subject: Re: [PATCH v2 1/2] media: exynos-gsc: fix lockdep warning
On 11/07/2017 09:53 AM, Shuah Khan wrote:
> On 10/16/2017 09:18 AM, Hans Verkuil wrote:
>> On 10/16/2017 05:16 PM, Shuah Khan wrote:
>>> The driver mmap functions shouldn't take lock when calling vb2_mmap().
>>> Fix it to not take the lock.
>>>
>>> Reference: commit log for f035eb4e976ef5a059e30bc91cfd310ff030a7d3
>>> and e752577ed7bf55c81e10343fced8b378cda2b63b
>>>
>>> The following lockdep warning is fixed with this change.
>>>
>>> [ 1990.972058] ======================================================
>>> [ 1990.978172] WARNING: possible circular locking dependency detected
>>> [ 1990.984327] 4.14.0-rc2-00002-gfab205f-dirty #4 Not tainted
>>> [ 1990.989783] ------------------------------------------------------
>>> [ 1990.995937] qtdemux0:sink/2765 is trying to acquire lock:
>>> [ 1991.001309] (&gsc->lock){+.+.}, at: [<bf1729f0>] gsc_m2m_mmap+0x24/0x5c [exynos_gsc]
>>> [ 1991.009108]
>>> but task is already holding lock:
>>> [ 1991.014913] (&mm->mmap_sem){++++}, at: [<c01df2e4>] vm_mmap_pgoff+0x44/0xb8
>>> [ 1991.021932]
>>> which lock already depends on the new lock.
>>>
>>> [ 1991.030078]
>>> the existing dependency chain (in reverse order) is:
>>> [ 1991.037530]
>>> -> #1 (&mm->mmap_sem){++++}:
>>> [ 1991.042913] __might_fault+0x80/0xb0
>>> [ 1991.047096] video_usercopy+0x1cc/0x510 [videodev]
>>> [ 1991.052297] v4l2_ioctl+0xa4/0xdc [videodev]
>>> [ 1991.057036] do_vfs_ioctl+0xa0/0xa18
>>> [ 1991.061102] SyS_ioctl+0x34/0x5c
>>> [ 1991.064834] ret_fast_syscall+0x0/0x28
>>> [ 1991.069072]
>>> -> #0 (&gsc->lock){+.+.}:
>>> [ 1991.074193] lock_acquire+0x6c/0x88
>>> [ 1991.078179] __mutex_lock+0x68/0xa34
>>> [ 1991.082247] mutex_lock_interruptible_nested+0x1c/0x24
>>> [ 1991.087888] gsc_m2m_mmap+0x24/0x5c [exynos_gsc]
>>> [ 1991.093029] v4l2_mmap+0x54/0x88 [videodev]
>>> [ 1991.097673] mmap_region+0x3a8/0x638
>>> [ 1991.101743] do_mmap+0x330/0x3a4
>>> [ 1991.105470] vm_mmap_pgoff+0x90/0xb8
>>> [ 1991.109542] SyS_mmap_pgoff+0x90/0xc0
>>> [ 1991.113702] ret_fast_syscall+0x0/0x28
>>> [ 1991.117945]
>>> other info that might help us debug this:
>>>
>>> [ 1991.125918] Possible unsafe locking scenario:
>>>
>>> [ 1991.131810] CPU0 CPU1
>>> [ 1991.136315] ---- ----
>>> [ 1991.140821] lock(&mm->mmap_sem);
>>> [ 1991.144201] lock(&gsc->lock);
>>> [ 1991.149833] lock(&mm->mmap_sem);
>>> [ 1991.155725] lock(&gsc->lock);
>>> [ 1991.158845]
>>> *** DEADLOCK ***
>>>
>>> [ 1991.164740] 1 lock held by qtdemux0:sink/2765:
>>> [ 1991.169157] #0: (&mm->mmap_sem){++++}, at: [<c01df2e4>] vm_mmap_pgoff+0x44/0xb8
>>> [ 1991.176609]
>>> stack backtrace:
>>> [ 1991.180946] CPU: 2 PID: 2765 Comm: qtdemux0:sink Not tainted 4.14.0-rc2-00002-gfab205f-dirty #4
>>> [ 1991.189608] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>>> [ 1991.195686] [<c01102c8>] (unwind_backtrace) from [<c010cabc>] (show_stack+0x10/0x14)
>>> [ 1991.203393] [<c010cabc>] (show_stack) from [<c08543a4>] (dump_stack+0x98/0xc4)
>>> [ 1991.210586] [<c08543a4>] (dump_stack) from [<c016b2fc>] (print_circular_bug+0x254/0x410)
>>> [ 1991.218644] [<c016b2fc>] (print_circular_bug) from [<c016c580>] (check_prev_add+0x468/0x938)
>>> [ 1991.227049] [<c016c580>] (check_prev_add) from [<c016f4dc>] (__lock_acquire+0x1314/0x14fc)
>>> [ 1991.235281] [<c016f4dc>] (__lock_acquire) from [<c016fefc>] (lock_acquire+0x6c/0x88)
>>> [ 1991.242993] [<c016fefc>] (lock_acquire) from [<c0869fb4>] (__mutex_lock+0x68/0xa34)
>>> [ 1991.250620] [<c0869fb4>] (__mutex_lock) from [<c086aa08>] (mutex_lock_interruptible_nested+0x1c/0x24)
>>> [ 1991.259812] [<c086aa08>] (mutex_lock_interruptible_nested) from [<bf1729f0>] (gsc_m2m_mmap+0x24/0x5c [exynos_gsc])
>>> [ 1991.270159] [<bf1729f0>] (gsc_m2m_mmap [exynos_gsc]) from [<bf037120>] (v4l2_mmap+0x54/0x88 [videodev])
>>> [ 1991.279510] [<bf037120>] (v4l2_mmap [videodev]) from [<c01f4798>] (mmap_region+0x3a8/0x638)
>>> [ 1991.287792] [<c01f4798>] (mmap_region) from [<c01f4d58>] (do_mmap+0x330/0x3a4)
>>> [ 1991.294986] [<c01f4d58>] (do_mmap) from [<c01df330>] (vm_mmap_pgoff+0x90/0xb8)
>>> [ 1991.302178] [<c01df330>] (vm_mmap_pgoff) from [<c01f28cc>] (SyS_mmap_pgoff+0x90/0xc0)
>>> [ 1991.309977] [<c01f28cc>] (SyS_mmap_pgoff) from [<c0108820>] (ret_fast_syscall+0x0/0x28)
>>>
>>> Signed-off-by: Shuah Khan <shuahkh@....samsung.com>
>>> Suggested-by: Hans Verkuil <hansverk@...co.com>
>>> Acked-by: Marek Szyprowski <m.szyprowski@...sung.com>
>>
>> Acked-by: Hans Verkuil <hansverk@...co.com>
>>
>> Regards,
>>
>> Hans
>
> Hi Mauro,
>
> Are you planning to take this in for 4.15-rc1? This patch is applicable
> to stable as well.
>
> thanks,
> -- Shuah
>
Hi Mauro,
Doesn't look like this fox made it into 4.15-rc2 - do you plan to get this
into 4.15 at some point?
I am seeing this lockdep warning in 4.15-rc2
thanks,
-- Shuah
Powered by blists - more mailing lists