Searched hist:"3853 c35e243d56238159e8365b6aca410bdd4576" (Results 1 – 2 of 2) sorted by relevance
/linux/drivers/infiniband/sw/rxe/ |
H A D | rxe_pool.h | diff 3853c35e243d56238159e8365b6aca410bdd4576 Thu Dec 17 00:15:49 CET 2020 Bob Pearson <rpearsonhpe@gmail.com> RDMA/rxe: Add unlocked versions of pool APIs
The existing pool APIs use the rw_lock pool_lock to protect critical sections that change the pool state. This does not correctly implement a typical sequence like the following
elem = <lookup key in pool>
if found use elem else
elem = <alloc new elem in pool>
<add key to elem>
Which is racy if multiple threads are attempting to perform this at the same time. We want the second thread to use the elem created by the first thread not create two equivalent elems.
This patch adds new APIs that are the same as existing APIs but do not take the pool_lock. A caller can then take the lock and perform a sequence of pool operations and then release the lock.
Link: https://lore.kernel.org/r/20201216231550.27224-7-rpearson@hpe.com Signed-off-by: Bob Pearson <rpearson@hpe.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
H A D | rxe_pool.c | diff 3853c35e243d56238159e8365b6aca410bdd4576 Thu Dec 17 00:15:49 CET 2020 Bob Pearson <rpearsonhpe@gmail.com> RDMA/rxe: Add unlocked versions of pool APIs
The existing pool APIs use the rw_lock pool_lock to protect critical sections that change the pool state. This does not correctly implement a typical sequence like the following
elem = <lookup key in pool>
if found use elem else
elem = <alloc new elem in pool>
<add key to elem>
Which is racy if multiple threads are attempting to perform this at the same time. We want the second thread to use the elem created by the first thread not create two equivalent elems.
This patch adds new APIs that are the same as existing APIs but do not take the pool_lock. A caller can then take the lock and perform a sequence of pool operations and then release the lock.
Link: https://lore.kernel.org/r/20201216231550.27224-7-rpearson@hpe.com Signed-off-by: Bob Pearson <rpearson@hpe.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|