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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 10 Mar 2017 19:44:23 +0100
From:   Harald Geyer <harald@...ib.org>
To:     Mark Brown <broonie@...nel.org>
cc:     Liam Girdwood <lgirdwood@...il.com>, Tejun Heo <tj@...nel.org>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] workqueue: Add new function mod_fwd_delayed_work()

Mark Brown writes:
> On Mon, Feb 27, 2017 at 08:17:10PM +0100, Harald Geyer wrote:
> > Mark Brown writes:
> 
> > > I'd need to figure out exactly what the restrictions are and like I say
> > > the name of the function itself is confusing, I suspect because it
> > > predates SMP.
> 
> > I guess you know that, but just to avoid any confusion: The bug in the
> > regulator code is not related to SMP at all.
> 
> It's not?  Oh.  I had formed the impression that this was a race
> condition.

I have used the word "race" in the description of patch 2/2 - sorry if
that was the wrong word, I'm trained in physics not computer science.
The description of patch 2/2 was:

> regulator: core: Fix race on multiple calls to regulator_disable_deferred()
>
> The old code has two issues:
> 1) When multiple consumers call regulator_disable_deferred() close in time,
> always the delay requested in the first call is used.
> 2) When a consumer calls regulator_disable_deferred(), but enables and
> calls regulator_disable_deferred() again before the timer fires, the timer
> isn't reset.
>
> Both issues can cause the regulator to get disabled early.

Issue (1) is what I had thought of a race - not in multiprocessing but
in multitasking. Please educate me, if this is not the case or if you can
think of a way how I could have expressed the idea more clearly.

> Well, we need to figure out what the desired solution is!

Do we have reached consensus on what to do? Do people wait for me to do some
work? Based on the comments in this thread it seems one way forward is,
that I'm resending the series with mod_fwd_delayed_work() renamed to
postpone_delayed_work(). Please let me know if you still consider
alternative approaches or need more time to evaluate the situation.

TIA,
Harald
-- 
If you want to support my work:
see http://friends.ccbib.org/harald/supporting/
or donate via CLAM to xASPBtezLNqj4cUe8MT5nZjthRSEjrRQXN
or via peercoin to P98LRdhit3gZbHDBe7ta5jtXrMJUms4p7w