inconsistent lock state in free_huge_page

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 3207316b Linux 4.19.164
git tree: linux-4.19.y
console output: https://syzkaller.appspot.com/x/log.txt?x=108627df500000
kernel config: https://syzkaller.appspot.com/x/.config?x=ce6a43827932e236
dashboard link: https://syzkaller.appspot.com/bug?extid=2bd7d01eead6a479fd4f
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13b2a8c0d00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14528e93500000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+2bd7d0...@syzkaller.appspotmail.com

================================
WARNING: inconsistent lock state
4.19.164-syzkaller #0 Not tainted
--------------------------------
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
000000001c188194 (hugetlb_lock){?.+.}, at: spin_lock include/linux/spinlock.h:329 [inline]
000000001c188194 (hugetlb_lock){?.+.}, at: free_huge_page+0x482/0xd20 mm/hugetlb.c:1276
{HARDIRQ-ON-W} state was registered at:
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:144
spin_lock include/linux/spinlock.h:329 [inline]
hugetlb_overcommit_handler+0x2d4/0x460 mm/hugetlb.c:2999
proc_sys_call_handler.isra.0+0x1f3/0x3b0 fs/proc/proc_sysctl.c:597
__vfs_write+0xf7/0x770 fs/read_write.c:485
vfs_write+0x1f3/0x540 fs/read_write.c:549
ksys_write+0x12b/0x2a0 fs/read_write.c:599
do_syscall_64+0xf9/0x620 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
irq event stamp: 121222
hardirqs last enabled at (121219): [<ffffffff8815d0a7>] default_idle+0x17/0x310 arch/x86/kernel/process.c:557
hardirqs last disabled at (121220): [<ffffffff8100432f>] trace_hardirqs_off_thunk+0x1a/0x1c
softirqs last enabled at (121222): [<ffffffff813a3acd>] irq_enter+0xbd/0xd0 kernel/softirq.c:354
softirqs last disabled at (121221): [<ffffffff813a3ab2>] irq_enter+0xa2/0xd0 kernel/softirq.c:358

other info that might help us debug this:
Possible unsafe locking scenario:

CPU0
----
lock(hugetlb_lock);
<Interrupt>
lock(hugetlb_lock);

*** DEADLOCK ***

1 lock held by swapper/0/0:
#0: 00000000da6fe65d (&(&virtscsi_vq->vq_lock)->rlock){-.-.}, at: virtscsi_vq_done drivers/scsi/virtio_scsi.c:219 [inline]
#0: 00000000da6fe65d (&(&virtscsi_vq->vq_lock)->rlock){-.-.}, at: virtscsi_req_done+0x123/0x210 drivers/scsi/virtio_scsi.c:238

stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.164-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1fc/0x2fe lib/dump_stack.c:118
print_usage_bug.cold+0x42e/0x570 kernel/locking/lockdep.c:2544
valid_state kernel/locking/lockdep.c:2557 [inline]
mark_lock_irq kernel/locking/lockdep.c:2751 [inline]
mark_lock+0xc70/0x1160 kernel/locking/lockdep.c:3131
mark_irqflags kernel/locking/lockdep.c:3006 [inline]
__lock_acquire+0x1077/0x3ff0 kernel/locking/lockdep.c:3372
lock_acquire+0x170/0x3c0 kernel/locking/lockdep.c:3907
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:144
spin_lock include/linux/spinlock.h:329 [inline]
free_huge_page+0x482/0xd20 mm/hugetlb.c:1276
__put_page+0xe2/0x3a0 mm/swap.c:112
put_page include/linux/mm.h:963 [inline]
bio_release_pages+0x1cf/0x320 block/bio.c:1607
bio_check_pages_dirty+0x272/0x410 block/bio.c:1659
dio_bio_complete+0x567/0x710 fs/direct-io.c:552
dio_bio_end_aio+0x42/0x490 fs/direct-io.c:357
bio_endio+0x471/0x810 block/bio.c:1780
req_bio_endio block/blk-core.c:278 [inline]
blk_update_request+0x30f/0xaf0 block/blk-core.c:3111
scsi_end_request+0x7d/0xb60 drivers/scsi/scsi_lib.c:673
scsi_io_completion+0x279/0x17c0 drivers/scsi/scsi_lib.c:1102
scsi_softirq_done+0x336/0x3d0 drivers/scsi/scsi_lib.c:1758
__blk_mq_complete_request block/blk-mq.c:583 [inline]
blk_mq_complete_request+0x472/0x660 block/blk-mq.c:620
virtscsi_vq_done drivers/scsi/virtio_scsi.c:223 [inline]
virtscsi_req_done+0x14b/0x210 drivers/scsi/virtio_scsi.c:238
vring_interrupt+0x12f/0x220 drivers/virtio/virtio_ring.c:953
__handle_irq_event_percpu+0x27e/0x8e0 kernel/irq/handle.c:149
handle_irq_event_percpu kernel/irq/handle.c:189 [inline]
handle_irq_event+0x102/0x285 kernel/irq/handle.c:206
handle_edge_irq+0x260/0xcf0 kernel/irq/chip.c:797
generic_handle_irq_desc include/linux/irqdesc.h:155 [inline]
handle_irq+0x35/0x50 arch/x86/kernel/irq_64.c:87
do_IRQ+0x93/0x1c0 arch/x86/kernel/irq.c:246
common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670
</IRQ>
RIP: 0010:native_safe_halt+0xe/0x10 arch/x86/include/asm/irqflags.h:61
Code: 48 89 df e8 44 1f 85 f9 e9 2e ff ff ff 48 89 df e8 37 1f 85 f9 eb 82 90 90 90 90 90 e9 07 00 00 00 0f 00 2d 14 aa 51 00 fb f4 <c3> 90 e9 07 00 00 00 0f 00 2d 04 aa 51 00 f4 c3 90 90 41 56 41 55
RSP: 0018:ffffffff89e07d40 EFLAGS: 00000282 ORIG_RAX: ffffffffffffffda
RAX: 1ffffffff13e3034 RBX: dffffc0000000000 RCX: 0000000000000000
RDX: dffffc0000000000 RSI: 0000000000000001 RDI: ffffffff89e78904
RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff89f18190
R13: 1ffffffff13c0fb2 R14: 0000000000000000 R15: 0000000000000000
arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
default_idle+0x49/0x310 arch/x86/kernel/process.c:557
cpuidle_idle_call kernel/sched/idle.c:153 [inline]
do_idle+0x2ec/0x4b0 kernel/sched/idle.c:263
cpu_startup_entry+0xc5/0xe0 kernel/sched/idle.c:369


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches