On Fri, Dec 6, 2024 at 11:56 AM Etienne <etmartin4313@xxxxxxxxx> wrote: > > > > I tried this V9 patchset and realized that upon max_request_timeout the connection will be dropped irrespectively if the task is in D state or not. I guess this is expected behavior. > > > > Yes, the connection will be dropped regardless of what state the task is in. > Thanks for confirmation > > > > > > To me the concerning aspect is when tasks are going in D state because of the consequence when running with hung_task_timeout_secs and hung_task_panic=1. > > > > Could you elaborate on this a bit more? When running with > > hung_task_timeout_secs and hung_task_panic=1, how does it cause the > > task to go into D state? > > Sorry for the confusion. It doesn't cause tasks to go in D state. > What I meant is that I've been looking for a way to terminate tasks > stuck in D state because we have hung_task_panic=1 and this is causing > bad consequences when they trigger the hung task timer. Gotcha, thanks for clarifying! > > > > Here this timer may get queued and if echo 1 > /sys/fs/fuse/connections/'nn'/abort is done at more or less the same time over the same connection I'm wondering what will happen? > > > At least I think we may need timer_delete_sync() instead of timer_delete() in fuse_abort_conn() and potentially call it from the top of fuse_abort_conn() instead. > > > > I don't think this is an issue because there's still a reference on > > the "struct fuse_conn" when fuse_abort_conn() is called. The fuse_conn > > struct is freed in fuse_conn_put() when the last refcount is dropped, > > and in fuse_conn_put() there's this line > > > > if (fc->timeout.req_timeout) > > timer_shutdown_sync(&fc->timeout.timer); > > > > that guarantees the timer is not queued / callback of timer is not > > running / cannot be rearmed. > > Got it. I missed that last part in fuse_conn_put() > Thanks
