linux-kernel - Re: cancel_delayed_work and its use of del_timer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 24 Aug 2009 11:07:55 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: cancel_delayed_work and its use of del_timer_sync

On Mon, Aug 24, 2009 at 07:49:10PM +0200, Oleg Nesterov wrote:
> On 08/23, Dmitry Torokhov wrote:
> 
> > it is possible to have a reschedule_delayed_work() taht would do a
> > "soft" cancel and [re]submit the work. In the use cases I am concerned
> > about we don't really care if work is not reliably cancelled, we just
> > need to be able to schedule it earlier if it has already been scheduled
> > for execution in some point in the future.
> 
> Well. this depends on how "soft" should be that cancel.
> 
> Consider the auto-rearming delayed work, its work->func() calls
> queue_delayed_work(self, BIG_DELAY). The caller of requeue_work(SMALL_DELAY)
> preempts cwq->thread right after it sets _PENDING.
> 
> Now, what should requeue_work() do ? Even if the requeue_work() and
> work->func() run on different CPUs, in this case requeue_ must spin.
> 
> So. It is easy to create requeue_work() which never sleeps/spins, but
> it can return the error in case it hits the queueing in progress.
> 
> Is it OK?
> 
> And another question, should it cancel (without sleep/spin) this dwork
> if the timer has expired, the work is pending, but its ->func() has not
> started yet?
>

It depends... In most cases we have a delayed work scheduled with a
BIG_DELAY and then interrupt comes and we want to reschedule the delayed
work so it can be executed right away. So, in this particular case, we
don't need to cancel a work that is being scheduled at this particular
moment. On the other hand there was a driver that wanted the same
semantics for delayed works as timers... I think that if work is already
scheduled for execution we could let it go and not try to cancel it.

-- 
Dmitry
--
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/