linux-kernel - Re: [PATCH 0/5] gpiolib: Handle immutable irq

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, 15 Mar 2022 09:35:08 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     linux-kernel@...r.kernel.org, Bartosz Golaszewski <brgl@...ev.pl>,
        Thierry Reding <thierry.reding@...il.com>,
        Joey Gouly <joey.gouly@....com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Hector Martin <marcan@...can.st>,
        Sven Peter <sven@...npeter.dev>,
        Alyssa Rosenzweig <alyssa@...enzweig.io>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-gpio@...r.kernel.org, linux-tegra@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-arm-msm@...r.kernel.org, kernel-team@...roid.com
Subject: Re: [PATCH 0/5] gpiolib: Handle immutable irq_chip structures

On 2022-03-15 00:44, Linus Walleij wrote:
> On Wed, Feb 23, 2022 at 4:44 PM Marc Zyngier <maz@...nel.org> wrote:
> 
>> I recently realised that the gpiolib play ugly tricks on the
>> unsuspecting irq_chip structures by patching the callbacks.
> 
> Sorry about that...

No worries. It probably did seem like a good idea at the
time, and I have the benefit of hindsight here...

> 
>> My current approach is to add a new irq_chip flag (IRQCHIP_IMMUTABLE)
>> which does what it says on the tin: don't you dare writing there.
>> Gpiolib is further updated not to install its own callbacks, and it
>> becomes the responsibility of the driver to call into the gpiolib when
>> required. This is similar to what we do for other subsystems such as
>> PCI-MSI.
> 
> OK if there is a precedent it is usually wise to follow.
> 
>> I'd welcome comments on the approach. If deemed acceptable, there are
>> another 300+ drivers to update! Not to mention the documentation. I
>> appreciate that this is a lot of potential changes, but the current
>> situation is messy.
> 
> I'm happy with this approach as long as the 300+ drivers get fixed
> and the old way of doing it gets deleted.

Of course. Note that it will take some time before it actually happens.
My current plan is to stick in a pr_warn() each time a driver
following the old scheme gets registered, as a nudge for people to
update their driver if they care about it.

Regarding documentation, are you OK with me simply replacing the
current code samples with the new approach? It will at least avoid
giving people the wrong idea. I also want to write a brief migration
guide that people willing to bump up their patch count can follow.

I'll repost something once -rc1 is out.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...