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 <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
