From: Viresh Kumar <viresh.kumar@linaro.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Linux PM list <linux-pm@vger.kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Russell King <linux@arm.linux.org.uk>
Subject: Re: [PATCH v3] cpufreq: Avoid attempts to create duplicate symbolic links
Date: Mon, 27 Jul 2015 07:59:52 +0530 [thread overview]
Message-ID: <20150727022952.GF19944@linux> (raw)
In-Reply-To: <2161701.diIE0m8ocR@vostro.rjw.lan>
On 26-07-15, 02:28, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> After commit 87549141d516 (cpufreq: Stop migrating sysfs files on
> hotplug) there is a problem with CPUs that share cpufreq policy
> objects with other CPUs and are initially offline.
>
> Say CPU1 shares a policy with CPU0 which is online and is registered
> first. As part of the registration process, cpufreq_add_dev() is
> called for it. It creates the policy object and a symbolic link
> to it from the CPU1's sysfs directory. If CPU1 is registered
> subsequently and it is offline at that time, cpufreq_add_dev() will
> attempt to create a symbolic link to the policy object for it, but
> that link is present already, so a warning about that will be
> triggered.
>
> To avoid that warning, make cpufreq use an additional CPU mask
> containing related CPUs that are actually present for each policy
> object. That mask is initialized when the policy object is populated
> after its creation (for the first online CPU using it) and it includes
> CPUs from the "policy CPUs" mask returned by the cpufreq driver's
> ->init() callback that are physically present at that time. Symbolic
> links to the policy are created only for the CPUs in that mask.
>
> If cpufreq_add_dev() is invoked for an offline CPU, it checks the
> new mask and only creates the symlink if the CPU was not in it (the
> CPU is added to the mask at the same time).
>
> In turn, cpufreq_remove_dev() drops the given CPU from the new mask,
> removes its symlink to the policy object and returns, unless it is
> the CPU owning the policy object. In that case, the policy object
> is moved to a new CPU's sysfs directory or deleted if the CPU being
> removed was the last user of the policy.
>
> While at it, notice that cpufreq_remove_dev() can't fail, because
> its return value is ignored, so make it ignore return values from
> __cpufreq_remove_dev_prepare() and __cpufreq_remove_dev_finish()
> and prevent these functions from aborting on errors returned by
> __cpufreq_governor(). Also drop the now unused sif argument from
> them.
>
> Fixes: 87549141d516 (cpufreq: Stop migrating sysfs files on hotplug)
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Reported-by: Russell King <linux@arm.linux.org.uk>
> ---
>
> This goes back to the https://patchwork.kernel.org/patch/6856011/
> idea, but has a couple of bugs fixed and goes a it further with
> cleaning things up.
>
> ---
> drivers/cpufreq/cpufreq.c | 108 +++++++++++++++++++++++-----------------------
> include/linux/cpufreq.h | 1
> 2 files changed, 56 insertions(+), 53 deletions(-)
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
next prev parent reply other threads:[~2015-07-27 2:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-23 21:14 [PATCH] cpufreq: Avoid attempts to create duplicate symbolic links Rafael J. Wysocki
2015-07-24 14:09 ` Viresh Kumar
2015-07-24 20:20 ` Rafael J. Wysocki
2015-07-24 22:17 ` [PATCH v2] " Rafael J. Wysocki
2015-07-25 13:00 ` Viresh Kumar
2015-07-25 22:46 ` Rafael J. Wysocki
2015-07-26 0:28 ` [PATCH v3] " Rafael J. Wysocki
2015-07-27 2:29 ` Viresh Kumar [this message]
2015-07-27 12:39 ` Rafael J. Wysocki
2015-07-27 2:27 ` [PATCH v2] " Viresh Kumar
2015-07-27 13:45 ` Rafael J. Wysocki
2015-07-27 14:39 ` Viresh Kumar
2015-07-29 1:38 ` Rafael J. Wysocki
2015-07-29 5:45 ` Viresh Kumar
2015-07-29 9:11 ` Russell King - ARM Linux
2015-07-29 13:57 ` Rafael J. Wysocki
2015-07-29 14:21 ` Viresh Kumar
2015-07-29 20:32 ` Rafael J. Wysocki
2015-07-30 9:00 ` Viresh Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150727022952.GF19944@linux \
--to=viresh.kumar@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).