Re: booting sun sparc T5120 with "nosmp" kernel causes OOPS in n2_crypto module

2016-05-25 Thread Anatoly Pugachev 
tried to boot git kernel ( 4.6.0+ , git commit
ecc5fbd5ef472a4c659dc56a5739b3f041c0530c ) with "nosmp" , got n2_crypto OOPS
as well ext4 OOPS (unable to finish boot , mount / fs) , boot log :




SPARC Enterprise T5120, No Keyboard
Copyright (c) 1998, 2016, Oracle and/or its affiliates. All rights reserved.
OpenBoot 4.33.6.g, 16256 MB memory available, Serial #78400024.
Ethernet address 0:14:4f:ac:4a:18, Host ID: 84ac4a18.



Boot device: disk1  File and args: 
SILO Version 1.4.14
boot: 6
Allocated 64 Megs of memory at 0x4000 for kernel
Uncompressing image...
Loaded kernel version 4.6.0
Loading initial ramdisk (17830856 bytes at 0xC80 phys, 0x40C0 virt)...
|
[0.00] PROMLIB: Sun IEEE Boot Prom 'OBP 4.33.6.g 2016/03/11 06:05'
[0.00] PROMLIB: Root node compatible: sun4v
[0.00] Linux version 4.6.0+ (mator@nvg5120) (gcc version 5.3.1 20160509 
(Debian 5.3.1-19) ) #1 SMP Wed May 25 22:17:28 MSK 2016
[0.00] bootconsole [earlyprom0] enabled
[0.00] ARCH: SUN4V
[0.00] Ethernet address: 00:14:4f:ac:4a:18
[0.00] MM: PAGE_OFFSET is 0x8000 (max_phys_bits == 39)
[0.00] MM: VMALLOC [0x0001 --> 0x6000]
[0.00] MM: VMEMMAP [0x6000 --> 0xc000]
[0.00] Kernel: Using 3 locked TLB entries for main kernel image.
[0.00] Remapping the kernel... done.
[0.00] OF stdout device is: /virtual-devices@100/console@1
[0.00] PROM: Built device tree with 195069 bytes of memory.
[0.00] MDESC: Size is 61728 bytes.
[0.00] PLATFORM: banner-name [SPARC Enterprise T5120]
[0.00] PLATFORM: name [SUNW,SPARC-Enterprise-T5120]
[0.00] PLATFORM: hostid [84ac4a18]
[0.00] PLATFORM: serial# [00ab4130]
[0.00] PLATFORM: stick-frequency [457646c0]
[0.00] PLATFORM: mac-address [144fac4a18]
[0.00] PLATFORM: watchdog-resolution [1000 ms]
[0.00] PLATFORM: watchdog-max-timeout [3153600 ms]
[0.00] PLATFORM: max-cpus [64]
[0.00] Top of RAM: 0x3ffb16000, Total RAM: 0x3f76ac000
[0.00] Memory hole size: 132MB
[0.00] Allocated 16384 bytes for kernel page tables.
[0.00] Zone ranges:
[0.00]   Normal   [mem 0x0840-0x0003ffb15fff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x0840-0x0003ffa89fff]
[0.00]   node   0: [mem 0x0003ffa9a000-0x0003ffaadfff]
[0.00]   node   0: [mem 0x0003ffb08000-0x0003ffb15fff]
[0.00] Initmem setup node 0 [mem 0x0840-0x0003ffb15fff]
[0.00] Booting Linux...
[0.00] CPU CAPS: [flush,stbar,swap,muldiv,v9,blkinit,n2,mul32]
[0.00] CPU CAPS: [div32,v8plus,popc,vis,vis2,ASIBlkInit]
[0.00] percpu: Embedded 10 pages/cpu @8003ff00 s37720 r8192 
d36008 u131072
[0.00] SUN4V: Mondo queue sizes [cpu(8192) dev(16384) r(8192) nr(256)]
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 2061296
[0.00] Kernel command line: root=/dev/mapper/vg1-root ro nosmp
[0.00] log_buf_len individual max cpu contribution: 4096 bytes
[0.00] log_buf_len total cpu_extra contributions: 258048 bytes
[0.00] log_buf_len min size: 131072 bytes
[0.00] log_buf_len: 524288 bytes
[0.00] early log buf free: 127696(97%)
[0.00] PID hash table entries: 4096 (order: 2, 32768 bytes)
[0.00] Dentry cache hash table entries: 2097152 (order: 11, 16777216 
bytes)
[0.00] Inode-cache hash table entries: 1048576 (order: 10, 8388608 
bytes)
[0.00] Sorting __ex_table...
[0.00] Memory: 16429712K/16636592K available (5626K kernel code, 737K 
rwdata, 1408K rodata, 464K init, 750K bss, 206880K reserved, 0K cma-reserved)
[0.00] Hierarchical RCU implementation.
[0.00]  Build-time adjustment of leaf fanout to 64.
[0.00]  RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=64.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=64
[0.00] NR_IRQS:2048 nr_irqs:2048 1
[0.00] SUN4V: Using IRQ API major 1, cookie only virqs disabled
[1319829.255759] clocksource: stick: mask: 0x max_cycles: 
0x10cc5ac4c8a, max_idle_ns: 440795218862 ns
[1319829.257796] clocksource: mult[dbabc5] shift[24]
[1319829.258492] clockevent: mult[952b25d1] shift[31]
[1319829.261610] Console: colour dummy device 80x25
[1319829.262298] console [tty0] enabled
[1319829.262589] bootconsole [earlyprom0] disabled
[0.00] PROMLIB: Sun IEEE Boot Prom 'OBP 4.33.6.g 2016/03/11 06:05'
[0.00] PROMLIB: Root node compatible: sun4v
[0.00] Linux version 4.6.0+ (mator@nvg5120) (gcc version 5.3.1 20160509 
(Debian 5.3.1-19) ) #1 SMP Wed May 25 22:17:28 MSK 2016
[0.00] bootconsole [earlyprom0] enabled
[0.00] ARCH: SUN4V
[

Re: tcrypt failing on hmac(crc32)

2016-05-25 Thread Marcus Meissner 
On Wed, May 25, 2016 at 01:39:46PM +0200, Stephan Mueller wrote:
> Am Mittwoch, 25. Mai 2016, 13:36:10 schrieb Marcus Meissner:
> 
> Hi Marcus,
> 
> > Hi,
> > 
> > On Wed, May 25, 2016 at 09:10:31AM +0200, Stephan Mueller wrote:
> > > Am Mittwoch, 25. Mai 2016, 09:07:52 schrieb Marcus Meissner:
> > > 
> > > Hi Marcus,
> > > 
> > > > Hi,
> > > > 
> > > > when enabling the testmgr framework and FIPS in 4.6 and 4.4 and running
> > > > "modprobe tcrypt"
> > > > 
> > > }, {
> > > 
> > > .alg = "hmac(crc32)",
> > > .test = alg_test_hash,
> > > 
> > > ...
> > > 
> > > fips_allowed = 1 missing?
> > 
> > The kernel was not in FIPS mode, and adding it did not help. :/
> 
> Sorry, I read FIPS and implied fips=1 :-)

