SIGKILL delay

[xinyangge]

Description

We've hit significant SIGKILL delay in the order of O(10s) when (1) one process runs "find" against a folder of millions of directories/files, and (2) another process tries to send SIGKILL to it. I'm not sure if this is specific to signal handling/delivery, because even we run "echo hello" in the second process could take very long to respond. Is there anything related to the gVisor's internal scheduling that can cause such long delay when a process is enumerating the filesystem busily?

Steps to reproduce

No response

runsc version

release-20250820.0-120-g6bf3c4885132-dirty

docker version (if using docker)

uname

No response

kubectl (if using Kubernetes)

repo state (if built from source)

No response

runsc debug logs (if available)

[nixprime]

The gofer client currently reads all entries in a directory at once, for reasons described by

gvisor/pkg/sentry/fsimpl/gofer/directory.go

Line 217 in 96519d0

// NOTE(b/135560623): 9P2000.L's readdir does not specify behavior in the

. The runsc fsgofer and directfs shouldn't have that problem since in both cases the underlying filesystem is Linux, so we could add an alternative operating mode that paginates directory entries, and enable it unconditionally for directfs / by mount option or some other gofer-indicated attribute for lisafs. (-directfs is enabled by default, so unless you're explicitly disabling it, supporting this only for directfs may be sufficient in the short term.)

Regarding the SIGKILL delay, this is plausibly because we don't check for pending signals anywhere in the path that reads all directory entries described above. We could change this, but it wouldn't fix the second issue described, where running an unrelated process also takes a long time. My guess for that issue is that reading all directory entries is holding a mutex also required by the other process, the fix for which would be paginating directory entries in the client as described above.