On Sun, 21.06.09 19:02, Paul Davis ([email protected]) wrote: > >> > So what does this do? It's a simple policy daemon that hands out > >> > SCHED_RR scheduling to normal user processes/threads that ask for it. > >> > >> This appears to be a baroque mechanism designed to solve a problem > >> suspectible to vastly simpler solutions. > > > > Simpler solutions? I am listening! What would a "simpler solution" be, > > that doesn't suffer by all the issues I pointed out in the README? > > > > Also, what's baroque with this? I mean, really, this offers an API of > > two tiny functions. Not sure why you'd call that baroque? > > the API is simple. the implementation that the API sits on top of it > baroque. not yours, necessarily, but the combination of RTKit and > Ingo's patch. Baroque doesn't necessarily mean "huge, vast and > incomprehensible". it can just mean "overly intricate for the task at > hand".
It's me who wrote the kernel patch actually. And after discussing my plans and the pros and cos with a few kernel/rt folks the patch went into Ingo's tree. The patch didn't come out of the blue sky and then Lennart came around and wrote rtkit using it. No. Instead I have been discussing the issue we fix with rtkit with a couple of people off and on for quite some time now. And a couple of weeks ago I decided to actually to do something about it and wrote this little patch accompanied by this little userspace support for it which is going by the name of rtkit. This is the patch btw: http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commitdiff;h=ca94c442535a44d508c99a77e54f21a59f4fc462 Have you actually read rtkit's README file? This goes a bit into details about the reasons to solve the issues this way. http://git.0pointer.de/?p=rtkit.git;a=blob;f=README > >All I kindly ask for is to ease the distributors life by > > adding a tiny bit of fallback code that does a tiny call into rtkit in > > case sched_setschedparam() fails with EPERM and is #ifdef as __linux__ > > && HAVE_DBUS and is also contorollable as a compile-time configure > > option. > > so, sched_setschedparam(), a documented, implemented and demonstrably > functional call fails in some cases. and your proposal is to replace > this well-established API with a new API that doesn't actually > accomplish anything new except *WORKING* ? No. I am not talking about *replacing*. I have asked for adding support for rtkit to it. > i'm sorry but to me this is just absurd. the call is there, it works > (for a user with certain priviledges granted), and has a reasonably > long pedigree. why should fixing the problem with priviledge > granting be accomplished with a different call to get the same > scheduling priority, a call that relies on new kernel functionality > that isn't necessary for the sched_sp() approach? this is applying a > band-aid to a deeper solution, and its because of this that its hard > to support it. The thing is that we cannot safely hand out RT privileges to user processes without doing acess/rate limiting, watchdog support, calls into policy systems and so on and so on. > go and ask linus or ingo and/or whoever is deputized to handle (a) > scheduling and (b) priviledge control mechanisms. if they come back > and say "we think this is an appropriate solution and we don't intend > to address this any further in terms of kernel mechanisms" then the > conversation moves on to the next step - why are distributions not > being more creative with the priviledge granting mechanism that is > already in place? my reading of ingo's patch is that its mechanism, > not policy (as usual for the kernel), and its really *mostly* > duplicating facilities that are already intended to be accessed via > sched_setschedparam(). You are really misunderstanding the situation here. Firstly, *I* wrote the patch, and *I* was the one pushing this through. Secondly, this is not coming out of the blue sky, but this is the result of discussions with the RT folks, both inside RH and outside of RH. (which is partially documented in the acked-by/signed-off-by of the patch, just have a look!) Now, if you think you have a better insight into how things should be done than all of us, then hey, be my guest, why don't you make some *proper* suggestions how an alternative should be looking like? Asking for "creative use" and giving the fault to the distributors just doesn't cut it. The big problem with RLIMIT_RTPRIO is that it is vulnerable to a combined fork bomb/busy loop attack. Which I btw documented in the README (which I figure you didn't read?). Because that is the way it is, we, the distributors, never enabled RLIMIT_RTPRIO by default. What did happen is that some distros added an ugly unsecure kludge by adding "jackuser" group or suchlike that you can add a user to that had RLIMIT_RTPRIO set. But that's hardly a clean solution, and also leaves the "out-of-the-box" issue unresolved. The low-level sched_setschedparam() syscall is a basic primitive that can be used as building block for implementing RT in userspace. It does only minimal policy leaving all the rest for userspace, as it should be. Nothing in POSIX however says that this is the API that applications should rely on to use, behind which all security policy decisions are hidden. > apparently, you feel otherwise. the thing is lennart that the kernel > guys and others interested in regular user access to SCHED_(!OTHER) > put a lot of effort into the current rlimit mechanism as the > appropriate solution. You seem to suggest that I wasn't talking to the kernel folks before I do something like this. That is wrong. This announcement of mine was just the last step in doing all this, not the first step. > none of the mainstream distributions have bothered to make it > configurable, usable etc. etc. Yes, and there are good reasons for it (see above). Gah. This discussion is so pointless. If you don't want to use in Jack then fine. The distributions will ship the API and if you don't make use of it, so be it. It's certainly disappointing, but ultimately it's not my problem. No hard feelings, Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
