From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934412AbbDIJWc (ORCPT ); Thu, 9 Apr 2015 05:22:32 -0400 Received: from mail.eperm.de ([89.247.134.16]:34045 "EHLO mail.eperm.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932885AbbDIJW0 (ORCPT ); Thu, 9 Apr 2015 05:22:26 -0400 From: Stephan Mueller To: Herbert Xu Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] crypto: remove instance when test failed Date: Thu, 09 Apr 2015 11:22:19 +0200 Message-ID: <9590265.Rdkakn8z8k@tauon> User-Agent: KMail/4.14.6 (Linux/3.19.3-200.fc21.x86_64; KDE/4.14.6; x86_64; ; ) In-Reply-To: <20150409074141.GA4394@gondor.apana.org.au> References: <1461449.htSjBpksos@tachyon.chronox.de> <20150409074141.GA4394@gondor.apana.org.au> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Donnerstag, 9. April 2015, 15:41:41 schrieb Herbert Xu: Hi Herbert, >On Thu, Apr 09, 2015 at 09:36:03AM +0200, Stephan Mueller wrote: >> diff --git a/crypto/algapi.c b/crypto/algapi.c >> index f1d0307..cfca1de 100644 >> --- a/crypto/algapi.c >> +++ b/crypto/algapi.c >> @@ -533,6 +533,13 @@ int crypto_register_instance(struct crypto_template >> *tmpl,> >> if (IS_ERR(larval)) >> >> goto unlock; >> >> + err = -EAGAIN; >> + if (unlikely(!crypto_mod_get(&inst->alg))) { >> + up_write(&crypto_alg_sem); >> + crypto_unregister_instance(inst); >> + goto err; >> + } > >Just grab the reference count as soon as you enter the function >and then you can unconditionally drop the reference count at the >end. If you fail to grab it then just return an error and the >caller will free it for you. I tested it and this approach does not work. If I see that right, the reason for that is the following: The suggestion is to grab the ref count at the start of the function followed by a __crypto_register_alg. __crypto_register_alg however sets the refcount to 1 unconditionally. That means that the final put of the alg will most likely set the refcount to 0 that causes an issue with all other operations (at least I cannot allocate HMAC or CMAC any more -- the ones I currently test). So, the grabing of the alg must happen after the invocation of __crypto_register_alg. > >Cheers, Ciao Stephan