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
| ||
|
Date: Fri, 11 Apr 2008 10:01:30 +0200 From: "Michael Kerrisk" <mtk.manpages@...il.com> To: "Peter Zijlstra" <a.p.zijlstra@...llo.nl> Cc: "Michael Kerrisk" <mtk.manpages@...glemail.com>, "Eugene Teo" <eugeneteo@...nel.sg>, linux-kernel@...r.kernel.org, "Neil Horman" <nhorman@...driver.com>, "Ingo Molnar" <mingo@...e.hu> Subject: Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits On 4/11/08, Michael Kerrisk <mtk.manpages@...glemail.com> wrote: > On Thu, Feb 28, 2008 at 5:50 PM, Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote: > > > > On Thu, 2008-02-28 at 16:44 +0100, Michael Kerrisk wrote: [...] > > I've been testing this patch. Above you seemed to be saying that > > doing a sched_yield() would be equivalent to a sleep, causing the rt > > counter to be reset to zero. Howver, the results I'm seeing suggest > > that a sched_yield() does not cause the counter to be reset to zero > > (i.e., despite calling sched_yield() at frequent intervals, the > > process still encounters the RLIM_RTTIME soft limit and gets SIGXCPU). > > Can you comment? > > > It appears you are right. I must have been staring at something else > than code when I said that :-(, yield() will indeed _not_ reset the > counter. > > Now, I think it makes some sense to reset it, because we do try to play > nice by calling yield. OTOH we don't actually block and become > unrunnable - we'll still be contending for CPU time. On the one hand, it seems reasonable to reset the counter. The POSIX definition of sched_yield() says that it "shall force the running thread to relinquish the processor until it again becomes the head of its thread list". On the other hand, what if this is the only runnable real-time process? Then sched_yield() is effectively a no-op, and a runaway process could lock up the system (which I gather is what RLIMIT_RTTIME was primarily designed to prevent). I don't really have a strong leaning either way about what should be done, other than that we should probably make a specific choice, and document it in the setrlimit(2) man page. Cheers, Michael -- I'll likely only see replies if they are CCed to mtk.manpages at gmail dot com -- 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/
Powered by blists - more mailing lists