[ofa-general] [PATCH] infiniband/core: Enable loopback of DR SMP responses from userspace
Hal Rosenstock
hal.rosenstock at gmail.com
Wed Sep 5 13:56:47 PDT 2007
On 9/5/07, Sean Hefty <mshefty at ichips.intel.com> wrote:
> > 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?
If you are referring to why IB_MAD_RESULT_SUCCESS only (without REPLY
or CONSUMED) is treated like an incoming MAD, at this point,
unfortunately, I do not recall. As Sean pointed out, it does only
handle the outgoing case and not the returning case which is what he
is proposing to be added.
-- Hal
> 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
>
More information about the general
mailing list