From: bugzilla-daemon@bugzilla.kernel.org
To: linux-xfs@kernel.org
Subject: [Bug 200835] New: XFS hangs in xfs_reclaim_inode()
Date: Thu, 16 Aug 2018 16:03:18 +0000 [thread overview]
Message-ID: <bug-200835-201763@https.bugzilla.kernel.org/> (raw)
https://bugzilla.kernel.org/show_bug.cgi?id=200835
Bug ID: 200835
Summary: XFS hangs in xfs_reclaim_inode()
Product: File System
Version: 2.5
Kernel Version: 4.14.62
Hardware: Intel
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: XFS
Assignee: filesystem_xfs@kernel-bugs.kernel.org
Reporter: peter.klotz99@gmail.com
Regression: No
Created attachment 277895
--> https://bugzilla.kernel.org/attachment.cgi?id=277895&action=edit
Hang of kernel 4.14.62
The attached file shows backtraces that occur in quick succession and
ultimately lead to a complete server hang.
The backtraces seem related to inode reclamation.
For example the first backtrace:
Aug 16 02:33:30 hpmicroserver kernel: INFO: task khugepaged:28 blocked for more
than 120 seconds.
Aug 16 02:33:30 hpmicroserver kernel: Not tainted 4.14.62-1-lts #1
Aug 16 02:33:30 hpmicroserver kernel: "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Aug 16 02:33:30 hpmicroserver kernel: khugepaged D 0 28 2
0x80000000
Aug 16 02:33:30 hpmicroserver kernel: Call Trace:
Aug 16 02:33:30 hpmicroserver kernel: ? __schedule+0x284/0x860
Aug 16 02:33:30 hpmicroserver kernel: schedule+0x28/0x80
Aug 16 02:33:30 hpmicroserver kernel: schedule_timeout+0x292/0x370
Aug 16 02:33:30 hpmicroserver kernel: ? check_preempt_curr+0x62/0x90
Aug 16 02:33:30 hpmicroserver kernel: wait_for_completion+0xaf/0x140
Aug 16 02:33:30 hpmicroserver kernel: ? wake_up_q+0x70/0x70
Aug 16 02:33:30 hpmicroserver kernel: flush_work+0x116/0x1d0
Aug 16 02:33:30 hpmicroserver kernel: ? worker_detach_from_pool+0xa0/0xa0
Aug 16 02:33:30 hpmicroserver kernel: xlog_cil_force_lsn+0x78/0x210 [xfs]
Aug 16 02:33:30 hpmicroserver kernel: ? enqueue_task_fair+0x5a/0x500
Aug 16 02:33:30 hpmicroserver kernel: ? native_sched_clock+0x37/0x90
Aug 16 02:33:30 hpmicroserver kernel: ? __switch_to_asm+0x40/0x70
Aug 16 02:33:30 hpmicroserver kernel: _xfs_log_force_lsn+0x71/0x340 [xfs]
Aug 16 02:33:30 hpmicroserver kernel: ? try_to_wake_up+0x54/0x4b0
Aug 16 02:33:30 hpmicroserver kernel: ? update_group_capacity+0x27/0x1e0
Aug 16 02:33:30 hpmicroserver kernel: ? xfs_reclaim_inode+0xe3/0x340 [xfs]
Aug 16 02:33:30 hpmicroserver kernel: __xfs_iunpin_wait+0xa7/0x160 [xfs]
Aug 16 02:33:30 hpmicroserver kernel: ? bit_waitqueue+0x30/0x30
Aug 16 02:33:30 hpmicroserver kernel: xfs_reclaim_inode+0xe3/0x340 [xfs]
Aug 16 02:33:30 hpmicroserver kernel: xfs_reclaim_inodes_ag+0x1b1/0x300 [xfs]
Aug 16 02:33:30 hpmicroserver kernel: xfs_reclaim_inodes_nr+0x31/0x40 [xfs]
Aug 16 02:33:30 hpmicroserver kernel: super_cache_scan+0x152/0x1a0
Aug 16 02:33:30 hpmicroserver kernel: shrink_slab.part.45+0x1e8/0x3c0
Aug 16 02:33:30 hpmicroserver kernel: shrink_node+0x123/0x310
Aug 16 02:33:30 hpmicroserver kernel: do_try_to_free_pages+0xc3/0x330
Aug 16 02:33:30 hpmicroserver kernel: try_to_free_pages+0xf4/0x1b0
Aug 16 02:33:30 hpmicroserver kernel: __alloc_pages_slowpath+0x3e4/0xd80
Aug 16 02:33:30 hpmicroserver kernel: ? __switch_to+0x170/0x4b0
Aug 16 02:33:30 hpmicroserver kernel: ? __switch_to_asm+0x34/0x70
Aug 16 02:33:30 hpmicroserver kernel: ? __switch_to_asm+0x34/0x70
Aug 16 02:33:30 hpmicroserver kernel: ? __switch_to_asm+0x40/0x70
Aug 16 02:33:30 hpmicroserver kernel: __alloc_pages_nodemask+0x226/0x240
Aug 16 02:33:30 hpmicroserver kernel: khugepaged_alloc_page+0x17/0x50
Aug 16 02:33:30 hpmicroserver kernel: khugepaged+0xbcb/0x2120
Aug 16 02:33:30 hpmicroserver kernel: ? wait_woken+0x80/0x80
Aug 16 02:33:30 hpmicroserver kernel: ? collapse_shmem+0xb90/0xb90
Aug 16 02:33:30 hpmicroserver kernel: kthread+0x119/0x130
Aug 16 02:33:30 hpmicroserver kernel: ? __kthread_parkme+0xa0/0xa0
Aug 16 02:33:30 hpmicroserver kernel: ret_from_fork+0x22/0x40
The problem has occurred twice so far. Once in kernel 4.14.52 and once in
4.14.62. I am using the Arch Linux LTS kernel so it is more or less the vanilla
kernel.
The server has two XFS filesystems. One is a 30TB XFS/LUKS/RAID setup, the
other one is a plain 4TB XFS volume.
--
You are receiving this mail because:
You are watching the assignee of the bug.
next reply other threads:[~2018-08-16 19:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-16 16:03 bugzilla-daemon [this message]
2018-08-16 16:04 ` [Bug 200835] XFS hangs in xfs_reclaim_inode() bugzilla-daemon
2018-08-17 2:36 ` bugzilla-daemon
2018-08-17 5:32 ` bugzilla-daemon
2018-08-17 5:34 ` bugzilla-daemon
2018-08-17 8:43 ` bugzilla-daemon
2018-08-17 11:55 ` bugzilla-daemon
2018-08-17 13:06 ` bugzilla-daemon
2018-08-17 13:25 ` bugzilla-daemon
2018-08-17 14:04 ` bugzilla-daemon
2018-08-17 14:06 ` bugzilla-daemon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-200835-201763@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@bugzilla.kernel.org \
--cc=linux-xfs@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).