Re: [PATCH V2 3/3] block: model freeze & enter queue as lock for supporting lockdep

[Ming Lei <ming.lei@redhat.com>]

On Wed, Dec 04, 2024 at 11:21:53AM +0800, Lai, Yi wrote:
> On Wed, Oct 30, 2024 at 07:08:48PM +0800, Ming Lei wrote:
> > On Wed, Oct 30, 2024 at 06:39:13PM +0800, Lai, Yi wrote:
> > > On Wed, Oct 30, 2024 at 05:50:15PM +0800, Ming Lei wrote:
> > > > On Wed, Oct 30, 2024 at 4:51 PM Lai, Yi <yi1.lai@linux.intel.com> wrote:
> > > > >
> > > > > On Wed, Oct 30, 2024 at 03:13:09PM +0800, Ming Lei wrote:
> > > > > > On Wed, Oct 30, 2024 at 02:45:03PM +0800, Lai, Yi wrote:
> > > > ...
> > > > > >
> > > > > > It should be addressed by the following patch:
> > > > > >
> > > > > > https://lore.kernel.org/linux-block/ZyEGLdg744U_xBjp@fedora/
> > > > > >
> > > > >
> > > > > I have applied proposed fix patch on top of next-20241029. Issue can
> > > > > still be reproduced.
> > > > >
> > > > > It seems the dependency chain is different from Marek's log and mine.
> > > > 
> > > > Can you post the new log since q->q_usage_counter(io)->fs_reclaim from
> > > > blk_mq_init_sched is cut down by the patch?
> > > >
> > > 
> > > New possible deadlock log after patch applied:
> > 
> > This one looks like one real deadlock, any memory allocation with
> > q->sysfs_lock held has such risk.
> > 
> > There is another similar report related with queue sysfs store operation:
> > 
> > https://lore.kernel.org/linux-scsi/ZxG38G9BuFdBpBHZ@fedora/
> >  
> >
> For v6.13-rc3, there is possible deadlock in
> blk_trace_ioctl/perf_event_ctx_lock_nested/in blk_trace_ioctl. Based on
> my bisection log, it all bisected to your commit f1be1788a32e block:
> model freeze & enter queue as lock for supporting lockdep.
> 
> I am hoping this will be insightful to you.
> 
> possible deadlock in blk_trace_ioctl:
> [   33.317360] ffff88800fc8f3e0 (&mm->mmap_lock){++++}-{4:4}, at: __might_fault+0xf1/0x1b0
> [   33.317859]
> [   33.317859] but task is already holding lock:
> [   33.318206] ffff8880109b92e0 (&q->debugfs_mutex){+.+.}-{4:4}, at: blk_trace_ioctl+0xaa/0x290
> [   33.318722]
> [   33.318722] which lock already depends on the new lock.
> [   33.318722]

The warning has been fixed by the following patches in for-6.14/block:

blktrace: move copy_[to|from]_user() out of ->debugfs_lock
blktrace: don't centralize grabbing q->debugfs_mutex in blk_trace_ioctl

https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/log/?h=for-6.14/block


Thanks,
Ming