License cleanup #5

yishaih · 2016-09-28T15:24:44Z

Add CCAN functionality to solve licensing issue.
Cleanup and code sharing.

This tree uses the version of container_of in infinband/verbs.h, and requires stddef.h to declare offsetof. Signed-off-by: Yishai Hadas <yishaih@mellanox.com>

Add CCAN min/max functionality and use it among the project. In addition, turn on HAVE_BUILTIN_TYPES_COMPATIBLE_P and fix typing mistakes for min/max usage. Signed-off-by: Yishai Hadas <yishaih@mellanox.com> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>

Add CCAN list functionality to be used by down stream patches. It includes changes to relevant cmake files among the project as introduced by Jason. Signed-off-by: Yishai Hadas <yishaih@mellanox.com> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>

Move to use CCAN list functionality which its license meets the project needs. Signed-off-by: Yishai Hadas <yishaih@mellanox.com>

Move to use CCAN list functionality which its license meets the project needs. Acked-By: Devesh Sharma <devesh.sharma@broadcom.com> Signed-off-by: Yishai Hadas <yishaih@mellanox.com>

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>

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>

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>

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>

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

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>

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

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

[ 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>

Remove container_of and offset local declarations

30c8b55

This tree uses the version of container_of in infinband/verbs.h, and requires stddef.h to declare offsetof. Signed-off-by: Yishai Hadas <yishaih@mellanox.com>

jgunthorpe mentioned this pull request Sep 28, 2016

Add directory to place common code and move trivial functions into it #4

Closed

yishaih force-pushed the license_cleanup branch from c78c0b3 to 285b7c4 Compare September 29, 2016 10:29

yishaih added 4 commits September 29, 2016 13:44

libmlx5: Move to use CCAN list functionality

1e97c9e

Move to use CCAN list functionality which its license meets the project needs. Signed-off-by: Yishai Hadas <yishaih@mellanox.com>

libocrdma: Move to use CCAN list functionality

41e7501

Move to use CCAN list functionality which its license meets the project needs. Acked-By: Devesh Sharma <devesh.sharma@broadcom.com> Signed-off-by: Yishai Hadas <yishaih@mellanox.com>

yishaih force-pushed the license_cleanup branch from 285b7c4 to 41e7501 Compare September 29, 2016 10:45

dledford merged commit 6302717 into linux-rdma:master Sep 29, 2016

Honggang-LI mentioned this pull request Oct 14, 2020

infiniband-diags: update ibportstate port enabling example #847

Closed

haoyue-Xu mentioned this pull request Oct 25, 2022

[PATCH rdma-core 0/8] Fix sge num bug, refactor rq inline, support cqe inline #1240

Merged

shefty mentioned this pull request Nov 11, 2025

librdmacm: Fix rdma_resolve_addrinfo() deadlock in sync mode #1661

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

License cleanup #5

License cleanup #5

Uh oh!

yishaih commented Sep 28, 2016

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

License cleanup #5

License cleanup #5

Uh oh!

Conversation

yishaih commented Sep 28, 2016

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants