From patchwork Mon Sep 24 22:43:52 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Lezcano X-Patchwork-Id: 1501101 Return-Path: X-Original-To: patchwork-linux-acpi@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id 451303FE80 for ; Mon, 24 Sep 2012 22:44:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751519Ab2IXWoC (ORCPT ); Mon, 24 Sep 2012 18:44:02 -0400 Received: from mail-wi0-f172.google.com ([209.85.212.172]:43162 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751097Ab2IXWoB (ORCPT ); Mon, 24 Sep 2012 18:44:01 -0400 Received: by mail-wi0-f172.google.com with SMTP id hq12so2539837wib.1 for ; Mon, 24 Sep 2012 15:44:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references :x-gm-message-state; bh=JfD0kxxL357UsTWLw+tFXGKNaxALajRO4T5w3X7YZK0=; b=jbeyzSYb3A5wRs89GbQSkullAhoSGeewVQ/3wqZqaX3FshInSnLTxvyRR46jG+6W+S q1sbibKQ/aqz7YDbB4uOEgKPRYsuLHXdgB0VaBY1l4mZaIVn2doYKelEpf3v4YF1FvNw ZUhtC4jp9Z5Pbr2kyqsObO35w7ijXugYsNf/ww2wRoo1RAgrhfXN18zAHESbs1Y0TcAP kh36imCenB8yrR7s9h9/EgKEgMx69fEvioU6mkgzvY/XewcZEqIq8LUMHLqRXoC2oANd oxowj4MizXZcjPePyLCUeLOpuH+V5xVJ7iXqyjz3kBr7GGCUucWrAK4ORobui5AVapqD EfCA== Received: by 10.180.33.111 with SMTP id q15mr7914163wii.20.1348526640814; Mon, 24 Sep 2012 15:44:00 -0700 (PDT) Received: from localhost.localdomain (AToulouse-651-1-259-252.w109-214.abo.wanadoo.fr. [109.214.174.252]) by mx.google.com with ESMTPS id k2sm19286398wiz.7.2012.09.24.15.43.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Sep 2012 15:43:59 -0700 (PDT) From: Daniel Lezcano To: rjw@sisk.pl, lenb@kernel.org Cc: linux-pm@vger.kernel.org, lorenzo.pieralisi@arm.com, pdeschrijver@nvidia.com, linux-acpi@vger.kernel.org, patches@linaro.org, linaro-dev@lists.linaro.org Subject: [PATCH 2/4] cpuidle : move driver checking within the lock section Date: Tue, 25 Sep 2012 00:43:52 +0200 Message-Id: <1348526634-19029-3-git-send-email-daniel.lezcano@linaro.org> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1348526634-19029-1-git-send-email-daniel.lezcano@linaro.org> References: <1348526634-19029-1-git-send-email-daniel.lezcano@linaro.org> X-Gm-Message-State: ALoCoQn8+zlhagSmN+fm64kdIsdLGTA84qjF+8kNFv1oxKe9xG9VTaygF5pgyHI49L/eGSsK1Ukn Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org The code checks if the driver is already set without taking the lock, but, right after, it takes the lock to assign the variable. If it is safe to check the variable without lock, then it is safe to assign it without lock. If it is unsafe to assign without a lock, then it is unsafe to check it without a lock. I don't find a path in the different drivers where that could happen because the arch specific drivers are written in such way it is not possible to register a driver while it is unregistered, except maybe in a very improbable case when "intel_idle" and "processor_idle" are competing. One could unregister a driver, while the other one is registering. Signed-off-by: Daniel Lezcano --- drivers/cpuidle/driver.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c index 39ba8e1..4a0c4ab 100644 --- a/drivers/cpuidle/driver.c +++ b/drivers/cpuidle/driver.c @@ -85,17 +85,17 @@ EXPORT_SYMBOL_GPL(cpuidle_get_driver); */ void cpuidle_unregister_driver(struct cpuidle_driver *drv) { + spin_lock(&cpuidle_driver_lock); + if (drv != cpuidle_curr_driver) { WARN(1, "invalid cpuidle_unregister_driver(%s)\n", drv->name); - return; + goto out; } - spin_lock(&cpuidle_driver_lock); - if (!WARN_ON(drv->refcnt > 0)) cpuidle_curr_driver = NULL; - +out: spin_unlock(&cpuidle_driver_lock); } EXPORT_SYMBOL_GPL(cpuidle_unregister_driver);