Re: lockdep splats with blk-mq drivers

[Sebastian Ott <sebott@linux.ibm.com>]

Hi,

On Thu, 19 Apr 2018, Sebastian Ott wrote:
> Since commit 1d9bd5161ba3 ("blk-mq: replace timeout synchronization with a
> RCU and generation based scheme") I observe lockdep complaints (full
> message attached):
> 
> [   21.763369]        CPU0                    CPU1
> [   21.763370]        ----                    ----
> [   21.763371]   lock(&rq->gstate_seq);
> [   21.763374]                                local_irq_disable();
> [   21.763375]                                lock(&(&dq->lock)->rlock);
> [   21.763377]                                lock(&rq->gstate_seq);
> [   21.763379]   <Interrupt>
> [   21.763380]     lock(&(&dq->lock)->rlock);
> [   21.763382] 
>                 *** DEADLOCK ***
> 
> 
> This only happens in combination with DASD (s390 specific) and another
> blk-mq driver (scsi, null_blk). The distinctive behavior of DASD is that
> it calls blk_mq_start_request with irqs disabled.
> 
> This is a false positive since gstate_seq on CPU0 is from a different
> request queue / block driver than gstate_seq on CPU1.
> 
> Possible fixes are to use local_irq_save/restore in blk_mq_start_request.
> Or, since it's a false positive, teach lockdep that these are different
> locks - like below:

Something we can do here? I've send 2 proposals to address this. Do they
make sense?

Regards,
Sebastian