From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753251AbcFOGuW (ORCPT ); Wed, 15 Jun 2016 02:50:22 -0400 Received: from helcar.hengli.com.au ([209.40.204.226]:51775 "EHLO helcar.hengli.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750841AbcFOGuU (ORCPT ); Wed, 15 Jun 2016 02:50:20 -0400 Date: Wed, 15 Jun 2016 14:49:40 +0800 From: Herbert Xu To: Baolin Wang Cc: Jens Axboe , Alasdair G Kergon , Mike Snitzer , "open list:DEVICE-MAPPER (LVM)" , David Miller , Eric Biggers , Joonsoo Kim , tadeusz.struk@intel.com, smueller@chronox.de, Masanari Iida , Shaohua Li , Dan Williams , "Martin K. Petersen" , Sagi Grimberg , Kent Overstreet , Keith Busch , Tejun Heo , Ming Lei , Mark Brown , Arnd Bergmann , linux-crypto@vger.kernel.org, linux-block@vger.kernel.org, "open list:SOFTWARE RAID (Multiple Disks) SUPPORT" , LKML Subject: Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag Message-ID: <20160615064939.GA14227@gondor.apana.org.au> References: <238ce3d506051c863300b90720c3e103175747cc.1465301616.git.baolin.wang@linaro.org> <20160607141613.GA2237@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 15, 2016 at 02:27:04PM +0800, Baolin Wang wrote: > > After some investigation, I still think we should divide the bulk > request from dm-crypt into small request (each one is 512bytes) if > this algorithm is not support bulk mode (like CBC). We have talked > with dm-crypt > maintainers why dm-crypt always use 512 bytes as one request size in > below thread, could you please check it? > http://www.kernelhub.org/?p=2&msg=907022 That link only points to an email about an oops. Diggin through that thread, the only objection I have seen is about the fact that you have to generate a fresh IV for each sector, which is precisely what I'm suggesting that you do. IOW, implement the IV generators in the crypto API, and then you can easily generate a new IV (if necessary) for each sector. > That means if we move the IV handling into crypto API, we still can > not use bulk interface for all algorithm, for example we still need to > read/write with 512 bytes for CBC, you can't use 4k or more block on > CBC (and most other encryption modes). If only a part of 4k block is > written (and then system crash happens), CBC would corrupt the block > completely. It means if we map one whole bio with bulk interface in > dm-crypt, we need to divide into every 512 bytes requests in crypto > layer. So I don't think we can handle every algorithm with bulk > interface just moving the IV handling into crypto API. Thanks. Of course you would do CBC in 512-byte blocks, but my point is that you should do this in a crypto API algorithm, rather than dm-crypt as we do now. Once you implement that then dm-crypt can treat every algorithm as if they supported bulk processing. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt