On 4/9/19 10:53 AM, Mark Rutland wrote: > On Mon, Apr 08, 2019 at 11:50:31AM +0200, Peter Zijlstra wrote: >> On Mon, Apr 08, 2019 at 10:22:29AM +0200, Peter Zijlstra wrote: >>> On Mon, Apr 08, 2019 at 09:12:28AM +0200, Thomas-Mich Richter wrote: >>
..... >> >> Instead encode the CPU number in @pending_disable, such that we can >> tell which CPU requested the disable. This then allows us to detect >> the above scenario and even redirect the IPI to make up for the failed >> queue. >> >> Cc: Heiko Carstens <[email protected]> >> Cc: Kees Cook <[email protected]> >> Cc: Hendrik Brueckner <[email protected]> >> Cc: [email protected] >> Cc: Martin Schwidefsky <[email protected]> >> Cc: Mark Rutland <[email protected]> >> Cc: Jiri Olsa <[email protected]> >> Reported-by: Thomas-Mich Richter <[email protected]> >> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> > > I can't think of a nicer way of handling this, so FWIW: > > Acked-by: Mark Rutland <[email protected]> > > Mark. > >> --- Thanks for the fix with commit id 86071b11317550d994b55ce5e31aa06bcad783b5. However doing an fgrep on the pending_disable member of struct perf_event reveals two more hits in file kernel/events/ringbuffer.c when events have auxiliary data. Not sure if this needs to be addresses too, just wanted to let you know. -- Thomas Richter, Dept 3252, IBM s390 Linux Development, Boeblingen, Germany -- Vorsitzender des Aufsichtsrats: Matthias Hartmann Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
