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

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

Date:   Thu, 9 May 2019 21:47:08 +0200
From:   Martin Sperl <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 23.01.2019, at 18:56, Mark Brown <broonie@...nel.org> wrote:
> 
>> On Sun, Jan 20, 2019 at 12:24:23PM +0100, kernel@...tin.sperl.org wrote:
>> 
>> These kind of changes it requires are consuming a bit more time than
>> I was hoping for.
> 
> Thanks for trying.
> 
>> So maybe at this very moment the best is reverting the patch.
> 
> Yes, I'm just going to do that for now.
> 
>> 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.
> 
> I'm fairly sure that's what's going on but not been able to get my head
> around things enough to figure out what's going wrong yet.

While thinking about this again maybe an idea:
What about implement a second spi_transfer_one implementation (together
with a message pump implementation) that would handle things correctly.

Any driver then can select the old (default) or new implementation and thus
would allow the optimizations to take place only for verified working drivers...

At least this way we would not be blocked because no hw exposing this
Behavior is available to us - at the cost of extra code to get maintained.

What I would then also like to do for the new implementation is modify the
API a bit - ideally I would like to:
* Make spi_sync the primary interface which the message pump is also 
  using directly
* move all the prepare stuff early into spi-sync, so that for example the
  Preparing (including dma mapping) would get done in the calling thread
  And only the prepared message would get submitted to the queue
  - special processing would be needed for the spi-async case.

This should optimize the computations out of the central loop faster.

Adding spi-nand support could get added later by someone who has
access to a device making use of this.

If that sounds as somewhat acceptable then I will try get something
Implemented.

Any other ideas where we could improve as well?

Martin