On 5/15/25 16:44, Chuck Lever wrote:
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.
I _think_ you are expected to set the callbacks prior to do the tls
handshake upcall (at least, that's what I'm doing).
It's not that you can (nor should) receive anything on the socket
while the handshake is active.
If it fails you can always reset them to the original callbacks.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
