[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070507113351.GA821@tv-sign.ru>
Date: Mon, 7 May 2007 15:33:51 +0400
From: Oleg Nesterov <oleg@...sign.ru>
To: Anton Vorontsov <cbou@...l.ru>
Cc: Jarek Poplawski <jarkao2@...pl>,
Andrew Morton <akpm@...ux-foundation.org>,
David Chinner <dgc@....com>,
David Howells <dhowells@...hat.com>,
Gautham Shenoy <ego@...ibm.com>, Ingo Molnar <mingo@...e.hu>,
Srivatsa Vaddagiri <vatsa@...ibm.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] make-cancel_rearming_delayed_work-reliable-fix
On 05/07, Anton Vorontsov wrote:
>
> 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?
Yes, the new implemantation should work correctly.
However, this particular case was already fixed earlier,
workqueue-make-cancel_rearming_delayed_workqueue-work-on-idle-dwork.patch
http://marc.info/?l=linux-mm-commits&m=117081275901499
Note that INIT_DELAYED_WORK() sets work->data = 0, and
cancel_rearming_delayed_work() does "Was it ever queued"
check.
Still, before this patch, cancel_rearming_delayed_work() hangs
if this work was used before, but not active + re-arming now.
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists