Resending with linux-nfs and kernel-tls-handshake on Cc On 5/15/25 10:35 AM, Chuck Lever wrote: > Hi - > > I'm troubleshooting an issue where, after a successful handshake, the > kernel TLS socket's data_ready callback is never invoked. I'm able to > reproduce this 100% on an Atom-based system with a Realtek Ethernet > device. But on many other systems, the problem is intermittent or not > reproducible. > > The problem seems to be that strp->msg_ready is already set when > tls_data_ready is called, and that prevents any further processing. I > see that msg_ready is set when the handshake daemon sets the ktls > security parameters, and is then never cleared. > > function: tls_setsockopt > function: do_tls_setsockopt_conf > function: tls_set_device_offload_rx > function: tls_set_sw_offload > function: init_prot_info > function: tls_strp_init > function: tls_sw_strparser_arm > function: tls_strp_check_rcv > function: tls_strp_read_sock > function: tls_strp_load_anchor_with_queue > function: tls_rx_msg_size > function: tls_device_rx_resync_new_rec > function: tls_rx_msg_ready > > For a working system (a VMware guest using a VMXNet device), setsockopt > leaves msg_ready set to zero: > > function: tls_setsockopt > function: do_tls_setsockopt_conf > function: tls_set_device_offload_rx > function: tls_set_sw_offload > function: init_prot_info > function: tls_strp_init > function: tls_sw_strparser_arm > function: tls_strp_check_rcv > > The first tls_data_ready call then handles the waiting ingress data as > expected. > > Any advice is appreciated. > -- Chuck Lever
