From: Dmitry Safonov <dima@arista.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: linux-kernel@vger.kernel.org, David Ahern <dsahern@kernel.org>,
Eric Dumazet <edumazet@google.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
Andy Lutomirski <luto@amacapital.net>,
Bob Gilligan <gilligan@arista.com>,
Dmitry Safonov <0x7f454c46@gmail.com>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
Leonard Crestez <cdleonard@gmail.com>,
Paolo Abeni <pabeni@redhat.com>,
Salam Noureddine <noureddine@arista.com>,
netdev@vger.kernel.org, linux-crypto@vger.kernel.org
Subject: Re: [PATCH v2 2/5] crypto/pool: Add crypto_pool_reserve_scratch()
Date: Mon, 9 Jan 2023 21:08:32 +0000 [thread overview]
Message-ID: <262dd341-5b6e-875c-0ded-03b5135ea9ad@arista.com> (raw)
In-Reply-To: <20230106180427.2ccbea51@kernel.org>
On 1/7/23 02:04, Jakub Kicinski wrote:
> On Tue, 3 Jan 2023 18:42:54 +0000 Dmitry Safonov wrote:
>> Instead of having build-time hardcoded constant, reallocate scratch
>> area, if needed by user. Different algos, different users may need
>> different size of temp per-CPU buffer. Only up-sizing supported for
>> simplicity.
>
>> -static int crypto_pool_scratch_alloc(void)
>> +/* Slow-path */
>> +/**
>> + * crypto_pool_reserve_scratch - re-allocates scratch buffer, slow-path
>> + * @size: request size for the scratch/temp buffer
>> + */
>> +int crypto_pool_reserve_scratch(unsigned long size)
>
> Does this have to be a separate call? Can't we make it part of
> the pool allocation? AFAICT the scratch gets freed when last
> pool is freed, so the user needs to know to allocate the pool
> _first_ otherwise there's a potential race:
>
> CPU 1 CPU 2
>
> alloc pool
> set scratch
> free pool
> [frees scratch]
> alloc pool
Yeah, I think it will be cleaner if it was an argument for
crypto_pool_alloc_*() and would prevent potential misuse as you
describe. Which also means that I don't have to declare
crypto_pool_scratch_alloc() in patch 1, will just add a new parameter in
this patch to alloc function.
>
>> {
>> - int cpu;
>> -
>> - lockdep_assert_held(&cpool_mutex);
>> +#define FREE_BATCH_SIZE 64
>> + void *free_batch[FREE_BATCH_SIZE];
>> + int cpu, err = 0;
>> + unsigned int i = 0;
>>
>> + mutex_lock(&cpool_mutex);
>> + if (size == scratch_size) {
>> + for_each_possible_cpu(cpu) {
>> + if (per_cpu(crypto_pool_scratch, cpu))
>> + continue;
>> + goto allocate_scratch;
>> + }
>> + mutex_unlock(&cpool_mutex);
>> + return 0;
>> + }
>> +allocate_scratch:
>> + size = max(size, scratch_size);
>> + cpus_read_lock();
>> for_each_possible_cpu(cpu) {
>> - void *scratch = per_cpu(crypto_pool_scratch, cpu);
>> + void *scratch, *old_scratch;
>>
>> - if (scratch)
>> + scratch = kmalloc_node(size, GFP_KERNEL, cpu_to_node(cpu));
>> + if (!scratch) {
>> + err = -ENOMEM;
>> + break;
>> + }
>> +
>> + old_scratch = per_cpu(crypto_pool_scratch, cpu);
>> + /* Pairs with crypto_pool_get() */
>> + WRITE_ONCE(*per_cpu_ptr(&crypto_pool_scratch, cpu), scratch);
>
> You're using RCU for protection here, please use rcu accessors.
Will do.
>
>> + if (!cpu_online(cpu)) {
>> + kfree(old_scratch);
>> continue;
>> + }
>> + free_batch[i++] = old_scratch;
>> + if (i == FREE_BATCH_SIZE) {
>> + cpus_read_unlock();
>> + synchronize_rcu();
>> + while (i > 0)
>> + kfree(free_batch[--i]);
>> + cpus_read_lock();
>> + }
>
> This is a memory allocation routine, can we simplify this by
> dynamically sizing "free_batch" and using call_rcu()?
>
> struct humf_blah {
> struct rcu_head rcu;
> unsigned int cnt;
> void *data[];
> };
>
> cheezit = kmalloc(struct_size(blah, data, num_possible_cpus()));
>
> for_each ..
> cheezit->data[cheezit->cnt++] = old_scratch;
>
> call_rcu(&cheezit->rcu, my_free_them_scratches)
>
> etc.
>
> Feels like that'd be much less locking, unlocking and general
> carefully'ing.
Will give it a try for v3, thanks for the idea and review,
Dmitry
next prev parent reply other threads:[~2023-01-09 21:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-03 18:42 [PATCH v2 0/5] net/crypto: Introduce crypto_pool Dmitry Safonov
2023-01-03 18:42 ` [PATCH v2 1/5] crypto: " Dmitry Safonov
2023-01-07 1:53 ` Jakub Kicinski
2023-01-09 20:59 ` Dmitry Safonov
2023-01-09 21:11 ` Dmitry Safonov
2023-01-03 18:42 ` [PATCH v2 2/5] crypto/pool: Add crypto_pool_reserve_scratch() Dmitry Safonov
2023-01-07 2:04 ` Jakub Kicinski
2023-01-09 21:08 ` Dmitry Safonov [this message]
2023-01-03 18:42 ` [PATCH v2 3/5] crypto/net/tcp: Use crypto_pool for TCP-MD5 Dmitry Safonov
2023-01-07 2:05 ` Jakub Kicinski
2023-01-09 21:16 ` Dmitry Safonov
2023-01-03 18:42 ` [PATCH v2 4/5] crypto/net/ipv6: sr: Switch to using crypto_pool Dmitry Safonov
2023-01-03 18:42 ` [PATCH v2 5/5] crypto/Documentation: Add crypto_pool kernel API Dmitry Safonov
2023-01-04 13:17 ` kernel test robot
2023-01-07 2:06 ` Jakub Kicinski
2023-01-09 21:23 ` Dmitry Safonov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=262dd341-5b6e-875c-0ded-03b5135ea9ad@arista.com \
--to=dima@arista.com \
--cc=0x7f454c46@gmail.com \
--cc=cdleonard@gmail.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=gilligan@arista.com \
--cc=herbert@gondor.apana.org.au \
--cc=kuba@kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=netdev@vger.kernel.org \
--cc=noureddine@arista.com \
--cc=pabeni@redhat.com \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®