From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 62C41EB64D9 for ; Thu, 15 Jun 2023 23:38:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229711AbjFOXiy (ORCPT ); Thu, 15 Jun 2023 19:38:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57418 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229600AbjFOXix (ORCPT ); Thu, 15 Jun 2023 19:38:53 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2C0F8294E; Thu, 15 Jun 2023 16:38:53 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id AE27262C63; Thu, 15 Jun 2023 23:38:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7BB25C433C0; Thu, 15 Jun 2023 23:38:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686872331; bh=Fqi/K2Gf7K/Hp8uv0SoXSv+oUBt2a09UEToTLMpKZAU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JNSeXOdAoDxAxc+XyTRJ4Nnp3IXYQg1jp8Tq9VNVbB4jpUTGrz1qdR2t0a/HNRUnh tuGNQuQ1UZSBI6y/ESQWcL+dV5Nt6fUnRUCd8piqBa9t8OG2dfT+741FTon228RjIQ eFyB2AjIJBTRZdAdbiLWgPJTso6HdXP6eYjC5AX0OoFsuC9TtxznJVTHuj1FVOHYna 1glW8sM9VWVmo2Y+cJgRJOlKxMSo9aixEnG+jQrqpDmsmBWMM7yBp0Gf+Qy4zhAFXf jZVfyc/HCarUXQAlLB6p9xd0Z+eCu64Ns4FZj8tozsCFIriiK2CPCV9PI+PNuXGHya wyiB8/zDRO7IA== Date: Thu, 15 Jun 2023 16:38:49 -0700 From: Eric Biggers To: Dmitry Safonov Cc: Herbert Xu , linux-kernel@vger.kernel.org, Bob Gilligan , David Ahern , "David S. Miller" , Dmitry Safonov <0x7f454c46@gmail.com>, Eric Dumazet , "Eric W. Biederman" , Francesco Ruggeri , Jakub Kicinski , Paolo Abeni , Salam Noureddine , linux-crypto@vger.kernel.org Subject: Re: [PATCH-next 2/3] crypto: api - Provide gfp mask for tfm allocation Message-ID: <20230615233849.GB25295@sol.localdomain> References: <20230614174643.3836590-1-dima@arista.com> <20230614174643.3836590-3-dima@arista.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230614174643.3836590-3-dima@arista.com> Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Wed, Jun 14, 2023 at 06:46:42PM +0100, Dmitry Safonov wrote: > diff --git a/crypto/cipher.c b/crypto/cipher.c > index d39ef5f72ab8..184188339a4a 100644 > --- a/crypto/cipher.c > +++ b/crypto/cipher.c > @@ -102,7 +102,7 @@ struct crypto_cipher *crypto_clone_cipher(struct crypto_cipher *cipher) > return ERR_PTR(-ENOSYS); > > ntfm = __crypto_alloc_tfm(alg, CRYPTO_ALG_TYPE_CIPHER, > - CRYPTO_ALG_TYPE_MASK); > + CRYPTO_ALG_TYPE_MASK, GFP_ATOMIC); > if (IS_ERR(ntfm)) > return ERR_CAST(ntfm); > Should crypto_clone_cipher() not have a gfp_t argument itself? I'm wondering if any users of the crypto_clone_*() functions will need anything other than GFP_ATOMIC, such as GFP_NOFS or GFP_NOIO. FWIW, btrfs's support for fscrypt is planned to use per-extent keys. It's challenging to implement. I've been thinking it might need a crypto_clone_skcipher() function that it can use during filesystem I/O. That use case would want GFP_NOFS, I think. - Eric