Skip to content

Add a .travis.yml file #7

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 1 commit into from
Sep 29, 2016
Merged

Add a .travis.yml file #7

merged 1 commit into from
Sep 29, 2016

Conversation

@jgunthorpe
Copy link
Member

@jgunthorpe jgunthorpe commented Sep 28, 2016

Necessary to use the Travis CI service.

First draft, TravisCI should run this automatically from the pull request.

@jgunthorpe
Add a .travis.yml file
70aa9d6 
Necessary to use the Travis CI service.

Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
@jgunthorpe
Copy link
Member Author

jgunthorpe commented Sep 28, 2016 •
edited
Loading

This is a reasonable starting point now.

Todo:

  • Use -Werror once my warning fixes land and we have a warning free build. Want to keep it that way.
  • Use a matrix config and run through clang and the 32 bit build as well.

@dledford dledford merged commit 3a7c790 into linux-rdma:master Sep 29, 2016
@jgunthorpe jgunthorpe deleted the travisci branch September 29, 2016 15:53
Hakon-Bugge added a commit to Hakon-Bugge/rdma-core that referenced this pull request Nov 1, 2018
@Hakon-Bugge
ibacm: Copy correct number of address bytes before calling provider
6e04c07 
In acm_ep_insert_addr() an attempt to zero out the tmp address buffer
is performed. But the subsequent memcpy(), which uses the supplied
addr_len as argument, copies the whole shebang. This implies that the
provider is called with an address with arbitrary data padded.

This leads to a false mis-compare in the default provider's binary
tree lookup. Here is the stack trace and dump of the address buffer
from gdb (edited for better brevity):

(gdb) where
 #0  acmp_compare_dest (dest1=0x18c46a8, dest2=0x18c5d70) at prov/acmp/src/acmp.c:289
 linux-rdma#1  tfind () from /lib64/libc.so.6
 linux-rdma#2  acmp_get_dest () at prov/acmp/src/acmp.c:336
 linux-rdma#3  acmp_acquire_dest () at prov/acmp/src/acmp.c:379
 linux-rdma#4  acmp_add_addr () at prov/acmp/src/acmp.c:2385
 linux-rdma#5  acm_ep_insert_addr (..., addr_len=addr_len@entry=64, ...) at src/acm.c:2044
 linux-rdma#6  acm_ep_insert_addr (..., addr_len=64, ...) at src/acm.c:1325
 linux-rdma#7  acm_add_ep_ip (ip_str=0x7ffeeda298e0 "192.168.200.200", ...) at src/acm.c:1326
 linux-rdma#8  acm_ipnl_handler () at src/acm.c:1453
 linux-rdma#9  acm_server () at src/acm.c:1884
 linux-rdma#10 main () at src/acm.c:3245

(gdb) x/20u dest1
0x18c46a8:  192 168     200     200     155     127     0       0
0x18c46b0:  95  184     77      105     155     127     0       0
0x18c46b8:  0   0       64      49
(gdb) x/20u dest2
0x18c5d70:  192 168     200     200     0       0       0       0
0x18c5d78:  0   0       0       0       0       0       0       0
0x18c5d80:  0   0       0       0

The fix is to use the real length of the address in the memcpy() in
acm_ep_insert_addr().

Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Hakon-Bugge added a commit to Hakon-Bugge/rdma-core that referenced this pull request Nov 22, 2018
@Hakon-Bugge
ibacm: Copy correct number of address bytes before calling provider
ffd4e51 
In acm_ep_insert_addr() an attempt to zero out the tmp address buffer
is performed. But the subsequent memcpy(), which uses the supplied
addr_len as argument, copies the whole shebang. This implies that the
provider is called with an address with arbitrary data padded.

This leads to a false mis-compare in the default provider's binary
tree lookup. Here is the stack trace and dump of the address buffer
from gdb (edited for better brevity):

