Sean Hefty [Sat, 23 Jan 2010 07:28:57 +0000 (23:28 -0800)]
dapl/cma: fix referencing freed address
DAPL uses a pointer to reference the local and remote addresses
of an endpoint. It expects that those addresses are located
in memory that is always accessible. Typically, for the local
address, the pointer references the address stored with the DAPL
HCA device. However, for the cma provider, it changes this pointer
to reference the address stored with the rdma_cm_id.
This causes a problem when that endpoint is connected on the
passive side of a connection. When connect requests are given
to DAPL, a new rdma_cm_id is associated with the request. The
DAPL code replaces the current rdma_cm_id associated with a
user's endpoint with the new rdma_cm_id. The old rdma_cm_id is
then deleted. But the endpoint's local address pointer still
references the address stored with the old rdma_cm_id. The
result is that any reference to the address will access freed
memory.
Fix this by keeping the local address pointer always pointing
to the address associated with the DAPL HCA device. This is about
the best that can be done given the DAPL interface design.
Sean Hefty [Sat, 23 Jan 2010 07:28:57 +0000 (23:28 -0800)]
dapl/cma: fix referencing freed address
DAPL uses a pointer to reference the local and remote addresses
of an endpoint. It expects that those addresses are located
in memory that is always accessible. Typically, for the local
address, the pointer references the address stored with the DAPL
HCA device. However, for the cma provider, it changes this pointer
to reference the address stored with the rdma_cm_id.
This causes a problem when that endpoint is connected on the
passive side of a connection. When connect requests are given
to DAPL, a new rdma_cm_id is associated with the request. The
DAPL code replaces the current rdma_cm_id associated with a
user's endpoint with the new rdma_cm_id. The old rdma_cm_id is
then deleted. But the endpoint's local address pointer still
references the address stored with the old rdma_cm_id. The
result is that any reference to the address will access freed
memory.
Fix this by keeping the local address pointer always pointing
to the address associated with the DAPL HCA device. This is about
the best that can be done given the DAPL interface design.
Sean Hefty [Sat, 23 Jan 2010 07:28:57 +0000 (23:28 -0800)]
dapl/cma: fix referencing freed address
DAPL uses a pointer to reference the local and remote addresses
of an endpoint. It expects that those addresses are located
in memory that is always accessible. Typically, for the local
address, the pointer references the address stored with the DAPL
HCA device. However, for the cma provider, it changes this pointer
to reference the address stored with the rdma_cm_id.
This causes a problem when that endpoint is connected on the
passive side of a connection. When connect requests are given
to DAPL, a new rdma_cm_id is associated with the request. The
DAPL code replaces the current rdma_cm_id associated with a
user's endpoint with the new rdma_cm_id. The old rdma_cm_id is
then deleted. But the endpoint's local address pointer still
references the address stored with the old rdma_cm_id. The
result is that any reference to the address will access freed
memory.
Fix this by keeping the local address pointer always pointing
to the address associated with the DAPL HCA device. This is about
the best that can be done given the DAPL interface design.
Sean Hefty [Sat, 23 Jan 2010 06:29:39 +0000 (22:29 -0800)]
dapl: quick fix for wrong private data size
DAPl expects the private data size to be up to 256 bytes, but
on windows the private data size is limited to 56 bytes. As
a result, DAPL can access memory beyond the end of what's
allocated.
A more 'correct' fix is being submitted upstream to dapl. This
is a simpler fix for the Windows 2.2 release only.
Sean Hefty [Sat, 23 Jan 2010 06:29:39 +0000 (22:29 -0800)]
dapl: quick fix for wrong private data size
DAPl expects the private data size to be up to 256 bytes, but
on windows the private data size is limited to 56 bytes. As
a result, DAPL can access memory beyond the end of what's
allocated.
A more 'correct' fix is being submitted upstream to dapl. This
is a simpler fix for the Windows 2.2 release only.
Sean Hefty [Sat, 23 Jan 2010 00:22:36 +0000 (16:22 -0800)]
dapl: use private_data_len for mem copies
When copying private_data out of rdma_cm events, use the
reported private_data_len for the size, and not IB maximums.
This fixes a bug running over the librdmacm on windows, where
DAPL accessed invalid memory.
Sean Hefty [Sat, 23 Jan 2010 00:22:36 +0000 (16:22 -0800)]
dapl: use private_data_len for mem copies
When copying private_data out of rdma_cm events, use the
reported private_data_len for the size, and not IB maximums.
This fixes a bug running over the librdmacm on windows, where
DAPL accessed invalid memory.
Sean Hefty [Sat, 23 Jan 2010 00:22:36 +0000 (16:22 -0800)]
dapl: use private_data_len for mem copies
When copying private_data out of rdma_cm events, use the
reported private_data_len for the size, and not IB maximums.
This fixes a bug running over the librdmacm on windows, where
DAPL accessed invalid memory.
Sean Hefty [Sat, 23 Jan 2010 00:22:36 +0000 (16:22 -0800)]
dapl: use private_data_len for mem copies
When copying private_data out of rdma_cm events, use the
reported private_data_len for the size, and not IB maximums.
This fixes a bug running over the librdmacm on windows, where
DAPL accessed invalid memory.