Skip to content

Trivial fixes and documentation updates #2

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 23 commits into from
Sep 23, 2016
Merged

Trivial fixes and documentation updates #2

merged 23 commits into from
Sep 23, 2016

Conversation

@jgunthorpe
Copy link
Member

@jgunthorpe jgunthorpe commented Sep 21, 2016

This is the next stage of patches, about half have been on the list already.

I view all of these as very simple and uncontroversial.

jgunthorpe and others added 23 commits September 21, 2016 15:33
@jgunthorpe
Consolidate the .gitignore files
1cc050d 
Remove auto* stuff in the sub directories and replace it with one
copy of cmake stuff in the top level.

Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
@jgunthorpe
Move the AUTHORS files into MAINTAINERS
cbd9800 
Mark historical past authors using the 'H:' tag. We don't need this
information sprinkled throughout the tree.

Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
@jgunthorpe
Add reporting bugs and submitting patches sections to README.md
6f07632 
Based on the wording from the libibverbs and srp_daemon README files.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
@jgunthorpe
mlx5: Add cmake options to replace --with-mlx5_debug/mw_debug
1547df4 
Simply enable -D flags when building.

Use as:
  $ cmake -DMLX5_DEBUG=TRUE -DMLX5_MW_DEBUG=TRUE

Reported-by: Yishai Hadas <yishaih@dev.mellanox.co.il>
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
@jgunthorpe
ipathverbs: Recognize bashisms in truescale-serdes.cmds
7384afc 
Debian's Lintian remarks:

E: rdma-plumbing: shell-script-fails-syntax-check usr/lib/truescale-serdes.cmds

And indeed:

$ sh -n providers/ipathverbs/truescale-serdes.cmds
providers/ipathverbs/truescale-serdes.cmds: 100: providers/ipathverbs/truescale-serdes.cmds: Syntax error: "(" unexpected (expecting "}")

This is a bashism, change the script to require bash.

Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
@jgunthorpe
nes: Fix clang 3.6 warning -Wtautological-constant-out-of-range-compare
f1a8181 
clang will miscompile this code because it make assumptions
about the signededness of enums.

Instead create a constant for an invalid ibv_wc_opcode and use that
everywhere. Unsigned enums will use -1, signed enums should use INT_MAX.

Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
@jgunthorpe
ocrdma: Fix incorrect type of ibwc_status
e549022 
clang 3.6 remarks:

../providers/ocrdma/ocrdma_verbs.c:1517:35: warning: implicit conversion from enumeration type 'enum ibv_wc_status' to different enumeration type 'enum ibv_wc_opcode' [-Wenum-conversion]
        enum ibv_wc_opcode ibwc_status = IBV_WC_GENERAL_ERR;

And it is not wrong, the enum should be ib_wc_status not opcode.

Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
@jgunthorpe
ocrdma: Fix incorrect enum constant
15241b4 
clang 3.6 remarks:

../providers/ocrdma/ocrdma_verbs.c:597:14: warning: implicit conversion from enumeration type 'enum ibv_qp_state' to different enumeration type 'enum ocrdma_qp_state' [-Wenum-conversion]
        qp->state = IBV_QPS_RESET;

And it is not wrong.  IBV_QPS_RESET=0 and OCRDMA_QPS_RST=0 so this
patch is a NOP.

Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
@jgunthorpe
verbs: Fix incorrect type of len
93f222c 
gcc remarks:

../librdmacm/examples/udpong.c:301:11: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
   if (len < 0)

len is set by:
		len = svr_recv(&msg, sizeof msg, &addr, &addrlen);

And svr_recv returns:

