This is addressing a bit of a big problem we're hitting with the way optimized code is getting generated for kernel binaries today; we have a central function that has a function call with one set of unwind rules, but the return address is a different block with really different unwind rules (maybe it's a noreturn call, I didn't read through the source tbh).
It's the usual problem with this kind of thing - we need to decrement the return pc before looking up the scope for unwind rules. The patch is straightforward, but I haven't come up with any way to test it short of "have a kernel binary and corefile" and I can't use either of those (no small part of it being that they're enormous). Not thrilled about this, but I haven't come up with a synthetic repo case for it.
I don't know who would be a good reviewer given how little I can provide here - I'll add Pavel and Greg, but don't feel obligated to give an opinion if you don't have time to look at the code. I would let this simmer for longer trying to come up with some kind of test case, but it happens to impact a code sequence that is hit by a lot of internal people here, so I need to get going with a fix.
Don't we want to subtract 1 here? Otherwise this function might return true incorrectly if we actually need to subtract at least 1 from the PC