Prior to this patch and the addition of the of the
smi_check_local_resp_smp() test, the only DR SMP that could have made
it to the device's process_mad call would have been a DR SMP Request
that was targeted to the local SMA. It is possible that the device's
SMA would not handle the DR SMP Request and that it would return only
IB_MAD_RESULT_SUCCESS; however in that case the find_mad_agent() call
would still access the un-initialized mad_priv->mad.mad. For
this reason I do not believe this code path was previously executed,
and I believe there will be no effect on the existing behavior.
Okay - the existing code is confusing me then. It looks buggy, and it
appears that your change ends up fixing the problem.
Hal, can you explain what the following code in handle_outgoing_dr_smp()
is doing?
case IB_MAD_RESULT_SUCCESS:
/* Treat like an incoming receive MAD */
port_priv = ib_get_mad_port(mad_agent_priv->agent.device,
mad_agent_priv->agent.port_num);
if (port_priv) {
mad_priv->mad.mad.mad_hdr.tid =
((struct ib_mad *)smp)->mad_hdr.tid;
recv_mad_agent = find_mad_agent(port_priv,
&mad_priv->mad.mad);
}
if (!port_priv || !recv_mad_agent) {
kmem_cache_free(ib_mad_cache, mad_priv);
kfree(local);
ret = 0;
goto out;
}
local->mad_priv = mad_priv;
local->recv_mad_agent = recv_mad_agent;
break;
- Sean
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
