linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: yanfei.xu@windriver.com, damien.lemoal@wdc.com
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] block: fix possible bd_size_lock deadlock
Date: Fri, 12 Mar 2021 12:37:47 -0700	[thread overview]
Message-ID: <af8f7d00-d612-c0d2-e254-ff3c967fb94c@kernel.dk> (raw)
In-Reply-To: <20210311121139.205222-1-yanfei.xu@windriver.com>

On 3/11/21 5:11 AM, yanfei.xu@windriver.com wrote:
> From: Yanfei Xu <yanfei.xu@windriver.com>
> 
> bd_size_lock spinlock could be taken in block softirq, thus we should
> disable the softirq before taking the lock.
> 
> WARNING: inconsistent lock state
> 5.12.0-rc2-syzkaller #0 Not tainted
> --------------------------------
> inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-R} usage.
> kworker/u4:0/7 [HC0[0]:SC1[1]:HE0:SE0] takes:
> 8f87826c (&inode->i_size_seqcount){+.+-}-{0:0}, at:
> end_bio_bh_io_sync+0x38/0x54 fs/buffer.c:3006
> {SOFTIRQ-ON-W} state was registered at:
>   lock_acquire.part.0+0xf0/0x41c kernel/locking/lockdep.c:5510
>   lock_acquire+0x6c/0x74 kernel/locking/lockdep.c:5483
>   do_write_seqcount_begin_nested include/linux/seqlock.h:520 [inline]
>   do_write_seqcount_begin include/linux/seqlock.h:545 [inline]
>   i_size_write include/linux/fs.h:863 [inline]
>   set_capacity+0x13c/0x1f8 block/genhd.c:50
>   brd_alloc+0x130/0x180 drivers/block/brd.c:401
>   brd_init+0xcc/0x1e0 drivers/block/brd.c:500
>   do_one_initcall+0x8c/0x59c init/main.c:1226
>   do_initcall_level init/main.c:1299 [inline]
>   do_initcalls init/main.c:1315 [inline]
>   do_basic_setup init/main.c:1335 [inline]
>   kernel_init_freeable+0x2cc/0x330 init/main.c:1537
>   kernel_init+0x10/0x120 init/main.c:1424
>   ret_from_fork+0x14/0x20 arch/arm/kernel/entry-common.S:158
>   0x0
> irq event stamp: 2783413
> hardirqs last  enabled at (2783412): [<802011ec>]
> __do_softirq+0xf4/0x7ac kernel/softirq.c:329
> hardirqs last disabled at (2783413): [<8277d260>]
> __raw_read_lock_irqsave include/linux/rwlock_api_smp.h:157 [inline]
> hardirqs last disabled at (2783413): [<8277d260>]
> _raw_read_lock_irqsave+0x84/0x88 kernel/locking/spinlock.c:231
> softirqs last  enabled at (2783410): [<826b5050>] spin_unlock_bh
> include/linux/spinlock.h:399 [inline]
> softirqs last  enabled at (2783410): [<826b5050>]
> batadv_nc_purge_paths+0x10c/0x148 net/batman-adv/network-coding.c:467
> softirqs last disabled at (2783411): [<8024ddfc>] do_softirq_own_stack
> include/asm-generic/softirq_stack.h:10 [inline]
> softirqs last disabled at (2783411): [<8024ddfc>] do_softirq
> kernel/softirq.c:248 [inline]
> softirqs last disabled at (2783411): [<8024ddfc>] do_softirq+0xd8/0xe4
> kernel/softirq.c:235
> 
> other info that might help us debug this:
>  Possible unsafe locking scenario:
> 
>        CPU0
>        ----
>   lock(&inode->i_size_seqcount);
>   <Interrupt>
>     lock(&inode->i_size_seqcount);
> 
>  *** DEADLOCK ***
> 
> 3 locks held by kworker/u4:0/7:
>  #0: 88c622a8 ((wq_completion)bat_events){+.+.}-{0:0}, at: set_work_data
> kernel/workqueue.c:615 [inline]
>  #0: 88c622a8 ((wq_completion)bat_events){+.+.}-{0:0}, at:
> set_work_pool_and_clear_pending kernel/workqueue.c:643 [inline]
>  #0: 88c622a8 ((wq_completion)bat_events){+.+.}-{0:0}, at:
> process_one_work+0x214/0x998 kernel/workqueue.c:2246
>  #1: 85147ef8
> ((work_completion)(&(&bat_priv->nc.work)->work)){+.+.}-{0:0}, at:
> set_work_data kernel/workqueue.c:615 [inline]
>  #1: 85147ef8
> ((work_completion)(&(&bat_priv->nc.work)->work)){+.+.}-{0:0}, at:
> set_work_pool_and_clear_pending kernel/workqueue.c:643 [inline]
>  #1: 85147ef8
> ((work_completion)(&(&bat_priv->nc.work)->work)){+.+.}-{0:0}, at:
> process_one_work+0x214/0x998 kernel/workqueue.c:2246
>  #2: 8f878010 (&ni->size_lock){...-}-{2:2}, at:
> ntfs_end_buffer_async_read+0x6c/0x558 fs/ntfs/aops.c:66

Damien? We have that revert queued up for this for 5.12, but looking
at that, the state before that was kind of messy too.


-- 
Jens Axboe


  reply	other threads:[~2021-03-12 19:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-11 12:11 [PATCH] block: fix possible bd_size_lock deadlock yanfei.xu
2021-03-12 19:37 ` Jens Axboe [this message]
2021-03-12 22:32   ` Damien Le Moal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=af8f7d00-d612-c0d2-e254-ff3c967fb94c@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=damien.lemoal@wdc.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yanfei.xu@windriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).