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

Message-Id: <20090824065111.A51D8526EC9@mailhub.coreip.homeip.net>
Date:	Sun, 23 Aug 2009 23:19:20 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Oleg Nesterov <oleg@...sign.ru>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: cancel_delayed_work and its use of del_timer_sync

Hi Oleg,

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(). I must say that the fact that cancel_delayed_work()
might 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.

My question is if sleeping in cancel_delayed_work can be avoided or if
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.

Thanks!

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