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
