On (04/03/18 19:13), Vaneet Narang wrote:
> Hi Sergey,
>
> >You shrink a 2 bytes offset down to a 1 byte offset, thus you enforce that
> 2 Byte offset is not shrinked to 1 byte, Its only 1 bit is reserved out of
> 16 bits of offset. So only 15 Bits can be used to store offset value.
Yes, you are
On (04/02/18 11:21), Maninder Singh wrote:
[..]
> >> static const char * const backends[] = {
> >> "lzo",
> >> #if IS_ENABLED(CONFIG_CRYPTO_LZ4)
> >> "lz4",
> >> +#if (PAGE_SIZE < (32 * KB))
> >> +"lz4_dyn",
> >> +#endif
> >
> >This is not the list of supported
On (03/29/18 15:56), Maninder Singh wrote:
> Hello Nick/Sergey,
>
> Any suggestion or comments, so that we can change code and resend the patch?
Well... there were no replies to
https://marc.info/?l=linux-kernel=152161450026771=2
and
https://marc.info/?l=linux-kernel=152161860627974=2
On (03/21/18 15:49), Nick Terrell wrote:
> depends on CONFIG_CRYPTO_ZSTD, which isn't defined until this patch is in
Yikes! How come I missed that... :)
> [0]
> lkml.kernel.org/r/9c9416b2dff19f05fb4c35879aaa83d11ff72c92.1521626182.git.geliangt...@gmail.com
Signed-off-by: Nick Terrell
On (03/21/18 19:56), Nick Terrell wrote:
[..]
> This seems like a reasonable extension to the algorithm, and it looks like
> LZ4_DYN is about a 5% improvement to compression ratio on your benchmark.
> The biggest question I have is if it is worthwhile to maintain a separate
> incompatible variant
CC-ing Nick
Nick, can you take a look?
Message-IDs:
lkml.kernel.org/r/1521607242-3968-1-git-send-email-maninder...@samsung.com
lkml.kernel.org/r/1521607242-3968-2-git-send-email-maninder...@samsung.com
-ss
On (03/21/18 10:10), Maninder Singh wrote:
[..]
> +static struct crypto_alg alg_lz4_dyn = {
> + .cra_name = "lz4_dyn",
> + .cra_flags = CRYPTO_ALG_TYPE_COMPRESS,
> + .cra_ctxsize= sizeof(struct lz4_ctx),
> + .cra_module =
On (03/21/18 10:10), Maninder Singh wrote:
> (Added cover letter to avoid much text in patch description)
>
> LZ4 specification defines 2 byte offset length for 64 KB data.
> But in case of ZRAM we compress data per page and in most of
> architecture PAGE_SIZE is 4KB. So we can decide offset
Hello,
On (03/06/18 20:59), Benjamin Warnke wrote:
>Currently ZRAM uses compression-algorithms from the crypto-api. ZRAM
>compresses each page individually. As a result the compression algorithm
>is
>forced to use a very small sliding window. None of the available
>compression
Cc Herbert and linux-crypto on this
https://marc.info/?l=linux-kernel=148226084823926
On (12/20/16 19:53), Sven Schmidt wrote:
>
> This patch updates the crypto modules using LZ4 compression to work with the
> new LZ4 kernel module version.
>
> Signed-off-by: Sven Schmidt
Hi,
On (10/14/15 16:38), Joonsoo Kim wrote:
[..]
> Creates virtual block devices called /dev/zramX (X = 0, 1, ...).
> @@ -18,9 +17,8 @@ config ZRAM
> config ZRAM_LZ4_COMPRESS
> bool "Enable LZ4 algorithm support"
> depends on ZRAM
> - select LZ4_COMPRESS
> - select
On (10/15/15 10:07), Joonsoo Kim wrote:
[..]
> > > if (error) {
> > > + crypto_free_ccomp(comp->tfm);
> > > kfree(comp);
> >
> > hm... zcomp_destroy(comp) ?
>
> It's not possible to use zcomp_destroy() here. It tries to access
> field of comp->stream which could be NULL.
ah,
On (10/14/15 16:38), Joonsoo Kim wrote:
[..]
> @@ -352,6 +352,7 @@ static ssize_t comp_algorithm_show(struct device *dev,
> size_t sz;
> struct zram *zram = dev_to_zram(dev);
>
> + deprecated_attr_warn("comp_algorithm");
> down_read(>init_lock);
> sz =
On (09/25/15 14:46), Joonsoo Kim wrote:
[..]
> > > struct zcomp_strm *zcomp_decompress_begin(struct zcomp *comp)
> > > {
> > > + if (comp->tfm_noctx)
> > > + return NULL;
> >
> > Hmm,, I understand why returns NULL but it seems to be awkward to use NULL
> > to express meaningful
On (09/25/15 14:43), Joonsoo Kim wrote:
[..]
> > > /* dynamic per-device compression frontend */
> > > struct zcomp {
> > > void *stream;
> > > - struct zcomp_backend *backend;
> > > + const char *backend;
> >
> > ^^ what for?
>
> Will remove.
I think that was my mistake, I realized
On (09/25/15 14:26), Joonsoo Kim wrote:
[..]
> > > +struct crypto_comp *crypto_alloc_comp_noctx(const char *alg_name,
> > > + u32 type, u32 mask);
> > > +
> >
> > this should be EXPORT_SYMBOL_GPL().
> >
>
> Will do in next version.
>
so you want to go with
On (09/18/15 14:19), Joonsoo Kim wrote:
[..]
> static int __init lzo_mod_init(void)
> diff --git a/include/linux/crypto.h b/include/linux/crypto.h
> index e71cb70..31152b1 100644
> --- a/include/linux/crypto.h
> +++ b/include/linux/crypto.h
> @@ -355,6 +355,8 @@ struct compress_alg {
>
On (09/18/15 14:19), Joonsoo Kim wrote:
[..]
> + /*
> + * Prepare to use crypto decompress_noctx API. One tfm is required
> + * to initialize crypto algorithm properly and fetch corresponding
> + * function pointer. But, it is sharable for multiple concurrent
> + *
On (09/21/15 22:13), Sergey Senozhatsky wrote:
> RFC
>
> resend reason:
> git (2.6.0-rc2) has crashed and spme patches were not sent out.
>
>
> Sorry for the noise.
>
> ===
what a day... really sorry.
(release 2.5.3) git has crashed again
[Net::S
Set CRYPTO_ALG_TFM_MAY_SHARE ->cra_flags when algorithm support
shared tfm.
Signed-off-by: Sergey Senozhatsky <sergey.senozhat...@gmail.com>
---
include/linux/crypto.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
inde
);
foo_end(zstrm);
where foo is compress or decompress zcomp functions.
This patch is a preparation to make crypto API-powered zcomp
possible. The reasoning is that some crypto compression backends
require zstrm for decompression.
Signed-off-by: Sergey Senozhatsky <sergey.senozhat...@gmail.
Signed-off-by: Sergey Senozhatsky <sergey.senozhat...@gmail.com>
---
crypto/842.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/crypto/842.c b/crypto/842.c
index 98e387e..579be68 100644
--- a/crypto/842.c
+++ b/crypto/842.c
@@ -56,7 +56,8 @@ static struct crypto_a
uct crypto_alg'. Crypto API provides
crypto_tfm_may_share() function that returns true if the algorithm
has CRYPTO_ALG_TFM_MAY_SHARE set and, thus, we can supply a shared
`struct crypto_comp *tfm'.
Not properly tested yet.
Sergey Senozhatsky (9):
crypto: introduce CRYPTO_ALG_TFM_MAY_SHARE f
Signed-off-by: Sergey Senozhatsky <sergey.senozhat...@gmail.com>
---
crypto/lzo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/crypto/lzo.c b/crypto/lzo.c
index 4b3e925..994667e 100644
--- a/crypto/lzo.c
+++ b/crypto/lzo.c
@@ -82,7 +82,8 @@ static int lzo_deco
Signed-off-by: Sergey Senozhatsky <sergey.senozhat...@gmail.com>
---
crypto/lz4.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/crypto/lz4.c b/crypto/lz4.c
index aefbcea..ca48de1 100644
--- a/crypto/lz4.c
+++ b/crypto/lz4.c
@@ -78,7 +78,8 @@ stat
Signed-off-by: Sergey Senozhatsky <sergey.senozhat...@gmail.com>
---
crypto/lz4hc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/crypto/lz4hc.c b/crypto/lz4hc.c
index a1d3b5b..34ef3de 100644
--- a/crypto/lz4hc.c
+++ b/crypto/lz4hc.c
@@ -78,7 +78,8 @@ stat
zstrm for
decompression or NULL if it does not.
Signed-off-by: Sergey Senozhatsky <sergey.senozhat...@gmail.com>
---
drivers/block/zram/zcomp.c| 3 ++-
drivers/block/zram/zcomp.h| 3 ++-
drivers/block/zram/zram_drv.c | 20
3 files changed, 20 insertions(+), 6 del
0 */
- return lz4_decompress_unknownoutputsize(src, src_len, dst, _len);
-}
-
-struct zcomp_backend zcomp_lz4 = {
- .compress = zcomp_lz4_compress,
- .decompress = zcomp_lz4_decompress,
- .create = zcomp_lz4_create,
- .destroy = zcomp_lz4_destroy,
- .
Read10411701.88 6426911.62 9423894.38
Re-read 10017386.62 6428218.88 1163.50
Signed-off-by: Joonsoo Kim <iamjoonsoo@lge.com>
Signed-off-by: Sergey Senozhatsky <sergey.senozhat...@gmail.com>
---
drivers/block/zram/
On (09/18/15 14:19), Joonsoo Kim wrote:
> -/* Never return NULL, may sleep */
> +/* May return NULL, may sleep */
> struct zcomp_strm *zcomp_decompress_begin(struct zcomp *comp)
> {
> + if (comp->tfm_noctx)
> + return NULL;
> +
> return zcomp_strm_find(comp);
> }
>
> @@
On (09/18/15 14:19), Joonsoo Kim wrote:
[..]
> -static struct zcomp_backend *find_backend(const char *compress)
> +static const char *find_backend(const char *compress)
> {
> int i = 0;
> while (backends[i]) {
> - if (sysfs_streq(compress, backends[i]->name))
> +
On (09/18/15 14:19), Joonsoo Kim wrote:
[..]
> @@ -61,7 +61,8 @@ static struct crypto_alg alg = {
> .cra_module = THIS_MODULE,
> .cra_u = { .compress = {
> .coa_compress = crypto842_compress,
> - .coa_decompress =
On (08/27/15 13:07), Sergey Senozhatsky wrote:
[..]
-struct zcomp_strm *zcomp_strm_find(struct zcomp *comp)
+struct zcomp_strm *zcomp_strm_find(struct zcomp *comp, bool decomp)
I think we can hide zcomp_strm_find()/_release (make them static),
and instead introduce
On (08/20/15 15:34), Joonsoo Kim wrote:
lz4's decompression doesn't requires any scratch buffer so
it doesn't need tfm context. Hence, it can support
crypto compression noctx API and this patch implements it.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
---
crypto/lz4.c | 17
On (08/20/15 15:35), Joonsoo Kim wrote:
zram regards zstrm's buffer as compression destination buffer, but,
it is not intuitive and there is no document about it. Providing
destination buffer to zcomp_compress() directly seems more intuitive
interface to me so this patch changes zcomp_compress
f2afb7e..000
--- a/drivers/block/zram/zcomp_lz4.c
+++ /dev/null
@@ -1,47 +0,0 @@
-/*
- * Copyright (C) 2014 Sergey Senozhatsky.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free
On (08/20/15 15:35), Joonsoo Kim wrote:
Crypto subsystem supports noctx API which doesn't require tfm.
To get tfm in zram, we need zstrm and it is limited resource.
If we uses noctx API, we don't need to get zstrm so that
we get much better performance when zstrm is insufficient.
This patch
On (08/20/15 15:34), Joonsoo Kim wrote:
lzo's decompression doesn't requires any scratch buffer so
it doesn't need tfm context. Hence, it can support
crypto compression noctx API and this patch implements it.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
---
crypto/lzo.c | 18
On (08/20/15 15:35), Joonsoo Kim wrote:
lz4hc's decompression doesn't requires any scratch buffer so
it doesn't need tfm context. Hence, it can support
crypto compression noctx API and this patch implements it.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
---
crypto/lz4hc.c | 17
will return to this a bit later.
not-yet-signed-off-by: Sergey Senozhatsky sergey.senozhatsky.w...@gmail.com
---
drivers/block/zram/Kconfig | 12 -
drivers/block/zram/Makefile | 1 +
drivers/block/zram/zcomp.c | 21 +++-
drivers/block/zram/zcomp.h | 9 +++-
drivers
+0,0 @@
-/*
- * Copyright (C) 2014 Sergey Senozhatsky.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option
Cc Stephan
On (06/11/15 08:28), Herbert Xu wrote:
[..]
Thanks. And I'll make sure drbg select sha256 so that this doesn't
happen.
Thanks.
FWIW, here is my .config (Stephan has requested)
-ss
---
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.1.0-rc7 Kernel
sha256 config enabled).
Sergey Senozhatsky (1):
crypto/drbg: report backend_cra_name when allocation fails
crypto/drbg.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--
2.4.3.368.g7974889
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body
Be more verbose and also report -backend_cra_name when
crypto_alloc_shash() or crypto_alloc_cipher() fail in
drbg_init_hash_kernel() or drbg_init_sym_kernel()
correspondingly.
Example
DRBG: could not allocate digest TFM handle: hmac(sha256)
Signed-off-by: Sergey Senozhatsky sergey.senozhat
: hmac(sha256)
Signed-off-by: Sergey Senozhatsky sergey.senozhat...@gmail.com
Headscratch -- the Kconfig should have HMAC selected for compilation. When
HMAC is available (regardless whether it is a module or not), it is pulled in
by the kernel crypto API. Thus, there should not have been
45 matches
Mail list logo
