> >>> @@ -679,9 +714,16 @@ static int mana_cfg_vport(struct > >>> mana_port_context *apc, u32 protection_dom_id, > >>> > >>> apc->tx_shortform_allowed = resp.short_form_allowed; > >>> apc->tx_vp_offset = resp.tx_vport_offset; > >>> + > >>> + netdev_info(apc->ndev, "Configured vPort %llu PD %u DB %u\n", > >>> + apc->port_handle, protection_dom_id, doorbell_pg_id); > >>> out: > >>> + if (err) > >>> + mana_uncfg_vport(apc); > >> > >> There seems to be a similar race between error handling here and the > >> "apc- > >>> vport_use_count > 0" checking above as pointed out in v7. > > > > Thanks for looking into this. > > > > This is different to the locking bug in mana_ib_cfg_vport(). The vport > > sharing between Ethernet and RDMA is exclusive, not shared. If another > > driver tries to take the vport while it is being configured, it will > > fail immediately. It is by > > Suppose the following steps: > 1. Ethernet driver take the lock first and do a "apc->vport_use_count++", > and > release the lock; > 2. RDMA driver take the lock, do "apc->vport_use_count > 0" checking and > return > -EBUSY; > 3. mana_send_request() or mana_verify_resp_hdr() return error to > Ethernet driver. > > It seems that vport is left unused when above happens, if that is what you > wanted? Yes, in this case the vport is left unused. There is no resource leak. This is expected. > > > > design to prevent possible deadlock. > > I am not sure I understand the deadlock here. Because we are dealing with two drivers. I don't want to block as mana_send_request() is a blocking call.