I think we are running in a precondition

ds = salg->digestsize;  // is CHKSUM_DIGEST_SIZE == 4 for CRC32
ss = salg->statesize;   // ? cant find it
alg = >base;  // base.cra_blocksize seems 
CHKSUM_BLOCKSIZE == 1
if (ds > alg->cra_blocksize ||
ss < alg->cra_blocksize)
goto out_put_alg;

4 > 1 ... so EINVAL return.

If this is the case, hmac(crc32) might be kind of non-sensical?

Ciao, Marcus
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: tcrypt failing on hmac(crc32)

2016-05-25 Thread Stephan Mueller 
Am Mittwoch, 25. Mai 2016, 13:36:10 schrieb Marcus Meissner:

Hi Marcus,

> Hi,
> 
> On Wed, May 25, 2016 at 09:10:31AM +0200, Stephan Mueller wrote:
> > Am Mittwoch, 25. Mai 2016, 09:07:52 schrieb Marcus Meissner:
> > 
> > Hi Marcus,
> > 
> > > Hi,
> > > 
> > > when enabling the testmgr framework and FIPS in 4.6 and 4.4 and running
> > > "modprobe tcrypt"
> > > 
> > }, {
> > 
> > .alg = "hmac(crc32)",
> > .test = alg_test_hash,
> > 
> > ...
> > 
> > fips_allowed = 1 missing?
> 
> The kernel was not in FIPS mode, and adding it did not help. :/

Sorry, I read FIPS and implied fips=1 :-)

Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: key retention service: DH support

