[Openib-windows] SRP connection state

[Fabian Tillier]

Hi Yossi,

On 9/19/06, Yossi Leybovich <sleybo at mellanox.co.il> wrote:
> > -----Original Message-----
> > From: openib-windows-bounces at openib.org
> > [mailto:openib-windows-bounces at openib.org] On Behalf Of Fabian Tillier
> > Sent: Wednesday, September 20, 2006 12:35 AM
> >
> > Hi Yossi,
> >
> > On 9/14/06, Yossi Leybovich <sleybo at mellanox.co.il> wrote:
> > >
> > > Fab
> > >
> > > there are  few places in code that we write/read the
> > connection state.
> > > srp_rej_cb
> > > srp_dreq_cb
> > > srp_reply_cb
> > > srp_connect
> > >
> > > Shouldn't this field need to be protect by lock ?
> >
> > srp_connect will block until the connection establishment is
> > complete (success or failure).  It then reads the connection
> > state that was set by the various CM callbacks.
> >
> > The CM callbacks are serialized by the CM.  These set the
> > state.  The establishment (REP, RTU, REJ) also signals the
> > connection event to wake up srp_connect.
> >
>
> What about this scenario:
> While srp_connect(not CM callback) check the state the CM get
> srp_dreq_cb which change the state .

A lock around the state doesn't help here.  Say you did have a lock.
srp_connect would take the lock when it is woken up by a previous CM
REP callback (the only case where we could get a DREQ callback).  The
state check would find the connection state as SRP_CONNECTED, release
the lock, and return.  The DREP callback could take the lock as soon
as it is released, and change the state.

As you can see, a lock around the state doesn't help here at all.
That said, there needs to be some serialization between the entire
__srp_connect_sessions function and the DREQ callback so that the
session being connected isn't destroyed while still being accessed,
and especially before being stored in the HBA object's session array.

I'll work on this.

- Fab