> > 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. > > 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