2016-05-25 Thread David Howells 
Mat Martineau  wrote:

> Since the KDF patches are not yet merged, I'm not sure of the best way to
> accomodate the future feature. We could future-proof KEYCTL_DH_COMPUTE by
> adding a 5th arg, an optional pointer to KDF configuration (NAME and
> LABEL).

If we want to do this, it needs to be done before the merge window closes,
maybe by -rc2.  Just requiring the extra argument to be 0 for now and/or
extending struct keyctl_dh_params to include some must-be-zeroed spare space
would do for now.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: key retention service: DH support

2016-05-25 Thread Herbert Xu 
On Tue, May 24, 2016 at 06:45:09PM +0200, Stephan Mueller wrote:
> Am Dienstag, 24. Mai 2016, 09:22:22 schrieb Mat Martineau:
> 
> Hi Mat, Herbert
> > 
> > KDF transformations would be extremely useful, but transforming the DH
> > output using a KDF needs to be configurable. There are enough different
> > uses for DH that it's important to have access to the raw values.
> > 
> > Since the KDF patches are not yet merged, I'm not sure of the best way to
> > accomodate the future feature. We could future-proof KEYCTL_DH_COMPUTE by
> > adding a 5th arg, an optional pointer to KDF configuration (NAME and
> > LABEL). Or a separate KEYCTL_DH_COMPUTE_KDF command can be added later.
> 
> With that statement, Herbert, should we start looking into my KDF patches 
> after the merge window closes?

Sure.

Cheers,
-- 
Email: Herbert Xu 
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-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwrng: stm32 - fix build warning

2016-05-25 Thread Arnd Bergmann 
On Wednesday, May 25, 2016 7:35:17 AM CEST Sudip Mukherjee wrote:
> On Tuesday 24 May 2016 02:05 AM, Arnd Bergmann wrote:
> > On Monday, May 23, 2016 6:14:08 PM CEST Sudip Mukherjee wrote:
> >> We have been getting build warning about:
> >> drivers/char/hw_random/stm32-rng.c: In function 'stm32_rng_read':
> >> drivers/char/hw_random/stm32-rng.c:82:19: warning: 'sr' may be used
> >>  uninitialized in this function
> >>
> >> On checking the code it turns out that sr can never be used
> >> uninitialized as sr is getting initialized in the while loop and while
> >> loop will always execute as the minimum value of max can be 32.
> >> So just initialize sr to 0 while declaring it to silence the compiler.
> >>
> >> Signed-off-by: Sudip Mukherjee 
> >> ---
> >
> > I notice that you are using a really old compiler. While this warning
> > seems to be valid in the sense that the compiler should figure out that
> > the variable might be used uninitialized, please update your toolchain
> > before reporting other such problems, as gcc-4.6 had a lot more false
> > positives that newer ones (5.x or 6.x) have.
> 
> yes, i need to upgrade gcc in my travis bot. But in my local system I am 
> having gcc-4.8.4 and there also I am having this error and i am sure 
> 4.8.4 is still being used by many people.

Right, the change from gcc-4.8 to 4.9 is what drastically changed hte
maybe-uninitialized warnings, introducing a number of additional warnings
(many of them correct) but removing many others (mostly false positives).
I tend to care only about the ones in 4.9+ for this reason. I haven't
run statistics on this in a while, but I guess we could consider turning
off this warning for 4.8 and earlier (though IIRC the switch to turn it
off only appeared in 4.9).

BTW, regarding your build infrastructure, I'd also recommend building
with 'make -s' to make the output more compact.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/3] block: Introduce blk_bio_map_sg() to map one bio

