[Severity: High]
Is this comment accurate? tls_rx_reader_release() begins by calling
tls_rx_msg_maybe_announce(). That function calls the consumer's callback
synchronously, and reader_present is still set when it does:
The comment is wrong, and so is the claim in the patch description
that records left queued raise no sk_data_ready(). Since commit
22f8bf8808dc ("tls: Suppress spurious saved_data_ready on all receive
paths"), tls_rx_reader_release() announces a record that was parsed
but not delivered, and that is the state the new break leaves behind.
The work item adds no value: when no record is parsed at the break,
the next TCP segment or the strparser's own work item raises the
notification. v4 will drop the work item and correct the comment.
Can this self-deadlock on sk_lock.slock, which this CPU already holds
through bh_lock_sock()?
Only with KCM attached under TLS, and that pairing does not work
today: tls_sw_read_sock() reaches sk_flush_backlog(), which takes
sk_lock.slock. The release-time announce already fires on the other
read_sock exits, so the break does not add a new path.
[Severity: Low]
schedule_work() queues this on system_wq, which lacks WQ_MEM_RECLAIM.
Moot once the work item is gone.
pw-bot: cr
--
Chuck Lever (Come to NFS bake-a-thon! https://nfsv4bat.org)