On (24/12/04 09:51), Brian Geffon wrote: > > > > >> > > > > >> In those cases 1 minute fuse timeout will overshot HUNG_TASK_TIMEOUT > > > > >> and then the question is whether HUNG_TASK_PANIC is set. > > In my opinion this is a good argument for having the hung task timeout > and a fuse timeout independent. The hung task timeout is for hung > kernel threads Sorry, but no, it's not only for kernel threads. > in this situation we're potentially taking too long in > userspace but that doesn't necessarily mean the system is hung. And it's not for hung system. It's for tasks that stuck unreasonably long waiting for a particular event or resource. And those tasks very well can be user-space processes, being stuck in syscall waiting for something. > I think a loop which does an interruptible wait with a timeout of 1/2 > the hung task timeout would make sense to ensure the hung task timeout > doesn't hit. The point here is not to silent watchdog, we might as well just disable it and call it a day. The point here is that fuse can be used (and IS in our particular case) as a network filesystem, and the problem can be way outside of your system, so spinning in a wait loop doesn't fix any problem on that remote system no matter how long we spin, and that's what watchdog signals us.
