Comment 11 for bug 1934548

The alternative theory here is that this is always breaking at sbi_send_cpumask_ipi, which is being patched at:

ffffffe0000091e2: fffff097 auipc ra,0xfffff
ffffffe0000091e6: dfe080e7 jalr -514(ra) # ffffffe000007fe0 <ftrace_stub>

I even found ffffffe0000091e2 as one of the addresses being patched (look at __start_mcount_loc). And it happens that the patching code will end up calling flush_icache_range (which is really flush_icache_all). That, in turn, will end up doing some form of IPI.

So, possibly there is a race involved here, where the IPI code is being executed after it is patched, but before icache is flushed. It's hard to think that this segment lies inside a cache boundary, but there is certainly something else necessary for the sync here.