čt 19. 10. 2023 v 7:29 odesílatel Yi Zhang <yi.zhang@xxxxxxxxxx> napsal: > > Hi Hannes > Bisect shows it was introduced from this commit: > > commit 675b453e024154dd547921c6e6d5b58747ba7e0e > Author: Hannes Reinecke <hare@xxxxxxx> > Date: Thu Aug 24 16:39:23 2023 +0200 > > nvmet-tcp: enable TLS handshake upcall st 18. 10. 2023 v 16:08 odesílatel Yi Zhang <yi.zhang@xxxxxxxxxx> napsal: > > [ 5161.405594] ODEBUG: assert_init not available (active state 0) > [ 5161.521808] Workqueue: nvmet-wq nvmet_tcp_release_queue_work [nvmet_tcp] > [ 5161.697797] __timer_delete+0x70/0x170 > [ 5161.701550] ? __pfx___timer_delete+0x10/0x10 > [ 5161.705907] ? __mutex_lock+0x741/0x14b0 > [ 5161.709833] ? try_to_grab_pending+0x70/0x80 > [ 5161.714105] ? rcu_is_watching+0x11/0xb0 > [ 5161.718032] try_to_grab_pending+0x46/0x80 > [ 5161.722132] __cancel_work_timer+0xa0/0x460 > [ 5161.726318] ? mutex_lock_io_nested+0x1273/0x1310 > [ 5161.731024] ? __pfx___cancel_work_timer+0x10/0x10 > [ 5161.735816] ? do_raw_write_trylock+0xb5/0x190 > [ 5161.740260] ? __pfx_do_raw_write_trylock+0x10/0x10 > [ 5161.745141] ? rcu_is_watching+0x11/0xb0 > [ 5161.749066] ? trace_irq_enable.constprop.0+0x13d/0x180 > [ 5161.754292] ? __pfx_sk_stream_write_space+0x10/0x10 > [ 5161.759258] nvmet_tcp_release_queue_work+0x2db/0x1350 [nvmet_tcp] Maybe the problem is that nvmet_tcp_release_queue_work() always calls cancel_delayed_work_sync() against the tls_handshake_tmo_work timer, but the latter is initialized only if CONFIG_NVME_TARGET_TCP_TLS is defined. Maurizio
