From: Simon Kirby <sim@hostway.ca>
To: Andi Kleen <ak@linux.intel.com>
Cc: linux-kernel@vger.kernel.org
Subject: Hung task detector versus NFS (TASK_KILLABLE)
Date: Mon, 7 Mar 2016 15:59:44 -0800 [thread overview]
Message-ID: <20160307235944.GD15986@hostway.ca> (raw)
Hello!
Back in 2008, you committed 316d9679f33caf7e683471647d1472bfe133d858
which changed softlockup.c (now moved to hung_task.c) to avoid logging a
spew of soft lockup warnings when the Ethernet cable is unplugged with
active NFS mounts.
Meanwhile, I've been seeing hung task warnings like this for years, so I
wondered what the deal is. It seems there are VFS paths that can enter
uninterruptible sleep as result of locks held in interruptible sleep.
For example, I can reproduce hung task warnings by firewalling NFS, then
"cat a" twice: the second hangs in mutex_lock() from path_openat(), which
then spews a hung task warning.
I write this because I would actually find it useful to see the original
backtrace, even if it is interruptible, not just the collateral damage.
Since the "skipping" of NFS is basically incomplete anyway, how big a
deal is this "feature"?
Would anybody object if we just returned this to anything blocked?
The lines in question these days are here in kernel/hung_task.c:
/* use "==" to skip the TASK_KILLABLE tasks waiting on NFS */
if (t->state == TASK_UNINTERRUPTIBLE)
check_hung_task(t, timeout);
It used to be t->state & TASK_UNINTERRUPTIBLE.
Simon-
next reply other threads:[~2016-03-08 0:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-07 23:59 Simon Kirby [this message]
2016-03-08 3:11 ` Hung task detector versus NFS (TASK_KILLABLE) Andi Kleen
2016-03-09 20:23 ` Simon Kirby
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=20160307235944.GD15986@hostway.ca \
--to=sim@hostway.ca \
--cc=ak@linux.intel.com \
--cc=linux-kernel@vger.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