Re: [PATCH v2 3/3] crypto: scompress - defer allocation of scratch buffer to first use

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 26, 2017 at 01:07:34AM +0100, Ard Biesheuvel wrote:
> 
> > On 26 Jul 2017, at 00:36, Giovanni Cabiddu <giovanni.cabiddu@xxxxxxxxx> wrote:
> > 
> > Hi Ard,
> > 
> >> On Fri, Jul 21, 2017 at 04:42:38PM +0100, Ard Biesheuvel wrote:
> >> +static int crypto_scomp_init_tfm(struct crypto_tfm *tfm)
> >> +{
> >> +    int ret;
> >> +
> >> +    mutex_lock(&scomp_lock);
> >> +    ret = crypto_scomp_alloc_all_scratches();
> >> +    mutex_unlock(&scomp_lock);
> >> +
> >> +    return ret;
> >> +}
> > If you allocate the scratch buffers at init_tfm, don't you end
> > up with a situation where if you allocate two tfms of the same algo
> > then you get twice the number of scratches?
> > If that is the case, we should implement a reference count
> > mechanism.
> > Am I missing something?
> > 
> 
> Isn't the mutex supposed to take care of that?
Ignore my previous question. There is already a reference count
mechanism that prevents that to happen.
Your change sounds correct to me.

Regards,

-- 
Giovanni



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux