Re: [PATCH v3 9/9] zram: use crypto decompress_noctx API

2015-09-25 Thread Sergey Senozhatsky 
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 and following functions relies on.
> > If I have a time, I will think over.
> 
> I also think that it's not good thing but I can't think any better
> idea. Please let me know if you have better one.

yeah, me neither.

-ss
--
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 v3 1/9] crypto: introduce decompression API that can be called via sharable tfm object

2015-09-25 Thread Herbert Xu 
On Fri, Sep 25, 2015 at 04:56:10PM +0900, Sergey Senozhatsky wrote:
>
> so you want to go with _noctx() callbacks implementation?
> that CRYPTO_ALG_TFM_MAY_SHARE flag looks quite simple to
> me. or you guys hate it?

I think we should just replace crypto_pcomp with a new interface
that does what you guys want.  The current crypto_compress interface
is simply broken because it stores per-request state in the tfm.
This runs counter to every other crypto type, e.g., hash or aead.

The tfm should only hold shared data, e.g., compression algorithm
parameters but not per-request state.

As the original pcomp author has disappeared I think you could
even drop the partial stuff and just do a straight compression
interface.

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 v3 8/9] zram: use crypto API for compression

2015-09-25 Thread Sergey Senozhatsky 
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 do you keep it
later -- to allocate new zstreams. let's keep it.

-ss
--
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 v3 1/9] crypto: introduce decompression API that can be called via sharable tfm object

2015-09-25 Thread Sergey Senozhatsky 
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 _noctx() callbacks implementation?
that CRYPTO_ALG_TFM_MAY_SHARE flag looks quite simple to
me. or you guys hate it?

-ss
--
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: crypto_cbc_encrypt query

2015-09-25 Thread Herbert Xu 
pavi1729  wrote:
> Hi,
>  Shouldn't "walk" be memset ?
> 
> FILE:crypto/cbc.c
> FUNCTION:  crypto_cbc_encrypt
> 
> "walk" is local variable and its uninitialized in
> "crypto_cbc_encrypt". The same is passed to
> "blkcipher_walk_virt" which does below
> 
> walk->flags &= ~BLKCIPHER_WALK_PHYS;
> 
> So neither 'walk' nor 'walk->flags' is memset or init to a proper value.

Other bits are initialised elsewhere as they are used.

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