From: Andrew Morton <akpm@osdl.org>
To: Roland Dreier <roland@topspin.com>
Cc: jstubbs@work-at.co.jp, linux-kernel@vger.kernel.org
Subject: Re: PROBLEM: Consistent lock up on >=2.6.8
Date: Mon, 4 Oct 2004 20:51:36 -0700 [thread overview]
Message-ID: <20041004205136.49317eb7.akpm@osdl.org> (raw)
In-Reply-To: <52brfhvs46.fsf@topspin.com>
Roland Dreier <roland@topspin.com> wrote:
>
> @@ -2375,7 +2372,7 @@ void ip_vs_control_cleanup(void)
> {
> EnterFunction(2);
> ip_vs_trash_cleanup();
> - del_timer_sync(&defense_timer);
> + cancel_delayed_work(&defense_work);
>
> Do we need a flush_scheduled_work() here to be totally safe? Not sure
> if it could ever really happen but it seems the module could at least
> theoretically be unloaded with update_defense_level() still running...
Excellent point. We don't appear to have a function which does that.
How does this look?
(It's probably wrong, actually. THis stuff's tricky. In particular, the
work handler *has* to re-add the delayed work, 100% of the time.)
Add library functions to reliably kill off a delayed work whose handler
re-adds the delayed work. One for keventd, one for caller-owned workqueues.
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
25-akpm/include/linux/workqueue.h | 3 +++
25-akpm/kernel/workqueue.c | 25 +++++++++++++++++++++++++
2 files changed, 28 insertions(+)
diff -puN kernel/workqueue.c~cancel_rearming_delayed_work kernel/workqueue.c
--- 25/kernel/workqueue.c~cancel_rearming_delayed_work 2004-10-04 20:48:23.397238464 -0700
+++ 25-akpm/kernel/workqueue.c 2004-10-04 20:48:23.402237704 -0700
@@ -423,6 +423,31 @@ void flush_scheduled_work(void)
flush_workqueue(keventd_wq);
}
+/**
+ * cancel_rearming_delayed_workqueue - reliably kill off a delayed
+ * work whose handler rearms the delayed work.
+ * @wq: the controlling workqueue structure
+ * @work: the delayed work struct
+ */
+void cancel_rearming_delayed_workqueue(struct workqueue_struct *wq,
+ struct work_struct *work)
+{
+ while (!cancel_delayed_work(work))
+ flush_workqueue(wq);
+}
+EXPORT_SYMBOL(cancel_rearming_delayed_workqueue);
+
+/**
+ * cancel_rearming_delayed_work - reliably kill off a delayed keventd
+ * work whose handler rearms the delayed work.
+ * @work: the delayed work struct
+ */
+void cancel_rearming_delayed_work(struct work_struct *work)
+{
+ cancel_rearming_delayed_workqueue(keventd_wq, work);
+}
+EXPORT_SYMBOL(cancel_rearming_delayed_work);
+
int keventd_up(void)
{
return keventd_wq != NULL;
diff -puN include/linux/workqueue.h~cancel_rearming_delayed_work include/linux/workqueue.h
--- 25/include/linux/workqueue.h~cancel_rearming_delayed_work 2004-10-04 20:48:23.398238312 -0700
+++ 25-akpm/include/linux/workqueue.h 2004-10-04 20:48:23.403237552 -0700
@@ -70,6 +70,9 @@ extern int current_is_keventd(void);
extern int keventd_up(void);
extern void init_workqueues(void);
+void cancel_rearming_delayed_workqueue(struct workqueue_struct *wq,
+ struct work_struct *work);
+void cancel_rearming_delayed_work(struct work_struct *work);
/*
* Kill off a pending schedule_delayed_work(). Note that the work callback
_
next prev parent reply other threads:[~2004-10-05 3:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-04 7:11 PROBLEM: Consistent lock up on >=2.6.8 Jason Stubbs
2004-10-04 8:35 ` Andrew Morton
2004-10-04 10:31 ` Jason Stubbs
2004-10-04 19:05 ` Andrew Morton
2004-10-05 1:53 ` Jason Stubbs
2004-10-05 1:58 ` Andrew Morton
2004-10-05 4:17 ` Jason Stubbs
2004-10-29 15:08 ` RESEND: Consistent lock up 2.6.8-1.521 (and 2.6.8.1 w/ high-res-timers/skas/sysemu) Andrew A.
2004-10-29 15:22 ` Andrew A.
2004-10-29 15:23 ` Andrew A.
2004-10-05 2:03 ` PROBLEM: Consistent lock up on >=2.6.8 Roland Dreier
2004-10-05 3:51 ` Andrew Morton [this message]
2004-10-05 4:05 ` Roland Dreier
2004-11-25 1:03 ` Jason Stubbs
-- strict thread matches above, loose matches on Subject: below --
2004-12-06 8:30 Chris Caputo
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=20041004205136.49317eb7.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=jstubbs@work-at.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@topspin.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 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.