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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 05 Mar 2014 17:02:50 -0700 From: Khalid Aziz <khalid.aziz@...cle.com> To: "H. Peter Anvin" <hpa@...or.com>, David Lang <david@...g.hm> CC: Oleg Nesterov <oleg@...hat.com>, Andi Kleen <andi@...stfloor.org>, Thomas Gleixner <tglx@...utronix.de>, One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>, Ingo Molnar <mingo@...nel.org>, peterz@...radead.org, akpm@...ux-foundation.org, viro@...iv.linux.org.uk, linux-kernel@...r.kernel.org Subject: Re: [RFC] [PATCH] Pre-emption control for userspace On 03/05/2014 04:56 PM, H. Peter Anvin wrote: > On 03/05/2014 03:48 PM, Khalid Aziz wrote: >> >> Cost is writing to a memory location since thread is using mmap, not >> insignificant but hardly expensive. Thread does not need to know how >> much time it has left in current timeslice. It always sets the flag to >> request pre-emption immunity before entering the critical section and >> clears the flag when it exits its critical section. If the thread comes >> up for pre-emption while the flag is set, it gets immunity. If it does >> not, flag will be cleared at the end of critical section any way. >> > > A little more than that. The scheduler needs to set *another* flag > telling the process to yield upon leaving the critical section; if the > process doesn't, the scheduler needs to keep enough accounting to know > to penalize the process, or this method will not be usable for > unprivileged processes. Yes, you had made that suggestion earlier and I like it. It will be in v2 patch. I am thinking of making the penalty be denial of next preemption immunity request if a process fails to yield when it should have. Sounds good? Thanks, Khalid -- 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