On 2/10/2021 4:31 AM, Christoph Lameter wrote:
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;
}
Thanks for pointing this out. We'll look into it.
-Denny
