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
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].
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
:-)...
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.
Nothing really urgent, just something you might want to keep in mind
for the future, I thought.