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_decompress } } > + .coa_decompress = crypto842_decompress, > + .coa_decompress_noctx = NULL } } > }; > > static int __init crypto842_mod_init(void) > diff --git a/crypto/compress.c b/crypto/compress.c > index c33f076..abb36a8 100644 > --- a/crypto/compress.c > +++ b/crypto/compress.c > @@ -33,12 +33,21 @@ static int crypto_decompress(struct crypto_tfm *tfm, > dlen); > } > > +static int crypto_decompress_noctx(struct crypto_tfm *tfm, > + const u8 *src, unsigned int slen, > + u8 *dst, unsigned int *dlen) > +{ > + return tfm->__crt_alg->cra_compress.coa_decompress_noctx(src, slen, > + dst, dlen); > +} hm... well... sorry, if irrelevant. if the algorithm can have a _noctx() decompression function, does it automatically guarantee that this algorithm never dereferences a passed `struct crypto_tfm *tfm' pointer in its decompress function? in other words, can we simply pass that `shared tfm pointer' to the existing decompress function instead of defining new symbols, new callbacks, etc.? cot_decompress_noctx() == cot_decompress(shared_ftm) ? just a thought. [..] > +struct crypto_comp *crypto_alloc_comp_noctx(const char *alg_name, > + u32 type, u32 mask) > +{ > + struct crypto_comp *comp; > + struct crypto_tfm *tfm; > + struct compress_tfm *ops; > + > + comp = crypto_alloc_comp(alg_name, type, mask); > + if (IS_ERR(comp)) > + return comp; > + > + tfm = crypto_comp_tfm(comp); > + if (!tfm->__crt_alg->cra_compress.coa_decompress_noctx) { > + crypto_free_comp(comp); > + return ERR_PTR(-EINVAL); -ENOMEM? -ss -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html