On 25.4.2023. 17:33, Leon Romanovsky wrote:
On Tue, Apr 25, 2023 at 11:35:48AM +0200, Mirsad Goran Todorovac wrote:In the function ieee80211_tx_dequeue() there is a particular locking sequence: begin: spin_lock(&local->queue_stop_reason_lock); q_stopped = local->queue_stop_reasons[q]; spin_unlock(&local->queue_stop_reason_lock); However small the chance (increased by ftracetest), an asynchronous interrupt can occur in between of spin_lock() and spin_unlock(), and the interrupt routine will attempt to lock the same &local->queue_stop_reason_lock again. This will cause a costly reset of the CPU and the wifi device or an altogether hang in the single CPU and single core scenario. This is the probable trace of the deadlock: Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel: Possible unsafe locking scenario: Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel: CPU0 Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel: ---- Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel: lock(&local->queue_stop_reason_lock); Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel: <Interrupt> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel: lock(&local->queue_stop_reason_lock); Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel: *** DEADLOCK ***Can you please add to the commit message whole lockdep trace? And please trim "Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel: " line prefix, it doesn't add any value.
Sure. I will do this ASAP. I thought of it myself, but I reckoned it would be an overkill. Will come in PATCH v4. Best regards, Mirsad -- Mirsad Todorovac System engineer Faculty of Graphic Arts | Academy of Fine Arts University of Zagreb Republic of Croatia, the European Union Sistem inženjer Grafički fakultet | Akademija likovnih umjetnosti Sveučilište u Zagrebu
