linux-kernel - Re: [PATCH] spi: mediatek: Enable irq before the spi registration

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5db65fd1-575f-df19-0de3-b3e32e4bf1d1@leemhuis.info>
Date:   Wed, 4 Jan 2023 15:08:51 +0100
From:   Thorsten Leemhuis <regressions@...mhuis.info>
To:     Mark Brown <broonie@...nel.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        Ricardo Ribalda <ribalda@...omium.org>
Cc:     linux-mediatek@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org,
        Daniel Golle <daniel@...rotopia.org>,
        linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] spi: mediatek: Enable irq before the spi registration

Hi Mark!

On 27.12.22 14:43, Mark Brown wrote:
> On Sun, 25 Dec 2022 09:37:12 +0100, Ricardo Ribalda wrote:
>> If the irq is enabled after the spi si registered, there can be a race
>> with the initialization of the devices on the spi bus.
>>
>> Eg:
>> mtk-spi 1100a000.spi: spi-mem transfer timeout
>> spi-nor: probe of spi0.0 failed with error -110
>> Unable to handle kernel NULL pointer dereference at virtual address
>> 0000000000000010
>> ...
>> Call trace:
>>  mtk_spi_can_dma+0x0/0x2c
>>
>> [...]
> 
> Applied to
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
> 
> Thanks!
> 
> [1/1] spi: mediatek: Enable irq before the spi registration
>       commit: b24cded8c065d7cef8690b2c7b82b828cce57708
> 
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.
> [...]

Quick question: why did you queue this for the next merge window? This
change *afaics* is fixing a reported regression (a kernel oops)
introduced this cycle:
https://lore.kernel.org/lkml/Y6dL2ZWgd1BD6kew@makrotopia.org/

Or have I missed or confused something?

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.

#regzbot poke