linux-kernel - Re: [PATCH v5 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] [day] [month] [year] [list]

Message-ID: <20200630180445.dvhm5fje6cuk6h4g@e107158-lin.cambridge.arm.com>
Date:   Tue, 30 Jun 2020 19:04:45 +0100
From:   Qais Yousef <qais.yousef@....com>
To:     Patrick Bellasi <patrick.bellasi@...bug.net>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Valentin Schneider <valentin.schneider@....com>,
        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>,
        Chris Redpath <chris.redpath@....com>,
        Lukasz Luba <lukasz.luba@....com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 2/2] sched/uclamp: Protect uclamp fast path code with
 static key

On 06/30/20 19:44, Patrick Bellasi wrote:

[...]

> > I am sorry there's no written rule that says one should do it in a specific
> > way. And AFAIK both way are implemented in the kernel. I appreciate your
> > suggestion but as the person who did all the hard work, I think my preference
> > matters here too.
> 
> You sure know that sometime reviewing code can be an "hard work" too, so I
> would not go down that way at all with the discussion. Quite likely I
> have a different "subjective" view on how Open Source development works.
> 
> > And actually with my approach when uclamp is not compiled in there's no need to
> > define an extra variable; and since uclamp_is_used() is defined as false for
> > !CONFIG_UCLAMP_TASK, it'll help with DCE, so less likely to end up with dead
> > code that'll never run in the final binary.
> 
> Good, this is the simple and small reply I've politely asked for.

I am sorry if I offended you. I took all your comments seriously and answered
them to the best of my ability. All of your comments and suggestions were
highly appreciated too. If the wrong message reached across, rest assured it
wasn't the intended one.

Thanks

--
Qais Yousef