On Tue, 22 Sep 2020 23:14:59 +0530 Rohit Maheshwari wrote:
> Since driver first return success to tls_dev_add, if req to HW is
> successful, but later if HW returns failure, that connection traffic
> fails permanently and connection status remains unknown to stack.
>
> Fixes: 34aba2c45024 ("cxgb4/chcr : Register to tls add and del callback")
> Signed-off-by: Rohit Maheshwari <roh...@chelsio.com>
> #if IS_ENABLED(CONFIG_IPV6)
> } else {
> - if (!sk->sk_ipv6only &&
> - ipv6_addr_type(&sk->sk_v6_daddr) == IPV6_ADDR_MAPPED) {
> - tx_info->ip_family = AF_INET;
> - ret = chcr_ktls_act_open_req(sk, tx_info, atid);
> - } else {
> - tx_info->ip_family = AF_INET6;
> - ret = cxgb4_clip_get(tx_info->netdev,
> - (const u32 *)
> - &sk->sk_v6_rcv_saddr.s6_addr,
> - 1);
> - if (ret)
> - goto out;
> - ret = chcr_ktls_act_open_req6(sk, tx_info, atid);
> - }
> + ret = cxgb4_clip_get(tx_info->netdev, (const u32 *)
> + &sk->sk_v6_rcv_saddr,
> + 1);
> + if (ret)
> + return ret;
> + ret = chcr_ktls_act_open_req6(sk, tx_info, atid);
You removed the mapped socket handling which seems unrelated to the
rest of the patch.
> + spin_lock(&tx_info->lock);
> + tx_info->conn_up = true;
> + spin_unlock(&tx_info->lock);
What's the context this lock is taken in? You seem to always do only
spin_lock(), does the control path not need to be _bh() or _irq()?
