On Fri, Aug 09, 2024 at 09:39:41AM GMT, Morten Hein Tiljeset wrote: > > The file descriptor could already be closed but the task could be stuck > > exiting and so queued task work including destroying files wouldn't be > > done yet. You could also try and see if you can figure out what tasks > > require your workload to do a lazy umount in the first place. That might > > bring you closer to the root cause. > > > > What kernel version are you running anyway? > That's an interesting idea about the stuck task, I'll try looking into that. We're not > doing lazy unmounts on purpose -- I'm only concluding that it must be happening based on > the mount namespace being NULL. I wonder if the lazy unmount could happen implicitly > as a consequence of some other operation? You don't need a lazy umount for this. You could also just have a container or service exiting that uses a mount namespace. In that case the last exiting task will close all of its open files and then put the mount namespace. The mount namespace will unmount all mounts that were still around NULLing the mntns. Say P1 has somehow managed to get hold of a file descriptor in some other mount namespace M1 and holds a file descriptor referring to some mount in there. Now the last process pinning M1 exists and puts all mounts associated with M1. Now P1 holds a file descriptor pointing to a mount that has a NULL mount namespace. A task could hang running task work because of some device file or whatever that it's closing. Or it could hang exiting namespaces. I vaguely remember that years ago on earlier kernels we had some issues there.