2016-05-25 Thread Baolin Wang 
On 25 May 2016 at 16:52, Ming Lei  wrote:
>>  /*
>> + * map a bio to scatterlist, return number of sg entries setup.
>> + */
>> +int blk_bio_map_sg(struct request_queue *q, struct bio *bio,
>> +  struct scatterlist *sglist,
>> +  struct scatterlist **sg)
>> +{
>> +   struct bio_vec bvec, bvprv = { NULL };
>> +   struct bvec_iter iter;
>> +   int nsegs, cluster;
>> +
>> +   nsegs = 0;
>> +   cluster = blk_queue_cluster(q);
>> +
>> +   if (bio->bi_rw & REQ_DISCARD) {
>> +   /*
>> +* This is a hack - drivers should be neither modifying the
>> +* biovec, nor relying on bi_vcnt - but because of
>> +* blk_add_request_payload(), a discard bio may or may not 
>> have
>> +* a payload we need to set up here (thank you Christoph) and
>> +* bi_vcnt is really the only way of telling if we need to.
>> +*/
>> +
>> +   if (bio->bi_vcnt)
>> +   goto single_segment;
>> +
>> +   return 0;
>> +   }
>> +
>> +   if (bio->bi_rw & REQ_WRITE_SAME) {
>> +single_segment:
>> +   *sg = sglist;
>> +   bvec = bio_iovec(bio);
>> +   sg_set_page(*sg, bvec.bv_page, bvec.bv_len, bvec.bv_offset);
>> +   return 1;
>> +   }
>> +
>> +   bio_for_each_segment(bvec, bio, iter)
>> +   __blk_segment_map_sg(q, , sglist, , sg,
>> +, );
>> +
>> +   return nsegs;
>> +}
>> +EXPORT_SYMBOL(blk_bio_map_sg);
>
> You can use __blk_bios_map_sg() to implement blk_bio_map_sg(),
> then code duplication may be avoided.

OK. I'll re-factor the code to map one bio.

>
>> +
>> +/*
>>   * map a request to scatterlist, return number of sg entries setup. Caller
>>   * must make sure sg can hold rq->nr_phys_segments entries
>>   */
>> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
>> index 1fd8fdf..e5de4f8 100644
>> --- a/include/linux/blkdev.h
>> +++ b/include/linux/blkdev.h
>> @@ -1013,6 +1013,9 @@ extern void blk_queue_write_cache(struct request_queue 
>> *q, bool enabled, bool fu
>>  extern struct backing_dev_info *blk_get_backing_dev_info(struct 
>> block_device *bdev);
>>
>>  extern int blk_rq_map_sg(struct request_queue *, struct request *, struct 
>> scatterlist *);
>> +extern int blk_bio_map_sg(struct request_queue *q, struct bio *bio,
>> + struct scatterlist *sglist,
>> + struct scatterlist **sg);
>>  extern void blk_dump_rq_flags(struct request *, char *);
>>  extern long nr_blockdev_pages(void);
>>
>> --
>> 1.7.9.5
>>



-- 
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/3] block: Introduce blk_bio_map_sg() to map one bio

2016-05-25 Thread Ming Lei 
On Wed, May 25, 2016 at 2:12 PM, Baolin Wang  wrote:
> In dm-crypt, it need to map one bio to scatterlist for improving the
> hardware engine encryption efficiency. Thus this patch introduces the
> blk_bio_map_sg() function to map one bio with scatterlists.
>
> Signed-off-by: Baolin Wang 
> ---
>  block/blk-merge.c  |   45 +
>  include/linux/blkdev.h |3 +++
>  2 files changed, 48 insertions(+)
>
> diff --git a/block/blk-merge.c b/block/blk-merge.c
> index 2613531..9b92af4 100644
> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -417,6 +417,51 @@ single_segment:
>  }
>
>  /*
> + * map a bio to scatterlist, return number of sg entries setup.
> + */
> +int blk_bio_map_sg(struct request_queue *q, struct bio *bio,
> +  struct scatterlist *sglist,
> +  struct scatterlist **sg)
> +{
> +   struct bio_vec bvec, bvprv = { NULL };
> +   struct bvec_iter iter;
> +   int nsegs, cluster;
> +
> +   nsegs = 0;
> +   cluster = blk_queue_cluster(q);
> +
> +   if (bio->bi_rw & REQ_DISCARD) {
> +   /*
> +* This is a hack - drivers should be neither modifying the
> +* biovec, nor relying on bi_vcnt - but because of
> +* blk_add_request_payload(), a discard bio may or may not 
> have
> +* a payload we need to set up here (thank you Christoph) and
> +* bi_vcnt is really the only way of telling if we need to.
> +*/
> +
> +   if (bio->bi_vcnt)
> +   goto single_segment;
> +
> +   return 0;
> +   }
> +
> +   if (bio->bi_rw & REQ_WRITE_SAME) {
> +single_segment:
> +   *sg = sglist;
> +   bvec = bio_iovec(bio);
> +   sg_set_page(*sg, bvec.bv_page, bvec.bv_len, bvec.bv_offset);
> +   return 1;
> +   }
> +
> +   bio_for_each_segment(bvec, bio, iter)
> +   __blk_segment_map_sg(q, , sglist, , sg,
> +, );
> +
> +   return nsegs;
> +}
> +EXPORT_SYMBOL(blk_bio_map_sg);

