All of lore.kernel.org
 help / color / mirror / Atom feed
From: syzbot <syzbot+dcd73ff9291e6d34b3ab@syzkaller.appspotmail.com>
To: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org,
	netdev@vger.kernel.org, pabeni@redhat.com,
	rds-devel@oss.oracle.com, santosh.shilimkar@oracle.com,
	syzkaller-bugs@googlegroups.com
Subject: [syzbot] possible deadlock in rds_wake_sk_sleep (4)
Date: Wed, 18 May 2022 20:35:33 -0700	[thread overview]
Message-ID: <000000000000fae03b05df551046@google.com> (raw)

Hello,

syzbot found the following issue on:

HEAD commit:    1e1b28b936ae Add linux-next specific files for 20220513
git tree:       linux-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=10117426f00000
kernel config:  https://syzkaller.appspot.com/x/.config?x=e4eb3c0c4b289571
dashboard link: https://syzkaller.appspot.com/bug?extid=dcd73ff9291e6d34b3ab
compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=16cc3759f00000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15e9e209f00000

Bisection is inconclusive: the issue happens on the oldest tested release.

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=11e218c6f00000
final oops:     https://syzkaller.appspot.com/x/report.txt?x=13e218c6f00000
console output: https://syzkaller.appspot.com/x/log.txt?x=15e218c6f00000

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

======================================================
WARNING: possible circular locking dependency detected
5.18.0-rc6-next-20220513-syzkaller #0 Not tainted
------------------------------------------------------
kworker/u4:1/11 is trying to acquire lock:
ffff88807603bc60 (&rs->rs_recv_lock){...-}-{2:2}, at: rds_wake_sk_sleep+0x1f/0xe0 net/rds/af_rds.c:109

but task is already holding lock:
ffff88801a9f6100 (&rm->m_rs_lock){..-.}-{2:2}, at: rds_send_remove_from_sock+0x340/0x9e0 net/rds/send.c:628

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (&rm->m_rs_lock){..-.}-{2:2}:
       __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
       _raw_spin_lock_irqsave+0x39/0x50 kernel/locking/spinlock.c:162
       rds_message_purge net/rds/message.c:138 [inline]
       rds_message_put+0x1d9/0xc20 net/rds/message.c:180
       rds_inc_put net/rds/recv.c:82 [inline]
       rds_inc_put+0x13a/0x1a0 net/rds/recv.c:76
       rds_clear_recv_queue+0x147/0x350 net/rds/recv.c:767
       rds_release+0xd4/0x3b0 net/rds/af_rds.c:73
       __sock_release+0xcd/0x280 net/socket.c:650
       sock_close+0x18/0x20 net/socket.c:1365
       __fput+0x277/0x9d0 fs/file_table.c:317
       task_work_run+0xdd/0x1a0 kernel/task_work.c:177
       ptrace_notify+0x114/0x140 kernel/signal.c:2353
       ptrace_report_syscall include/linux/ptrace.h:420 [inline]
       ptrace_report_syscall_exit include/linux/ptrace.h:482 [inline]
       syscall_exit_work kernel/entry/common.c:249 [inline]
       syscall_exit_to_user_mode_prepare+0xdb/0x230 kernel/entry/common.c:276
       __syscall_exit_to_user_mode_work kernel/entry/common.c:281 [inline]
       syscall_exit_to_user_mode+0x9/0x50 kernel/entry/common.c:294
       do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86
       entry_SYSCALL_64_after_hwframe+0x46/0xb0

-> #0 (&rs->rs_recv_lock){...-}-{2:2}:
       check_prev_add kernel/locking/lockdep.c:3095 [inline]
       check_prevs_add kernel/locking/lockdep.c:3214 [inline]
       validate_chain kernel/locking/lockdep.c:3829 [inline]
       __lock_acquire+0x2abe/0x5660 kernel/locking/lockdep.c:5053
       lock_acquire kernel/locking/lockdep.c:5665 [inline]
       lock_acquire+0x1ab/0x570 kernel/locking/lockdep.c:5630
       __raw_read_lock_irqsave include/linux/rwlock_api_smp.h:160 [inline]
       _raw_read_lock_irqsave+0x45/0x90 kernel/locking/spinlock.c:236
       rds_wake_sk_sleep+0x1f/0xe0 net/rds/af_rds.c:109
       rds_send_remove_from_sock+0xb9/0x9e0 net/rds/send.c:634
       rds_send_path_drop_acked+0x2ef/0x3d0 net/rds/send.c:710
       rds_tcp_write_space+0x1b1/0x690 net/rds/tcp_send.c:198
       tcp_new_space net/ipv4/tcp_input.c:5451 [inline]
       tcp_check_space net/ipv4/tcp_input.c:5470 [inline]
       tcp_check_space+0x3d0/0x800 net/ipv4/tcp_input.c:5464
       tcp_data_snd_check net/ipv4/tcp_input.c:5479 [inline]
       tcp_rcv_established+0x8c4/0x20e0 net/ipv4/tcp_input.c:5986
       tcp_v4_do_rcv+0x66c/0x980 net/ipv4/tcp_ipv4.c:1659
       sk_backlog_rcv include/net/sock.h:1050 [inline]
       __release_sock+0x134/0x3b0 net/core/sock.c:2832
       release_sock+0x54/0x1b0 net/core/sock.c:3387
       rds_send_xmit+0x143f/0x2540 net/rds/send.c:422
       rds_send_worker+0x92/0x2e0 net/rds/threads.c:200
       process_one_work+0x996/0x1610 kernel/workqueue.c:2289
       worker_thread+0x665/0x1080 kernel/workqueue.c:2436
       kthread+0x2e9/0x3a0 kernel/kthread.c:376
       ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:297

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&rm->m_rs_lock);
                               lock(&rs->rs_recv_lock);
                               lock(&rm->m_rs_lock);
  lock(&rs->rs_recv_lock);

 *** DEADLOCK ***

