On Mon, Oct 05, 2026, [email protected] wrote: > > + if (++nodata >= TLS_RX_NODATA_LIMIT) { > > + /* tls_rx_reader_release() calls > > + * saved_data_ready(), not the callback a > > + * consumer installs after the handshake. > > + */ > > + sk->sk_data_ready(sk); > > [Severity: High] > Can this direct call to sk->sk_data_ready() re-enter tls_sw_read_sock() > and deadlock on sk_lock.slock?
Yes. kcm_attach() accepts a TCP socket that already has TLS_RX set up, and strp_data_ready() calls strp_read_sock() directly when the socket is not owned by user. From softirq, the nested tls_sw_read_sock() finds reader_present set, and sk_wait_event() calls release_sock() before it looks at the zero timeout. I have not reproduced the deadlock. Making the call after tls_rx_reader_release() does not fix it. The nested call then acquires the reader, consumes its own 16 empty records, and recurses again, so the depth is set by the peer. The notification has to leave the reader's call chain. I'll rework it for v3. > [Severity: Low] > Should this be READ_ONCE(sk->sk_data_ready)(sk), as the TCP call sites > use? The direct call goes away with the rework above. pw-bot: cr -- Chuck Lever (Come to NFS bake-a-thon! https://nfsv4bat.org)
