On Sat 2014-08-02 17:47:52, Sergey Oboguev wrote:
> On Wed, Jul 30, 2014 at 6:02 AM, Pavel Machek <[email protected]> wrote:
> > Hi!
> >
> >> One of the intended purposes of this facility (but its not sole purpose)
> >> is to
> >> render a lightweight mechanism for priority protection of lock-holding
> >> critical
> >> sections that would be an adequate match for lightweight locking primitives
> >> such as futex, with both featuring a fast path completing within the
> >> userspace.
>
> > Do we get a manpage describing the interface...?
>
> At this point it is just an RFC, and the only available write-up is an article
> (URL is in the original message).
>
> There has been no word from the maintainers yet whether the proposal appears
> to be a "go" or "no-go" in general.
It appears to be "no-go" to me.
> Regular "set priority" cannot be wrapped around "deferred set priority".
Umm. Why not?
int getpriority(int which, int who);
int setpriority(int which, int who, int prio);
Description
The scheduling priority of the process, process group, or user, as
indicated by which and who is obtained with the getpriority() call
and set with the setpriority() call.
The value which is one of PRIO_PROCESS, PRIO_PGRP, or PRIO_USER, and
who is interpreted relative to which (a process identifier for
PRIO_PROCESS, process group identifier for PRIO_PGRP, and a user ID
for PRIO_USER). A zero value for who denotes (respectively) the
calling process, the process group of the calling process, or the
real user ID of the calling process. Prio is a value in the range -20
to 19 (but see the Notes below). The default priority is 0; lower
priorities cause more favorable scheduling.
In vsyscall area:
if (which==PRIO_PROCESS && who==0) {
perform your optimized priority set
} else {
perform syscall
}
Now, you have to make sure to keep reasonably close semantics, but
that would be good idea, anyway.
> Even more importantly, its use also relies on a thread caching the
> application's
> current knowledge of the thread priority in the userspace, and if the thread
> priority had been changed from the outside of the application (or even by
> another thread within the same application), this knowledge becomes invalid,
> and then the application is responsible for performing whatever recovery
> action
> is appropriate.
You mean "we rely on applications handling the situation they can't
and will not handle"?
Actually, it seems to be a security issue to me.
If root renices the application to high nice value, application should
not be able to work around it by the DPRIO interface.
IOW the priority should be always the lower of DPRIO and normal one,
at the very least.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
