linux-kernel - Re: Regression: spi: core: avoid waking pump thread from spi

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: <EE52ED32-CBB4-40D4-8615-CA814158C826@martin.sperl.org>
Date:   Sun, 20 Jan 2019 12:24:23 +0100
From:   kernel@...tin.sperl.org
To:     Mark Brown <broonie@...nel.org>
Cc:     Jon Hunter <jonathanh@...dia.com>,
        linux-tegra <linux-tegra@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-spi@...r.kernel.org
Subject: Re: Regression: spi: core: avoid waking pump thread from spi_sync instead run teardown delayed

Hi Mark!

> On 18.01.2019, at 20:12, Mark Brown <broonie@...nel.org> wrote:
> 
> On Fri, Jan 18, 2019 at 06:11:31PM +0100, kernel@...tin.sperl.org wrote:
> 
>> Does something like this looks acceptable?
> 
> Yes, it does!

> 
>> SPI_CONTROLLER_MODE_EXCLUSIVE could replace the bus_lock_flag.
>> I am also not sure of the “convention” of memory mode (i.e
>> using mem_ops). Is it maybe implicitly spi_bus_locked - i.e
>> typically only a single device?
> 
> Yes, it does - we're basically handing over the entire SPI bus to
> another bit of hardware that will do memory mapped flash access so we
> can't really have anything else trying to do SPI operations at the same
> time.

These kind of changes it requires are consuming a bit more time than
I was hoping for.

So maybe at this very moment the best is reverting the patch.

I have some patches that would move towards that goal in
baby steps without having to resort to a big rewrite at
this very moment.

Maybe Jon can check each patch one after another to see if any is 
producing the unexpected behavior and only then you would include
them...

As for the root cause of the regression: my guess is that spi-mem is
just not triggering a shutdown any more because of how message_pump works.

The improvement of the state-machine can then get addressed
separately.

Martin