linux-kernel - Re: [PATCH 1/2] spi: dt-bindings: introduce linux,use-rt-queue flag

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: <4784636.LvFx2qVVIh@steina-w>
Date:   Fri, 09 Jun 2023 11:13:39 +0200
From:   Alexander Stein <alexander.stein@...tq-group.com>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Matthias Schiffer <matthias.schiffer@...tq-group.com>,
        linux-arm-kernel@...ts.infradead.org,
        Mark Brown <broonie@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>, linux-spi@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux@...tq-group.com
Subject: Re: [PATCH 1/2] spi: dt-bindings: introduce linux,use-rt-queue flag

Am Freitag, 9. Juni 2023, 10:42:04 CEST schrieb Linus Walleij:
> On Fri, Jun 9, 2023 at 10:15 AM Alexander Stein
> 
> <alexander.stein@...tq-group.com> wrote:
> > > A agree with Mark that a command line option isn't that bad. It's
> > > something
> > > that pertains to just the Linux kernel after all? And you can put that
> > > command line option in the default device tree, in chosen, if you want.
> > 
> > I don't like the idea of a command line enabling realtime scheduling for
> > all instances of the SPI controller driver or even all SPI controllers.
> > Actually this might be worse if a non-rt SPI bus is considered for RT
> > scheduling. IMHO this should be configurable per SPI controller,
> 
> OK that's a fair point.
> 
> I don't think command line arguments are necessarily global by
> nature, AFAIK it's fine to invent something like pl022.4.rt_sched=1
> where 4 is the instance number. Parsing it is just code.

Now we are touching the topic of non-deterministic device names/numbers. This 
gets worse if your SPI controller is attached to some other device, although 
RT capabilities are rather limited in that case anyway.

> > e.g. a sysfs attribute.
> 
> But it needs to be set before userspace is up :/

Does it? IMHO a realtime system is allowed to use blocking mechanism (e.g. 
dynamic memory allocatin and so on) during startup/configuration phase, 
ignoring any deadlines.
Once it starts operating this is a no-go.
This seems rather similar to configure scheduling priority for IRQ threads on 
RT preempt systems. IIRC according to RT folks, this is considered an 
administration task, thus the responsibility of userspace.

> I fully sympathize with this problem, because I have faced
> similar problems myself.

You mean RT-scheduling before userspace is up? Can you elaborate the issues 
you see?

> My fallback solution for this driver would be to keep using the
> old DT property (which was merged when reviewing was
> not as strict) if that works, or use undocumented DT properties,
> it's not the end of the world but does leave the bad taste of
> a work not finished.

I was surprised to see the driver specific property for configuring RT sched 
as well. I assume the intention of this series is to support this feature for 
other SPI controller drivers as well. So some kind of feature has to be added 
anyway.

Best regards,
Alexander

> Yours,
> Linus Walleij


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/