linux-kernel - Re: [PATCH 3.6-rc6] cpufreq/powernow-k8: workqueue user shouldn't migrate the kworker to another CPU

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

Message-Id: <201209230353.49737.trenn@suse.de>
Date:	Sun, 23 Sep 2012 03:53:48 +0200
From:	Thomas Renninger <trenn@...e.de>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Tejun Heo <tj@...nel.org>, Andre Przywara <andre.przywara@....com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, cpufreq@...r.kernel.org,
	linux-pm@...r.kernel.org, Duncan <1i5t5.duncan@....net>,
	Andreas Herrmann <andreas.herrmann3@....com>
Subject: Re: [PATCH 3.6-rc6] cpufreq/powernow-k8: workqueue user shouldn't migrate the kworker to another CPU

Hi,

better late than never..

On Monday 17 September 2012 22:38:20 Rafael J. Wysocki wrote:
> On Monday, September 17, 2012, Tejun Heo wrote:
> > powernowk8_target() runs off a per-cpu work item and if the
> > cpufreq_policy->cpu is different from the current one, it migrates the
> > kworker to the target CPU by manipulating current->cpus_allowed.  The
> > function migrates the kworker back to the original CPU but this is
> > still broken.  Workqueue concurrency management requires the kworkers
> > to stay on the same CPU and powernowk8_target() ends up triggerring
> > BUG_ON(rq != this_rq()) in try_to_wake_up_local() if it contends on
> > fidvid_mutex and sleeps.
> > 
> > It is unclear why this bug is being reported now.  Duncan says it
> > appeared to be a regression of 3.6-rc1 and couldn't reproduce it on
> > 3.5.  Bisection seemed to point to 63d95a91 "workqueue: use @pool
> > instead of @gcwq or @cpu where applicable" which is an non-functional
> > change.  Given that the reproduce case sometimes took upto days to
> > trigger, it's easy to be misled while bisecting.  Maybe something made
> > contention on fidvid_mutex more likely?  I don't know.
> > 
> > This patch fixes the bug by punting to another per-cpu work item on
> > the target CPU if it isn't the same as the current one.  The code
> > assumes that cpufreq_policy->cpu is kept online by the caller, which
> > Rafael tells me is the case.
> > 
> > Signed-off-by: Tejun Heo <tj@...nel.org>
> > Reported-by: Duncan <1i5t5.duncan@....net>
> > Cc: Rafael J. Wysocki <rjw@...k.pl>
> > Cc: Andreas Herrmann <andreas.herrmann3@....com>
> > Cc: stable@...nel.org
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47301
> > ---
> > 
> > While it's very late in the merge cycle, the fix is limited in scope
> > and fairly safe, so it wouldn't be too crazy to merge but then again
> > this can go through the next -rc1 and then -stable.  Linus, Rafael,
> > what do you guys think?
> 
> Well, I don't see much reason to wait with this, although I'd like some
> more people to check it.
> 
> Andre, Thomas, can you please have a look at it?

The cpufreq changes are not really (functional) changes.
I cannot judge the risk of the real change:

> > +	INIT_WORK_ONSTACK(&tw.work, powernowk8_target_on_cpu);
instead of using set_cpus_allowed_ptr.

Changing scheduler behavior of powernow-k8 
sounds rather intrusive for rc6, but I would fully trust
Tejun's advise on this.

I wonder whether more drivers are affected similarly, grepping for:
set_cpus_allowed_ptr
shows quite some hits.

My 2 cents...,

   Thomas
--
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/