linux-kernel - Re: [RFC PATCH] block: Make request_queue lockdep splats show up earlier

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <13031d34692b0c97799de81c0b83875d56076e13.camel@linux.intel.com>
Date: Mon, 17 Mar 2025 19:13:10 +0100
From: Thomas Hellström <thomas.hellstrom@...ux.intel.com>
To: Bart Van Assche <bvanassche@....org>, Jens Axboe <axboe@...nel.dk>
Cc: linux-block@...r.kernel.org, linux-kernel@...r.kernel.org, Ming Lei
	 <ming.lei@...hat.com>
Subject: Re: [RFC PATCH] block: Make request_queue lockdep splats show up
 earlier

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