linux-kernel - Re: [PATCH 4/4] workqueue: Remove now superfluous cancel_delayed

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: <1296755141.26581.470.camel@laptop>
Date:	Thu, 03 Feb 2011 18:45:41 +0100
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Tejun Heo <tj@...nel.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jens Axboe <axboe@...nel.dk>,
	Faisal Latif <faisal.latif@...el.com>,
	Roland Dreier <roland@...nel.org>,
	Sean Hefty <sean.hefty@...el.com>,
	Hal Rosenstock <hal.rosenstock@...il.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Alessandro Rubini <rubini@...vis.unipv.it>,
	Trond Myklebust <Trond.Myklebust@...app.com>,
	Mark Fasheh <mfasheh@...e.com>,
	Joel Becker <jlbec@...lplan.org>,
	"David S. Miller" <davem@...emloft.net>,
	"John W. Linville" <linville@...driver.com>,
	Johannes Berg <johannes@...solutions.net>,
	Yong Zhang <yong.zhang0@...il.com>
Subject: Re: [PATCH 4/4] workqueue: Remove now superfluous
 cancel_delayed_work() calls

On Thu, 2011-02-03 at 17:19 +0100, Tejun Heo wrote:
> Hello, Peter.
> 
> On Thu, Feb 03, 2011 at 03:09:44PM +0100, Peter Zijlstra wrote:
> > Since queue_delayed_work() can now deal with existing timers, we don't
> > need to explicitly call cancel_delayed_work() anymore.
> 
> This is nice but there's small complication with the way
> queue_delayed_work() behaves.  If a delayed work item is already
> pending, another queue_delayed_work() doesn't modify the delay whether
> the new delay is longer or shorter than the current one.  The previous
> patch doesn't really change the behavior as the whole thing is gated
> with WORK_STRUCT_PENDING_BIT.
> 
> So, cancel_delayed_work() followed by queue_delayed_work() schedules
> the work to be executed at the specified time regardless of the
> current pending state while queue_delayed_work() takes effect iff
> currently the work item is not pending.

Right, I didn't think it would matter much, the difference is tiny. Only
a small window between the timer triggering and the work getting
scheduled has a different semantics, it used to be the same as before
that window, now its like after that window.

Since its all timing the code needs to deal with those cases anyway, no?

> The current behavior is weird and it often is easier to use explicit
> timer + work item if the timer needs to be modified, but it has been
> that way from the beginning so I don't think changing it would be a
> good idea.  We can introduce a new interface (mod_delayed_work()
> maybe) for this tho.

Well we could simply not apply patch 4 and things simply remain as they
are. The mod_timer() semantics are identical to add_timer() if you call
del_timer() like thing before, so patch 3 doesn't actually change any
semantics if you keep using it the old way.
--
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/