From: Jarek Poplawski <jarkao2@o2.pl>
To: Jason Wessel <jason.wessel@windriver.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [BUG] 2.6.21 hang in cancel_rearming_delayed_workqueue()
Date: Fri, 25 May 2007 10:16:31 +0200 [thread overview]
Message-ID: <20070525081631.GB985@ff.dom.local> (raw)
In-Reply-To: <4656564D.5030307@windriver.com>
On 25-05-2007 05:21, Jason Wessel wrote:
> There is a problem with the calling cancel_rearming_delayed_work if the
> timer was not yet active.
>
> I see this problem when netpoll_cleanup() is called without having done
> any work because it had not processed any packets yet. The problem
> appears to be a result of the loop check
> while(!cancel_delayed_work(dwork)). This endlessly loops because
> del_timer_sync() can return 0 or 1 for success which is passed back as a
> result to the final invariant check for the loop. In this particular
> case zero will always be returned because the timer is not active.
>
> It is possible that the problem exists else where, but I thought I would
> ask if this is expected?
>
> #0 del_timer_sync (timer=0xc7ed90f8) at kernel/timer.c:530
> #1 0xc012f08e in cancel_rearming_delayed_workqueue (wq=0xc7fee800,
> dwork=0xc7ed90e8) at include/linux/workqueue.h:201
> #2 0xc012f0af in cancel_rearming_delayed_work (dwork=0x20)
> at kernel/workqueue.c:680
> #3 0xc0312f78 in netpoll_cleanup (np=0xc880bf40) at net/core/netpoll.c:784
>
> Possible fix.
>
> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
>
> Index: linux-2.6.21/kernel/workqueue.c
> ===================================================================
> --- linux-2.6.21.orig/kernel/workqueue.c
> +++ linux-2.6.21/kernel/workqueue.c
> @@ -666,7 +666,7 @@ EXPORT_SYMBOL(flush_scheduled_work);
> void cancel_rearming_delayed_workqueue(struct workqueue_struct *wq,
> struct delayed_work *dwork)
> {
> - while (!cancel_delayed_work(dwork))
> + while (cancel_delayed_work(dwork) > 0)
> flush_workqueue(wq);
> }
> EXPORT_SYMBOL(cancel_rearming_delayed_workqueue);
It's very optimistic change...
I wonder, how this all could work so long (or how it is supposed
to work now without breaking other callers) with (almost) reversed
condition?
According to this comment:
" * cancel_rearming_delayed_workqueue - reliably kill off a delayed
work whose handler rearms the delayed work."
So, it cannot be used in netpoll_cleanup() if there is no rearming
during this cancel at all. This is a tricky behaviour of course,
and is changed in 2.6.22-rc.
Regards,
Jarek P.
next prev parent reply other threads:[~2007-05-25 8:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-25 3:21 [BUG] 2.6.21 hang in cancel_rearming_delayed_workqueue() Jason Wessel
2007-05-25 8:16 ` Jarek Poplawski [this message]
2007-05-25 13:21 ` Jason Wessel
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=20070525081631.GB985@ff.dom.local \
--to=jarkao2@o2.pl \
--cc=jason.wessel@windriver.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