[ 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
This is btrfs which is pretty far down on our priority list. This is best reported to the upstream btrfs devs.
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/
The fix seems is already merged to master branch so probably next kernel package will not have this issue. I'm closing this ticket.
No .. wrong. Fix still is not merged. Reopening.
This can be cosed now.