[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZD6M4DHz0e9Ag3XU@corigine.com>
Date: Tue, 18 Apr 2023 14:28:16 +0200
From: Simon Horman <simon.horman@...igine.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
David Ahern <dsahern@...nel.org>,
Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>,
Jakub Kicinski <kuba@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Dmitry Safonov <dima@...sta.com>,
Andy Lutomirski <luto@...capital.net>,
Ard Biesheuvel <ardb@...nel.org>,
Bob Gilligan <gilligan@...sta.com>,
Dan Carpenter <error27@...il.com>,
David Laight <David.Laight@...lab.com>,
Dmitry Safonov <0x7f454c46@...il.com>,
Eric Biggers <ebiggers@...nel.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Francesco Ruggeri <fruggeri05@...il.com>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
Ivan Delalande <colona@...sta.com>,
Leonard Crestez <cdleonard@...il.com>,
Salam Noureddine <noureddine@...sta.com>,
netdev@...r.kernel.org
Subject: Re: [PATCH 2/6] crypto: api - Add crypto_clone_tfm
On Thu, Apr 13, 2023 at 02:24:17PM +0800, Herbert Xu wrote:
> This patch adds the helper crypto_clone_tfm. The purpose is to
> allocate a tfm object with GFP_ATOMIC. As we cannot sleep, the
> object has to be cloned from an existing tfm object.
>
> This allows code paths that cannot otherwise allocate a crypto_tfm
> object to do so. Once a new tfm has been obtained its key could
> then be changed without impacting other users.
>
> Signed-off-by: Herbert Xu <herbert@...dor.apana.org.au>
Reviewed-by: Simon Horman <simon.horman@...igine.com>
Powered by blists - more mailing lists