(gdb) where
 #0  acmp_compare_dest (dest1=0x18c46a8, dest2=0x18c5d70) at prov/acmp/src/acmp.c:289
 linux-rdma#1  tfind () from /lib64/libc.so.6
 linux-rdma#2  acmp_get_dest () at prov/acmp/src/acmp.c:336
 linux-rdma#3  acmp_acquire_dest () at prov/acmp/src/acmp.c:379
 linux-rdma#4  acmp_add_addr () at prov/acmp/src/acmp.c:2385
 linux-rdma#5  acm_ep_insert_addr (..., addr_len=addr_len@entry=64, ...) at src/acm.c:2044
 linux-rdma#6  acm_ep_insert_addr (..., addr_len=64, ...) at src/acm.c:1325
 linux-rdma#7  acm_add_ep_ip (ip_str=0x7ffeeda298e0 "192.168.200.200", ...) at src/acm.c:1326
 linux-rdma#8  acm_ipnl_handler () at src/acm.c:1453
 linux-rdma#9  acm_server () at src/acm.c:1884
 linux-rdma#10 main () at src/acm.c:3245

(gdb) x/20u dest1
0x18c46a8:  192 168     200     200     155     127     0       0
0x18c46b0:  95  184     77      105     155     127     0       0
0x18c46b8:  0   0       64      49
(gdb) x/20u dest2
0x18c5d70:  192 168     200     200     0       0       0       0
0x18c5d78:  0   0       0       0       0       0       0       0
0x18c5d80:  0   0       0       0

The fix is to use the real length of the address in the memcpy() in
acm_ep_insert_addr(). This is derived from the addr_type. Hence, we
can re-factor and remove the addr_len from the call stack.

Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Reviewed-by: Mark Haywood <mark.haywood@oracle.com>
Hakon-Bugge added a commit to Hakon-Bugge/rdma-core that referenced this pull request Nov 23, 2018
@Hakon-Bugge
ibacm: Copy correct number of address bytes before calling provider
c73f5d7 
In acm_ep_insert_addr() an attempt to zero out the tmp address buffer
is performed. But the subsequent memcpy(), which uses the supplied
addr_len as argument, copies the whole shebang. This implies that the
provider is called with an address with arbitrary data padded.

This leads to a false mis-compare in the default provider's binary
tree lookup. Here is the stack trace and dump of the address buffer
from gdb (edited for better brevity):

(gdb) where
 #0  acmp_compare_dest (dest1=0x18c46a8, dest2=0x18c5d70) at prov/acmp/src/acmp.c:289
 linux-rdma#1  tfind () from /lib64/libc.so.6
 linux-rdma#2  acmp_get_dest () at prov/acmp/src/acmp.c:336
 linux-rdma#3  acmp_acquire_dest () at prov/acmp/src/acmp.c:379
 linux-rdma#4  acmp_add_addr () at prov/acmp/src/acmp.c:2385
 linux-rdma#5  acm_ep_insert_addr (..., addr_len=addr_len@entry=64, ...) at src/acm.c:2044
 linux-rdma#6  acm_ep_insert_addr (..., addr_len=64, ...) at src/acm.c:1325
 linux-rdma#7  acm_add_ep_ip (ip_str=0x7ffeeda298e0 "192.168.200.200", ...) at src/acm.c:1326
 linux-rdma#8  acm_ipnl_handler () at src/acm.c:1453
 linux-rdma#9  acm_server () at src/acm.c:1884
 linux-rdma#10 main () at src/acm.c:3245

(gdb) x/20u dest1
0x18c46a8:  192 168     200     200     155     127     0       0
0x18c46b0:  95  184     77      105     155     127     0       0
0x18c46b8:  0   0       64      49
(gdb) x/20u dest2
0x18c5d70:  192 168     200     200     0       0       0       0
0x18c5d78:  0   0       0       0       0       0       0       0
0x18c5d80:  0   0       0       0

The fix is to use the real length of the address in the memcpy() in
acm_ep_insert_addr(). This is derived from the addr_type. Hence, we
can re-factor and remove the addr_len from the call stack.

Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Reviewed-by: Mark Haywood <mark.haywood@oracle.com>
@dledford dledford mentioned this pull request Dec 12, 2018
Closed
rosenbaumalex pushed a commit to rosenbaumalex/rdma-core that referenced this pull request Jan 7, 2019
@Hakon-Bugge @rosenbaumalex
ibacm: Copy correct number of address bytes before calling provider
8882237 
In acm_ep_insert_addr() an attempt to zero out the tmp address buffer
is performed. But the subsequent memcpy(), which uses the supplied
addr_len as argument, copies the whole shebang. This implies that the
provider is called with an address with arbitrary data padded.

