lkml.org 
[lkml]   [2014]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH RFC] sched: deferred set priority (dprio)
    On Sat 2014-08-02 17:47:52, Sergey Oboguev wrote:
    > On Wed, Jul 30, 2014 at 6:02 AM, Pavel Machek <pavel@ucw.cz> 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


    \
     
     \ /
      Last update: 2014-08-03 11:01    [W:5.519 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site