Re: [RFC PATCH] block: Make request_queue lockdep splats show up earlier
From: Thomas Hellström
Date: Mon Mar 17 2025 - 14:13:37 EST
On Mon, 2025-03-17 at 10:37 -0700, Bart Van Assche wrote:
> On 3/17/25 10:11 AM, Thomas Hellström wrote:
> > diff --git a/block/blk-core.c b/block/blk-core.c
> > index d6c4fa3943b5..4aa439309406 100644
> > --- a/block/blk-core.c
> > +++ b/block/blk-core.c
> > @@ -455,6 +455,12 @@ struct request_queue *blk_alloc_queue(struct
> > queue_limits *lim, int node_id)
> > lockdep_init_map(&q->q_lockdep_map, "&q-
> > >q_usage_counter(queue)",
> > &q->q_lock_cls_key, 0);
> >
> > + /* Prime io_lockdep_map as reclaim tainted */
> > + fs_reclaim_acquire(GFP_KERNEL);
> > + rwsem_acquire_read(&q->io_lockdep_map, 0, 0, _RET_IP_);
> > + rwsem_release(&q->io_lockdep_map, _RET_IP_);
> > + fs_reclaim_release(GFP_KERNEL);
> > +
> > q->nr_requests = BLKDEV_DEFAULT_RQ;
> >
> > return q;
>
> Hmm ... my understanding is that it is fine if FS code calls block
> layer
> code but also that block layer code never should call FS code.
>
> Thanks,
>
> Bart.
That added code only mimics the locking sequence that happens during
reclaim with the existing code to register the locking order expected
by the reclaim code. If anything violates that, lockdep splat [2] will
appear.
So I'm not quite following your comment?
Thanks,
Thomas