On Sun, 21.06.09 19:02, Paul Davis (paul@email-addr-hidden) 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:
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 Linux-audio-dev@email-addr-hidden http://lists.linuxaudio.org/mailman/listinfo/linux-audio-devReceived on Mon Jun 22 04:15:05 2009
This archive was generated by hypermail 2.1.8 : Mon Jun 22 2009 - 04:15:05 EEST