From: Oleg Nesterov <oleg@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Mandeep Singh Baines <msb@chromium.org>,
Neil Horman <nhorman@redhat.com>,
"Rafael J. Wysocki" <rjw@sisk.pl>, Tejun Heo <tj@kernel.org>,
linux-kernel@vger.kernel.org
Subject: [PATCH 3/3] coredump: change wait_for_dump_helpers() to use wait_event_interruptible()
Date: Fri, 8 Mar 2013 18:59:20 +0100 [thread overview]
Message-ID: <20130308175920.GA26332@redhat.com> (raw)
In-Reply-To: <20130308175852.GA26300@redhat.com>
wait_for_dump_helpers() calls wake_up/kill_fasync from inside the
wait_event-like loop. This is not needed and in fact this is not
strictly correct, we can/should do this only once after we change
pipe->writers. We could even check if it becomes zero.
Change this code to use use wait_event_interruptible(), this can
also help to make this wait freezable.
With this patch we check pipe->readers without pipe_lock(), this
is fine. Once we see pipe->readers == 1 we know that the handler
decremented the counter, this is all we need.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
---
fs/coredump.c | 15 +++++++++------
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/fs/coredump.c b/fs/coredump.c
index 477f393..667413c 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -439,17 +439,20 @@ static void wait_for_dump_helpers(struct file *file)
pipe_lock(pipe);
pipe->readers++;
pipe->writers--;
+ wake_up_interruptible_sync(&pipe->wait);
+ kill_fasync(&pipe->fasync_readers, SIGIO, POLL_IN);
+ pipe_unlock(pipe);
- while ((pipe->readers > 1) && (!signal_pending(current))) {
- wake_up_interruptible_sync(&pipe->wait);
- kill_fasync(&pipe->fasync_readers, SIGIO, POLL_IN);
- pipe_wait(pipe);
- }
+ /*
+ * We actually want wait_event_freezable() but then we need
+ * to clear TIF_SIGPENDING and improve dump_interrupted().
+ */
+ wait_event_interruptible(pipe->wait, pipe->readers == 1);
+ pipe_lock(pipe);
pipe->readers--;
pipe->writers++;
pipe_unlock(pipe);
-
}
/*
--
1.5.5.1
next prev parent reply other threads:[~2013-03-08 18:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-08 17:58 [PATCH -mm 0/3] coredump: signal_pending() checks and cleanups Oleg Nesterov
2013-03-08 17:59 ` [PATCH 1/3] coredump: introduce dump_interrupted() Oleg Nesterov
2013-03-08 20:54 ` Mandeep Singh Baines
2013-03-09 18:48 ` Oleg Nesterov
2013-03-08 21:20 ` Andrew Morton
2013-03-09 19:16 ` Oleg Nesterov
2013-03-08 17:59 ` [PATCH 2/3] coredump: factor out the setting of PF_DUMPCORE Oleg Nesterov
2013-03-08 20:21 ` Mandeep Singh Baines
2013-03-08 17:59 ` Oleg Nesterov [this message]
2013-03-08 20:22 ` [PATCH 3/3] coredump: change wait_for_dump_helpers() to use wait_event_interruptible() Mandeep Singh Baines
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=20130308175920.GA26332@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=msb@chromium.org \
--cc=nhorman@redhat.com \
--cc=rjw@sisk.pl \
--cc=tj@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