From: Anton Vorontsov <cbou@mail.ru>
To: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Jarek Poplawski <jarkao2@o2.pl>,
Andrew Morton <akpm@linux-foundation.org>,
David Chinner <dgc@sgi.com>, David Howells <dhowells@redhat.com>,
Gautham Shenoy <ego@in.ibm.com>, Ingo Molnar <mingo@elte.hu>,
Srivatsa Vaddagiri <vatsa@in.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] make-cancel_rearming_delayed_work-reliable-fix
Date: Mon, 7 May 2007 15:55:11 +0400 [thread overview]
Message-ID: <20070507115511.GA10367@zarina> (raw)
In-Reply-To: <20070507103420.GA74@tv-sign.ru>
On Mon, May 07, 2007 at 02:34:20PM +0400, Oleg Nesterov wrote:
> On 05/07, Jarek Poplawski wrote:
> >
> > There is a lot of new things in the final version of this
> > patch. I guess, there was no such problem in the previous
> > version.
>
> No, this is basically the same patch + re-check-cwq-after-lock,
> the latter is mostly needed to prevent racing with CPU-hotplug.
>
> > I can also see you have new doubts about usefulness, which
> > I cannot understand:
> > - even if there are some slowdowns, where does it matter?
> > - the "old" method uses only one method of cancelling, i.e.
> > del_timer, not trying to stop requeuing or to remove from
> > the queue; it seems to be effective only with long delayed
> > timers, and its real problems are probably mostly invisible.
>
> The slowdown is small, changelog mentions it just to be "fair".
>
> I am not happy with the complication this patch adds, mostly
> I hate this smb_wmb() in insert_work(). I have an idea how to
> remove it later, but this needs another patch not related to
> workqueue.c.
>
> > BTW, I'm still not convinced all additions are needed:
> > the "old" cancel_rearming_ doesn't care about checking
> > or waiting on anything after del_timer positive.
>
> It would be very strange to do wait_on_work() only in case
> when del_timer() failed. This way we still need to do
> cancel_work_sync() after cancel_rearming_delayed_work(),
> but only when del_timer() failed, ugly. Note also that
> wait_on_work() does not sleep if work->func() is not running.
>
> Also, consider this callback:
>
> void work_handler(struct work_struct *w)
> {
> struct delayed_work dw = container_of(...);
>
> queue_delayed_work(dw, delay);
>
> // <------------- cancel_rearming_delayed_work()
>
> cancel_delayed_work(dw);
> queue_delayed_work(dw, another_delay);
> }
>
> Yes, this is strange and ugly. But correct! The current version
I guess pseudo code below is not that strange, but real usecase:
probe()
{
INIT_DELAYED_WORK(...);
/* we're not issuing queue_delayed_work() in probe(), work will
* be started by interrupt */
return;
}
remove()
{
/* hang will happen here if there was no queue_delyed_work()
* call (like there was no interrupts, which starts rearming
* work */
cancel_rearming_delayed_work();
}
Your patch will fix it, right?
> Oleg.
Good luck,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.org/bd2
next prev parent reply other threads:[~2007-05-07 11:55 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-03 20:42 [PATCH] make cancel_rearming_delayed_work() reliable Oleg Nesterov
2007-05-04 1:15 ` Andrew Morton
2007-05-04 17:09 ` Oleg Nesterov
2007-05-05 21:32 ` [PATCH] make-cancel_rearming_delayed_work-reliable-fix Oleg Nesterov
2007-05-07 10:31 ` Jarek Poplawski
2007-05-07 10:34 ` Oleg Nesterov
2007-05-07 11:55 ` Anton Vorontsov [this message]
2007-05-07 11:33 ` Oleg Nesterov
2007-05-08 9:16 ` Jarek Poplawski
2007-05-08 12:02 ` Oleg Nesterov
2007-05-08 13:07 ` Jarek Poplawski
2007-05-08 7:15 ` [PATCH] make cancel_rearming_delayed_work() reliable Jarek Poplawski
2007-05-08 12:31 ` Oleg Nesterov
2007-05-08 13:56 ` Jarek Poplawski
2007-05-08 14:05 ` Oleg Nesterov
2007-05-08 14:32 ` Jarek Poplawski
2007-05-08 14:12 ` Jarek Poplawski
2007-05-11 13:55 ` Tejun Heo
2007-05-11 13:47 ` Oleg Nesterov
2007-05-11 15:19 ` Tejun Heo
2007-05-11 14:53 ` Oleg Nesterov
2007-05-12 5:50 ` Tejun Heo
2007-05-13 19:27 ` Oleg Nesterov
2007-05-13 20:16 ` Tejun Heo
2007-05-13 21:25 ` Oleg Nesterov
2007-05-14 19:44 ` Oleg Nesterov
2007-05-15 8:26 ` Tejun Heo
2007-05-15 13:09 ` Jarek Poplawski
2007-05-15 22:08 ` Oleg Nesterov
2007-05-16 5:21 ` Jarek Poplawski
2007-05-15 22:00 ` Oleg Nesterov
2007-05-16 11:25 ` Tejun Heo
2007-05-16 18:52 ` Oleg Nesterov
2007-05-17 9:36 ` Tejun Heo
2007-05-18 7:35 ` Jarek Poplawski
2007-05-18 8:13 ` Jarek Poplawski
2007-05-18 13:33 ` Tejun Heo
2007-05-21 7:00 ` Jarek Poplawski
2007-05-21 8:59 ` Tejun Heo
2007-05-21 10:10 ` Jarek Poplawski
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=20070507115511.GA10367@zarina \
--to=cbou@mail.ru \
--cc=akpm@linux-foundation.org \
--cc=dgc@sgi.com \
--cc=dhowells@redhat.com \
--cc=ego@in.ibm.com \
--cc=jarkao2@o2.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=oleg@tv-sign.ru \
--cc=vatsa@in.ibm.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