On Wed, 2018-09-19 at 10:21 +-0800, jianchao.wang wrote: +AD4 On 09/19/2018 01:44 AM, Bart Van Assche wrote: +AD4 +AD4 There is only one blk+AF8-pm+AF8-request+AF8-resume() call and that call is +AD4 +AD4 inside blk+AF8-queue+AF8-enter() after the pm+AF8-only counter has been +AD4 +AD4 checked. +AD4 +AD4 +AD4 +AD4 For the legacy block layer, nr+AF8-pending is increased after the +AD4 +AD4 blk+AF8-queue+AF8-enter() call from inside blk+AF8-old+AF8-get+AF8-request() succeeded. +AD4 +AD4 +AD4 +AD4 So I don't see how blk+AF8-pm+AF8-request+AF8-resume() or q-+AD4-nr+AF8-pending+-+- could +AD4 +AD4 escape from the preempt checking? +AD4 +AD4 For example: +AD4 +AD4 +AD4 blk+AF8-pre+AF8-runtime+AF8-suspend generic+AF8-make+AF8-request +AD4 blk+AF8-queue+AF8-enter // +AD4 success here, no blk+AF8-pm+AF8-request+AF8-resume here +AD4 blk+AF8-mq+AF8-make+AF8-requset +AD4 blk+AF8-set+AF8-pm+AF8-only +AD4 +AD4 if (blk+AF8-requests+AF8-in+AF8-flight(q) +AD0APQ 0) +AHs +AD4 synchronize+AF8-rcu()+ADs +AD4 if (blk+AF8-requests+AF8-in+AF8-flight(q) +AD0APQ 0) +AD4 ret +AD0 0+ADs +AD4 +AH0 +AD4 blk+AF8-mq+AF8-get+AF8-request Hello Jianchao, I think you are right. I will add a q+AF8-usage+AF8-counter check before setting 'ret' to zero. Bart.
