Thread (12 messages) flat view 12 messages, 3 authors, 2021-09-07

Re: [PATCH] cpufreq: intel_pstate: Fix for HWP interrupt before driver is ready

From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date: 2021-09-06 19:57:11
Also in: lkml

On Mon, 2021-09-06 at 20:25 +0200, Rafael J. Wysocki wrote:
On Mon, Sep 6, 2021 at 8:14 PM Srinivas Pandruvada
[off-list ref] wrote:
quoted
On Mon, 2021-09-06 at 19:54 +0200, Rafael J. Wysocki wrote:
quoted
[...]
quoted
quoted
We are handling offline for other thermal interrupt sources from
same
interrupt in therm-throt.c, where we do similar in offline path (by
TGLX). If cpufreq offline can cause such issue of changing CPU,
This is not cpufreq offline, but intel_pstate_update_status() which
may be triggered via sysfs.  And again, the theoretically problematic
thing is dereferencing cpudata (which may be cleared by a remote CPU)
from the interrupt handler without protection.
This will be a problem.
quoted
I can call intel_pstate_disable_hwp_interrupt() via override from
https://elixir.bootlin.com/linux/latest/C/ident/thermal_throttle_offline
after masking APIC interrupt.
But why would using RCU be harder than this?
I think, this will require all_cpu_data and cpu_data to be rcu
protected. This needs to be well tested.

I think better to revert the patch for the next release.

Thanks,
Srinivas
Also please note that on RT kernels interrupt handlers are run in
threads.
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help