On Sun, Oct 18, 2026 at 10:13:40PM +0700, Nguyen Ngoc Thang wrote:
gb_operation_request_send() sends the request message and only then arms the operation timer. The host driver can complete the operation before add_timer() runs, e.g. when the transfer fails right away. The completion work then calls timer_delete_sync() on a timer that is not armed yet, the synchronous caller wakes up and drops the last reference, and the operation is freed while the timer is still pending:
ODEBUG: free active (active state 0) object type: timer_list hint: gb_operation_timeout+0x0/0xc0 WARNING: lib/debugobjects.c:629 at debug_print_object+0x198/0x2b0 kmem_cache_free+0xfd/0x6d0 gb_operation_sync_timeout+0x1c7/0x270 gb_svc_process_deferred_request+0x5f3/0x1150
Arm the timer before the message is sent. If sending fails, delete the timer again. If it has already fired, its work is queued and drops the active and operation references itself, so the error path must not drop them a second time.
Fixing this is going to be a bit more involved, for example, as you now have to deal with the request message potentially being cancelled before it has been submitted.
Sashiko also flagged this, and some other implications:
https://sashiko.dev/#/patchset/20261017171743.24612-1-ngocthang2710.1999%40g...
Johan