Cc Herbert and linux-crypto on this
https://marc.info/?l=linux-kernel&m=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 <4ssch...@informat
have 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"
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
---
crypto/drb
> >Example
> > DRBG: could not allocate digest TFM handle: hmac(sha256)
> >
> >Signed-off-by: Sergey Senozhatsky
>
> Headscratch -- the Kconfig should have HMAC selected for compilation. When
> HMAC is available (regardless whether it is a module or not), it is pul
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 Config
;
> @@ -51,7 +35,6 @@ struct zcomp {
> };
>
> ssize_t zcomp_available_show(const char *comp, char *buf);
> -bool zcomp_available_algorithm(const char *comp);
>
> struct zcomp *zcomp_create(const char *comp, int max_strm);
> void zcomp_destroy(struct zcomp *comp);
> @@ -60,
the moment.
I will return to this a bit later.
not-yet-signed-off-by: Sergey Senozhatsky
---
drivers/block/zram/Kconfig | 12 -
drivers/block/zram/Makefile | 1 +
drivers/block/zram/zcomp.c | 21 +++-
drivers/block/zram/zcomp.h | 9 +++-
drivers/block/zram/
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
> ---
> crypto/lzo.c | 18 +-
> 1
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
> ---
> crypto/lz4.c | 17 -
> 1 f
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
> ---
> crypto/lz4hc.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_compr
*comp, struct zcomp_strm *zstrm);
>
> int zcomp_compress(struct zcomp *comp, struct zcomp_strm *zstrm,
> - const unsigned char *src, unsigned char *dst, size_t *dst_len);
> + const unsigned char *src, unsigned char *dst,
> + unsigned int *d
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
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 ins
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:
> -/* 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:
[..]
> @@ -61,7 +61,8 @@ static struct crypto_alg alg = {
> .cra_module = THIS_MODULE,
> .cra_u = { .compress = {
> .coa_compress = crypto842_compress,
> - .coa_decompress = crypto842_decomp
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
> + * decompres
Signed-off-by: Sergey Senozhatsky
---
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_decompress(struct crypto_tfm *tfm, const u8
Signed-off-by: Sergey Senozhatsky
---
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 @@ static int lz4_decompress_crypto(struct crypto_tfm *tfm
Signed-off-by: Sergey Senozhatsky
---
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 @@ static int lz4hc_decompress_crypto(struct
Set CRYPTO_ALG_TFM_MAY_SHARE ->cra_flags when algorithm support
shared tfm.
Signed-off-by: Sergey Senozhatsky
---
include/linux/crypto.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index e71cb70..66f10f8 100644
--- a/incl
);
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
---
drivers/block/zram
Signed-off-by: Sergey Senozhatsky
---
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_alg alg = {
.cra_name
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_M
zstrm for
decompression or NULL if it does not.
Signed-off-by: Sergey Senozhatsky
---
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 deletions(-)
diff --git a/drivers/block
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
rypto-CRYPTO_ALG_TFM_MAY_SHARE
Read10411701.88 6426911.62 9423894.38
Re-read 10017386.62 6428218.88 1163.50
Signed-off-by: Joonsoo Kim
Signed-off-by: Sergey Senozhatsky
---
drivers/block/zram/zcomp.c | 27 +--
drivers/block/zram/z
uct zcomp *comp, struct zcomp_strm *zstrm);
int zcomp_decompress(struct zcomp *comp, struct zcomp_strm *zstrm,
const unsigned char *src,
- size_t src_len, unsigned char *dst);
+ unsigned int src_len, unsigned char *dst);
bool zcomp_set_max_streams(
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 why
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 semantic
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 _noct
Hi,
On (10/14/15 16:38), Joonsoo Kim wrote:
[..]
> static const char * const backends[] = {
> "lzo",
> -#ifdef CONFIG_ZRAM_LZ4_COMPRESS
> "lz4",
> -#endif
> NULL
> };
>
> static const char *find_backend(const char *compress)
> {
> - int i = 0;
> - while (backends[i]
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 LZ4
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(&zram->init_lock);
> sz = zcomp_avai
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
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 lengt
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 = THIS_MODUL
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 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 o
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/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&m=152161450026771&w=2
and
https://marc.info/?l=linux-kernel&m=152161860627974&w=2
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 algorith
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 (11/30/18 10:45), Dave Rodgman wrote:
> Looking a bit more closely, these structs are formatted fairly
> inconsistently in the crypto directory. So, lzo-rle is consistent with
> what lzo does... but various other files do it differently.
>
> I'm happy to submit a whitespace cleanup patch if p
47 matches
Mail list logo
