I am not entirely sure I understood your question correctly, hopefully I got it right. I think your question is that this patch only helps if T_1 sets rgi->killed_for_retry _before_ T_2 executes the above code that does wait_for_pending_deadlock_kill(). So what if T_1 does so a bit later, after T_2 has already proceeded beyond this check?
That's so.
Now consider the second case, where T_1 only sets rgi->killed_for_retry _after_ T_2 has passed the above code point:
1. T_2 acquires some lock inside InnoDB
2. T_2 passes the above code point with the check for rgi->killed_for_retry, it calls mark_start_commit() and starts the commit process.
3. T_1 only now gets a lock conflict with T_2, it calls thd_rpl_deadlock_check(), sets rgi->killed_for_retry, schedules a task for the manager thread to kill T_2
4. T_1 goes to wait on the lock.
In this situation, the lock in InnoDB was still held by T_2 when it ran mark_start_commit().
Hmm, this is unclear. I thought you had a case in which T_2 releases an innodb stats lock at the end of its current statement. And T_1 would try to acquire the lock within that timeframe. Am I confused in the above? It'd be great to have a T_2 worker stack at time of the lock is granted to it, but it's not provided.. Obvisoulsy under this perception T_2 would execute mark_start_commit() after the lock is released. Please clear it out.