From: Bob Pearson <rpearsonhpe@gmail.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: zyjzyj2000@gmail.com, linux-rdma@vger.kernel.org
Subject: Re: [PATCH for-next 1/6] RDMA/rxe: Make rxe_alloc() take pool lock
Date: Thu, 21 Oct 2021 12:46:50 -0500 [thread overview]
Message-ID: <21346584-a27f-323b-e932-042fa7cd94b5@gmail.com> (raw)
In-Reply-To: <20211020231653.GA28428@nvidia.com>
On 10/20/21 6:16 PM, Jason Gunthorpe wrote:
> On Sun, Oct 10, 2021 at 06:59:26PM -0500, Bob Pearson wrote:
>> In rxe there are two separate pool APIs for creating a new object
>> rxe_alloc() and rxe_alloc_locked(). Currently they are identical.
>> Make rxe_alloc() take the pool lock which is in line with the other
>> APIs in the library.
>>
>> Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com>
>> drivers/infiniband/sw/rxe/rxe_pool.c | 21 ++++-----------------
>> 1 file changed, 4 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/infiniband/sw/rxe/rxe_pool.c b/drivers/infiniband/sw/rxe/rxe_pool.c
>> index ffa8420b4765..7a288ebacceb 100644
>> +++ b/drivers/infiniband/sw/rxe/rxe_pool.c
>> @@ -352,27 +352,14 @@ void *rxe_alloc_locked(struct rxe_pool *pool)
>>
>> void *rxe_alloc(struct rxe_pool *pool)
>> {
>> - struct rxe_type_info *info = &rxe_type_info[pool->type];
>> - struct rxe_pool_entry *elem;
>> + unsigned long flags;
>> u8 *obj;
>>
>> - if (atomic_inc_return(&pool->num_elem) > pool->max_elem)
>> - goto out_cnt;
>> -
>> - obj = kzalloc(info->size, GFP_KERNEL);
>> - if (!obj)
>> - goto out_cnt;
>> -
>> - elem = (struct rxe_pool_entry *)(obj + info->elem_offset);
>> -
>> - elem->pool = pool;
>> - kref_init(&elem->ref_cnt);
>> + write_lock_irqsave(&pool->pool_lock, flags);
>> + obj = rxe_alloc_locked(pool);
>> + write_unlock_irqrestore(&pool->pool_lock, flags);
>
> But why? This just makes a GFP_KERNEL allocation into a GFP_ATOMIC
> allocation, which is bad.
>
> Jason
>
how bad? It only has to happen once in the driver for mcast group elements where
currently I have (to avoid the race when two QPs try to join the same mcast grp
on different CPUs at the same time)
spin_lock()
grp = rxe_get_key_locked(pool, mgid)
if !grp
grp = rxe_alloc_locked(pool)
spin_unlock()
Here the kzalloc has to be GFP_ATOMIC. But I could write after fixing things to
move the kzalloc out of the lock in rxe_alloc().
newgrp = rxe_alloc(pool) /* using GFP_KERNEL */
spin_lock()
grp = rxe_get_key_locked(pool, mgid)
if (grp)
kfree(newgrp)
else {
grp = newgrp
<set key in grp>
}
spin_unlock()
A typical use case would be for a bunch of QPs to join a mcast group and most of the
time the key lookup succeeds. The trade off is between extra malloc/free and occasional
bad behavior from GFP_ATOMIC.
The majority of uses for rxe_alloc() do not have these issues and I can move the kzalloc
outside of the lock and use GFP_KERNEL.
Bob
next prev parent reply other threads:[~2021-10-21 17:47 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-10 23:59 [PATCH for-next 0/6] RDMA/rxe: Fix potential races Bob Pearson
2021-10-10 23:59 ` [PATCH for-next 1/6] RDMA/rxe: Make rxe_alloc() take pool lock Bob Pearson
2021-10-20 23:16 ` Jason Gunthorpe
2021-10-21 17:46 ` Bob Pearson [this message]
2021-10-25 12:43 ` Jason Gunthorpe
2021-10-25 18:48 ` Robert Pearson
2021-10-10 23:59 ` [PATCH for-next 2/6] RDMA/rxe: Copy setup parameters into rxe_pool Bob Pearson
2021-10-10 23:59 ` [PATCH for-next 3/6] RDMA/rxe: Save object pointer in pool element Bob Pearson
2021-10-20 23:20 ` Jason Gunthorpe
2021-10-21 17:21 ` Bob Pearson
2021-10-25 15:40 ` Jason Gunthorpe
2021-10-10 23:59 ` [PATCH for-next 4/6] RDMA/rxe: Combine rxe_add_index with rxe_alloc Bob Pearson
2021-10-10 23:59 ` [PATCH for-next 5/6] RDMA/rxe: Combine rxe_add_key " Bob Pearson
2021-10-10 23:59 ` [PATCH for-next 6/6] RDMA/rxe: Fix potential race condition in rxe_pool Bob Pearson
2021-10-20 23:23 ` Jason Gunthorpe
2021-10-12 6:34 ` [PATCH for-next 0/6] RDMA/rxe: Fix potential races Leon Romanovsky
2021-10-12 20:19 ` Bob Pearson
2021-10-19 13:07 ` Leon Romanovsky
2021-10-19 16:35 ` Bob Pearson
2021-10-19 18:43 ` Jason Gunthorpe
2021-10-19 22:51 ` Bob Pearson
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=21346584-a27f-323b-e932-042fa7cd94b5@gmail.com \
--to=rpearsonhpe@gmail.com \
--cc=jgg@nvidia.com \
--cc=linux-rdma@vger.kernel.org \
--cc=zyjzyj2000@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.