linux-kernel - Re: [PATCH 0/5] Fix FIFO-99 abuse

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: <20190802143324.GH2332@hirez.programming.kicks-ass.net>
Date:   Fri, 2 Aug 2019 16:33:24 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Qais Yousef <qais.yousef@....com>
Cc:     mingo@...nel.org, linux-kernel@...r.kernel.org,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 0/5] Fix FIFO-99 abuse

On Fri, Aug 02, 2019 at 03:08:54PM +0100, Qais Yousef wrote:
> On 08/02/19 14:41, Peter Zijlstra wrote:
> > On Fri, Aug 02, 2019 at 11:26:12AM +0100, Qais Yousef wrote:
> > 
> > > Yes a somewhat enforced default makes more sense to me. I assume you no longer
> > > want to put the kthreads that just need to be above OTHER in FIFO-1?
> > 
> > I'm not sure, maybe, there's not that many of them, but possibly we add
> > another interface for them.
> 
> By the way, did you see this one which is set to priority 16?
> 
> https://elixir.bootlin.com/linux/v5.3-rc2/source/drivers/gpu/drm/msm/msm_drv.c#L523

I did, I ignored it because it wasn't 99 or something silly like that,
but I'd definitely mop it up when doing the proposed.

> > Also; like said before, the admin had better configure.
> 
> I agree. But I don't think an 'admin' is an easily defined entity for all
> systems. On mobile, is it the SoC vendor, Android framework, or the
> handset/platform vendor/integrator?

Mostly Android I suspect, but if SoC specific drivers have RT threads,
it's their responsibility to integrate properly with the rest of Android
of course.

> > Also also, RR-SMP is actually broken (and nobody has cared enough to
> > bother fixing it).
> 
> If you can give me enough pointers to understand the problem I might be able to
> bother with it :-)

So the push-pull balancer we have (designed for FIFO but also applied to
RR) will only move a task if the destination CPU has a lower prio.  In
the case where one CPU has 3 tasks and the other 1, and they're all the
same prio, it does nothing.  For FIFO that is fine, for RR, not so much.

Because then the one CPU will RR between 3 tasks, giving each task
1/3rd, while the other will only run the one task.