[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1335193863.28150.172.camel@twins>
Date: Mon, 23 Apr 2012 17:11:03 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Juri Lelli <juri.lelli@...il.com>
Cc: tglx@...utronix.de, mingo@...hat.com, rostedt@...dmis.org,
cfriesen@...tel.com, oleg@...hat.com, fweisbec@...il.com,
darren@...art.com, johan.eker@...csson.com, p.faure@...tech.ch,
linux-kernel@...r.kernel.org, claudio@...dence.eu.com,
michael@...rulasolutions.com, fchecconi@...il.com,
tommaso.cucinotta@...up.it, nicola.manica@...i.unitn.it,
luca.abeni@...tn.it, dhaval.giani@...il.com, hgu1972@...il.com,
paulmck@...ux.vnet.ibm.com, raistlin@...ux.it,
insop.song@...csson.com, liming.wang@...driver.com
Subject: Re: [PATCH 05/16] sched: SCHED_DEADLINE policy implementation.
On Mon, 2012-04-23 at 16:43 +0200, Juri Lelli wrote:
>
> > From what I can see there are no constraints on the values in
> > __setparam_dl() so the above left term can be constructed to be an
> > overflow.
> >
>
> Yes, could happen :-\.
>
> > Ideally we'd use u128 here, but I don't think people will let us :/
> >
>
> Do we need to do something about that? If we cannot go for bigger space
> probably limit dl_deadline (or warn the user)..
Depends on what happens, if only this task gets screwy, no real problem,
they supplied funny input, they get funny output. If OTOH it affects
other tasks we should do something.
Ideally we'd avoid the situation by some clever maths, second best would
be rejecting the parameters up front.
--
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/
Powered by blists - more mailing lists