Kaike Wan [Wed, 25 Mar 2015 22:40:46 +0000 (15:40 -0700)]
ibacm: Use pkey 0xffff or 0x7fff for SA query
Currently, ibacm uses the first pkey on the local port to query SA. More
appropriately, it should use either 0xffff or 0x7fff for SA query.
However, if the local port is not configured with either pkey, ibacm will
continue to use the first pkey.
Signed-off-by: Kaike Wan <kaike.wan@intel.com> Signed-off-by: Sean Hefty <sean.hefty@intel.com>
Kaike Wan [Wed, 25 Mar 2015 22:40:46 +0000 (15:40 -0700)]
ibacm: Use pkey 0xffff or 0x7fff for SA query
Currently, ibacm uses the first pkey on the local port to query SA. More
appropriately, it should use either 0xffff or 0x7fff for SA query.
However, if the local port is not configured with either pkey, ibacm will
continue to use the first pkey.
Kaike Wan [Wed, 7 Jan 2015 22:25:34 +0000 (14:25 -0800)]
ibacm: open only prov endpoints with name/addr configured
This patch modifies the ibacm core so that it will request the provider to
open those endpoints that have been assigned with at least one name or address.
This change will avoid unnecessary endpoint open and close for those without
any name/address configured by the administrator.
Signed-off-by: Kaike Wan <kaike.wan@intel.com> Signed-off-by: Sean Hefty <sean.hefty@intel.com>
Kaike Wan [Wed, 7 Jan 2015 22:25:34 +0000 (14:25 -0800)]
ibacm: open only prov endpoints with name/addr configured
This patch modifies the ibacm core so that it will request the provider to
open those endpoints that have been assigned with at least one name or address.
This change will avoid unnecessary endpoint open and close for those without
any name/address configured by the administrator.
Kaike Wan [Wed, 3 Dec 2014 19:42:54 +0000 (11:42 -0800)]
ibacm: incorrect ifc_len is specified in SIOCGIFCONF request
The ifc->ifs_len in the ioctl SIOCGIFCONF request should only specify the
associated ifreq buffer length and not include the ifc header length.
This bug was found by running ibacm with Valgrind:
==8201== Syscall param ioctl(SIOCGIFCONF).ifc_buf points to unaddressable byte(s)
==8201== at 0x3E886DF7B7: ioctl (in /lib64/libc-2.12.so)
==8201== by 0x40A11A: acm_if_iter_sys (acm_util.c:154)
==8201== by 0x406979: acm_get_system_ips (acm.c:1584)
==8201== by 0x4069FD: acm_assign_ep_names (acm.c:1602)
==8201== by 0x4070D1: acm_ep_up (acm.c:1744)
==8201== by 0x407799: acm_port_up (acm.c:1896)
==8201== by 0x407DE1: acm_activate_devices (acm.c:2027)
==8201== by 0x409CAC: main (acm.c:2728)
==8201== Address 0x5063470 is 0 bytes after a block of size 2,576 alloc'd
==8201== at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==8201== by 0x40A0BB: acm_if_iter_sys (acm_util.c:144)
==8201== by 0x406979: acm_get_system_ips (acm.c:1584)
==8201== by 0x4069FD: acm_assign_ep_names (acm.c:1602)
==8201== by 0x4070D1: acm_ep_up (acm.c:1744)
==8201== by 0x407799: acm_port_up (acm.c:1896)
==8201== by 0x407DE1: acm_activate_devices (acm.c:2027)
==8201== by 0x409CAC: main (acm.c:2728)
Signed-off-by: Kaike Wan <kaike.wan@intel.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Signed-off-by: Sean Hefty <sean.hefty@intel.com>
Kaike Wan [Wed, 3 Dec 2014 20:14:44 +0000 (12:14 -0800)]
ibacm/ibacmp: fix a crash when SM restarts
Ibacm may cause segfault when the SM restarts: when the SM restarts, ibacm will
receive P_Key change event and instruct ibacmp to close all endpoints. However,
ibacmp only resets the core endpoint pointer in its ep structure and keeps the ep
in the port's ep_list. Afterwards, the ibacm core will ask ibacmp to create
an ep for each pkey enumerated from the local port. The ep will be found
from the port's ep_list if it exists. However, if an old pkey is not present
in the new SM configuration, the old ep will still be linked in the port's
ep_list with the ep->endpoint being set to NULL. When the ibacm core forwards
the client reregistration event to ibacmp, ibacmp will enumerate the ep_list and
try to join multicast group for each ep, including any one with ep->endpoint
set to NULL. In this case, it will cause segfault in acm_send_sa_mad().
Additional check should be able to avoid the crash.
Signed-off-by: Kaike Wan <kaike.wan@intel.com> Signed-off-by: Sean Hefty <sean.hefty@intel.com>
Kaike Wan [Wed, 3 Dec 2014 20:14:44 +0000 (12:14 -0800)]
ibacm/ibacmp: fix a crash when SM restarts
Ibacm may cause segfault when the SM restarts: when the SM restarts, ibacm will
receive P_Key change event and instruct ibacmp to close all endpoints. However,
ibacmp only resets the core endpoint pointer in its ep structure and keeps the ep
in the port's ep_list. Afterwards, the ibacm core will ask ibacmp to create
an ep for each pkey enumerated from the local port. The ep will be found
from the port's ep_list if it exists. However, if an old pkey is not present
in the new SM configuration, the old ep will still be linked in the port's
ep_list with the ep->endpoint being set to NULL. When the ibacm core forwards
the client reregistration event to ibacmp, ibacmp will enumerate the ep_list and
try to join multicast group for each ep, including any one with ep->endpoint
set to NULL. In this case, it will cause segfault in acm_send_sa_mad().
Additional check should be able to avoid the crash.
Kaike Wan [Wed, 3 Dec 2014 19:42:54 +0000 (11:42 -0800)]
ibacm: incorrect ifc_len is specified in SIOCGIFCONF request
The ifc->ifs_len in the ioctl SIOCGIFCONF request should only specify the
associated ifreq buffer length and not include the ifc header length.
This bug was found by running ibacm with Valgrind:
==8201== Syscall param ioctl(SIOCGIFCONF).ifc_buf points to unaddressable byte(s)
==8201== at 0x3E886DF7B7: ioctl (in /lib64/libc-2.12.so)
==8201== by 0x40A11A: acm_if_iter_sys (acm_util.c:154)
==8201== by 0x406979: acm_get_system_ips (acm.c:1584)
==8201== by 0x4069FD: acm_assign_ep_names (acm.c:1602)
==8201== by 0x4070D1: acm_ep_up (acm.c:1744)
==8201== by 0x407799: acm_port_up (acm.c:1896)
==8201== by 0x407DE1: acm_activate_devices (acm.c:2027)
==8201== by 0x409CAC: main (acm.c:2728)
==8201== Address 0x5063470 is 0 bytes after a block of size 2,576 alloc'd
==8201== at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==8201== by 0x40A0BB: acm_if_iter_sys (acm_util.c:144)
==8201== by 0x406979: acm_get_system_ips (acm.c:1584)
==8201== by 0x4069FD: acm_assign_ep_names (acm.c:1602)
==8201== by 0x4070D1: acm_ep_up (acm.c:1744)
==8201== by 0x407799: acm_port_up (acm.c:1896)
==8201== by 0x407DE1: acm_activate_devices (acm.c:2027)
==8201== by 0x409CAC: main (acm.c:2728)
Signed-off-by: Kaike Wan <kaike.wan@intel.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Signed-off-by: Sean Hefty <sean.hefty@intel.com>
Kaike Wan [Wed, 3 Dec 2014 19:42:54 +0000 (11:42 -0800)]
ibacm: incorrect ifc_len is specified in SIOCGIFCONF request
The ifc->ifs_len in the ioctl SIOCGIFCONF request should only specify the
associated ifreq buffer length and not include the ifc header length.
This bug was found by running ibacm with Valgrind:
==8201== Syscall param ioctl(SIOCGIFCONF).ifc_buf points to unaddressable byte(s)
==8201== at 0x3E886DF7B7: ioctl (in /lib64/libc-2.12.so)
==8201== by 0x40A11A: acm_if_iter_sys (acm_util.c:154)
==8201== by 0x406979: acm_get_system_ips (acm.c:1584)
==8201== by 0x4069FD: acm_assign_ep_names (acm.c:1602)
==8201== by 0x4070D1: acm_ep_up (acm.c:1744)
==8201== by 0x407799: acm_port_up (acm.c:1896)
==8201== by 0x407DE1: acm_activate_devices (acm.c:2027)
==8201== by 0x409CAC: main (acm.c:2728)
==8201== Address 0x5063470 is 0 bytes after a block of size 2,576 alloc'd
==8201== at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==8201== by 0x40A0BB: acm_if_iter_sys (acm_util.c:144)
==8201== by 0x406979: acm_get_system_ips (acm.c:1584)
==8201== by 0x4069FD: acm_assign_ep_names (acm.c:1602)
==8201== by 0x4070D1: acm_ep_up (acm.c:1744)
==8201== by 0x407799: acm_port_up (acm.c:1896)
==8201== by 0x407DE1: acm_activate_devices (acm.c:2027)
==8201== by 0x409CAC: main (acm.c:2728)
Signed-off-by: Kaike Wan <kaike.wan@intel.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Kaike Wan [Wed, 3 Dec 2014 19:37:51 +0000 (11:37 -0800)]
ibacm: close the provider endpoint when it fails to assign a name to a core endpoint
In function acm_ep_up(), when it fails to assign any name to an endpoint, the
endpoint in the provider is not properly closed before the core endpoint is
freed. This may cause segfault when ibacmp tries to join multicast group with
a stale core endpoint pointer.
Signed-off-by: Kaike Wan <kaike.wan@intel.com> Signed-off-by: Sean Hefty <sean.hefty@intel.com>
Kaike Wan [Wed, 3 Dec 2014 19:37:51 +0000 (11:37 -0800)]
ibacm: close the provider endpoint when it fails to assign a name to a core endpoint
In function acm_ep_up(), when it fails to assign any name to an endpoint, the
endpoint in the provider is not properly closed before the core endpoint is
freed. This may cause segfault when ibacmp tries to join multicast group with
a stale core endpoint pointer.
Kaike Wan [Wed, 3 Dec 2014 19:42:54 +0000 (11:42 -0800)]
ibacm: incorrect ifc_len is specified in SIOCGIFCONF request
The ifc->ifs_len in the ioctl SIOCGIFCONF request should only specify the
associated ifreq buffer length and not include the ifc header length.
This bug was found by running ibacm with Valgrind:
==8201== Syscall param ioctl(SIOCGIFCONF).ifc_buf points to unaddressable byte(s)
==8201== at 0x3E886DF7B7: ioctl (in /lib64/libc-2.12.so)
==8201== by 0x40A11A: acm_if_iter_sys (acm_util.c:154)
==8201== by 0x406979: acm_get_system_ips (acm.c:1584)
==8201== by 0x4069FD: acm_assign_ep_names (acm.c:1602)
==8201== by 0x4070D1: acm_ep_up (acm.c:1744)
==8201== by 0x407799: acm_port_up (acm.c:1896)
==8201== by 0x407DE1: acm_activate_devices (acm.c:2027)
==8201== by 0x409CAC: main (acm.c:2728)
==8201== Address 0x5063470 is 0 bytes after a block of size 2,576 alloc'd
==8201== at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==8201== by 0x40A0BB: acm_if_iter_sys (acm_util.c:144)
==8201== by 0x406979: acm_get_system_ips (acm.c:1584)
==8201== by 0x4069FD: acm_assign_ep_names (acm.c:1602)
==8201== by 0x4070D1: acm_ep_up (acm.c:1744)
==8201== by 0x407799: acm_port_up (acm.c:1896)
==8201== by 0x407DE1: acm_activate_devices (acm.c:2027)
==8201== by 0x409CAC: main (acm.c:2728)
Signed-off-by: Kaike Wan <kaike.wan@intel.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com>