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: <05586fa4-308b-4a13-a5f7-0c93ec3760a5@linux.ibm.com>
Date: Fri, 22 Nov 2024 17:17:00 +0100
From: Alexandra Winter <wintera@...ux.ibm.com>
To: Wen Gu <guwen@...ux.alibaba.com>, wenjia@...ux.ibm.com, jaka@...ux.ibm.com,
        davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
        pabeni@...hat.com
Cc: alibuda@...ux.alibaba.com, tonylu@...ux.alibaba.com, horms@...nel.org,
        linux-rdma@...r.kernel.org, linux-s390@...r.kernel.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net 1/2] net/smc: initialize close_work early to avoid
 warning



On 22.11.24 08:16, Wen Gu wrote:
> We encountered a warning that close_work was canceled before
> initialization.
> 
>   WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0
>   Workqueue: events smc_lgr_terminate_work [smc]
>   RIP: 0010:__flush_work+0x19e/0x1b0
>   Call Trace:
>    ? __wake_up_common+0x7a/0x190
>    ? work_busy+0x80/0x80
>    __cancel_work_timer+0xe3/0x160
>    smc_close_cancel_work+0x1a/0x70 [smc]
>    smc_close_active_abort+0x207/0x360 [smc]
>    __smc_lgr_terminate.part.38+0xc8/0x180 [smc]
>    process_one_work+0x19e/0x340
>    worker_thread+0x30/0x370
>    ? process_one_work+0x340/0x340
>    kthread+0x117/0x130
>    ? __kthread_cancel_work+0x50/0x50
>    ret_from_fork+0x22/0x30
> 
> This is because when smc_close_cancel_work is triggered, e.g. the RDMA
> driver is rmmod and the LGR is terminated, the conn->close_work is
> flushed before initialization, resulting in WARN_ON(!work->func).
> 
> __smc_lgr_terminate             | smc_connect_{rdma|ism}
> -------------------------------------------------------------
>                                 | smc_conn_create
> 				| \- smc_lgr_register_conn
> for conn in lgr->conns_all      |
> \- smc_conn_kill                |
>    \- smc_close_active_abort    |
>       \- smc_close_cancel_work  |
>          \- cancel_work_sync    |
>             \- __flush_work     |
> 	         (close_work)   |
> 	                        | smc_close_init
> 	                        | \- INIT_WORK(&close_work)
> 
> So fix this by initializing close_work before establishing the
> connection.
> 
> Fixes: 46c28dbd4c23 ("net/smc: no socket state changes in tasklet context")
> Fixes: 413498440e30 ("net/smc: add SMC-D support in af_smc")
> Signed-off-by: Wen Gu <guwen@...ux.alibaba.com>
> ---
>  net/smc/af_smc.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
> index 9d76e902fd77..ed6d4d520bc7 100644
> --- a/net/smc/af_smc.c
> +++ b/net/smc/af_smc.c
> @@ -383,6 +383,7 @@ void smc_sk_init(struct net *net, struct sock *sk, int protocol)
>  	smc->limit_smc_hs = net->smc.limit_smc_hs;
>  	smc->use_fallback = false; /* assume rdma capability first */
>  	smc->fallback_rsn = 0;
> +	smc_close_init(smc);
>  }
>  
>  static struct sock *smc_sock_alloc(struct net *net, struct socket *sock,
> @@ -1299,7 +1300,6 @@ static int smc_connect_rdma(struct smc_sock *smc,
>  		goto connect_abort;
>  	}
>  
> -	smc_close_init(smc);
>  	smc_rx_init(smc);
>  
>  	if (ini->first_contact_local) {
> @@ -1435,7 +1435,6 @@ static int smc_connect_ism(struct smc_sock *smc,
>  			goto connect_abort;
>  		}
>  	}
> -	smc_close_init(smc);
>  	smc_rx_init(smc);
>  	smc_tx_init(smc);
>  
> @@ -2479,7 +2478,6 @@ static void smc_listen_work(struct work_struct *work)
>  		goto out_decl;
>  
>  	mutex_lock(&smc_server_lgr_pending);
> -	smc_close_init(new_smc);
>  	smc_rx_init(new_smc);
>  	smc_tx_init(new_smc);
>  


Thank you for the very good commit message. Makes sense to me.

Reviewed-by: Alexandra Winter <wintera@...ux.ibm.com>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