Bug 1547319

Summary: 4.16.0-0.rc1.git4.1.fc28.x86_64 #1 Not tainted: possible recursive locking detected
Product: [Fedora] Fedora Reporter: Tomasz Kłoczko <kloczko.tomasz>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: airlied, bskeggs, ewk, hdegoede, ichavero, itamar, jarodwilson, jglisse, john.j5live, jonathan, josef, kernel-maint, labbott, linville, mchehab, mjg59, steved
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-09-23 11:57:40 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tomasz Kłoczko 2018-02-21 00:26:17 UTC 
[ 1985.310136] ============================================
[ 1985.310137] WARNING: possible recursive locking detected
[ 1985.310140] 4.16.0-0.rc1.git4.1.fc28.x86_64 #1 Not tainted
[ 1985.310142] --------------------------------------------
[ 1985.310144] php-fpm/1650 is trying to acquire lock:
[ 1985.310146]  (fs_reclaim){+.+.}, at: [<00000000218239d6>] fs_reclaim_acquire.part.75+0x5/0x30
[ 1985.310156] 
               but task is already holding lock:
[ 1985.310158]  (fs_reclaim){+.+.}, at: [<00000000218239d6>] fs_reclaim_acquire.part.75+0x5/0x30
[ 1985.310164] 
               other info that might help us debug this:
[ 1985.310166]  Possible unsafe locking scenario:

[ 1985.310168]        CPU0
[ 1985.310170]        ----
[ 1985.310171]   lock(fs_reclaim);
[ 1985.310174]   lock(fs_reclaim);
[ 1985.310176] 
                *** DEADLOCK ***

[ 1985.310179]  May be due to missing lock nesting notation

[ 1985.310182] 2 locks held by php-fpm/1650:
[ 1985.310183]  #0:  (&mm->mmap_sem){++++}, at: [<00000000a8a1839b>] __do_page_fault+0x17a/0x530
[ 1985.310190]  #1:  (fs_reclaim){+.+.}, at: [<00000000218239d6>] fs_reclaim_acquire.part.75+0x5/0x30
[ 1985.310196] 
               stack backtrace:
[ 1985.310200] CPU: 3 PID: 1650 Comm: php-fpm Not tainted 4.16.0-0.rc1.git4.1.fc28.x86_64 #1
[ 1985.310202] Hardware name: Sony Corporation VPCSB2M9E/VAIO, BIOS R2087H4 06/15/2012
[ 1985.310204] Call Trace:
[ 1985.310211]  dump_stack+0x85/0xbf
[ 1985.310216]  __lock_acquire.cold.62+0xaf/0x227
[ 1985.310221]  ? __bfs+0x118/0x230
[ 1985.310225]  ? __lock_acquire+0x1033/0x16d0
[ 1985.310229]  ? lock_acquire+0x9e/0x1b0
[ 1985.310233]  ? fs_reclaim_acquire.part.75+0x5/0x30
[ 1985.310265]  ? alloc_extent_state+0x1e/0x180 [btrfs]
[ 1985.310269]  ? fs_reclaim_acquire.part.75+0x29/0x30
[ 1985.310272]  ? fs_reclaim_acquire.part.75+0x5/0x30
[ 1985.310275]  ? kmem_cache_alloc+0x29/0x2f0
[ 1985.310299]  ? alloc_extent_state+0x1e/0x180 [btrfs]
[ 1985.310323]  ? __clear_extent_bit+0x2c0/0x3c0 [btrfs]
[ 1985.310348]  ? try_release_extent_mapping+0x198/0x210 [btrfs]
[ 1985.310370]  ? __btrfs_releasepage+0x30/0xc0 [btrfs]
[ 1985.310375]  ? shrink_page_list+0x993/0xe90
[ 1985.310380]  ? shrink_inactive_list+0x1f0/0x6d0
[ 1985.310386]  ? shrink_node_memcg+0x1fd/0x780
[ 1985.310391]  ? native_sched_clock+0x3e/0xa0
[ 1985.310397]  ? shrink_node+0x11c/0x320
[ 1985.310402]  ? do_try_to_free_pages+0xc9/0x350
[ 1985.310406]  ? try_to_free_pages+0x140/0x380
[ 1985.310410]  ? __alloc_pages_slowpath+0x477/0x10a0
[ 1985.310416]  ? __alloc_pages_nodemask+0x3a8/0x430
[ 1985.310421]  ? do_huge_pmd_anonymous_page+0x126/0x7d0
[ 1985.310425]  ? __handle_mm_fault+0xe88/0x1290
[ 1985.310430]  ? handle_mm_fault+0x161/0x350
[ 1985.310433]  ? __do_page_fault+0x271/0x530
[ 1985.310436]  ? do_page_fault+0x32/0x2a0
[ 1985.310439]  ? page_fault+0x65/0x80
[ 1985.310442]  ? page_fault+0x7b/0x80
Comment 1 Laura Abbott 2018-02-21 16:22:18 UTC 
This is btrfs which is pretty far down on our priority list. This is best reported to the upstream btrfs devs.
Comment 2 Tomasz Kłoczko 2018-02-23 10:16:47 UTC 
FYI. I had the reply from btrfs guys and this is not btrfs bug.

Here is the whole thread with one line fix of this issue:

https://patchwork.kernel.org/patch/10207013/
Comment 3 Tomasz Kłoczko 2018-02-23 10:22:07 UTC 
The fix seems is already merged to master branch so probably next kernel package will not have this issue.
I'm closing this ticket.
Comment 4 Tomasz Kłoczko 2018-02-23 10:25:45 UTC 
No .. wrong. Fix still is not merged.
Reopening.
Comment 5 Tomasz Kłoczko 2018-09-23 11:57:40 UTC 
This can be cosed now.