linux-kernel - Re: [PATCH] Softlockup (out of cpu) killer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 12 Dec 2011 10:00:38 -0800
From:	Vincent Li <vincent.mc.li@...il.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Ingo Molnar <mingo@...e.hu>, Don Zickus <dzickus@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mandeep Singh Baines <msb@...omium.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Softlockup (out of cpu) killer

>
> Your whole premise is broken. Being a cpu hog and the softlockup
> mechanism aren't related at all.
>
I fully understand that I may misunderstand the the cpu hog and
softlockup mechanism :)

> Furthermore, since the normal scheduling policy is a proportional one, a
> cpu hog can't in fact starve anybody (although a fork bomb could). And
> FIFO/RR are privileged ops.
>

I have a test program with FIFO privileges
http://www.vcn.bc.ca/~vli/schedrtcpu.c.txt that reliably eat 100% cpu
in top and the patch can kill it reliably, we have an user-space
traffic processing program that runs on FIFO similar like the test
program, under some condition, that user-space program could stuck on
the cpu and we want to kill it for high availability reason. with this
patch, we were able to do that.

I do notice that in the schedrtcpu.c test program, if I fork two
process like below:

pid_t spawn() {
        pid_t pid = fork();
        if (pid == 0)
                busyloop();
        return pid;
}

	pid1 = spawn();
	pid2 = spawn();

	waitpid(pid1, &status, 0);
	waitpid(pid2, &status, 0);

and run it on two cpu box, I got "sched: RT throttling activated" on
console and the test program wouldn't stuck on cpu, and can only reach
to 95% percent, it is strange that if I don't fork process, and only
runs the busyloop, it would not activate RT throttling and
consistently eat 100% single cpu.

 in our corner case, it appears that patch does help solve our problem.

> Furthermore the distinction between memory and cpu-time is that memory
> isn't a renewable resource, whereas time is. There's always more time,
> but there's not always more memory.
>
understood, thanks

> So no, I don't think either you patch nor your concept make any sense.
> Consider it nacked.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/