5 locks held by kworker/u4:1/11:
 #0: ffff888024ca6938 ((wq_completion)krdsd){+.+.}-{0:0}, at: arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
 #0: ffff888024ca6938 ((wq_completion)krdsd){+.+.}-{0:0}, at: arch_atomic_long_set include/linux/atomic/atomic-long.h:41 [inline]
 #0: ffff888024ca6938 ((wq_completion)krdsd){+.+.}-{0:0}, at: atomic_long_set include/linux/atomic/atomic-instrumented.h:1280 [inline]
 #0: ffff888024ca6938 ((wq_completion)krdsd){+.+.}-{0:0}, at: set_work_data kernel/workqueue.c:636 [inline]
 #0: ffff888024ca6938 ((wq_completion)krdsd){+.+.}-{0:0}, at: set_work_pool_and_clear_pending kernel/workqueue.c:663 [inline]
 #0: ffff888024ca6938 ((wq_completion)krdsd){+.+.}-{0:0}, at: process_one_work+0x87a/0x1610 kernel/workqueue.c:2260
 #1: ffffc90000107da8 ((work_completion)(&(&cp->cp_send_w)->work)){+.+.}-{0:0}, at: process_one_work+0x8ae/0x1610 kernel/workqueue.c:2264
 #2: ffff8880781d0d30 (k-sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1680 [inline]
 #2: ffff8880781d0d30 (k-sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sock_set_cork+0x16/0x90 net/ipv4/tcp.c:3215
 #3: ffff8880781d0fb8 (k-clock-AF_INET){++.-}-{2:2}, at: rds_tcp_write_space+0x25/0x690 net/rds/tcp_send.c:184
 #4: ffff88801a9f6100 (&rm->m_rs_lock){..-.}-{2:2}, at: rds_send_remove_from_sock+0x340/0x9e0 net/rds/send.c:628

stack backtrace:
CPU: 0 PID: 11 Comm: kworker/u4:1 Not tainted 5.18.0-rc6-next-20220513-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: krdsd rds_send_worker
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
 check_noncircular+0x25f/0x2e0 kernel/locking/lockdep.c:2175
 check_prev_add kernel/locking/lockdep.c:3095 [inline]
 check_prevs_add kernel/locking/lockdep.c:3214 [inline]
 validate_chain kernel/locking/lockdep.c:3829 [inline]
 __lock_acquire+0x2abe/0x5660 kernel/locking/lockdep.c:5053
 lock_acquire kernel/locking/lockdep.c:5665 [inline]
 lock_acquire+0x1ab/0x570 kernel/locking/lockdep.c:5630
 __raw_read_lock_irqsave include/linux/rwlock_api_smp.h:160 [inline]
 _raw_read_lock_irqsave+0x45/0x90 kernel/locking/spinlock.c:236
 rds_wake_sk_sleep+0x1f/0xe0 net/rds/af_rds.c:109
 rds_send_remove_from_sock+0xb9/0x9e0 net/rds/send.c:634
 rds_send_path_drop_acked+0x2ef/0x3d0 net/rds/send.c:710
 rds_tcp_write_space+0x1b1/0x690 net/rds/tcp_send.c:198
 tcp_new_space net/ipv4/tcp_input.c:5451 [inline]
 tcp_check_space net/ipv4/tcp_input.c:5470 [inline]
 tcp_check_space+0x3d0/0x800 net/ipv4/tcp_input.c:5464
 tcp_data_snd_check net/ipv4/tcp_input.c:5479 [inline]
 tcp_rcv_established+0x8c4/0x20e0 net/ipv4/tcp_input.c:5986
 tcp_v4_do_rcv+0x66c/0x980 net/ipv4/tcp_ipv4.c:1659
 sk_backlog_rcv include/net/sock.h:1050 [inline]
 __release_sock+0x134/0x3b0 net/core/sock.c:2832
 release_sock+0x54/0x1b0 net/core/sock.c:3387
 rds_send_xmit+0x143f/0x2540 net/rds/send.c:422
 rds_send_worker+0x92/0x2e0 net/rds/threads.c:200
 process_one_work+0x996/0x1610 kernel/workqueue.c:2289
 worker_thread+0x665/0x1080 kernel/workqueue.c:2436
 kthread+0x2e9/0x3a0 kernel/kthread.c:376
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:297
 </TASK>


---
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 syzkaller@googlegroups.com.

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

             reply	other threads:[~2022-05-19  3:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-19  3:35 syzbot [this message]
2024-01-31 15:34 ` [syzbot] Re: Test [syzbot] possible deadlock in rds_wake_sk_sleep syzbot
     [not found] <20220519115146.2526-1-hdanton@sina.com>
2022-05-19 12:11 ` [syzbot] possible deadlock in rds_wake_sk_sleep (4) syzbot

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=000000000000fae03b05df551046@google.com \
    --to=syzbot+dcd73ff9291e6d34b3ab@syzkaller.appspotmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rds-devel@oss.oracle.com \
    --cc=santosh.shilimkar@oracle.com \
    --cc=syzkaller-bugs@googlegroups.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.