linux-kernel - Re: [PATCH] async_tx: deprecate broken support for channel switching

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] [day] [month] [year] [list]

Message-ID: <20170216043924.GQ2843@localhost>
Date:   Thu, 16 Feb 2017 10:09:24 +0530
From:   Vinod Koul <vinod.koul@...el.com>
To:     Dan Williams <dan.j.williams@...el.com>
Cc:     Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
        Anup Patel <anup.patel@...adcom.com>,
        Rameshwar Prasad Sahu <rsahu@....com>,
        Russell King <linux@...linux.org.uk>,
        linux-kernel@...r.kernel.org, linux-raid@...r.kernel.org,
        dmaengine@...r.kernel.org, Anatolij Gustschin <agust@...x.de>,
        Saeed Bishara <saeed.bishara@...il.com>
Subject: Re: [PATCH] async_tx: deprecate broken support for channel switching

On Wed, Feb 15, 2017 at 06:42:09PM -0800, Dan Williams wrote:
> Back in 2011, Russell pointed out that the "async_tx channel switch"
> capability was violating expectations of the dma mapping api [1]. At the
> time the existing uses were reviewed as still usable, but that longer
> term we needed a rework of the raid offload implementation. While some
> of the framework for a fixed implementation was introduced in 2012 [2],
> the wider rewrite never materialized.
> 
> There continues to be interest in raid offload with new dma/raid engine
> drivers being submitted. Those drivers must not build on top of the
> broken channel switching capability.
> 
> Prevent async_tx from using an offload engine if the channel switching
> capability is enabled. This still allows the engine to be used for other
> purposes, but the broken way async_tx uses these engines for raid will
> be disabled. For configurations where this causes a performance
> regression the only solution is to start the work of eliminating the
> async_tx api and moving channel management into the raid code directly
> where it can manage marshalling an operation stream between multiple dma
> channels.

Applied, thanks

-- 
~Vinod