Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932949AbdCJSoj (ORCPT ); Fri, 10 Mar 2017 13:44:39 -0500 Received: from h1.radempa.de ([176.9.142.194]:55217 "EHLO mail.cosmopool.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754075AbdCJSoa (ORCPT ); Fri, 10 Mar 2017 13:44:30 -0500 From: Harald Geyer To: Mark Brown cc: Liam Girdwood , Tejun Heo , Lai Jiangshan , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] workqueue: Add new function mod_fwd_delayed_work() In-reply-to: <20170307124258.raimufnbnni4pf5m@sirena.org.uk> References: <1487785285-3567-1-git-send-email-harald@ccbib.org> <20170222182111.4jajk2ed52okx323@sirena.org.uk> <20170223173449.c747nrfr3oxrjrr7@sirena.org.uk> <20170227125427.3xgdukr4ok472v6c@sirena.org.uk> <20170307124258.raimufnbnni4pf5m@sirena.org.uk> Comments: In-reply-to Mark Brown message dated "Tue, 07 Mar 2017 13:42:58 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1270.1489171463.1@stardust.g4.wien.funkfeuer.at> Date: Fri, 10 Mar 2017 19:44:23 +0100 Message-Id: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1973 Lines: 48 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