This leads to a false mis-compare in the default provider's binary
tree lookup. Here is the stack trace and dump of the address buffer
from gdb (edited for better brevity):

(gdb) where
 #0  acmp_compare_dest (dest1=0x18c46a8, dest2=0x18c5d70) at prov/acmp/src/acmp.c:289
 linux-rdma#1  tfind () from /lib64/libc.so.6
 linux-rdma#2  acmp_get_dest () at prov/acmp/src/acmp.c:336
 linux-rdma#3  acmp_acquire_dest () at prov/acmp/src/acmp.c:379
 linux-rdma#4  acmp_add_addr () at prov/acmp/src/acmp.c:2385
 linux-rdma#5  acm_ep_insert_addr (..., addr_len=addr_len@entry=64, ...) at src/acm.c:2044
 linux-rdma#6  acm_ep_insert_addr (..., addr_len=64, ...) at src/acm.c:1325
 linux-rdma#7  acm_add_ep_ip (ip_str=0x7ffeeda298e0 "192.168.200.200", ...) at src/acm.c:1326
 linux-rdma#8  acm_ipnl_handler () at src/acm.c:1453
 linux-rdma#9  acm_server () at src/acm.c:1884
 linux-rdma#10 main () at src/acm.c:3245

(gdb) x/20u dest1
0x18c46a8:  192 168     200     200     155     127     0       0
0x18c46b0:  95  184     77      105     155     127     0       0
0x18c46b8:  0   0       64      49
(gdb) x/20u dest2
0x18c5d70:  192 168     200     200     0       0       0       0
0x18c5d78:  0   0       0       0       0       0       0       0
0x18c5d80:  0   0       0       0

The fix is to use the real length of the address in the memcpy() in
acm_ep_insert_addr(). This is derived from the addr_type. Hence, we
can re-factor and remove the addr_len from the call stack.

Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Reviewed-by: Mark Haywood <mark.haywood@oracle.com>
aron-silverton pushed a commit to oracle/rdma-core that referenced this pull request Mar 27, 2019
@Hakon-Bugge @aron-silverton
ibacm: Copy correct number of address bytes before calling provider
18c3546 
In acm_ep_insert_addr() an attempt to zero out the tmp address buffer
is performed. But the subsequent memcpy(), which uses the supplied
addr_len as argument, copies the whole shebang. This implies that the
provider is called with an address with arbitrary data padded.

This leads to a false mis-compare in the default provider's binary
tree lookup. Here is the stack trace and dump of the address buffer
from gdb (edited for better brevity):

(gdb) where
 #0  acmp_compare_dest (dest1=0x18c46a8, dest2=0x18c5d70) at prov/acmp/src/acmp.c:289
 linux-rdma#1  tfind () from /lib64/libc.so.6
 linux-rdma#2  acmp_get_dest () at prov/acmp/src/acmp.c:336
 linux-rdma#3  acmp_acquire_dest () at prov/acmp/src/acmp.c:379
 linux-rdma#4  acmp_add_addr () at prov/acmp/src/acmp.c:2385
 linux-rdma#5  acm_ep_insert_addr (..., addr_len=addr_len@entry=64, ...) at src/acm.c:2044
 linux-rdma#6  acm_ep_insert_addr (..., addr_len=64, ...) at src/acm.c:1325
 linux-rdma#7  acm_add_ep_ip (ip_str=0x7ffeeda298e0 "192.168.200.200", ...) at src/acm.c:1326
 linux-rdma#8  acm_ipnl_handler () at src/acm.c:1453
 linux-rdma#9  acm_server () at src/acm.c:1884
 linux-rdma#10 main () at src/acm.c:3245

(gdb) x/20u dest1
0x18c46a8:  192 168     200     200     155     127     0       0
0x18c46b0:  95  184     77      105     155     127     0       0
0x18c46b8:  0   0       64      49
(gdb) x/20u dest2
0x18c5d70:  192 168     200     200     0       0       0       0
0x18c5d78:  0   0       0       0       0       0       0       0
0x18c5d80:  0   0       0       0

