lsof -b may still cause kernel blocks

[propertone]

[Linux] I'm not sure if this is a bug, but lsof -b does not entirely avoid blocking calls. While it avoid stat/lstat/readlink calls on the mounted filesystems, strace shows that it still calls lstat and stat on the file descriptor symlinks in /proc/*/fd/*. Unlike lstat, stat will resolve symlinks, so if the open file handle is on a filesystem that's hung, then lsof will hang as well, even with the -b option.

I've tested this on Linux using the latest version of lsof

[masatake]

If your strace supports -k option, could you run the strace command with the option, so I can find in which context, the systems calls are called.

[propertone]

Here's a sample strace lsof invocation:

[/var/tmp/lsof_4.94.0.linux] % strace -k -o /tmp/strace.out -estat,lstat ./lsof -b -w -i:80

...
stat("/proc/10577/", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
 > /usr/lib64/libc-2.17.so(__xstat+0x15) [0xef465]
 > /var/tmp/lsof_4.94.0.linux/lsof(gather_proc_info+0x2c1) [0x407fd1]
 > /var/tmp/lsof_4.94.0.linux/lsof(main+0x1c45) [0x415ffc]
 > /usr/lib64/libc-2.17.so(__libc_start_main+0xf4) [0x22554]
 > /var/tmp/lsof_4.94.0.linux/lsof(_start+0x28) [0x402408]
lstat("/proc/10577/fd/0", {st_mode=S_IFLNK|0300, st_size=64, ...}) = 0
 > /usr/lib64/libc-2.17.so(__lxstat+0x15) [0xef505]
 > /var/tmp/lsof_4.94.0.linux/lsof(process_id+0x14e8) [0x407519]
 > /var/tmp/lsof_4.94.0.linux/lsof(gather_proc_info+0x64c) [0x40835c]
 > /var/tmp/lsof_4.94.0.linux/lsof(main+0x1c45) [0x415ffc]
 > /usr/lib64/libc-2.17.so(__libc_start_main+0xf4) [0x22554]
 > /var/tmp/lsof_4.94.0.linux/lsof(_start+0x28) [0x402408]
stat("/proc/10577/fd/0", {st_mode=S_IFREG|0600, st_size=1573, ...}) = 0
 > /usr/lib64/libc-2.17.so(__xstat+0x15) [0xef465]
 > /var/tmp/lsof_4.94.0.linux/lsof(process_id+0x151c) [0x40754d]
 > /var/tmp/lsof_4.94.0.linux/lsof(gather_proc_info+0x64c) [0x40835c]
 > /var/tmp/lsof_4.94.0.linux/lsof(main+0x1c45) [0x415ffc]
 > /usr/lib64/libc-2.17.so(__libc_start_main+0xf4) [0x22554]
 > /var/tmp/lsof_4.94.0.linux/lsof(_start+0x28) [0x402408]
lstat("/proc/10577/fd/1", {st_mode=S_IFLNK|0300, st_size=64, ...}) = 0
 > /usr/lib64/libc-2.17.so(__lxstat+0x15) [0xef505]
 > /var/tmp/lsof_4.94.0.linux/lsof(process_id+0x14e8) [0x407519]
 > /var/tmp/lsof_4.94.0.linux/lsof(gather_proc_info+0x64c) [0x40835c]
 > /var/tmp/lsof_4.94.0.linux/lsof(main+0x1c45) [0x415ffc]
 > /usr/lib64/libc-2.17.so(__libc_start_main+0xf4) [0x22554]
 > /var/tmp/lsof_4.94.0.linux/lsof(_start+0x28) [0x402408]
stat("/proc/10577/fd/1", {st_mode=S_IFREG|0600, st_size=1573, ...}) = 0
 > /usr/lib64/libc-2.17.so(__xstat+0x15) [0xef465]
 > /var/tmp/lsof_4.94.0.linux/lsof(process_id+0x151c) [0x40754d]
 > /var/tmp/lsof_4.94.0.linux/lsof(gather_proc_info+0x64c) [0x40835c]
 > /var/tmp/lsof_4.94.0.linux/lsof(main+0x1c45) [0x415ffc]
 > /usr/lib64/libc-2.17.so(__libc_start_main+0xf4) [0x22554]
 > /var/tmp/lsof_4.94.0.linux/lsof(_start+0x28) [0x402408]
...

[masatake]

Thank you. I read gather_proc_info and process_id.
In my understanding, calling these system calls in the context is needed. lsof on Linux doesn't work at all without calling the system calls in the context.

[kurok]

I looked into this. The -b flag isn't being checked in the Linux dialect's common code path.

In lib/dialects/linux/dproc.c, the process_id() function calls stat()/lstat() directly on /proc/PID/fd/N when HasNFS == 0 (no NFS mounts — the typical case). The safe wrappers statsafely()/lstatsafely() that respect -b are only used when HasNFS != 0.

This affects stat calls on CWD, root, exe, and all fd paths.

Fix: Always use statsafely()/lstatsafely() regardless of HasNFS. They already fall through to normal stat() when -b isn't set, so there's no performance cost.

Let's close the issue