Received: by 10.213.65.68 with SMTP id h4csp468662imn; Fri, 16 Mar 2018 08:40:46 -0700 (PDT) X-Google-Smtp-Source: AG47ELu00vGsnojUWbveNmXr4tnVvRKTdmsnOF4Y217LaABw20QQgB0oorLfJg484IbetcwsJyZH X-Received: by 10.99.97.138 with SMTP id v132mr1809223pgb.138.1521214846882; Fri, 16 Mar 2018 08:40:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521214846; cv=none; d=google.com; s=arc-20160816; b=LOTHfqA7GS+B62v7/1v1c4IU9Sknh7FK3B3dLrLqbivKrXUYYODV6ep+l7m7y2+bbl qAmuiBC7ECfvUDsgYCLVs0XRcAZ2/gIv/UqShv9EiROIdQ8qTtMNvA6PdNfoLJ6i3183 LtVnS+VdU4+rvWgswlugTiC5G2r5go2vuJD27jA/iey+xNEasAcRl3S8Ortom7o1YLSq pcT7OSZFY2jm3TJjJj3Y8SzSArOYYKiavyCSOdLx4v2tHqSw6OpI+okqOGGeZbFPRKmK rjhQLS9Q+2zOX56w0NcdUbPA97s9I6aUGkt5M063KL3G6J65z4pwhyFYY/fmLr+Upm3X /xaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=giqgu/iJXNB9c0cqQyuN6TESnxTmcALblVCwc8f5LxY=; b=gP1eI/v39k2pCvl5q4bnHbDsBPsc8uERutnHiKxPglcBt3kvCe7j71xKyW2Xs1PBLs LMftUg8dAcKOgcKKxwOL0T2BgL6XjWllLrq5E+f4UvqZMOuXQghhZ2s7iKncjnpoTtRw orL824/qvewLos5St+6tqGwtSe8SjwqbHI98vNPBNenabXJzG55Jd0Gsbk3Oq7Ime9w6 ycoXDhqbfeRJ+X78FiXQ1LukWkTogr8Mx5F8PdZ7dC1u9QAmUkx+9o0izWeEawVdMgZ7 RJKibWJD+O2ulwNEEw9BYyFZsXYzok6m+G5qF4ekTq/wSkmoTGWcRdGYMMOdan3fiAv5 owrA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v5si5755282pfl.205.2018.03.16.08.40.32; Fri, 16 Mar 2018 08:40:46 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934520AbeCPPjB (ORCPT + 99 others); Fri, 16 Mar 2018 11:39:01 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:43072 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934167AbeCPPiw (ORCPT ); Fri, 16 Mar 2018 11:38:52 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 7B064C19; Fri, 16 Mar 2018 15:38:51 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Rafael J. Wysocki" , Viresh Kumar , Sasha Levin Subject: [PATCH 4.14 063/109] cpufreq: Fix governor module removal race Date: Fri, 16 Mar 2018 16:23:32 +0100 Message-Id: <20180316152333.395213939@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180316152329.844663293@linuxfoundation.org> References: <20180316152329.844663293@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: "Rafael J. Wysocki" [ Upstream commit a8b149d32b663c1a4105273295184b78f53d33cf ] It is possible to remove a cpufreq governor module after cpufreq_parse_governor() has returned success in store_scaling_governor() and before cpufreq_set_policy() acquires a reference to it, because the governor list is not protected during that period and nothing prevents the governor from being unregistered then. Prevent that from happening by acquiring an extra reference to the governor module temporarily in cpufreq_parse_governor(), under cpufreq_governor_mutex, and dropping it in store_scaling_governor(), when cpufreq_set_policy() returns. Note that the second cpufreq_parse_governor() call site is fine, because it only cares about the policy member of new_policy. Signed-off-by: Rafael J. Wysocki Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/cpufreq/cpufreq.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -631,6 +631,8 @@ static int cpufreq_parse_governor(char * *governor = t; err = 0; } + if (t && !try_module_get(t->owner)) + t = NULL; mutex_unlock(&cpufreq_governor_mutex); } @@ -759,6 +761,10 @@ static ssize_t store_scaling_governor(st return -EINVAL; ret = cpufreq_set_policy(policy, &new_policy); + + if (new_policy.governor) + module_put(new_policy.governor->owner); + return ret ? ret : count; }