| 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: Wed, 21 Apr 2010 21:24:02 +0200 From: Primiano Tucci <p.tucci@...il.com> To: rostedt@...dmis.org Cc: Peter Zijlstra <peterz@...radead.org>, linux-kernel@...r.kernel.org, tglx <tglx@...utronix.de> Subject: Re: Considerations on sched APIs under RT patch > Actually, we do better than that. With adaptive locks, if the process on > the other CPU is still running, the high priority task will spin until > the other process releases the lock or goes to sleep. If it goes to > sleep, then the high prio task will also sleep, otherwise it just spins > and takes the lock when it is released. > > -- Steve It sounds more reasonable now. I know that in a preemptible kernel even syscalls can be preempted. that absolutely fair except for those syscalls (such as setaffinity, setpriority) that control the scheduler. Going back to my original problem, the real question is: Is it sure that calling a scheduler api won't induce a re-scheduling of the caller process (e.g. as in the case of a lock held by another processor)? It would be very unpleasant if the scheduling apis can induce re-scheduling, making the realization of a Real Time scheduling infrastructure completely un-deterministic. If I have clearly understood your replies it seems that my problem is due to an *old* kernel version that still uses rw_lock into the setaffinity! Is it right? Thank you for your extremely valuable support. Primiano -- Primiano Tucci http://www.primianotucci.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