21 Jun
2009
21 Jun
'09
9:53 p.m.
On Sun, 21.06.09 19:02, Paul Davis (paul(a)linuxaudiosystems.com) wrote:
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=commitdif…
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
No. I am not talking about *replacing*. I have asked for adding
support for rtkit to it.
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. 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* ? 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