https://bugs.kde.org/show_bug.cgi?id=522479
Bug ID: 522479
Summary: drkonqi-coredump ENOSPC ptrace handling
Classification: Applications
Product: drkonqi
Version First 6.6.5
Reported In:
Platform: Arch Linux
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
DESCRIPTION
during root ENOSPC events when systemd-coredump calls drkonqi from a
application crash (example: Steam/Webhelper), the ptrace is locked and the
handle not terminated. even if drkonqi is killed, the memory is not released
from subsystems (amdgpu gtt) leaving the system in a broken state and balloon
ram resources.
worse, as oom-killer starts trying to kill userspace applications, and this
inevitably causes other applications to crash, the process repeats.
---
STEPS TO REPRODUCE
1. open a application with device handles (such as hardware video decoding in a
browser or the steam application)
2. cause a ENOSPC event on the root filesystem, preventing coredump to
(/var/lib/systemd/coredump)
3. drkonqi-coredump hangs, and ptrace is held in ram.
OBSERVED RESULT
drkonqi never releases the ptrace and never closes, using STDERR. Terminating
the pid (pkill -9) of drkonqi-coredump, never releases ptrace.
EXPECTED RESULT
drkonqi detects the block I/O operation failed, during coredump write; puts out
a error message to STDERR or error handler, then releases ptrace before
gracefully closing with a non-0 exit status, letting logging handle.
SOFTWARE/OS VERSIONS
KDE Plasma Version: 6.6.5
KDE Frameworks Version: 6.26.0
Qt Version: 6.11.1
Kernel Version: 7.0.12-1-cachyos (64-bit)
Graphics Platform: Wayland
Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor
Memory: 64 GiB of RAM (62.7 GiB usable)
Graphics Processor: AMD Radeon RX 9070 XT
ADDITIONAL INFORMATION
I observed this recently and it took a bit of debugging to notice the issue. I
leave steam running in the background as this is my general
desktop/workstation, steam-webhelper creates GEM buffers in the GPU. Because
the crash handlers froze the processes mid-execution, the kernel was blocked
from running its normal cleanup routines, so even after a kill -9 on the
orphaned processes the amdgpu kernel modules reference counters for theose GEM
buffers got completely deadlocked. this lead to the DRM subsystem permanently
reserving that ram for ghost graphic sessions that no longer existed.
It had locked my entire systems ram/swap/zrm locked up in this. ballooning out
to over 31.21gb of physical ram just from the single process. Worse it
duplicated, so i had a total of 62.42gb of reserved space accross ram/swap/zrm.
Leaving my system, despite having far above average amounts of available
pageable memory space, on the edge of kernel lockup.
on a average system with less than 24gb of ram, which is more common usecase,
this issue wouldnt be recoverable, forcing the system into a state where the
user would not be able to resolve the enospc, potentially corrupting their root
filesystem. Something i have observed in the past with some filesystems and how
they handle full disks when attempting to mount them after not being properly
unmounted leaving lingering locks.
for a non-technical user, this would result in a unrecoverable system without
the use of external tools to mount the root filesystem and fix it.
--
You are receiving this mail because:
You are watching all bug changes.
