Giters

ColinIanKing / stress-ng

This is the stress-ng upstream project git repository. stress-ng will stress test a computer system in various selectable ways. It was designed to exercise various physical subsystems of a computer as well as the various operating system kernel interfaces.

Home Page:https://github.com/ColinIanKing/stress-ng

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

mlock stressor may cause dbus to be unresponsive, causing service restarts

medicalwei opened this issue · comments

commented

This issue was found when running command "stress-ng --aggressive --verify --mlock 0 --timeout 300" invoked by root user

When running this command with sudo, the system becomes almost unresponsive.

It seems like, instead of getting killed by oom-killer (which killed stress-ng-mlock, which is expected), systemd cannot talk to dbus, causing service restarts:

Sep 28 20:40:32 ubuntu kernel: [12223.795213] systemd[1]: bluetooth.service: Unexpected error response from GetNameOwner(): Connection terminated
...
Sep 28 20:40:37 ubuntu kernel: [12228.336613] systemd[1]: upower.service: Unexpected error response from GetNameOwner(): Connection terminated
Sep 28 20:40:37 ubuntu kernel: [12228.345269] systemd[1]: thermald.service: Unexpected error response from GetNameOwner(): Connection terminated
Sep 28 20:40:37 ubuntu kernel: [12228.347717] systemd[1]: accounts-daemon.service: Unexpected error response from GetNameOwner(): Connection terminated
Sep 28 20:40:37 ubuntu kernel: [12228.348821] systemd[1]: avahi-daemon.service: Unexpected error response from GetNameOwner(): Connection terminated
Sep 28 20:40:37 ubuntu kernel: [12228.350074] systemd[1]: rtkit-daemon.service: Unexpected error response from GetNameOwner(): Connection terminated
...

this eventually caused systemd to restart systemd-oomd and gdm

We are wondering how this issue should be addressed. Captured syslog is attached in this issue report.

syslog.tar.xz

commented

Running as root with mlock will mean that the kernel will mlock as many pages as the stressor allocates, meaning they can't be swapped out and you end up with a low memory denial-of-service attack on other processes. This is not an issue with stress-ng, it's exactly what you've asked - run on all cpus, lock pages into memory, and running as root will allow mlock to not fail when it allocates as many pages as it can map into memory.

commented

Thanks, we are determining whether it should be our setup issue or issue with any component. If it can be summarized into a low memory DoS attack caused by root user, I don't think this is valid test case for us.