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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090824175101.GB16202@redhat.com>
Date:	Mon, 24 Aug 2009 19:51:01 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Roland Dreier <rdreier@...co.com>,
	Stefan Richter <stefanr@...6.in-berlin.de>
Subject: Re: cancel_delayed_work and its use of del_timer_sync

Damn, forgot to update CC, re-sending...

Hi Dmitry,

(add Roland and Stefan)

On 08/23, Dmitry Torokhov wrote:
>
> I noticed that you went back and forth on using del_timer() vs.
> del_timer_sync() in cancel_delayed_work(), finally settling on using
> del_timer_sync().

Yes. del_timer() can't work when the user does something like

	cancel_delayed_work(dw);
	flush_workqueue();

	kfree(dw);

Perhaps we can add __cancel_delayed_work() which uses del_timer(), most
callers don't really need del_timer_sync. I dunno.

> I must say that the fact that cancel_delayed_work()
> might sleep

Just in case, it can spin, but not sleep

> (given that there exists cancel_delayed_work_sync) catches a
> few drivers writers by surprise. Moreover it makes delayed works
> unsuitable in cases when we do want to cancel (so we can reschedule)
> work in an interrupt context.

Yep. it is not useable from irq. But only because nobody removed
"#ifdef CONFIG_SMP" from set_running_timer(). I guess I should send a
patch finally.

> 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?

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/