The fix is to use the real length of the address in the memcpy() in
acm_ep_insert_addr(). This is derived from the addr_type. Hence, we
can re-factor and remove the addr_len from the call stack.

Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Reviewed-by: Mark Haywood <mark.haywood@oracle.com>

Orabug: 29037270

(cherry picked from commit c73f5d7)
cherry-pick-repo=linux-rdma/rdma-core.git
unmodified-from-upstream: c73f5d7

Signed-off-by: Mark Haywood <mark.haywood@oracle.com>
Signed-off-by: Aron Silverton <aron.silverton@oracle.com>
aron-silverton pushed a commit to oracle/rdma-core that referenced this pull request Mar 27, 2019
@Hakon-Bugge @aron-silverton
ibacm: Copy correct number of address bytes before calling provider
303f845 
In acm_ep_insert_addr() an attempt to zero out the tmp address buffer
is performed. But the subsequent memcpy(), which uses the supplied
addr_len as argument, copies the whole shebang. This implies that the
provider is called with an address with arbitrary data padded.

This leads to a false mis-compare in the default provider's binary
tree lookup. Here is the stack trace and dump of the address buffer
from gdb (edited for better brevity):

(gdb) where
 #0  acmp_compare_dest (dest1=0x18c46a8, dest2=0x18c5d70) at prov/acmp/src/acmp.c:289
 linux-rdma#1  tfind () from /lib64/libc.so.6
 linux-rdma#2  acmp_get_dest () at prov/acmp/src/acmp.c:336
 linux-rdma#3  acmp_acquire_dest () at prov/acmp/src/acmp.c:379
 linux-rdma#4  acmp_add_addr () at prov/acmp/src/acmp.c:2385
 linux-rdma#5  acm_ep_insert_addr (..., addr_len=addr_len@entry=64, ...) at src/acm.c:2044
 linux-rdma#6  acm_ep_insert_addr (..., addr_len=64, ...) at src/acm.c:1325
 linux-rdma#7  acm_add_ep_ip (ip_str=0x7ffeeda298e0 "192.168.200.200", ...) at src/acm.c:1326
 linux-rdma#8  acm_ipnl_handler () at src/acm.c:1453
 linux-rdma#9  acm_server () at src/acm.c:1884
 linux-rdma#10 main () at src/acm.c:3245

(gdb) x/20u dest1
0x18c46a8:  192 168     200     200     155     127     0       0
0x18c46b0:  95  184     77      105     155     127     0       0
0x18c46b8:  0   0       64      49
(gdb) x/20u dest2
0x18c5d70:  192 168     200     200     0       0       0       0
0x18c5d78:  0   0       0       0       0       0       0       0
0x18c5d80:  0   0       0       0

The fix is to use the real length of the address in the memcpy() in
acm_ep_insert_addr(). This is derived from the addr_type. Hence, we
can re-factor and remove the addr_len from the call stack.

Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Reviewed-by: Mark Haywood <mark.haywood@oracle.com>

Orabug: 29037270

(cherry picked from commit c73f5d7)
cherry-pick-repo=linux-rdma/rdma-core.git
unmodified-from-upstream: c73f5d7

Signed-off-by: Mark Haywood <mark.haywood@oracle.com>
Signed-off-by: Aron Silverton <aron.silverton@oracle.com>
aron-silverton pushed a commit to oracle/rdma-core that referenced this pull request Apr 9, 2019
@Hakon-Bugge @aron-silverton
ibacm: Copy correct number of address bytes before calling provider
418af08 
In acm_ep_insert_addr() an attempt to zero out the tmp address buffer
is performed. But the subsequent memcpy(), which uses the supplied
addr_len as argument, copies the whole shebang. This implies that the
provider is called with an address with arbitrary data padded.

This leads to a false mis-compare in the default provider's binary
tree lookup. Here is the stack trace and dump of the address buffer
from gdb (edited for better brevity):