You can use __blk_bios_map_sg() to implement blk_bio_map_sg(),
then code duplication may be avoided.

> +
> +/*
>   * map a request to scatterlist, return number of sg entries setup. Caller
>   * must make sure sg can hold rq->nr_phys_segments entries
>   */
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index 1fd8fdf..e5de4f8 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -1013,6 +1013,9 @@ extern void blk_queue_write_cache(struct request_queue 
> *q, bool enabled, bool fu
>  extern struct backing_dev_info *blk_get_backing_dev_info(struct block_device 
> *bdev);
>
>  extern int blk_rq_map_sg(struct request_queue *, struct request *, struct 
> scatterlist *);
> +extern int blk_bio_map_sg(struct request_queue *q, struct bio *bio,
> + struct scatterlist *sglist,
> + struct scatterlist **sg);
>  extern void blk_dump_rq_flags(struct request *, char *);
>  extern long nr_blockdev_pages(void);
>
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: tcrypt failing on hmac(crc32)

2016-05-25 Thread Stephan Mueller 
Am Mittwoch, 25. Mai 2016, 09:07:52 schrieb Marcus Meissner:

Hi Marcus,

> Hi,
> 
> when enabling the testmgr framework and FIPS in 4.6 and 4.4 and running
> "modprobe tcrypt"

}, {
.alg = "hmac(crc32)",
.test = alg_test_hash,
...

fips_allowed = 1 missing?
> 
> [ 1153.298266] alg: hash: Failed to load transform for hmac(crc32): -2
> [ 1153.340636] tcrypt: one or more tests failed!
> 
> I spent some hours making sense of what is missing, but I got lost in the
> maze of the crypto apis between sync and async hashes somewhere.
> 
> Does anyone know the solution for this, otherwise I will need to continue
> looking.
> 
> Ciao, Marcus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwrng: stm32 - fix build warning

2016-05-25 Thread Sudip Mukherjee 

On Tuesday 24 May 2016 02:05 AM, Arnd Bergmann wrote:

On Monday, May 23, 2016 6:14:08 PM CEST Sudip Mukherjee wrote:

We have been getting build warning about:
drivers/char/hw_random/stm32-rng.c: In function 'stm32_rng_read':
drivers/char/hw_random/stm32-rng.c:82:19: warning: 'sr' may be used
uninitialized in this function

On checking the code it turns out that sr can never be used
uninitialized as sr is getting initialized in the while loop and while
loop will always execute as the minimum value of max can be 32.
So just initialize sr to 0 while declaring it to silence the compiler.

Signed-off-by: Sudip Mukherjee 
---


I notice that you are using a really old compiler. While this warning
seems to be valid in the sense that the compiler should figure out that
the variable might be used uninitialized, please update your toolchain
before reporting other such problems, as gcc-4.6 had a lot more false
positives that newer ones (5.x or 6.x) have.


yes, i need to upgrade gcc in my travis bot. But in my local system I am 
having gcc-4.8.4 and there also I am having this error and i am sure 
4.8.4 is still being used by many people.


Regards
Sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwrng: stm32 - fix build warning

2016-05-25 Thread Sudip Mukherjee 

On Tuesday 24 May 2016 02:50 PM, Maxime Coquelin wrote:

2016-05-24 10:58 GMT+02:00 Arnd Bergmann :

On Tuesday, May 24, 2016 10:50:17 AM CEST Maxime Coquelin wrote:

diff --git a/drivers/char/hw_random/stm32-rng.c
b/drivers/char/hw_random/stm32-rng.c
index 92a810648bd0..2a0fc90e4dc3 100644
--- a/drivers/char/hw_random/stm32-rng.c
+++ b/drivers/char/hw_random/stm32-rng.c
@@ -68,6 +68,10 @@ static int stm32_rng_read(struct hwrng *rng, void
*data, size_t max, bool wait)
 } while (!sr && --timeout);
 }

