In the Linux kernel, the following vulnerability has been resolved:
drivers/perf: hisi: Don't migrate perf to the CPU going to teardown
The driver needs to migrate the perf context if the current using CPU going to teardown. By the time calling the cpuhp::teardown() callback the cpuonlinemask() hasn't updated yet and still includes the CPU going to teardown. In current driver's implementation we may migrate the context to the teardown CPU and leads to the below calltrace:
... [ 368.104662][ T932] task:cpuhp/0 state:D stack: 0 pid: 15 ppid: 2 flags:0x00000008 [ 368.113699][ T932] Call trace: [ 368.116834][ T932] _switchto+0x7c/0xbc [ 368.120924][ T932] _schedule+0x338/0x6f0 [ 368.125098][ T932] schedule+0x50/0xe0 [ 368.128926][ T932] schedulepreemptdisabled+0x18/0x24 [ 368.134229][ T932] _mutexlock.constprop.0+0x1d4/0x5dc [ 368.139617][ T932] _mutexlockslowpath+0x1c/0x30 [ 368.144573][ T932] mutexlock+0x50/0x60 [ 368.148579][ T932] perfpmumigratecontext+0x84/0x2b0 [ 368.153884][ T932] hisipciepmuofflinecpu+0x90/0xe0 [hisipciepmu] [ 368.160579][ T932] cpuhpinvokecallback+0x2a0/0x650 [ 368.165707][ T932] cpuhpthreadfun+0xe4/0x190 [ 368.170316][ T932] smpbootthreadfn+0x15c/0x1a0 [ 368.175099][ T932] kthread+0x108/0x13c [ 368.179012][ T932] retfromfork+0x10/0x18 ...
Use function cpumaskanybut() to find one correct active cpu to fixes this issue.