(gdb) where
 #0  acmp_compare_dest (dest1=0x18c46a8, dest2=0x18c5d70) at prov/acmp/src/acmp.c:289
 linux-rdma#1  tfind () from /lib64/libc.so.6
 linux-rdma#2  acmp_get_dest () at prov/acmp/src/acmp.c:336
 linux-rdma#3  acmp_acquire_dest () at prov/acmp/src/acmp.c:379
 linux-rdma#4  acmp_add_addr () at prov/acmp/src/acmp.c:2385
 linux-rdma#5  acm_ep_insert_addr (..., addr_len=addr_len@entry=64, ...) at src/acm.c:2044
 linux-rdma#6  acm_ep_insert_addr (..., addr_len=64, ...) at src/acm.c:1325
 linux-rdma#7  acm_add_ep_ip (ip_str=0x7ffeeda298e0 "192.168.200.200", ...) at src/acm.c:1326
 linux-rdma#8  acm_ipnl_handler () at src/acm.c:1453
 linux-rdma#9  acm_server () at src/acm.c:1884
 linux-rdma#10 main () at src/acm.c:3245

(gdb) x/20u dest1
0x18c46a8:  192 168     200     200     155     127     0       0
0x18c46b0:  95  184     77      105     155     127     0       0
0x18c46b8:  0   0       64      49
(gdb) x/20u dest2
0x18c5d70:  192 168     200     200     0       0       0       0
0x18c5d78:  0   0       0       0       0       0       0       0
0x18c5d80:  0   0       0       0

The fix is to use the real length of the address in the memcpy() in
acm_ep_insert_addr(). This is derived from the addr_type. Hence, we
can re-factor and remove the addr_len from the call stack.

Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Reviewed-by: Mark Haywood <mark.haywood@oracle.com>

Orabug: 29037270

(cherry picked from commit c73f5d7)
cherry-pick-repo=linux-rdma/rdma-core.git
unmodified-from-upstream: c73f5d7

Signed-off-by: Mark Haywood <mark.haywood@oracle.com>
Signed-off-by: Aron Silverton <aron.silverton@oracle.com>

Orabug: 29410510

Rebase from RDMA Core 19.2 -> 20.2.

(cherry picked from commit fc2e7b4b)
cherry-pick-repo=linux-git/RDMA/rdma-core.git
unmodified-from-upstream: fc2e7b4b

Signed-off-by: Mark Haywood <mark.haywood@oracle.com>
aron-silverton pushed a commit to oracle/rdma-core that referenced this pull request Nov 16, 2020
@Hakon-Bugge @aron-silverton
ibacm: Copy correct number of address bytes before calling provider
af52eab 
In acm_ep_insert_addr() an attempt to zero out the tmp address buffer
is performed. But the subsequent memcpy(), which uses the supplied
addr_len as argument, copies the whole shebang. This implies that the
provider is called with an address with arbitrary data padded.

This leads to a false mis-compare in the default provider's binary
tree lookup. Here is the stack trace and dump of the address buffer
from gdb (edited for better brevity):

(gdb) where
 #0  acmp_compare_dest (dest1=0x18c46a8, dest2=0x18c5d70) at prov/acmp/src/acmp.c:289
 linux-rdma#1  tfind () from /lib64/libc.so.6
 linux-rdma#2  acmp_get_dest () at prov/acmp/src/acmp.c:336
 linux-rdma#3  acmp_acquire_dest () at prov/acmp/src/acmp.c:379
 linux-rdma#4  acmp_add_addr () at prov/acmp/src/acmp.c:2385
 linux-rdma#5  acm_ep_insert_addr (..., addr_len=addr_len@entry=64, ...) at src/acm.c:2044
 linux-rdma#6  acm_ep_insert_addr (..., addr_len=64, ...) at src/acm.c:1325
 linux-rdma#7  acm_add_ep_ip (ip_str=0x7ffeeda298e0 "192.168.200.200", ...) at src/acm.c:1326
 linux-rdma#8  acm_ipnl_handler () at src/acm.c:1453
 linux-rdma#9  acm_server () at src/acm.c:1884
 linux-rdma#10 main () at src/acm.c:3245