+   if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
+   "bad RNG status - %x\n", sr))
+   writel_relaxed(0, priv->base + RNG_SR);
+
 /* If error detected or data not ready... */
 if (sr != RNG_SR_DRDY)
 break;
@@ -79,10 +83,6 @@ static int stm32_rng_read(struct hwrng *rng, void
*data, size_t max, bool wait)
 max -= sizeof(u32);
 }

-   if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
- "bad RNG status - %x\n", sr))
-   writel_relaxed(0, priv->base + RNG_SR);
-
 pm_runtime_mark_last_busy((struct device *) priv->rng.priv);
 pm_runtime_put_sync_autosuspend((struct device *) priv->rng.priv);

Thanks,



Yes, that looks good to me.


Thanks!
Sudip, do you want to send the patch, or I manage to do it?


Maybe you should send it, i have not done anything in reaching its final 
form.


Regards
Sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 3/3] md: dm-crypt: Introduce the bulk mode method when sending request

2016-05-25 Thread Baolin Wang 
In now dm-crypt code, it is ineffective to map one segment (always one
sector) of one bio with just only one scatterlist at one time for hardware
crypto engine. Especially for some encryption mode (like ecb or xts mode)
cooperating with the crypto engine, they just need one initial IV or null
IV instead of different IV for each sector. In this situation We can consider
to use multiple scatterlists to map the whole bio and send all scatterlists
of one bio to crypto engine to encrypt or decrypt, which can improve the
hardware engine's efficiency.

With this optimization, On my test setup (beaglebone black board) using 64KB
I/Os on an eMMC storage device I saw about 60% improvement in throughput for
encrypted writes, and about 100% improvement for encrypted reads. But this
is not fit for other modes which need different IV for each sector.

Signed-off-by: Baolin Wang 
---
 drivers/md/dm-crypt.c |  188 +
 1 file changed, 176 insertions(+), 12 deletions(-)

diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 4f3cb35..1c86ea7 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -33,6 +33,7 @@
 #include 
 
 #define DM_MSG_PREFIX "crypt"
