> 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? I'm on kernel 6.1.53 and I've also experienced the problem on the 5.15.x series.
