linux-kernel - Re: [PATCH 2/2] sched/uclamp: Protect uclamp fast path code with static key

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200619172524.y66a4hz6g6hr3thr@e107158-lin.cambridge.arm.com>
Date:   Fri, 19 Jun 2020 18:25:25 +0100
From:   Qais Yousef <qais.yousef@....com>
To:     Valentin Schneider <valentin.schneider@....com>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        Patrick Bellasi <patrick.bellasi@...bug.net>,
        Chris Redpath <chrid.redpath@....com>,
        Lukasz Luba <lukasz.luba@....com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] sched/uclamp: Protect uclamp fast path code with
 static key

On 06/19/20 16:17, Valentin Schneider wrote:

[...]

> > But here this is
> > just extra churn.
> >
> > If an imbalance has happend this means either:
> >
> >       1. enqueue/dequeue_task() is imablanced itself
> >       2. uclamp_update_active() calls dec without inc.
> >
> > If 1 happened we have more reasons to be worried about. For 2 the function
> > takes task_rq_lock() and does dec/inc in obvious way.
> >
> 
> True. I won't argue over the feasibility of the scenarios we are currently
> aware of, my point was that if they do happen, it's nice to have debug
> helps in the right places as the final breakage can happen much further
> downstream.
> 
> FWIW I don't like the diff I suggested at all, but if we can come up with a
> cleverer scheme I think we should do it, as per the above.

There's the fact as well that this whole thing is to deal with potentially
avoid doing anything that is stricly not necessary in the fast path.

keep in mind that my patch of introducing the sysctl is not accepted yet
because it introduces such thing, but in that case it's not a debug only
feature. CONFIG_SCHED_DEBUG do get enabled by distros because it exports a lot
of useful info.

--
Qais Yousef