linux-kernel - Re: [PATCH 1/2] workqueue: Add new function mod_fwd_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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 6 Mar 2017 17:22:12 -0500
From:   Tejun Heo <tj@...nel.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     Harald Geyer <harald@...ib.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] workqueue: Add new function mod_fwd_delayed_work()

Hello,

On Thu, Feb 23, 2017 at 09:34:49AM -0800, Mark Brown wrote:
> It is *very* non-obvious that mod_delayed_work() will have a problem
> from the documentation, there's "mod_delayed_work_on() on local CPU" as
> the body of the description but honestly I'm struggling to tell if
> that's even there intentionally or anything other than an implementation
> detail.  I'd expect to see some words describing the situations where it
> can be used or something, both the name and the lack of any information
> about issues suggest it's the default thing and will work safely.

What the mod function is implemneting is "whoever wins (runs the last)
determines the timeout".  It is a bit unwiedly because unlike the
timer, workqueue delay takes duration instead of the absoulte time
making coordinating from the user side trickier.

> > I was suprised when I found that no function like mod_fwd_delayed_work()
> > existed, so you have a point there.
> 
> I suspect people are just using mod_delayed_work(), not realising that
> there are restrictions.  I'm thinking that perhaps it should be fixed
> to be safe for calling from different contexts and a new function with
> the existing behaviour added, that seems less error prone.

I don't think it's a matter of "fixing" the existing
mod_delayed_work().  What the new function is implementing wouldn't
fit use cases where the timeout should only be shortened (IIRC,
writeback code does that).

I'm not against adding new interface to handle it better but I think
it makes more sense to add both directions.  How about adding
expedite_delayed_work_on() and postpone_delayed_work_on()?

Thanks.

-- 
tejun