From: Jakub Kicinski <kuba@kernel.org>
To: Dmitry Safonov <dima@arista.com>
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: Fri, 6 Jan 2023 18:04:27 -0800 [thread overview]
Message-ID: <20230106180427.2ccbea51@kernel.org> (raw)
In-Reply-To: <20230103184257.118069-3-dima@arista.com>
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
> {
> - 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.
> + 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.
> + }
> + cpus_read_unlock();
> + if (!err)
> + scratch_size = size;
next prev parent reply other threads:[~2023-01-07 2:04 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 [this message]
2023-01-09 21:08 ` Dmitry Safonov
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=20230106180427.2ccbea51@kernel.org \
--to=kuba@kernel.org \
--cc=0x7f454c46@gmail.com \
--cc=cdleonard@gmail.com \
--cc=davem@davemloft.net \
--cc=dima@arista.com \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=gilligan@arista.com \
--cc=herbert@gondor.apana.org.au \
--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;
as well as URLs for NNTP newsgroup(s).