From: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To: jgg@ziepe.ca, liangwenpeng@huawei.com,
linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org,
liweihang@huawei.com, netdev@vger.kernel.org,
syzkaller-bugs@googlegroups.com
Cc: syzbot <syzbot+4f322a6d84e991c38775@syzkaller.appspotmail.com>
Subject: Re: [syzbot] BUG: sleeping function called from invalid context in smc_pnet_apply_ib
Date: Thu, 17 Feb 2022 19:05:31 +0100 [thread overview]
Message-ID: <2691692.BEx9A2HvPv@leap> (raw)
In-Reply-To: <000000000000b772b805d8396f14@google.com>
On giovedì 17 febbraio 2022 17:41:22 CET syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: c832962ac972 net: bridge: multicast: notify switchdev driv..
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x=16b157bc700000
> kernel config: https://syzkaller.appspot.com/x/.config?x=266de9da75c71a45
> dashboard link: https://syzkaller.appspot.com/bug?extid=4f322a6d84e991c38775
> compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+4f322a6d84e991c38775@syzkaller.appspotmail.com
>
> infiniband syz1: set down
> infiniband syz1: added lo
> RDS/IB: syz1: added
> smc: adding ib device syz1 with port count 1
> BUG: sleeping function called from invalid context at kernel/locking/mutex.c:577
> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 17974, name: syz-executor.3
> preempt_count: 1, expected: 0
> RCU nest depth: 0, expected: 0
> 6 locks held by syz-executor.3/17974:
> #0: ffffffff90865838 (&rdma_nl_types[idx].sem){.+.+}-{3:3}, at: rdma_nl_rcv_msg+0x161/0x690 drivers/infiniband/core/netlink.c:164
> #1: ffffffff8d04edf0 (link_ops_rwsem){++++}-{3:3}, at: nldev_newlink+0x25d/0x560 drivers/infiniband/core/nldev.c:1707
> #2: ffffffff8d03e650 (devices_rwsem){++++}-{3:3}, at: enable_device_and_get+0xfc/0x3b0 drivers/infiniband/core/device.c:1321
> #3: ffffffff8d03e510 (clients_rwsem){++++}-{3:3}, at: enable_device_and_get+0x15b/0x3b0 drivers/infiniband/core/device.c:1329
> #4: ffff8880482c85c0 (&device->client_data_rwsem){++++}-{3:3}, at: add_client_context+0x3d0/0x5e0 drivers/infiniband/core/device.c:718
> #5: ffff8880230a4118 (&pnettable->lock){++++}-{2:2}, at: smc_pnetid_by_table_ib+0x18c/0x470 net/smc/smc_pnet.c:1159
> Preemption disabled at:
> [<0000000000000000>] 0x0
> CPU: 1 PID: 17974 Comm: syz-executor.3 Not tainted 5.17.0-rc3-syzkaller-00170-gc832962ac972 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> <TASK>
> __dump_stack lib/dump_stack.c:88 [inline]
> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
> __might_resched.cold+0x222/0x26b kernel/sched/core.c:9576
> __mutex_lock_common kernel/locking/mutex.c:577 [inline]
> __mutex_lock+0x9f/0x12f0 kernel/locking/mutex.c:733
> smc_pnet_apply_ib+0x28/0x160 net/smc/smc_pnet.c:251
> smc_pnetid_by_table_ib+0x2ae/0x470 net/smc/smc_pnet.c:1164
If I recall it well, read_lock() disables preemption.
smc_pnetid_by_table_ib() uses read_lock() and then it calls smc_pnet_apply_ib()
which, in turn, calls mutex_lock(&smc_ib_devices.mutex). Therefore the code
acquires a mutex while in atomic and we get a SAC bug.
Actually, even if my argument is correct(?), I don't know if the read_lock()
in smc_pnetid_by_table_ib() can be converted to a sleeping lock like a mutex or
a semaphore.
Any comment?
Thanks,
Fabio M. De Francesco
next prev parent reply other threads:[~2022-02-17 18:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-17 16:41 [syzbot] BUG: sleeping function called from invalid context in smc_pnet_apply_ib syzbot
2022-02-17 18:05 ` Fabio M. De Francesco [this message]
2022-02-21 8:40 ` Tony Lu
2022-02-21 9:18 ` Tony Lu
2022-02-21 10:21 ` Fabio M. De Francesco
2022-02-17 18:13 ` syzbot
2022-02-23 8:32 ` Fabio M. De Francesco
2022-02-23 9:06 ` syzbot
2022-02-23 9:23 ` Fabio M. De Francesco
2022-02-23 9:40 ` 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=2691692.BEx9A2HvPv@leap \
--to=fmdefrancesco@gmail.com \
--cc=jgg@ziepe.ca \
--cc=liangwenpeng@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=liweihang@huawei.com \
--cc=netdev@vger.kernel.org \
--cc=syzbot+4f322a6d84e991c38775@syzkaller.appspotmail.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 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).