(gdb) x/20u dest1
0x18c46a8:  192 168     200     200     155     127     0       0
0x18c46b0:  95  184     77      105     155     127     0       0
0x18c46b8:  0   0       64      49
(gdb) x/20u dest2
0x18c5d70:  192 168     200     200     0       0       0       0
0x18c5d78:  0   0       0       0       0       0       0       0
0x18c5d80:  0   0       0       0

The fix is to use the real length of the address in the memcpy() in
acm_ep_insert_addr(). This is derived from the addr_type. Hence, we
can re-factor and remove the addr_len from the call stack.

Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Reviewed-by: Mark Haywood <mark.haywood@oracle.com>

Orabug: 29037270

(cherry picked from commit c73f5d7)
cherry-pick-repo=github.com/linux-rdma/rdma-core.git
unmodified-from-upstream: c73f5d7

Signed-off-by: Mark Haywood <mark.haywood@oracle.com>
Acked-by: Aron Silverton <aron.silverton@oracle.com>

Orabug: 29410510

Rebase from RDMA Core 19.2 -> 20.2.

(cherry picked from commit 303f845)
cherry-pick-repo=linux-git.us.oracle.com/RDMA/rdma-core.git
unmodified-from-upstream: 303f845

Signed-off-by: Mark Haywood <mark.haywood@oracle.com>
Acked-by: Aron Silverton <aron.silverton@oracle.com>
@rleon rleon mentioned this pull request Sep 6, 2023
Merged
shefty pushed a commit to shefty/rdma-core that referenced this pull request Nov 10, 2025
@MarkZhang81 @shefty
From b1ef5e3f4cabb6eb4a0d14bd7f6a33e80c12f062 Mon Sep 17 00:00:00 2001
0855c67 
Subject: [PATCH] librdmacm: Fix rdma_resolve_addrinfo() deadlock in sync mode

Fix the issue that rdma_resolve_addrinfo() gets deadlock when run in
sync mode:
 (gdb) bt
 #0  futex_wait
 #1  __GI___lll_lock_wait
 linux-rdma#2  0x00007ffff7dae791 in lll_mutex_lock_optimized
 linux-rdma#3  ___pthread_mutex_lock
 linux-rdma#4  0x00007ffff7f9f018 in ucma_process_addrinfo_resolved
 linux-rdma#5  0x00007ffff7fa1447 in rdma_get_cm_event
 linux-rdma#6  0x00007ffff7fa1fef in ucma_complete
 linux-rdma#7  0x00007ffff7fa2f9c in resolve_ai_sa
 linux-rdma#8  0x00007ffff7fa36ab in __rdma_resolve_addrinfo
 linux-rdma#9  rdma_resolve_addrinfo
 linux-rdma#10 0x00000000004017b6 in start_cm_client_sync
 linux-rdma#11 0x00000000004018ee in main

Issue: 4582946
Fixes: 7b1a686 ("librdmacm: Provide interfaces to resolve IB services")
Change-Id: Ia724795a559bab6d965a35b8fd3e0f0096472a44
Signed-off-by: Mark Zhang <markzhang@nvidia.com>
shefty pushed a commit to shefty/rdma-core that referenced this pull request Nov 11, 2025
@MarkZhang81 @shefty
librdmacm: Fix rdma_resolve_addrinfo() deadlock in sync mode
22cc499 
Fix the issue that rdma_resolve_addrinfo() gets deadlock when run in
sync mode:
 (gdb) bt
 #0  futex_wait
 #1  __GI___lll_lock_wait
 linux-rdma#2  0x00007ffff7dae791 in lll_mutex_lock_optimized
 linux-rdma#3  ___pthread_mutex_lock
 linux-rdma#4  0x00007ffff7f9f018 in ucma_process_addrinfo_resolved
 linux-rdma#5  0x00007ffff7fa1447 in rdma_get_cm_event
 linux-rdma#6  0x00007ffff7fa1fef in ucma_complete
 linux-rdma#7  0x00007ffff7fa2f9c in resolve_ai_sa
 linux-rdma#8  0x00007ffff7fa36ab in __rdma_resolve_addrinfo
 linux-rdma#9  rdma_resolve_addrinfo
 linux-rdma#10 0x00000000004017b6 in start_cm_client_sync
 linux-rdma#11 0x00000000004018ee in main