+#define DM_MAX_SG_LIST 1024
 
 /*
  * context holding the current state of a multi-part conversion
@@ -46,6 +47,8 @@ struct convert_context {
sector_t cc_sector;
atomic_t cc_pending;
struct skcipher_request *req;
+   struct sg_table sgt_in;
+   struct sg_table sgt_out;
 };
 
 /*
@@ -803,6 +806,108 @@ static struct crypt_iv_operations crypt_iv_tcw_ops = {
.post  = crypt_iv_tcw_post
 };
 
+/*
+ * Check how many sg entry numbers are needed when map one bio
+ * with scatterlists in advance.
+ */
+static unsigned int crypt_sg_entry(struct bio *bio_t)
+{
+   struct request_queue *q = bdev_get_queue(bio_t->bi_bdev);
+   int cluster = blk_queue_cluster(q);
+   struct bio_vec bvec, bvprv = { NULL };
+   struct bvec_iter biter;
+   unsigned long nbytes = 0, sg_length = 0;
+   unsigned int sg_cnt = 0, first_bvec = 0;
+
+   if (bio_t->bi_rw & REQ_DISCARD) {
+   if (bio_t->bi_vcnt)
+   return 1;
+   return 0;
+   }
+
+   if (bio_t->bi_rw & REQ_WRITE_SAME)
+   return 1;
+
+   bio_for_each_segment(bvec, bio_t, biter) {
+   nbytes = bvec.bv_len;
+
+   if (!cluster) {
+   sg_cnt++;
+   continue;
+   }
+
+   if (!first_bvec) {
+   first_bvec = 1;
+   goto new_segment;
+   }
+
+   if (sg_length + nbytes > queue_max_segment_size(q))
+   goto new_segment;
+
+   if (!BIOVEC_PHYS_MERGEABLE(, ))
+   goto new_segment;
+
+   if (!BIOVEC_SEG_BOUNDARY(q, , ))
+   goto new_segment;
+
+   sg_length += nbytes;
+   continue;
+
+new_segment:
+   memcpy(, , sizeof(struct bio_vec));
+   sg_length = nbytes;
+   sg_cnt++;
+   }
+
+   return sg_cnt;
+}
+
+static int crypt_convert_alloc_table(struct crypt_config *cc,
+struct convert_context *ctx)
+{
+   struct bio *bio_in = ctx->bio_in;
+   struct bio *bio_out = ctx->bio_out;
+   unsigned int mode = skcipher_is_bulk_mode(any_tfm(cc));
+   unsigned int sg_in_max, sg_out_max;
+   int ret = 0;
+
+   if (!mode)
+   goto out2;
+
+   /*
+* Need to calculate how many sg entry need to be used
+* for this bio.
+*/
+   sg_in_max = crypt_sg_entry(bio_in) + 1;
+   if (sg_in_max > DM_MAX_SG_LIST || sg_in_max <= 2)
+   goto out2;
+
+   ret = sg_alloc_table(>sgt_in, sg_in_max, GFP_KERNEL);
+   if (ret)
+   goto out2;
+
+   if (bio_data_dir(bio_in) == READ)
+   goto out1;
+
+   sg_out_max = crypt_sg_entry(bio_out) + 1;
+   if (sg_out_max > DM_MAX_SG_LIST || sg_out_max <= 2)
+   goto out3;
+
+   ret = sg_alloc_table(>sgt_out, sg_out_max, GFP_KERNEL);
+   if (ret)
+   goto out3;
+
+   return 0;
+
+out3:
+   sg_free_table(>sgt_in);
+out2:
+   ctx->sgt_in.orig_nents = 0;
+out1:
+   ctx->sgt_out.orig_nents = 0;
+   return ret;
+}
+
 static void crypt_convert_init(struct crypt_config *cc,
   struct convert_context *ctx,
   struct bio *bio_out, struct bio *bio_in,
@@ -843,7 +948,13 @@ static int crypt_convert_block(struct crypt_config *cc,
 {
struct bio_vec bv_in = bio_iter_iovec(ctx->bio_in, ctx->iter_in);
struct bio_vec bv_out = bio_iter_iovec(ctx->bio_out, ctx->iter_out);
+   unsigned int mode = skcipher_is_bulk_mode(any_tfm(cc));
+   struct bio *bio_in =

[RFC 1/3] block: Introduce blk_bio_map_sg() to map one bio

2016-05-25 Thread Baolin Wang 
In dm-crypt, it need to map one bio to scatterlist for improving the
hardware engine encryption efficiency. Thus this patch introduces the
blk_bio_map_sg() function to map one bio with scatterlists.

Signed-off-by: Baolin Wang 
---
 block/blk-merge.c  |   45 +
 include/linux/blkdev.h |3 +++
 2 files changed, 48 insertions(+)

diff --git a/block/blk-merge.c b/block/blk-merge.c
index 2613531..9b92af4 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -417,6 +417,51 @@ single_segment:
 }
 
 /*
+ * map a bio to scatterlist, return number of sg entries setup.
+ */
+int blk_bio_map_sg(struct request_queue *q, struct bio *bio,
+  struct scatterlist *sglist,
+  struct scatterlist **sg)
+{
+   struct bio_vec bvec, bvprv = { NULL };
+   struct bvec_iter iter;
+   int nsegs, cluster;
+
+   nsegs = 0;
+   cluster = blk_queue_cluster(q);
+
+   if (bio->bi_rw & REQ_DISCARD) {
+   /*
+* This is a hack - drivers should be neither modifying the
+* biovec, nor relying on bi_vcnt - but because of
+* blk_add_request_payload(), a discard bio may or may not have
+* a payload we need to set up here (thank you Christoph) and
+* bi_vcnt is really the only way of telling if we need to.
+*/
+
+   if (bio->bi_vcnt)
+   goto single_segment;
+
+   return 0;
+   }
+
+   if (bio->bi_rw & REQ_WRITE_SAME) {
+single_segment:
+   *sg = sglist;
+   bvec = bio_iovec(bio);
+   sg_set_page(*sg, bvec.bv_page, bvec.bv_len, bvec.bv_offset);
+   return 1;
+   }
+
+   bio_for_each_segment(bvec, bio, iter)
+   __blk_segment_map_sg(q, , sglist, , sg,
+, );
+
+   return nsegs;
+}
+EXPORT_SYMBOL(blk_bio_map_sg);
+
+/*
  * map a request to scatterlist, return number of sg entries setup. Caller
  * must make sure sg can hold rq->nr_phys_segments entries
  */
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 1fd8fdf..e5de4f8 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1013,6 +1013,9 @@ extern void blk_queue_write_cache(struct request_queue 
*q, bool enabled, bool fu
 extern struct backing_dev_info *blk_get_backing_dev_info(struct block_device 
*bdev);
 
 extern int blk_rq_map_sg(struct request_queue *, struct request *, struct 
scatterlist *);
+extern int blk_bio_map_sg(struct request_queue *q, struct bio *bio,
+ struct scatterlist *sglist,
+ struct scatterlist **sg);
 extern void blk_dump_rq_flags(struct request *, char *);
 extern long nr_blockdev_pages(void);
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

2016-05-25 Thread Baolin Wang 
Now some cipher hardware engines prefer to handle bulk block rather than one
sector (512 bytes) created by dm-crypt, cause these cipher engines can handle
the intermediate values (IV) by themselves in one bulk block. This means we
can increase the size of the request by merging request rather than always 512
bytes and thus increase the hardware engine processing speed.

So introduce 'CRYPTO_ALG_BULK' flag to indicate this cipher can support bulk
mode.

Signed-off-by: Baolin Wang 
---
 include/crypto/skcipher.h |7 +++
 include/linux/crypto.h|6 ++
 2 files changed, 13 insertions(+)

diff --git a/include/crypto/skcipher.h b/include/crypto/skcipher.h
index 0f987f5..d89d29a 100644
--- a/include/crypto/skcipher.h
+++ b/include/crypto/skcipher.h
@@ -519,5 +519,12 @@ static inline void skcipher_request_set_crypt(
req->iv = iv;
 }
 
+static inline unsigned int skcipher_is_bulk_mode(struct crypto_skcipher 
*sk_tfm)
+{
+   struct crypto_tfm *tfm = crypto_skcipher_tfm(sk_tfm);
+
+   return crypto_tfm_alg_bulk(tfm);
+}
+
 #endif /* _CRYPTO_SKCIPHER_H */
 
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 6e28c89..a315487 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -63,6 +63,7 @@
 #define CRYPTO_ALG_DEAD0x0020
 #define CRYPTO_ALG_DYING   0x0040
 #define CRYPTO_ALG_ASYNC   0x0080
+#define CRYPTO_ALG_BULK0x0100
 
 /*
  * Set this bit if and only if the algorithm requires another algorithm of
@@ -623,6 +624,11 @@ static inline u32 crypto_tfm_alg_type(struct crypto_tfm 
*tfm)
return tfm->__crt_alg->cra_flags & CRYPTO_ALG_TYPE_MASK;
 }
 
+static inline unsigned int crypto_tfm_alg_bulk(struct crypto_tfm *tfm)
+{
+   return tfm->__crt_alg->cra_flags & CRYPTO_ALG_BULK;
+}
+
 static inline unsigned int crypto_tfm_alg_blocksize(struct crypto_tfm *tfm)
 {
return tfm->__crt_alg->cra_blocksize;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 0/3] Introduce the bulk mode method when sending request to crypto layer

2016-05-25 Thread Baolin Wang 
This patchset will check if the cipher can support bulk mode, then dm-crypt
will handle different ways to send requests to crypto layer according to
cipher mode.

Looking forward to any comments and suggestions. Thanks.

Baolin Wang (3):
  block: Introduce blk_bio_map_sg() to map one bio
  crypto: Introduce CRYPTO_ALG_BULK flag
  md: dm-crypt: Introduce the bulk mode method when sending request

 block/blk-merge.c |   45 +++
 drivers/md/dm-crypt.c |  188 ++---
 include/crypto/skcipher.h |7 ++
 include/linux/blkdev.h|3 +
 include/linux/crypto.h|6 ++
 5 files changed, 237 insertions(+), 12 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html