Messages in this thread | | | From | Marc Dionne <> | Date | Tue, 28 Jul 2020 16:11:51 -0300 | Subject | BUG in iscisd with 5.8-rc kernels |
| |
Since some point in the current 5.8 cycle, iscsid sometimes crashes and fails to come up after a reboot.
Here is a sample BUG:
kernel: BUG: scheduling while atomic: iscsid/763/0x00000200
kernel: Call Trace: kernel: dump_stack+0x6b/0x88 kernel: __schedule_bug.cold+0x4c/0x58 kernel: __schedule+0x646/0x800 kernel: schedule+0x4a/0xb0 kernel: __lock_sock+0x69/0x90 kernel: ? finish_wait+0x80/0x80 kernel: lock_sock_nested+0x4f/0x60 kernel: inet_getname+0x98/0xd0 kernel: iscsi_sw_tcp_conn_get_param+0x9b/0x110 [iscsi_tcp] kernel: show_conn_ep_param_ISCSI_PARAM_CONN_ADDRESS+0x6d/0x90 [scsi_transport_iscsi] kernel: dev_attr_show+0x16/0x40 kernel: sysfs_kf_seq_show+0x98/0xf0 kernel: seq_read+0xa8/0x420 kernel: vfs_read+0x9d/0x180 kernel: ksys_read+0x4f/0xc0 kernel: do_syscall_64+0x47/0x80 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
Not areas I'm familiar with, but looking at iscsi_sw_tcp_conn_get_param, it uses this pattern:
spin_lock_bh(&conn->session->frwd_lock) kernel_getsockname()/kernel_getpeername() spin_unlock_bh(&conn->session->frwd_lock)
.. and inet_getname since 1b66d253610c7 ("bpf: Add get{peer, sock}name attach types for sock_addr") has a new BPF_CGROUP_RUN_SA_PROG_LOCK() that will try to lock_sock the socket, while a spinlock is held. I suspect that when this needs to sleep, it triggers the BUG.
I cc'ed the author of that commit, not sure if any other lists would be useful to cc.
Marc
| |