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]

Date:   Tue, 15 Jan 2019 19:26:19 +0000
From:   Mark Brown <broonie@...nel.org>
To:     kernel@...tin.sperl.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

On Tue, Jan 15, 2019 at 06:39:27PM +0100, kernel@...tin.sperl.org wrote:

> Is it possible that the specific flash is not using the “normal” 
> spi_pump_message, but spi_controller_mem_ops operations? 

Right, that's my best guess at the minute as well.

> Maybe we are missing the teardown in that driver or something is
> changing flags there.

> grepping a bit:

> I see spi_mem_access_start calling spi_flush_queue, which is calling
> pump_message, which - if there is no transfer - will trigger a delayed
> tear-down, while it maybe should not be doing that.

If nothing else it's inefficient.

> Maybe spi_mem_access_end needs a call to spi_flush_queue as well?

Hrm, or needs to schedule the queue at any rate (though this will only
have an impact in the fairly unusual case where there's something
sharing the bus with a flash).

> Unfortunately this is theoretical work and quite a lot of guesswork
> without an actual device available for testing...

Indeed.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)