On 01/08/19 23:47, Thomas Gleixner wrote: > Right you are about cond_resched() being called, but for SRCU this does not > matter unless there is some way to do a synchronize operation on that SRCU > entity. It might have some other performance side effect though. I would use srcu_read_unlock/lock around the call. However, I'm wondering if the API can be improved because basically we have six functions for three checks of TIF flags. Does it make sense to have something like task_has_request_flags and task_do_requests (names are horrible I know) that can be used like if (task_has_request_flags()) { int err; ...srcu_read_unlock... // return -EINTR if signal_pending err = task_do_requests(); if (err < 0) goto exit_no_srcu_read_unlock; ...srcu_read_lock... } taking care of all three cases with a single hook? This is important especially because all these checks are done by all KVM architectures in slightly different ways, and a unified API would be a good reason to make all architectures look the same. (Of course I could also define this unified API in virt/kvm/kvm_main.c, so this is not blocking the series in any way!). Paolo