Signed-off-by: Mark Zhang <markzhang@nvidia.com>
@shefty shefty mentioned this pull request Nov 11, 2025
Closed
shefty pushed a commit to shefty/rdma-core that referenced this pull request Nov 11, 2025
@MarkZhang81 @shefty
librdmacm: Fix rdma_resolve_addrinfo() deadlock in sync mode
8d6827a 
Fix the issue that rdma_resolve_addrinfo() gets deadlock when run in
sync mode:
 (gdb) bt
 #0  futex_wait
 #1  __GI___lll_lock_wait
 linux-rdma#2  0x00007ffff7dae791 in lll_mutex_lock_optimized
 linux-rdma#3  ___pthread_mutex_lock
 linux-rdma#4  0x00007ffff7f9f018 in ucma_process_addrinfo_resolved
 linux-rdma#5  0x00007ffff7fa1447 in rdma_get_cm_event
 linux-rdma#6  0x00007ffff7fa1fef in ucma_complete
 linux-rdma#7  0x00007ffff7fa2f9c in resolve_ai_sa
 linux-rdma#8  0x00007ffff7fa36ab in __rdma_resolve_addrinfo
 linux-rdma#9  rdma_resolve_addrinfo
 linux-rdma#10 0x00000000004017b6 in start_cm_client_sync
 linux-rdma#11 0x00000000004018ee in main

Fixes: 7b1a686 ("librdmacm: Provide interfaces to resolve IB services")

Signed-off-by: Mark Zhang <markzhang@nvidia.com>
Signed-off-by: Sean Hefty <shefty@nvidia.com>
rleon pushed a commit that referenced this pull request Nov 12, 2025
@MarkZhang81 @rleon
librdmacm: Fix rdma_resolve_addrinfo() deadlock in sync mode
7528827 
Fix the issue that rdma_resolve_addrinfo() gets deadlock when run in
sync mode:
 (gdb) bt
 #0  futex_wait
 #1  __GI___lll_lock_wait
 #2  0x00007ffff7dae791 in lll_mutex_lock_optimized
 #3  ___pthread_mutex_lock
 #4  0x00007ffff7f9f018 in ucma_process_addrinfo_resolved
 #5  0x00007ffff7fa1447 in rdma_get_cm_event
 #6  0x00007ffff7fa1fef in ucma_complete
 #7  0x00007ffff7fa2f9c in resolve_ai_sa
 #8  0x00007ffff7fa36ab in __rdma_resolve_addrinfo
 #9  rdma_resolve_addrinfo
 #10 0x00000000004017b6 in start_cm_client_sync
 #11 0x00000000004018ee in main

Fixes: 7b1a686 ("librdmacm: Provide interfaces to resolve IB services")
Signed-off-by: Mark Zhang <markzhang@nvidia.com>
Signed-off-by: Sean Hefty <shefty@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
nmorey pushed a commit that referenced this pull request Nov 21, 2025
@MarkZhang81 @nmorey
librdmacm: Fix rdma_resolve_addrinfo() deadlock in sync mode
0ce536e 
[ Upstream commit 7528827 ]

Fix the issue that rdma_resolve_addrinfo() gets deadlock when run in
sync mode:
 (gdb) bt
 #0  futex_wait
 #1  __GI___lll_lock_wait
 #2  0x00007ffff7dae791 in lll_mutex_lock_optimized
 #3  ___pthread_mutex_lock
 #4  0x00007ffff7f9f018 in ucma_process_addrinfo_resolved
 #5  0x00007ffff7fa1447 in rdma_get_cm_event
 #6  0x00007ffff7fa1fef in ucma_complete
 #7  0x00007ffff7fa2f9c in resolve_ai_sa
 #8  0x00007ffff7fa36ab in __rdma_resolve_addrinfo
 #9  rdma_resolve_addrinfo
 #10 0x00000000004017b6 in start_cm_client_sync
 #11 0x00000000004018ee in main

Fixes: 7b1a686 ("librdmacm: Provide interfaces to resolve IB services")
Signed-off-by: Mark Zhang <markzhang@nvidia.com>
Signed-off-by: Sean Hefty <shefty@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Nicolas Morey <nmorey@suse.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@jgunthorpe @dledford