linux-kernel - Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

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]

Date:   Tue, 23 Jun 2020 17:40:21 +0100
From:   Qais Yousef <qais.yousef@....com>
To:     Doug Anderson <dianders@...omium.org>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     Benson Leung <bleung@...omium.org>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        hsinyi@...omium.org, Joel Fernandes <joelaf@...gle.com>,
        Nicolas Boichat <drinkcat@...omium.org>,
        Gwendal Grignou <gwendal@...omium.org>,
        Quentin Perret <qperret@...gle.com>, ctheegal@...eaurora.org,
        Guenter Roeck <groeck@...omium.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump
 cpu freq

On 06/22/20 11:21, Doug Anderson wrote:

[...]

> > If you propose something that will help the discussion. I think based on the
> > same approach Peter has taken to prevent random RT priorities. In uclamp case
> > I think we just want to allow driver to opt RT tasks out of the default
> > boosting behavior.
> >
> > I'm a bit wary that this extra layer of tuning might create a confusion, but
> > I can't reason about why is it bad for a driver to say I don't want my RT task
> > to be boosted too.
> 
> Right.  I was basically just trying to say "turn my boosting off".
> 
> ...so I guess you're saying that doing a v2 of my patch with the
> proper #ifdef protection wouldn't be a good way to go and I'd need to
> propose some sort of API for this?

It's up to Peter really.

It concerns me in general to start having in-kernel users of uclamp that might
end up setting random values (like we ended having random RT priorities), that
really don't mean a lot outside the context of the specific system it was
tested on. Given the kernel could run anywhere, it's hard to rationalize what's
okay or not.

Opting out of default RT boost for a specific task in the kernel, could make
sense though it still concerns me for the same reasons. Is this okay for all
possible systems this can run on?

It feels better for userspace to turn RT boosting off for all tasks if you know
your system is powerful, or use the per task API to switch off boosting for the
tasks you know they don't need it.

But if we want to allow in-kernel users, IMO it needs to be done in
a controlled way, in a similar manner Peter changed how RT priority can be set
in the kernel.

It would be good hear what Peter thinks.

Thanks

--
Qais Yousef