[lkml]   [2012]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 05/16] sched: SCHED_DEADLINE policy implementation.
    On 04/24/2012 12:13 AM, Tommaso Cucinotta wrote:
    > Il 23/04/2012 17:41, Juri Lelli ha scritto:
    >> The user could call __setparam_dl on a throttled task through
    >> __sched_setscheduler.
    > in case it can be related: a scenario that used to break isolation
    > (in the old aquosa crap): 1) create a deadline task 2) (actively)
    > wait till it's just about to be throttled 3) remove reservation
    > (i.e., return the task to the normal system policy and destroy
    > reservation info in the kernel) 4) reserve it again

    Yes, this is very similar to what I thought just after I've sent the
    email (ouch! :-)).

    > Assuming the borderline condition of a nearly fully saturated system,
    > if 3)-4) manage to happen sufficiently close to each other and right
    > after 2), now the task budget is refilled with a deadline which is
    > where it should not be, according to the admission control rules. In
    > other words, we may break guarantees of other tasks by a properly
    > misbehaving task. Something relevant when considering misbehaviour
    > and admission control from a security perspective [1].

    Thanks for the ref., I'll read it!

    > At that time, I was persuaded that the right way to avoid this would
    > be to avoid to free system cpu bw immediately when a reservation is
    > destroyed, but rather wait till its current abs deadline, then "free"
    > the bandwidth. A new task trying to re-create the reservation too
    > early, i.e., at step 4) above, would be rejected by the system as it
    > would still see a fully occupied cpu bw. Never implemented of course
    > :-)...

    A kind of "two steps" approach. It would work, I just have to think how
    to implement it (and let the system survive ;-)). Then create some
    bench to test it.

    > And also, from a security perspective, a misbehaving (sched_other)
    > task might thrash the system with useless nansosleeps forcing the OS
    > to continuously schedule/deschedule it. Equivalently, with a deadline
    > scheduler, you could try to set a very small period/deadline. That's
    > why in [1], among the configurable variables, there was a minimum
    > allowed reservation period.

    Yes, this should be easily controlled at admission time.

    > Nothing really urgent, just something you might want to keep in mind
    > for the future, I thought.

    Well, depends on how much effort will this turn to require. I personally
    would prefer to be able to come out with a new release ASAP. Just to
    continue the discussion with the most of the comments addressed and a
    more updated code (I also have a mainline version of the patchset
    quite ready).

    Thanks a lot,

    - Juri

     \ /
      Last update: 2012-04-24 09:25    [W:0.043 / U:9.600 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site