From: Bob Bell <b_lkml@thebellsplace.com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@osdl.org>,
trond@netapp.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] TASK_KILLABLE version 2
Date: Mon, 24 Sep 2007 16:16:48 -0400 [thread overview]
Message-ID: <20070924201648.GA6850@newbie.thebellsplace.net> (raw)
In-Reply-To: <20070902024348.GJ14130@parisc-linux.org>
On Sat, Sep 01, 2007 at 08:43:49PM -0600, Matthew Wilcox wrote:
> Here's the second version of TASK_KILLABLE. A few changes since version 1:
<snip>
> I obviously haven't covered every place that can result in a process
> sleeping uninterruptibly while attempting an operation. But sync_page
> (patch 4/5) covers about 90% of the times I've attempted to kill cat,
> and I hope that by providing the two examples, I can help other people
> to fix the cases that they find interesting.
I've been testing this patch on my systems. It's working for me when
I read() a file. Asynchronous write()s seem okay, too. However,
synchronous writes (caused by either calling fsync() or fcntl() to
release a lock) prevent the process from being killed when the NFS
server goes down.
When the process is sent SIGKILL, it's waiting with the following call
tree:
do_fsync
nfs_fsync
nfs_wb_all
nfs_sync_mapping_wait
nfs_wait_on_requests_locks (I believe)
nfs_wait_on_request
out_of_line_wait_on_bit
__wait_on_bit
nfs_wait_bit_interruptible
schedule
When the process is later viewed after being deemed "stuck", it's
waiting with the following call tree:
do_fsync
filemap_fdatawait
wait_on_page_writeback_range
wait_on_page_writeback
wait_on_page_bit
__wait_on_bit
sync_page
io_schedule
schedule
If I hazard a guess as to what might be wrong here, I believe that when
the processes catches SIGKILL, nfs_wait_bit_interruptible is returning
-ERESTARTSYS. That error bubbles back up to nfs_fsync. However,
nfs_fsync returns ctx->error, not -ERESTARTSYS, and ctx->error is 0.
do_fsync proceeds to call filemap_fdatawait. I question whether
nfs_sync should return an error, and if do_fsync should skip
filemap_fdatawait if the fsync op returned an error.
I did try replacing the call to sync_page in __wait_on_bit with
sync_page_killable and replacing TASK_UNINTERRUPTIBLE with
TASK_KILLABLE. That seemed to work once, but then really screwed things
up on subsequent attempts.
--
Bob Bell
next prev parent reply other threads:[~2007-09-24 20:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-02 2:43 [PATCH] TASK_KILLABLE version 2 Matthew Wilcox
2007-09-02 2:46 ` [PATCH 1/5] Use wake_up_locked() in eventpoll Matthew Wilcox
2007-09-02 2:46 ` [PATCH 2/5] Use macros instead of TASK_ flags Matthew Wilcox
2007-09-02 2:54 ` Matthew Wilcox
2007-09-02 3:35 ` Daniel Walker
2007-09-02 4:05 ` Matthew Wilcox
2007-09-03 21:03 ` Matthew Wilcox
2007-09-02 2:46 ` [PATCH 3/5] Add TASK_WAKEKILL Matthew Wilcox
2007-09-02 2:46 ` [PATCH 4/5] Add lock_page_killable Matthew Wilcox
2007-09-02 2:46 ` [PATCH 5/5] Make wait_on_retry_sync_kiocb killable Matthew Wilcox
2007-09-24 20:16 ` Bob Bell [this message]
2007-09-26 11:57 ` [PATCH] TASK_KILLABLE version 2 Ric Wheeler
2007-09-27 21:47 ` Nick Piggin
2007-12-07 1:49 ` Matthew Wilcox
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=20070924201648.GA6850@newbie.thebellsplace.net \
--to=b_lkml@thebellsplace.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=torvalds@osdl.org \
--cc=trond@netapp.com \
/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).