[ofa-general] [PATCH] Lock _do_madrpc for thread safety

[Hal Rosenstock]

Ira,

On 7/8/09, Ira Weiny <weiny2 at llnl.gov> wrote:
> Sasha,
>
> I am working on making libibnetdisc a parallel implementation.  As a result
> I
> have found that _do_madrpc is not thread safe.

Have you read Sasha's commit 51d25384626a7b4ba386c414ed56c647a7bf64df
from 12/26/08 ? In it, he states " I think that it will be more robust
for multithreaded
application to use its own synchronization methods (pthread mutex or any
other) for better control. "

> The following patch fixes
> this.  However, I don't know you want to do...
>
> If one only uses mad_rpc and mad_rpc_rmpp then the patch works.  However, if
> someone is using mad_send_via at the same time _do_madrpc will still fail.
> Is
> it by design that some responses will be lost while _do_madrpc is looking
> for
> it's response via the TID?
>
> Also, according to C13-18.1.1 and C13-19.1.1 you must use the SGID (or SLID)
> and the MgmtClass in addition to the TID to determine the uniqueness of a
> message.  The SGID (or SLID) is of course the same but should the MgmtClass
> be checked here as well?
>
> Finally, why does _do_madrpc cast the transaction id to a 32 bit value?

The kernel uses the high 32 bits for an agent ID. See kernel
Documentation/infiniband/user_mad.txt "Transaction IDs".

-- Hal

> Confused,
> Ira

<snip...>