[PATCH 2/2] crypto: Wrap the LHS in expressions of the form !x == y

2015-04-28 Thread David Howells
In the test manager, there are a number of if-statements with expressions of the form !x == y that incur warnings with gcc-5 of the following form: ../crypto/testmgr.c: In function '__test_aead': ../crypto/testmgr.c:523:12: warning: logical not is only applied to the left hand side of comparison

[PATCH 1/2] crypto: Constify (de)compression parameters

2015-04-28 Thread David Howells
In testmgr, struct pcomp_testvec takes a non-const 'params' field, which is pointed to a const deflate_comp_params or deflate_decomp_params object. With gcc-5 this incurs the following warnings: In file included from ../crypto/testmgr.c:44:0: ../crypto/testmgr.h:28736:13: warning: initialization

Re: [PATCH crypto-2.6] lib: make memzero_explicit more robust against dead store elimination

2015-04-28 Thread Stephan Mueller
Am Dienstag, 28. April 2015, 17:22:20 schrieb Daniel Borkmann: Hi Daniel, In commit 0b053c951829 (lib: memzero_explicit: use barrier instead of OPTIMIZER_HIDE_VAR), we made memzero_explicit() more robust in case LTO would decide to inline memzero_explicit() and eventually find out it could be

Re: [PATCH v3 2/5] lib: introduce crc_t10dif_update()

2015-04-28 Thread Akinobu Mita
2015-04-29 2:38 GMT+09:00 Tim Chen tim.c.c...@linux.intel.com: There are a lot of duplicated code between crc_t10dif_update and crc_t10dif. The only difference is for the update function we import the crc value. I will prefer that we consolidate the code into a local inline function that

Re: [PATCH v3 2/5] lib: introduce crc_t10dif_update()

2015-04-28 Thread Herbert Xu
On Tue, Apr 28, 2015 at 10:38:36AM -0700, Tim Chen wrote: + if (update) { + err = crypto_shash_import(desc.shash, crc); + BUG_ON(err); You don't even have to make this conditional. Just always do the import since it's just doing a memcpy anyway. Cheers,

Re: [PATCH v3 2/5] lib: introduce crc_t10dif_update()

2015-04-28 Thread Martin K. Petersen
Tim == Tim Chen tim.c.c...@linux.intel.com writes: Tim There are a lot of duplicated code between crc_t10dif_update and Tim crc_t10dif. The only difference is for the update function we Tim import the crc value. I will prefer that we consolidate the code Tim into a local inline function that

Re: [PATCH v3 0/5] target: Fix several problems related to T10-PI support

2015-04-28 Thread Martin K. Petersen
Sagi == Sagi Grimberg sa...@dev.mellanox.co.il writes: Sagi, Sagi I thought that WRITE_SAME with DIX would include PI for the block Sagi that is being sent over the wire, the initiator and target HBAs Sagi will verify the single block integrity and the target backend will Sagi expand the PI for

[PATCH crypto-2.6] lib: make memzero_explicit more robust against dead store elimination

2015-04-28 Thread Daniel Borkmann
In commit 0b053c951829 (lib: memzero_explicit: use barrier instead of OPTIMIZER_HIDE_VAR), we made memzero_explicit() more robust in case LTO would decide to inline memzero_explicit() and eventually find out it could be elimiated as dead store. While using barrier() works well for the case of

Re: [PATCH v3 2/5] lib: introduce crc_t10dif_update()

2015-04-28 Thread Tim Chen
On Sat, 2015-04-25 at 23:33 +0900, Akinobu Mita wrote: This introduces crc_t10dif_update() which enables to calculate CRC for a block which straddles multiple SG elements by calling multiple times. Signed-off-by: Akinobu Mita akinobu.m...@gmail.com Cc: Tim Chen tim.c.c...@linux.intel.com

Re: [PATCH v3 0/5] target: Fix several problems related to T10-PI support

2015-04-28 Thread Sagi Grimberg
On 4/28/2015 2:50 AM, Martin K. Petersen wrote: Sagi == Sagi Grimberg sa...@dev.mellanox.co.il writes: Sagi The problem is that the HBA does not have the write_same Sagi functionality you introduce here, i.e. generate multiple same Sagi protection fields for a single data block. Adding

Re: [PATCH 0/2] crypto: add new driver for Marvell CESA

2015-04-28 Thread Boris Brezillon
Herbert, David, Any comment on the crypto driver implementation ? I've had several reviews focused on: 1/ splitting the patch series into smaller subsets 2/ allowing for smoother transition from the old driver to the new one I'll address (or have addressed) all of these comments, but I'd like