static ssize_t svr_recv(struct message *msg, size_t size,

So clearly len is the wrong type, and the error test does
not work.

Acked-by: Sean Hefty <sean.hefty@intel.com>
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
@jgunthorpe
verbs: Use inttypes.h format string macros
b5d03f3 
Otherwise a 32bit compile of ibv_devinfo will print garbage for
these values.

Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
@jgunthorpe
verbs: Move documentation to Documentation/
13680fe 
And drop bits that are outdated or replaced by top-level Documentation.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
@jgunthorpe
rdmacm: Use correct format specifier for size_t
9024876 
clang 3.6 remarks:

../librdmacm/examples/rping.c:1203:30: warning: invalid conversion specifier 'Z' [-Wformat-invalid-specifier]
                                       "(valid range is %Zd to %d)\n",

And indeed, the correct specifier for size_t is '%zd'

Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
@jgunthorpe
rdmacm: Fix leading \'s in rcopy man page
ea3484a 
Debian's Lintian remarks:

W: rdma-plumbing: manpage-has-errors-from-man usr/share/man/man1/rcopy.1.gz 15: warning: numeric expression expected (got `u')

And indeed the man page displays corrupted. The leading \ is only needed
if the text starts with - so drop it on all other cases.

Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
@jgunthorpe
rdmacm: Fix typos
b31f8e8 
From: Benjamin Drung <benjamin.drung@profitbricks.com> (debian)
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
@jgunthorpe
rdmacm: Move documentation to Documentation/
08e597c 
And drop bits that are outdated or replaced by top-level Documentation.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
@jgunthorpe
ibcm: Move documentation to Documentation/
a9731b2 
And drop bits that are outdated or replaced by top-level Documentation.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
@jgunthorpe
umad: Replace .nl with .sp in man pages
2a80f49 
Debian's Lintian remarks:

W: rdma-plumbing: manpage-has-errors-from-man usr/share/man/man3/umad_get_ca.3.gz 11: warning: macro `nl' not defined
W: rdma-plumbing: manpage-has-errors-from-man usr/share/man/man3/umad_get_port.3.gz 11: warning: macro `nl' not defined
W: rdma-plumbing: manpage-has-errors-from-man usr/share/man/man3/umad_init.3.gz 11: warning: macro `nl' not defined

We use .sp in other the man pages to separate function signatures, follow
that practice consistently.

Acked-by: Hal Rosenstock <hal@dev.mellanox.co.il>
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
@jgunthorpe
iwpmd: Add man pages
061ed04 
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
@jgunthorpe
iwpmd: Install ancillary files for iwpm
7c0ee6f 
There were installed manually inside the rpm spec file, our
standard is to do them during 'make install'

Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
@jgunthorpe
iwpmd: Remove syslog.target from service file
e8f2b5c 
Debian's Lintian remarks:

W: rdma-plumbing: systemd-service-file-refers-to-obsolete-target lib/systemd/system/iwpmd.service syslog.target

Apparently systemd stopped recommending this in version 35, socket activation
eliminates the need.

Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
@jgunthorpe
rxe: Move documentation to Documentation/
de38d75 
Very little of the rxe RADME.md is relevant with the kernel driver upstream,
and the userspace provider part of this repository.  Move the remaining bits
to Documentation/rxe.md and delete the rest.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
@jgunthorpe
srp_daemon: Move documentation to Documentation/
b211776 
And drop bits that are outdated or replaced by top-level Documentation.

Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
@jgunthorpe
srp_daemon: Use SRP_DEFAULT_START/STOP for substitution
3d3d5be 
For clarity.

Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com>
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
@jgunthorpe jgunthorpe force-pushed the stage2 branch 2 times, most recently from feb105b to 3d3d5be Compare September 23, 2016 03:52
@dledford dledford merged commit 3d3d5be into linux-rdma:master Sep 23, 2016
@jgunthorpe jgunthorpe deleted the stage2 branch September 23, 2016 16:03
dledford pushed a commit that referenced this pull request Dec 23, 2016
@jgunthorpe @dledford
verbs: Do not copy uninitialized data in ibv_cmd_modify_qp
77fbb25 
Valgrind reports:

==1196== Syscall param write(buf) points to uninitialised byte(s)
==1196==    at 0x506250D: ??? (syscall-template.S:84)
==1196==    by 0x527756F: ibv_cmd_modify_qp (cmd.c:1291)
==1196==    by 0x8008D74: mlx4_modify_qp (verbs.c:820)
==1196==    by 0x527E4F4: ibv_modify_qp@@IBVERBS_1.1 (verbs.c:561)
==1196==    by 0x4E3FAB3: ucma_modify_qp_err.isra.6 (cma.c:1115)
==1196==    by 0x4E41D56: rdma_get_cm_event.part.15 (cma.c:2180)
==1196==    by 0x402CF0: cm_thread (rping.c:576)
==1196==    by 0x5059709: start_thread (pthread_create.c:333)
==1196==    by 0x558A82C: clone (clone.S:109)
==1196==  Address 0x9847980 is on thread 2's stack
==1196==  in frame #2, created by mlx4_modify_qp (verbs.c:775)

This is because of code like this:

        struct ibv_qp_attr qp_attr;
        qp_attr.qp_state = IBV_QPS_ERR;
        return rdma_seterrno(ibv_modify_qp(id->qp, &qp_attr, IBV_QP_STATE));

Always pass 0 into the kernel for for attributes that are not requested
to be modified.

Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
@yishaih yishaih mentioned this pull request May 9, 2017
Merged
rleon added a commit that referenced this pull request Apr 29, 2018
@rleon
Merge pull request #322 from gerd-rausch/ibacm-unix-domain
9ddd270 
Limit server to 127.0.0.1 & don't serve requests from librdmacm (take #2)
Hakon-Bugge added a commit to Hakon-Bugge/rdma-core that referenced this pull request Nov 22, 2018
@Hakon-Bugge
ibacm: Fix incorrect length used in address comparisons
9485fa7 
In acm_addr_lookup(), an address compare is performed. It compares
ACM_MAX_ADDRESS worth of bytes. However, the bytes exceeding the
actual address length, as given by addr_type, may contain arbitrary
data.

For example, in acm_svr_select_src() is only the valid bytes for an
IPv4 or IPv6 copied. Similar in acm_nl_to_addr_data().

Here is an example from debugging with gdb, slightly edited for better brevity:

(gdb) where
 #0  acm_addr_lookup () at src/acm.c:419
 linux-rdma#1  acm_get_port_ep_address () at src/acm.c:829
 linux-rdma#2  acm_get_ep_address () at src/acm.c:848
 linux-rdma#3  acm_rm_ep_ip () at src/acm.c:1322
 linux-rdma#4  acm_ipnl_handler () at src/acm.c:1452
 linux-rdma#5  acm_server () at src/acm.c:1867
 linux-rdma#6  main () at src/acm.c:3228

(gdb) x/16u ep->addr_info[i].addr.info.addr
0x1da66a8:  192 168     200     200     0       0       0       0
0x1da66b0:  0   0       0       0       0       0       0       0

(gdb) x/16u addr
0x7ffd165ca9f8: 192     168     200     200     62      127     0       0
0x7ffd165caa00: 95      8       14      129     62      127     0       0

(gdb) p addr_type
$5 = 2 '\002'

addr_type is here 2, which is ACM_ADDRESS_IP. We see that the IPv4
addresses are equal, but the compare detects different addresses,
because the full ACM_MAX_ADDRESS is used.

By introducing a helper function comparing names or addresses, the
actual length is used for addresses, and the functions
acm_mark_addr_invalid() and acm_addr_lookup() are greatly simplified.

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: Fix incorrect length used in address comparisons
c562033 
In acm_addr_lookup(), an address compare is performed. It compares
ACM_MAX_ADDRESS worth of bytes. However, the bytes exceeding the
actual address length, as given by addr_type, may contain arbitrary
data.

For example, in acm_svr_select_src() is only the valid bytes for an
IPv4 or IPv6 copied. Similar in acm_nl_to_addr_data().

Here is an example from debugging with gdb, slightly edited for better brevity:

(gdb) where
 #0  acm_addr_lookup () at src/acm.c:419
 linux-rdma#1  acm_get_port_ep_address () at src/acm.c:829
 linux-rdma#2  acm_get_ep_address () at src/acm.c:848
 linux-rdma#3  acm_rm_ep_ip () at src/acm.c:1322
 linux-rdma#4  acm_ipnl_handler () at src/acm.c:1452
 linux-rdma#5  acm_server () at src/acm.c:1867
 linux-rdma#6  main () at src/acm.c:3228

(gdb) x/16u ep->addr_info[i].addr.info.addr
0x1da66a8:  192 168     200     200     0       0       0       0
0x1da66b0:  0   0       0       0       0       0       0       0

(gdb) x/16u addr
0x7ffd165ca9f8: 192     168     200     200     62      127     0       0
0x7ffd165caa00: 95      8       14      129     62      127     0       0

(gdb) p addr_type
$5 = 2 '\002'

addr_type is here 2, which is ACM_ADDRESS_IP. We see that the IPv4
addresses are equal, but the compare detects different addresses,
because the full ACM_MAX_ADDRESS is used.

By introducing a helper function comparing names or addresses, the
actual length is used for addresses, and the functions
acm_mark_addr_invalid() and acm_addr_lookup() are greatly simplified.

Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>

---

v1 -> v2: Fixed Travis issue
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>
@razeh razeh mentioned this pull request Dec 20, 2018
Closed
rosenbaumalex pushed a commit to rosenbaumalex/rdma-core that referenced this pull request Jan 7, 2019
@Hakon-Bugge @rosenbaumalex
ibacm: Fix incorrect length used in address comparisons
f9a7f5f 
In acm_addr_lookup(), an address compare is performed. It compares
ACM_MAX_ADDRESS worth of bytes. However, the bytes exceeding the
actual address length, as given by addr_type, may contain arbitrary
data.

For example, in acm_svr_select_src() is only the valid bytes for an
IPv4 or IPv6 copied. Similar in acm_nl_to_addr_data().

Here is an example from debugging with gdb, slightly edited for better brevity:

(gdb) where
 #0  acm_addr_lookup () at src/acm.c:419
 linux-rdma#1  acm_get_port_ep_address () at src/acm.c:829
 linux-rdma#2  acm_get_ep_address () at src/acm.c:848
 linux-rdma#3  acm_rm_ep_ip () at src/acm.c:1322
 linux-rdma#4  acm_ipnl_handler () at src/acm.c:1452
 linux-rdma#5  acm_server () at src/acm.c:1867
 linux-rdma#6  main () at src/acm.c:3228

(gdb) x/16u ep->addr_info[i].addr.info.addr
0x1da66a8:  192 168     200     200     0       0       0       0
0x1da66b0:  0   0       0       0       0       0       0       0

(gdb) x/16u addr
0x7ffd165ca9f8: 192     168     200     200     62      127     0       0
0x7ffd165caa00: 95      8       14      129     62      127     0       0

(gdb) p addr_type
$5 = 2 '\002'

addr_type is here 2, which is ACM_ADDRESS_IP. We see that the IPv4
addresses are equal, but the compare detects different addresses,
because the full ACM_MAX_ADDRESS is used.

By introducing a helper function comparing names or addresses, the
actual length is used for addresses, and the functions
acm_mark_addr_invalid() and acm_addr_lookup() are greatly simplified.

Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>

---

v1 -> v2: Fixed Travis issue
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 added a commit to oracle/rdma-core that referenced this pull request Mar 27, 2019
@aron-silverton
oracle: Load RDMAIP kernel module using hot-plug
50a56fa 
Load the 'resilient_rdmaip' kernel module using the upstream kernel-boot
hot-plug framework.

NB: In the past, changes were made to the network service
(/etc/rc.d/init.d/network) to make it aware of the RDMAIP module. Those
changes include:

1. Disabling active/active bonding when the network service is stopped
   and enabling active/active bonding when the network service is
   started. In this context, stopping the network service means running
   'ifdown' on all interfaces so it is not clear why RDMAIP would still
   be atempting to do anything with the interfaces when they are down.
   RDMAIP should use netlink or other facilities to be aware of the
   interface state.

2. Triggering RDMAIP to run its bonding code when interfaces are up.
   This is apparently done to avoid some sort of delay in how long it
   might otherwise take RDMAIP to bond the interfaces. Again, this
   should be done automatically by having RDMAIP use netlink to be aware
   of interfaces state changes.

At this time, these changes are not included.

For linux-rdma#1: The network service used previously is no longer being used.
Instead, network interface configuration is done using systemd-networkd.
The systemd-networkd service has no concept of starting and stopping the
network. It is a network interface configuration service and stopping it
does not change the state of any of the interfaces it manages. Under
systemd, it is not possible to stop a service or socket and have all of
the netork interfaces shutdown in the way that would happen in the past
with "service network stop". If it is necessary to start and stop RDMAIP
then this must be done based on the state of the interfaces that RDMAIP
is currently bonding and not on a systemd-wide basis.

For linux-rdma#2: Again, there is no single service that enables all interfaces or
disables all interfaces. Furthermore, the concept of the network being
"up" in the current version of systemd is that the network is "up" as
soon as a single non-loopback interface has a routable IP addresses and
network connectivity. The network online target does NOT indicate that
all interfaces are active. It is possible, in some situations, to use
a 'systemd-networkd-wait-online.service' to have a service unit wait on
a particular interface but this requires prior knowledge of which
interface(s) to wait on and hardcoding this information into a service
unit. RDMAIP should be made aware of the state of the interfaces it is
bonding and run its actions when both initially reach link up.

Orabug: 28782057

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: Fix incorrect length used in address comparisons
da9eb91 
In acm_addr_lookup(), an address compare is performed. It compares
ACM_MAX_ADDRESS worth of bytes. However, the bytes exceeding the
actual address length, as given by addr_type, may contain arbitrary
data.

For example, in acm_svr_select_src() is only the valid bytes for an
IPv4 or IPv6 copied. Similar in acm_nl_to_addr_data().

Here is an example from debugging with gdb, slightly edited for better brevity:

(gdb) where
 #0  acm_addr_lookup () at src/acm.c:419
 linux-rdma#1  acm_get_port_ep_address () at src/acm.c:829
 linux-rdma#2  acm_get_ep_address () at src/acm.c:848
 linux-rdma#3  acm_rm_ep_ip () at src/acm.c:1322
 linux-rdma#4  acm_ipnl_handler () at src/acm.c:1452
 linux-rdma#5  acm_server () at src/acm.c:1867
 linux-rdma#6  main () at src/acm.c:3228

(gdb) x/16u ep->addr_info[i].addr.info.addr
0x1da66a8:  192 168     200     200     0       0       0       0
0x1da66b0:  0   0       0       0       0       0       0       0

(gdb) x/16u addr
0x7ffd165ca9f8: 192     168     200     200     62      127     0       0
0x7ffd165caa00: 95      8       14      129     62      127     0       0

(gdb) p addr_type
$5 = 2 '\002'

addr_type is here 2, which is ACM_ADDRESS_IP. We see that the IPv4
addresses are equal, but the compare detects different addresses,
because the full ACM_MAX_ADDRESS is used.

By introducing a helper function comparing names or addresses, the
actual length is used for addresses, and the functions
acm_mark_addr_invalid() and acm_addr_lookup() are greatly simplified.

Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>

---

v1 -> v2: Fixed Travis issue

Orabug: 29037253

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

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
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: Fix incorrect length used in address comparisons
8763162 
In acm_addr_lookup(), an address compare is performed. It compares
ACM_MAX_ADDRESS worth of bytes. However, the bytes exceeding the
actual address length, as given by addr_type, may contain arbitrary
data.

For example, in acm_svr_select_src() is only the valid bytes for an
IPv4 or IPv6 copied. Similar in acm_nl_to_addr_data().

Here is an example from debugging with gdb, slightly edited for better brevity:

(gdb) where
 #0  acm_addr_lookup () at src/acm.c:419
 linux-rdma#1  acm_get_port_ep_address () at src/acm.c:829
 linux-rdma#2  acm_get_ep_address () at src/acm.c:848
 linux-rdma#3  acm_rm_ep_ip () at src/acm.c:1322
 linux-rdma#4  acm_ipnl_handler () at src/acm.c:1452
 linux-rdma#5  acm_server () at src/acm.c:1867
 linux-rdma#6  main () at src/acm.c:3228

(gdb) x/16u ep->addr_info[i].addr.info.addr
0x1da66a8:  192 168     200     200     0       0       0       0
0x1da66b0:  0   0       0       0       0       0       0       0

(gdb) x/16u addr
0x7ffd165ca9f8: 192     168     200     200     62      127     0       0
0x7ffd165caa00: 95      8       14      129     62      127     0       0

(gdb) p addr_type
$5 = 2 '\002'

addr_type is here 2, which is ACM_ADDRESS_IP. We see that the IPv4
addresses are equal, but the compare detects different addresses,
because the full ACM_MAX_ADDRESS is used.

By introducing a helper function comparing names or addresses, the
actual length is used for addresses, and the functions
acm_mark_addr_invalid() and acm_addr_lookup() are greatly simplified.

Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>

---

v1 -> v2: Fixed Travis issue

Orabug: 29037253

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

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: Fix incorrect length used in address comparisons
9ff490c 
In acm_addr_lookup(), an address compare is performed. It compares
ACM_MAX_ADDRESS worth of bytes. However, the bytes exceeding the
actual address length, as given by addr_type, may contain arbitrary
data.

For example, in acm_svr_select_src() is only the valid bytes for an
IPv4 or IPv6 copied. Similar in acm_nl_to_addr_data().

Here is an example from debugging with gdb, slightly edited for better brevity:

(gdb) where
 #0  acm_addr_lookup () at src/acm.c:419
 linux-rdma#1  acm_get_port_ep_address () at src/acm.c:829
 linux-rdma#2  acm_get_ep_address () at src/acm.c:848
 linux-rdma#3  acm_rm_ep_ip () at src/acm.c:1322
 linux-rdma#4  acm_ipnl_handler () at src/acm.c:1452
 linux-rdma#5  acm_server () at src/acm.c:1867
 linux-rdma#6  main () at src/acm.c:3228

(gdb) x/16u ep->addr_info[i].addr.info.addr
0x1da66a8:  192 168     200     200     0       0       0       0
0x1da66b0:  0   0       0       0       0       0       0       0

(gdb) x/16u addr
0x7ffd165ca9f8: 192     168     200     200     62      127     0       0
0x7ffd165caa00: 95      8       14      129     62      127     0       0

(gdb) p addr_type
$5 = 2 '\002'

addr_type is here 2, which is ACM_ADDRESS_IP. We see that the IPv4
addresses are equal, but the compare detects different addresses,
because the full ACM_MAX_ADDRESS is used.

By introducing a helper function comparing names or addresses, the
actual length is used for addresses, and the functions
acm_mark_addr_invalid() and acm_addr_lookup() are greatly simplified.

Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>

---

v1 -> v2: Fixed Travis issue

Orabug: 29037253

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

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 bbd44792)
cherry-pick-repo=linux-git/RDMA/rdma-core.git
unmodified-from-upstream: bbd44792

Signed-off-by: Mark Haywood <mark.haywood@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>
gal-pressman referenced this pull request in amzn/rdma-core Jul 25, 2019
@gal-pressman
verbs: Initialize reserved attributes in create AH command
f2f0fb2 
Initialize the reserved fields in create AH command to eliminate
valgrind warnings such as:

==18022== Syscall param write(buf) points to uninitialised byte(s)
==18022==    at 0x513A894: write (in /usr/lib64/libc-2.26.so)
==18022==    by 0x4E440C0: _execute_cmd_write (cmd_fallback.c:250)
==18022==    by 0x4E418BC: ibv_cmd_create_ah (cmd.c:1443)
==18022==    by 0x7E9E0F7: efa_create_ah (verbs.c:1180)
==18022==    by 0x4E4C120: ibv_create_ah@@IBVERBS_1.1 (verbs.c:641)
==18022==    by 0x403191: pp_connect_ctx (ud_pingpong.c:117)
==18022==    by 0x402694: main (ud_pingpong.c:741)
==18022==  Address 0x1ffefffe0c is on thread 1's stack
==18022==  in frame #2, created by ibv_cmd_create_ah (cmd.c:1425)

Signed-off-by: Gal Pressman <galpress@amazon.com>
@gal-pressman gal-pressman mentioned this pull request Jul 25, 2019
Merged
@jgunthorpe jgunthorpe mentioned this pull request Mar 9, 2020
Merged
@Honggang-LI Honggang-LI mentioned this pull request Oct 14, 2020
Closed
aron-silverton pushed a commit to oracle/rdma-core that referenced this pull request Nov 16, 2020
@Hakon-Bugge @aron-silverton
ibacm: Fix incorrect length used in address comparisons
7defc58 
In acm_addr_lookup(), an address compare is performed. It compares
ACM_MAX_ADDRESS worth of bytes. However, the bytes exceeding the
actual address length, as given by addr_type, may contain arbitrary
data.

For example, in acm_svr_select_src() is only the valid bytes for an
IPv4 or IPv6 copied. Similar in acm_nl_to_addr_data().

Here is an example from debugging with gdb, slightly edited for better brevity:

(gdb) where
 #0  acm_addr_lookup () at src/acm.c:419
 linux-rdma#1  acm_get_port_ep_address () at src/acm.c:829
 linux-rdma#2  acm_get_ep_address () at src/acm.c:848
 linux-rdma#3  acm_rm_ep_ip () at src/acm.c:1322
 linux-rdma#4  acm_ipnl_handler () at src/acm.c:1452
 linux-rdma#5  acm_server () at src/acm.c:1867
 linux-rdma#6  main () at src/acm.c:3228

(gdb) x/16u ep->addr_info[i].addr.info.addr
0x1da66a8:  192 168     200     200     0       0       0       0
0x1da66b0:  0   0       0       0       0       0       0       0

(gdb) x/16u addr
0x7ffd165ca9f8: 192     168     200     200     62      127     0       0
0x7ffd165caa00: 95      8       14      129     62      127     0       0

(gdb) p addr_type
$5 = 2 '\002'

addr_type is here 2, which is ACM_ADDRESS_IP. We see that the IPv4
addresses are equal, but the compare detects different addresses,
because the full ACM_MAX_ADDRESS is used.

By introducing a helper function comparing names or addresses, the
actual length is used for addresses, and the functions
acm_mark_addr_invalid() and acm_addr_lookup() are greatly simplified.

Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>

---

v1 -> v2: Fixed Travis issue

Orabug: 29037253

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

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 8763162)
cherry-pick-repo=linux-git.us.oracle.com/RDMA/rdma-core.git
unmodified-from-upstream: 8763162

Signed-off-by: Mark Haywood <mark.haywood@oracle.com>
Acked-by: Aron Silverton <aron.silverton@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>
mazorasaf added a commit to mazorasaf/rdma-core that referenced this pull request Nov 27, 2024
@mazorasaf
fix build errors linux-rdma#2
47b039d 
Signed-off-by: Asaf Mazor <amazor@nvidia.com>
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