linux-kernel - Re: [PATCH] cpufreq, store_scaling_governor requires policy->rwsem to be held for duration of changing governors [v2]

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140806150831.GB32301@codeaurora.org>
Date:	Wed, 6 Aug 2014 08:08:31 -0700
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	Prarit Bhargava <prarit@...hat.com>
Cc:	Viresh Kumar <viresh.kumar@...aro.org>,
	Saravana Kannan <skannan@...eaurora.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Lenny Szubowicz <lszubowi@...hat.com>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>
Subject: Re: [PATCH] cpufreq, store_scaling_governor requires policy->rwsem
 to be held for duration of changing governors [v2]

On 08/06, Prarit Bhargava wrote:
> 
> 
> On 08/06/2014 04:10 AM, Viresh Kumar wrote:
> > On 6 August 2014 03:36, Saravana Kannan <skannan@...eaurora.org> wrote:
> >> Stephen and I looked into this. This is not a sysfs framework difference.
> >> The reason we don't have this issue when we use global tunables is because
> >> we add the attribute group to the cpufreq_global_kobject and that kobject
> >> doesn't have a kobj_type ops similar to the per policy kobject. So,
> >> read/write to those attributes do NOT go through the generic show/store ops
> >> that wrap every other cpufreq framework attribute read/writes.
> >>
> >> So, none of those read/write do any kind of locking. They don't race with
> >> POLICY_EXIT (because we remove the sysfs group first thing in POLICY_EXIT)
> >> but might still race with START/STOPs (not sure, haven't looked closely
> >> yet).
> >>
> >> For example, writing to sampling_rate of ondemand governor might cause a
> >> race in update_sampling_rate(). It could race and happen between a STOP and
> >> POLICY_EXIT (triggered by hotplug, gov change, etc).
> > 
> > This sounds good but I couldn't prove it. Doing this on my dual core exynos
> > doesn't give me that crash report and it should?
> 
> Are you sure you're not seeing another lockdep warning?  That was my problem --
> there was an xfs related lockdep warning which then resulted in lockdep being
> disabled from that point on.
> 

Are we talking about the lockdep splat or the crash that started
this thread or something else? For the lockdep splat you need the
corrected patch in this thread and the per policy governor flag.
I'm not sure how to recreate the crash that started this thread.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/