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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.