On Fri, Jan 28, 2022 at 10:18:45AM -0600, Bob Pearson wrote:
> On 1/28/22 06:53, Jason Gunthorpe wrote:
> > On Thu, Jan 27, 2022 at 03:37:33PM -0600, Bob Pearson wrote:
> >> Add code to check if a QP is attached to one or more multicast groups
> >> when destroy_qp is called and return an error if so.
> >
> > The core code already does some of this anyhow..
> >
> >> diff --git a/drivers/infiniband/sw/rxe/rxe_mcast.c b/drivers/infiniband/sw/rxe/rxe_mcast.c
> >> index 949784198d80..34e3c52f0b72 100644
> >> +++ b/drivers/infiniband/sw/rxe/rxe_mcast.c
> >> @@ -114,6 +114,7 @@ static int rxe_mcast_add_grp_elem(struct rxe_dev *rxe, struct rxe_qp *qp,
> >> grp->num_qp++;
> >> elem->qp = qp;
> >> elem->grp = grp;
> >> + atomic_inc(&qp->mcg_num);
> >
> > eg what prevents qp from being concurrently destroyed here?
> >
> > The core code because it doesn't allow a multicast group to be added
> > concurrently with destruction of a QP.
> >
> >> +int rxe_qp_chk_destroy(struct rxe_qp *qp)
> >> +{
> >> + /* See IBA o10-2.2.3
> >> + * An attempt to destroy a QP while attached to a mcast group
> >> + * will fail immediately.
> >> + */
> >> + if (atomic_read(&qp->mcg_num)) {
> >> + pr_warn_once("Attempt to destroy QP while attached to multicast group\n");
> >> + return -EBUSY;
> >
> > Don't print
> >
> > But yes, I think drivers are expected to do this, though most likely
> > this is already happening for other reasons and this is mearly
> > protective against bugs.
> >
> > Jason
>
> The real reason for this patch becomes apparent in the next one or two. With this no longer an issue half the complexity of rxe_mcast goes away. I'll get rid of the print.
> Personally I find them helpful when debugging user code. Maybe a
> pr_debug?
Sure
Jason
