linux-kernel - Re: RFC for a new Scheduling policy/class in the Linux-kernel

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 15 Jul 2009 18:52:23 -0400
From:	Ted Baker <baker@...fsu.edu>
To:	Chris Friesen <cfriesen@...tel.com>
Cc:	Raistlin <raistlin@...ux.it>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Douglas Niehaus <niehaus@...c.ku.edu>,
	Henrik Austad <henrik@...tad.us>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Bill Huey <billh@...ppy.monkey.org>,
	Linux RT <linux-rt-users@...r.kernel.org>,
	Fabio Checconi <fabio@...dalf.sssup.it>,
	"James H. Anderson" <anderson@...unc.edu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Dhaval Giani <dhaval.giani@...il.com>,
	Noah Watkins <jayhawk@....ucsc.edu>,
	KUSP Google Group <kusp@...glegroups.com>,
	Tommaso Cucinotta <cucinotta@...up.it>,
	Giuseppe Lipari <lipari@...is.sssup.it>
Subject: Re: RFC for a new Scheduling policy/class in the Linux-kernel

On Wed, Jul 15, 2009 at 04:12:00PM -0600, Chris Friesen wrote:

> As Peter mentioned, it's not so much a matter of whether it's desired or
> not.  It's required, at least in terms of supporting priority
> inheritance for pthread mutexes.  I haven't been involved with the
> linux-rt side of things, but I believe Peter implied that they used PI
> fairly heavily there to try to minimize priority inversion issues
> because it was infeasible to analyze all the various locks.  The kernel
> is over 10 million lines of code, so any locking changes pretty much
> have to fit into the existing framework with minimal changes.
...
> Any additional penalty due to PI should be limited to
> the mutexes which actually have PI enabled.  If an application can limit
> itself to "safe" syscalls and has enough knowledge of its own locking,
> then it could presumably use regular mutexes and avoid the overhead of PI.
>
> I'm not sure the same could apply to the kernel in general...Peter would
> have to address that as I'm not familiar with the linux-rt changes.

I understand the need to support the (largely broken for SMP)
POSIX real-time API, but from what I read of the scheduler it
seems that support for priority inheritance on mutexes has greatly
complicated the kernel, and that the cost extends to applications
that do not use priority inheritance mutexes.  I especially don't
see why why priority inheritance mutexes should ever be used by
the kernel itself.  Is there a way to provide in the kernel
whatever minimal hooks are needed to support the API for users who
want it, with less impact?

My experience on IEEE PASC and the Austin Group, including work
with POSIX validation test suites, has shown that many of the
POSIX specifications leave a huge amount of room for
implementation freedom -- much larger than I thought when I
balloted them.  I found this out when I wrote test programs that
implementors argued went beyond the specs, when I complained as
user about POSIX implementations that I thought did not meet the
specs, and when I read interpretation requests from other users
and implementors.

So, I think it would be worth the effort to read the POSIX
specification for PTHREAD_PRIO_INHERIT carefully, with a lawyerly
attitude, to see if it really requires going to the lengths the
Linux kernel currently goes.  That is, look for loopholes that
permit Linux to do the right thing. I can't do this today, but
maybe I will another day.

Ted
--
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/