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?
Bob
