| Message ID | 1640704432-76825-2-git-send-email-guwen@linux.alibaba.com (mailing list archive) |
|---|---|
| State | RFC |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | net/smc: Fix for race in smc link group termination | expand |
On 28/12/2021 16:13, Wen Gu wrote: > We encountered some crashes caused by the race between the access > and the termination of link groups. While I agree with the problems you found I am not sure if the solution is the right one. At the moment conn->lgr is checked all over the code as indication if a connection still has a valid link group. When you change this semantic by leaving conn->lgr set after the connection was unregistered from its link group then I expect various new problems to happen. For me the right solution would be to use correct locking before conn->lgr is checked and used. In smc_lgr_unregister_conn() the lgr->conns_lock is used when conn->lgr is unset (note that it is better to have that "conn->lgr = NULL;" line INSIDE the lock in this function). And on any places in the code where conn->lgr is used you get the read_lock while lgr is accessed. This could solve the problem, using existing mechanisms, right? Opinions?
Hi Karsten, Thanks for your suggestions. Wish you and your family a happy New Year! On 2021/12/29 8:56 pm, Karsten Graul wrote: > On 28/12/2021 16:13, Wen Gu wrote: >> We encountered some crashes caused by the race between the access >> and the termination of link groups. > > While I agree with the problems you found I am not sure if the solution is the right one. > At the moment conn->lgr is checked all over the code as indication if a connection > still has a valid link group. When you change this semantic by leaving conn->lgr set > after the connection was unregistered from its link group then I expect various new problems > to happen. Actually we also thought about this semantic mismatch problem. But we haven't encountered any problems caused by leaving conn->lgr set in our tests. After careful consideration, we chose to use this patch as a trade off against the more serious problems -- the crashes in mutliple places caused by abnormal termination. If any specific problems caused by leaving conn->lgr set can be expected, please inform us. Thanks. > > For me the right solution would be to use correct locking before conn->lgr is checked and used. > In my humble opinion, the key point is not avoiding access to a NULL pointer (conn->lgr) by checking it before, but avoiding access link group after it is freed, which becomes a piece of dirty memory. This patch focuses on how to ensure the safe access to link group, which is from conn->lgr or link->lgr. > In smc_lgr_unregister_conn() the lgr->conns_lock is used when conn->lgr is unset (note that > it is better to have that "conn->lgr = NULL;" line INSIDE the lock in this function). > I think lgr->conns_lock is used to make the read and modify to lgr->conns_all mutually exclusive. As mentioned above, we are aimed to avoid access link group after it is freed. It might be inappropriate to avoid access to a freed lgr by lgr->conns_lock. > And on any places in the code where conn->lgr is used you get the read_lock while lgr is accessed. > This could solve the problem, using existing mechanisms, right? Opinions? We also considered to protect the access to link group by locking at the beginning as you suggested, like RCU. But we found some imperfections of this way. 1) It is hard to cover all the race. link group is referred to all over the code and link group termination may be triggered at any time. So it is hard to find all the exact potential race code and protected each one respectively by locking. The discover of race code will rely heavily on testing and we may have to continuously add patches to fix each new race we find. 2) It is hard to hold lock during all the link group access. Only checking conn->lgr before accessing to link group is not safe even with correct locking. Even though conn->lgr is checked, link group may have been freed during the following access. access termination ----------------------------------------------------------- if (conn->lgr) | | kfree(lgr) access to lgr (undesired) | To ensure link group access safe, we need to hold the lock before every link group access and not put until link group access finishes, it will cover too much codes and we need to pay attention to the behavior in the lock-holding section. So we chose to use reference count and consider this issue from a life cycle perspective. Introducing reference count can overcome the imperfections mentioned above by: 1) Prolonging the life cycle of link group. Instead of finding all the race, the main idea of the patch is to prolong the life cycle of link group, making it longer than the access cycle of connections and links over the link group. So even link group is being terminated, the free of link group is later than all the access to it. We think the access cycle to link group of connections is from smc_lgr_register_conn() to smc_conn_free() and the access cycle to link group of links is from smcr_link_init() to smcr_link_clear(). 2) Introducing reference count. Instead of using lock, we use reference count to ensure link group is freed only when no one refers to it. No need to find every place which needs holding lock and pay attention to the behavior in lock-holding sections. What do you think about it? Thanks, Wen Gu
On 31/12/2021 10:44, Wen Gu wrote: > On 2021/12/29 8:56 pm, Karsten Graul wrote: >> On 28/12/2021 16:13, Wen Gu wrote: >>> We encountered some crashes caused by the race between the access >>> and the termination of link groups. > What do you think about it? > Hi Wen, thank you, and I also wish you and your family a happy New Year! Thanks for your detailed explanation, you convinced me of your idea to use a reference counting! I think its a good solution for the various problems you describe. I am still thinking that even if you saw no problems when conn->lgr is not NULL when the lgr is already terminated there should be more attention on the places where conn->lgr is checked. For example, in smc_cdc_get_slot_and_msg_send() there is a check for !conn->lgr with the intention to avoid working with a terminated link group. Should all checks for !conn->lgr be now replaced by the check for conn->freed ?? Does this make sense?
Thanks for your reply. On 2022/1/3 6:36 pm, Karsten Graul wrote: > On 31/12/2021 10:44, Wen Gu wrote: >> On 2021/12/29 8:56 pm, Karsten Graul wrote: >>> On 28/12/2021 16:13, Wen Gu wrote: >>>> We encountered some crashes caused by the race between the access >>>> and the termination of link groups. >> What do you think about it? >> > > Hi Wen, > > thank you, and I also wish you and your family a happy New Year! > > Thanks for your detailed explanation, you convinced me of your idea to use > a reference counting! I think its a good solution for the various problems you describe. > > I am still thinking that even if you saw no problems when conn->lgr is not NULL when the lgr > is already terminated there should be more attention on the places where conn->lgr is checked. Thank you for reminding. I agree with the concern. It should be improved to avoid the potential issue we haven't found. > For example, in smc_cdc_get_slot_and_msg_send() there is a check for !conn->lgr with the intention > to avoid working with a terminated link group. > Should all checks for !conn->lgr be now replaced by the check for conn->freed ?? Does this make sense? In my humble opinion, we can replace !conn->lgr with !conn->alert_token_local. If a smc connection is registered to a link group successfully by smc_lgr_register_conn(), conn->alert_token_local is set to non-zero. At this moment, the conn->lgr is ready to be used. And if the link group is terminated, conn->alert_token_local is reset to zero in smc_lgr_unregister_conn(), meaning that the link group registered to connection shouldn't be used anymore. So I think checking conn->alert_token_local has the same effect with checking conn->lgr to identify whether the link group pointed by conn->lgr is still healthy and able to be used. What do you think about it? :) Thanks, Wen Gu
On 05/01/2022 09:27, Wen Gu wrote: > On 2022/1/3 6:36 pm, Karsten Graul wrote: >> On 31/12/2021 10:44, Wen Gu wrote: >>> On 2021/12/29 8:56 pm, Karsten Graul wrote: >>>> On 28/12/2021 16:13, Wen Gu wrote: >>>>> We encountered some crashes caused by the race between the access >>>>> and the termination of link groups. > So I think checking conn->alert_token_local has the same effect with checking conn->lgr to > identify whether the link group pointed by conn->lgr is still healthy and able to be used. Yeah that sounds like a good solution for that! So is it now guaranteed that conn->lgr is always set and this check can really be removed completely, or should there be a new helper that checks conn->lgr and the alert_token, like smc_lgr_valid() ?
Thanks for your reply. On 2022/1/5 8:03 pm, Karsten Graul wrote: > On 05/01/2022 09:27, Wen Gu wrote: >> On 2022/1/3 6:36 pm, Karsten Graul wrote: >>> On 31/12/2021 10:44, Wen Gu wrote: >>>> On 2021/12/29 8:56 pm, Karsten Graul wrote: >>>>> On 28/12/2021 16:13, Wen Gu wrote: >>>>>> We encountered some crashes caused by the race between the access >>>>>> and the termination of link groups. >> So I think checking conn->alert_token_local has the same effect with checking conn->lgr to >> identify whether the link group pointed by conn->lgr is still healthy and able to be used. > > Yeah that sounds like a good solution for that! So is it now guaranteed that conn->lgr is always > set and this check can really be removed completely, or should there be a new helper that checks > conn->lgr and the alert_token, like smc_lgr_valid() ? In my humble opinion, the link group pointed by conn->lgr might have the following three stages if we remove 'conn->lgr = NULL' from smc_lgr_unregister_conn(). 1. conn->lgr = NULL and conn->alert_token_local is zero This means that the connection has never been registered in a link group. conn->lgr is clearly unable to use. 2. conn->lgr != NULL and conn->alert_token_local is non-zero This means that the connection has been registered in a link group, and conn->lgr is valid to access. 3. conn->lgr != NULL but conn->alert_token_local is zero This means that the connection was registered in a link group before, but is unregistered from it now. conn->lgr shouldn't be used anymore. So I am trying this way: 1) Introduce a new helper smc_conn_lgr_state() to check the three stages mentioned above. enum smc_conn_lgr_state { SMC_CONN_LGR_ORPHAN, /* conn was never registered in a link group */ SMC_CONN_LGR_VALID, /* conn is registered in a link group now */ SMC_CONN_LGR_INVALID, /* conn was registered in a link group, but now is unregistered from it and conn->lgr should not be used any more */ }; 2) replace the current conn->lgr check with the new helper. These new changes are under testing now. What do you think about it? :) Thanks, Wen Gu
On 06/01/2022 14:02, Wen Gu wrote: > Thanks for your reply. > > On 2022/1/5 8:03 pm, Karsten Graul wrote: >> On 05/01/2022 09:27, Wen Gu wrote: >>> On 2022/1/3 6:36 pm, Karsten Graul wrote: >>>> On 31/12/2021 10:44, Wen Gu wrote: >>>>> On 2021/12/29 8:56 pm, Karsten Graul wrote: >>>>>> On 28/12/2021 16:13, Wen Gu wrote: >>>>>>> We encountered some crashes caused by the race between the access >>>>>>> and the termination of link groups. > So I am trying this way: > > 1) Introduce a new helper smc_conn_lgr_state() to check the three stages mentioned above. > > enum smc_conn_lgr_state { > SMC_CONN_LGR_ORPHAN, /* conn was never registered in a link group */ > SMC_CONN_LGR_VALID, /* conn is registered in a link group now */ > SMC_CONN_LGR_INVALID, /* conn was registered in a link group, but now > is unregistered from it and conn->lgr should > not be used any more */ > }; > > 2) replace the current conn->lgr check with the new helper. > > These new changes are under testing now. > > What do you think about it? :) Sounds good, but is it really needed to separate 3 cases, i.e. who is really using them 3? Doesn't it come down to a more simple smc_conn_lgr_valid() which is easier to implement in the various places in the code? (i.e.: if (smc_conn_lgr_valid()) ....) Valid would mean conn->lgr != NULL and conn->alert_token_local != 0. The more special cases would check what they want by there own.
Thanks for your reply. On 2022/1/7 5:54 pm, Karsten Graul wrote: > On 06/01/2022 14:02, Wen Gu wrote: >> Thanks for your reply. >> >> On 2022/1/5 8:03 pm, Karsten Graul wrote: >>> On 05/01/2022 09:27, Wen Gu wrote: >>>> On 2022/1/3 6:36 pm, Karsten Graul wrote: >>>>> On 31/12/2021 10:44, Wen Gu wrote: >>>>>> On 2021/12/29 8:56 pm, Karsten Graul wrote: >>>>>>> On 28/12/2021 16:13, Wen Gu wrote: >>>>>>>> We encountered some crashes caused by the race between the access >>>>>>>> and the termination of link groups. >> So I am trying this way: >> >> 1) Introduce a new helper smc_conn_lgr_state() to check the three stages mentioned above. >> >> enum smc_conn_lgr_state { >> SMC_CONN_LGR_ORPHAN, /* conn was never registered in a link group */ >> SMC_CONN_LGR_VALID, /* conn is registered in a link group now */ >> SMC_CONN_LGR_INVALID, /* conn was registered in a link group, but now >> is unregistered from it and conn->lgr should >> not be used any more */ >> }; > > Sounds good, but is it really needed to separate 3 cases, i.e. who is really using them 3? > Doesn't it come down to a more simple smc_conn_lgr_valid() which is easier to implement in > the various places in the code? (i.e.: if (smc_conn_lgr_valid()) ....) > Valid would mean conn->lgr != NULL and conn->alert_token_local != 0. The more special cases > would check what they want by there own. Yes, Most of the time we only need to check whether conn->lgr is in SMC_CONN_LGR_VALID. Only in smc_conn_free() we need to identify whether conn->lgr is in SMC_CONN_LGR_ORPHAN (need a directly return) or SMC_CONN_LGR_INVALID (put link group refcnt and then return). So I agree with only checking whether conn->lgr is valid with a more simple smc_conn_lgr_valid(). And distinguish SMC_CONN_LGR_ORPHAN and SMC_CONN_LGR_INVALID cases by additional check for conn->lgr. Thanks, Wen Gu
diff --git a/net/smc/smc.h b/net/smc/smc.h index 1a4fc1c..3d0b8e3 100644 --- a/net/smc/smc.h +++ b/net/smc/smc.h @@ -221,6 +221,7 @@ struct smc_connection { */ u64 peer_token; /* SMC-D token of peer */ u8 killed : 1; /* abnormal termination */ + u8 freed : 1; /* normal termiation */ u8 out_of_sync : 1; /* out of sync with peer */ }; diff --git a/net/smc/smc_core.c b/net/smc/smc_core.c index 1f40b8e..d72eb13 100644 --- a/net/smc/smc_core.c +++ b/net/smc/smc_core.c @@ -184,6 +184,7 @@ static int smc_lgr_register_conn(struct smc_connection *conn, bool first) conn->alert_token_local = 0; } smc_lgr_add_alert_token(conn); + smc_lgr_hold(conn->lgr); /* lgr_put in smc_conn_free() */ conn->lgr->conns_num++; return 0; } @@ -216,7 +217,6 @@ static void smc_lgr_unregister_conn(struct smc_connection *conn) __smc_lgr_unregister_conn(conn); } write_unlock_bh(&lgr->conns_lock); - conn->lgr = NULL; } int smc_nl_get_sys_info(struct sk_buff *skb, struct netlink_callback *cb) @@ -749,6 +749,7 @@ int smcr_link_init(struct smc_link_group *lgr, struct smc_link *lnk, lnk->path_mtu = lnk->smcibdev->pattr[lnk->ibport - 1].active_mtu; lnk->link_id = smcr_next_link_id(lgr); lnk->lgr = lgr; + smc_lgr_hold(lgr); /* lgr_put in smcr_link_clear() */ lnk->link_idx = link_idx; smc_ibdev_cnt_inc(lnk); smcr_copy_dev_info_to_link(lnk); @@ -841,6 +842,7 @@ static int smc_lgr_create(struct smc_sock *smc, struct smc_init_info *ini) lgr->terminating = 0; lgr->freeing = 0; lgr->vlan_id = ini->vlan_id; + refcount_set(&lgr->refcnt, 1); /* set lgr refcnt to 1 */ mutex_init(&lgr->sndbufs_lock); mutex_init(&lgr->rmbs_lock); rwlock_init(&lgr->conns_lock); @@ -1120,8 +1122,20 @@ void smc_conn_free(struct smc_connection *conn) { struct smc_link_group *lgr = conn->lgr; - if (!lgr) + if (!lgr || conn->freed) + /* smc connection wasn't registered to a link group + * or has already been freed before. + * + * Judge these to ensure that lgr refcnt will be put + * only once if connection has been registered to a + * link group successfully. + */ return; + + conn->freed = 1; + if (conn->killed) + goto lgr_put; + if (lgr->is_smcd) { if (!list_empty(&lgr->list)) smc_ism_unset_conn(conn); @@ -1138,6 +1152,8 @@ void smc_conn_free(struct smc_connection *conn) if (!lgr->conns_num) smc_lgr_schedule_free_work(lgr); +lgr_put: + smc_lgr_put(lgr); /* lgr_hold in smc_lgr_register_conn() */ } /* unregister a link from a buf_desc */ @@ -1209,6 +1225,7 @@ void smcr_link_clear(struct smc_link *lnk, bool log) smc_ib_destroy_queue_pair(lnk); smc_ib_dealloc_protection_domain(lnk); smc_wr_free_link_mem(lnk); + smc_lgr_put(lnk->lgr); /* lgr_hold in smcr_link_init() */ smc_ibdev_cnt_dec(lnk); put_device(&lnk->smcibdev->ibdev->dev); smcibdev = lnk->smcibdev; @@ -1283,6 +1300,15 @@ static void smc_lgr_free_bufs(struct smc_link_group *lgr) __smc_lgr_free_bufs(lgr, true); } +/* won't be freed until no one accesses to lgr anymore */ +static void __smc_lgr_free(struct smc_link_group *lgr) +{ + smc_lgr_free_bufs(lgr); + if (!lgr->is_smcd) + smc_wr_free_lgr_mem(lgr); + kfree(lgr); +} + /* remove a link group */ static void smc_lgr_free(struct smc_link_group *lgr) { @@ -1298,7 +1324,6 @@ static void smc_lgr_free(struct smc_link_group *lgr) smc_llc_lgr_clear(lgr); } - smc_lgr_free_bufs(lgr); destroy_workqueue(lgr->tx_wq); if (lgr->is_smcd) { smc_ism_put_vlan(lgr->smcd, lgr->vlan_id); @@ -1306,11 +1331,21 @@ static void smc_lgr_free(struct smc_link_group *lgr) if (!atomic_dec_return(&lgr->smcd->lgr_cnt)) wake_up(&lgr->smcd->lgrs_deleted); } else { - smc_wr_free_lgr_mem(lgr); if (!atomic_dec_return(&lgr_cnt)) wake_up(&lgrs_deleted); } - kfree(lgr); + smc_lgr_put(lgr); /* theoretically last lgr_put */ +} + +void smc_lgr_hold(struct smc_link_group *lgr) +{ + refcount_inc(&lgr->refcnt); +} + +void smc_lgr_put(struct smc_link_group *lgr) +{ + if (refcount_dec_and_test(&lgr->refcnt)) + __smc_lgr_free(lgr); } static void smc_sk_wake_ups(struct smc_sock *smc) diff --git a/net/smc/smc_core.h b/net/smc/smc_core.h index d63b082..51203b1 100644 --- a/net/smc/smc_core.h +++ b/net/smc/smc_core.h @@ -249,6 +249,7 @@ struct smc_link_group { u8 terminating : 1;/* lgr is terminating */ u8 freeing : 1; /* lgr is being freed */ + refcount_t refcnt; /* lgr reference count */ bool is_smcd; /* SMC-R or SMC-D */ u8 smc_version; u8 negotiated_eid[SMC_MAX_EID_LEN]; @@ -470,6 +471,8 @@ static inline void smc_set_pci_values(struct pci_dev *pci_dev, void smc_lgr_cleanup_early(struct smc_connection *conn); void smc_lgr_terminate_sched(struct smc_link_group *lgr); +void smc_lgr_hold(struct smc_link_group *lgr); +void smc_lgr_put(struct smc_link_group *lgr); void smcr_port_add(struct smc_ib_device *smcibdev, u8 ibport); void smcr_port_err(struct smc_ib_device *smcibdev, u8 ibport); void smc_smcd_terminate(struct smcd_dev *dev, u64 peer_gid,
We encountered some crashes caused by the race between the access and the termination of link groups. Here are some of panic stacks we met: 1) Race between smc_clc_wait_msg() and __smc_lgr_terminate() BUG: kernel NULL pointer dereference, address: 00000000000002f0 Workqueue: smc_hs_wq smc_listen_work [smc] RIP: 0010:smc_clc_wait_msg+0x3eb/0x5c0 [smc] Call Trace: <TASK> ? smc_clc_send_accept+0x45/0xa0 [smc] ? smc_clc_send_accept+0x45/0xa0 [smc] smc_listen_work+0x783/0x1220 [smc] ? finish_task_switch+0xc4/0x2e0 ? process_one_work+0x1ad/0x3c0 process_one_work+0x1ad/0x3c0 worker_thread+0x4c/0x390 ? rescuer_thread+0x320/0x320 kthread+0x149/0x190 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x1f/0x30 </TASK> smc_listen_work() abnormal case like port error --------------------------------------------------------------- | __smc_lgr_terminate() | |- smc_conn_kill() | |- smc_lgr_unregister_conn() | |- set conn->lgr = NULL smc_clc_wait_msg() | |- access conn->lgr (panic) | 2) Race between smc_setsockopt() and __smc_lgr_terminate() BUG: kernel NULL pointer dereference, address: 00000000000002e8 RIP: 0010:smc_setsockopt+0x17a/0x280 [smc] Call Trace: <TASK> __sys_setsockopt+0xfc/0x190 __x64_sys_setsockopt+0x20/0x30 do_syscall_64+0x34/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae </TASK> smc_setsockopt() abnormal case like port error -------------------------------------------------------------- | __smc_lgr_terminate() | |- smc_conn_kill() | |- smc_lgr_unregister_conn() | |- set conn->lgr = NULL mod_delayed_work() | |- access conn->lgr (panic) | There are some other panic points and they are caused by the simmilar reason as described above, which is accessing link group after termination, thus getting a NULL pointer or invalid resource. Currently, there seems to be no synchronization between the link group access and a sudden termination of it. This patch tries to fix this by introducing reference count of link group and not freeing link group until reference count is zero. Link group might be referred to by link or smc connection. So the operation to the link group reference count can be concluded as follows: object [hold or initialized as 1] [put] -------------------------------------------------------------------- link group smc_lgr_create() smc_lgr_free() connections smc_lgr_register_conn() smc_conn_free() links smcr_link_init() smcr_link_clear() Througth this way, we extend the life cycle of link group and ensure it is longer than the life cycle of connections and links above it, so that avoid invalid access to link group after its termination. Signed-off-by: Wen Gu <guwen@linux.alibaba.com> --- net/smc/smc.h | 1 + net/smc/smc_core.c | 45 ++++++++++++++++++++++++++++++++++++++++----- net/smc/smc_core.h | 3 +++ 3 files changed, 44 insertions(+), 5 deletions(-)