Re: [PATCH] Fix: Remove racy Subnet Manager sendonly join checks

[Christoph Lameter <cl@xxxxxxxxx>]

On Tue, 9 Feb 2021, Jason Gunthorpe wrote:

> This one got spam filtered and didn't make it to the list:
>
> Received-SPF: SoftFail (hqemgatev14.nvidia.com: domain of
>         cl@xxxxxxxxx is inclined to not designate 3.19.106.255 as
>         permitted sender) identity=mailfrom; client-ip=3.19.106.255;
>         receiver=hqemgatev14.nvidia.com;
>         envelope-from="cl@xxxxxxxxx"; x-sender="cl@xxxxxxxxx";
>         x-conformance=spf_only; x-record-type="v=spf1"
>
> Also the extra From/Date/Subject ended up in the commit message

Yes the Linux Foundation guys are not willing to address this issue in any
way. I may have to give up my linux.com email address.

> I fixed it all up, applied to for-next

Thank you.

> It looks like OPA will also suffer this race (opa_pr_query_possible),
> maybe it is a little less likely since it will be driven by PR queries
> not broadcast joins.
>
> But the same logic is likely true there, I'd be surprised if OPA
> fabrics are not running a capable OPA SM at this point.

There is also another potentially racy check in there for OPA in regards
to the support of path records?

static bool ib_sa_opa_pathrecord_support(struct ib_sa_client *client,
                                         struct ib_sa_device *sa_dev,
                                         u8 port_num)
{
        struct ib_sa_port *port;
        unsigned long flags;
        bool ret = false;

        port = &sa_dev->port[port_num - sa_dev->start_port];
        spin_lock_irqsave(&port->classport_lock, flags);
        if (!port->classport_info.valid)
                goto ret;

        if (port->classport_info.data.type == RDMA_CLASS_PORT_INFO_OPA)
                ret = opa_get_cpi_capmask2(&port->classport_info.data.opa)
&
                        OPA_CLASS_PORT_INFO_PR_SUPPORT;
ret:
        spin_unlock_irqrestore(&port->classport_lock, flags);
        return ret;
}