linux-kernel - RE: [PATCH] infiniband: i40iw: replace atomic_add

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]

Date:   Tue, 1 Dec 2020 14:42:25 +0000
From:   "Saleem, Shiraz" <shiraz.saleem@...el.com>
To:     Yejune Deng <yejune.deng@...il.com>,
        "Latif, Faisal" <faisal.latif@...el.com>,
        "dledford@...hat.com" <dledford@...hat.com>,
        "jgg@...pe.ca" <jgg@...pe.ca>
CC:     "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] infiniband: i40iw: replace atomic_add_return()

> Subject: [PATCH] infiniband: i40iw: replace atomic_add_return()
> 
> atomic_inc_return() is a little neater
> 
> Signed-off-by: Yejune Deng <yejune.deng@...il.com>
> ---
>  drivers/infiniband/hw/i40iw/i40iw_cm.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/infiniband/hw/i40iw/i40iw_cm.c
> b/drivers/infiniband/hw/i40iw/i40iw_cm.c
> index 3053c345..26e92ae 100644
> --- a/drivers/infiniband/hw/i40iw/i40iw_cm.c
> +++ b/drivers/infiniband/hw/i40iw/i40iw_cm.c
> @@ -2426,7 +2426,7 @@ static void i40iw_handle_rst_pkt(struct i40iw_cm_node
> *cm_node,
>  		}
>  		break;
>  	case I40IW_CM_STATE_MPAREQ_RCVD:
> -		atomic_add_return(1, &cm_node->passive_state);
> +		atomic_inc_return(&cm_node->passive_state);

Just an atomic_inc would suffice here.

>  		break;
>  	case I40IW_CM_STATE_ESTABLISHED:
>  	case I40IW_CM_STATE_SYN_RCVD:
> @@ -3020,7 +3020,7 @@ static int i40iw_cm_reject(struct i40iw_cm_node
> *cm_node, const void *pdata, u8
>  	i40iw_cleanup_retrans_entry(cm_node);
> 
>  	if (!loopback) {
> -		passive_state = atomic_add_return(1, &cm_node->passive_state);
> +		passive_state = atomic_inc_return(&cm_node->passive_state);

Fine with it as its consistent across i40iw. But aren't there many more instances of this across the tree?
Isn't this a choice best left to the developer?