getdents64 denied by seccomp causing 100% CPU spinning on Chimera Linux
With the recent upgrade to tracker 3.6 and GNOME 45 (and Linux 6.5.6…is-this-a-kernel-thing?) on Chimera Linux I've started noticing weird instances of tracker-extract-3 spinning at 100% CPU usage.
Attaching a debugger to one of these processes showed:
(lldb) bt
* thread #1, name = 'tracker-extract', stop reason = signal SIGSTOP
* frame #0: 0x00007f5df074ed37 libglib-2.0.so.0`g_dir_read_name + 71
frame #1: 0x00007f5df057e83d libgio-2.0.so.0`g_io_modules_scan_all_in_directory_with_scope + 621
frame #2: 0x00007f5df057eff0 libgio-2.0.so.0`___lldb_unnamed_symbol4690 + 272
frame #3: 0x00007f5df057fa06 libgio-2.0.so.0`___lldb_unnamed_symbol4692 + 166
frame #4: 0x00007f5df05d0e77 libgio-2.0.so.0`g_vfs_get_default + 183
frame #5: 0x00007f5df055dbae libgio-2.0.so.0`g_file_new_for_path + 14
frame #6: 0x0000556ade6ffde9 tracker-extract-3`___lldb_unnamed_symbol1017 + 569
frame #7: 0x0000556ade6ffa1c tracker-extract-3`tracker_domain_ontology_new + 668
frame #8: 0x0000556ade6fdddb tracker-extract-3`main + 699
and attaching strace showed no syscalls being performed.
Manually launching an extract process on one of the files reported by tracker stats as failed:
$ tracker3 extract ~/Downloads/alpine-virt-3.17.3-x86_64.iso Disallowed syscall "getdents64" caught in sandbox
strace shows strange output for the denied syscall line (is that just strace limitations?):
open("/usr/lib/gio/modules", O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_DIRECTORY) = 3
[…]
getdents64(3, 0x7fd751c01088 /* d_reclen 19 bytes underflow */ /* 1+ entries */, 2048) = 217
--- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_call_addr=0x7fd7541e1bc0, si_syscall=__NR_getdents64, si_arch=AUDIT_ARCH_X86_64} ---
writev(2, [{iov_base="", iov_len=0}, {iov_base="Disallowed syscall \"getdents64\" "..., iov_len=50}], 2) = 50
rt_sigreturn({mask=[]}) = 217
Experiments revealed that the "no open
read-write" block of rules is the cause of the syscall being denied.
With those commented out, there issue does not happen (and the extract process spends time quietly waiting on a futex — well, whatever).
P.S. as for why that results in spinning, stepping in the debugger I see that it seems to constantly bounce in and out of g_io_modules_scan_all_in_directory_with_scope
, I guess glib didn't expect consistent failures to list the directory…