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.
(\18¬ [Thu, 21 Jan 2010 06:09:33 +0000 (06:09 +0000)]
ib/mad: fix routing of vendor mads
SVN commit 2174 introduced an error that resulted in all
vendor MADs being routed to the local HCA driver.
This results in the ib-diag vendstat failing to receive
a response when trying to gather statistics about a remote
device.
We should only route vendor mads to the local HCA if the
mad is one of the mellanox vendor classes, the mad is not
a response, and the local HCA is the destination for the
mad.
Problem reported by Mohammad Sawalha.
Signed-off-by: Sean Hefty <sean.hefty@intel.com>
git-svn-id: svn://openib.tc.cornell.edu/gen1@2675 ad392aa1-c5ef-ae45-8dd8-e69d62a5ef86
Sean Hefty [Thu, 21 Jan 2010 06:09:33 +0000 (06:09 +0000)]
ib/mad: fix routing of vendor mads
SVN commit 2174 introduced an error that resulted in all
vendor MADs being routed to the local HCA driver.
This results in the ib-diag vendstat failing to receive
a response when trying to gather statistics about a remote
device.
We should only route vendor mads to the local HCA if the
mad is one of the mellanox vendor classes, the mad is not
a response, and the local HCA is the destination for the
mad.
Problem reported by Mohammad Sawalha.
Signed-off-by: Sean Hefty <sean.hefty@intel.com>
git-svn-id: svn://openib.tc.cornell.edu/gen1@2675 ad392aa1-c5ef-ae45-8dd8-e69d62a5ef86
(\18¬ [Thu, 21 Jan 2010 06:09:19 +0000 (06:09 +0000)]
winverbs/ep: handle receiving REQ then DREQ
For fast connections, it's possible to receive a DREQ immediately
after receiving a REQ, without an RTU coming in between. If we've
sent a REP to the REQ, then the DREQ should be treated as if the
connection had been fully established. (The RTU could be delayed,
and the communication established event is processed asynchronously,
so there's no way to tell for certain.)
This fixes an issue where the passive side Accept() call fails
waiting for the RTU, but receives a DREQ instead.
Signed-off-by: Sean Hefty <sean.hefty@intel.com>
git-svn-id: svn://openib.tc.cornell.edu/gen1@2674 ad392aa1-c5ef-ae45-8dd8-e69d62a5ef86
Sean Hefty [Thu, 21 Jan 2010 06:09:19 +0000 (06:09 +0000)]
winverbs/ep: handle receiving REQ then DREQ
For fast connections, it's possible to receive a DREQ immediately
after receiving a REQ, without an RTU coming in between. If we've
sent a REP to the REQ, then the DREQ should be treated as if the
connection had been fully established. (The RTU could be delayed,
and the communication established event is processed asynchronously,
so there's no way to tell for certain.)
This fixes an issue where the passive side Accept() call fails
waiting for the RTU, but receives a DREQ instead.
Signed-off-by: Sean Hefty <sean.hefty@intel.com>
git-svn-id: svn://openib.tc.cornell.edu/gen1@2674 ad392aa1-c5ef-ae45-8dd8-e69d62a5ef86