linux-kernel - Re: [PATCH] RDMA/cm: fix cond_no

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220624201733.GA284068@nvidia.com>
Date:   Fri, 24 Jun 2022 17:17:33 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Mark Zhang <markzhang@...dia.com>
Cc:     Jiapeng Chong <jiapeng.chong@...ux.alibaba.com>, leon@...nel.org,
        linux-rdma@...r.kernel.org, linux-kernel@...r.kernel.org,
        Abaci Robot <abaci@...ux.alibaba.com>
Subject: Re: [PATCH] RDMA/cm: fix cond_no_effect.cocci warnings

On Tue, Jun 14, 2022 at 09:19:14AM +0800, Mark Zhang wrote:
> On 6/10/2022 5:45 PM, Jiapeng Chong wrote:
> > This was found by coccicheck:
> > 
> > ./drivers/infiniband/core/cm.c:685:7-9: WARNING: possible condition with no effect (if == else).
> > 
> > Reported-by: Abaci Robot <abaci@...ux.alibaba.com>
> > Signed-off-by: Jiapeng Chong <jiapeng.chong@...ux.alibaba.com>
> > ---
> >   drivers/infiniband/core/cm.c | 9 ++-------
> >   1 file changed, 2 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
> > index 1c107d6d03b9..bb6a2b6b9657 100644
> > --- a/drivers/infiniband/core/cm.c
> > +++ b/drivers/infiniband/core/cm.c
> > @@ -676,14 +676,9 @@ static struct cm_id_private *cm_find_listen(struct ib_device *device,
> >   			refcount_inc(&cm_id_priv->refcount);
> >   			return cm_id_priv;
> >   		}
> > -		if (device < cm_id_priv->id.device)
> > +		if (device < cm_id_priv->id.device ||
> > +		    be64_lt(service_id, cm_id_priv->id.service_id))
> >   			node = node->rb_left;
> > -		else if (device > cm_id_priv->id.device)
> > -			node = node->rb_right;
> > -		else if (be64_lt(service_id, cm_id_priv->id.service_id))
> > -			node = node->rb_left;
> > -		else if (be64_gt(service_id, cm_id_priv->id.service_id))
> > -			node = node->rb_right;
> >   		else
> >   			node = node->rb_right;
> >   	}
> 
> Not sure if the fix is correct, e.g. with this condition:
>   device > cm_id_priv->id.device &&
>   be64_lt(service_id, cm_id_priv->id.service_id)
> 
> The original code gets rb_right but this fix gets rb_left. Maybe the warning
> is complain about this:
> 	...
> 	else if (be64_gt(service_id, cm_id_priv->id.service_id))
> 		node = node->rb_right;
> 	else
> 		node = node->rb_right;
> 
> Besides cm_insert_listen() has same logic.

Yes, this is a standard pattern for walking tree with priority, we
should not obfuscate it.

The final else means 'equal' and the first if should ideally be placed
there

However this function is complicated by the use of the service_mask
for equality checking, and it doesn't even work right if the
service_mask is not -1.

If someone wants to clean this then please go through and eliminate
service_mask completely. From what I can see its value is always -1.
Three patches:
 - Remove the service_mask parameter from ib_cm_listen(), all callers
   use 0
 - Remove the service_mask parameter from cm_init_listen(), all
   callers use 0. Inspect and remove cm_id_priv->id.service_mask,
   it is the constant value  ~cpu_to_be64(0) which is a NOP when &'d
 - Move the test at the top of cm_find_listen() into the final else

Jason