Activity log for bug #1889625

Date Who What changed Old value New value Message
2020-07-30 13:48:05 Amir Tzin bug added bug
2020-07-30 14:00:08 Ubuntu Kernel Bot linux (Ubuntu): status New Incomplete
2020-07-30 21:03:09 Jeff Lane  linux (Ubuntu): status Incomplete In Progress
2020-07-30 21:03:12 Jeff Lane  linux (Ubuntu): importance Undecided Medium
2020-07-30 21:03:14 Jeff Lane  linux (Ubuntu): assignee Jeff Lane (bladernr)
2020-07-30 21:04:45 Jeff Lane  nominated for series Ubuntu Focal
2020-07-30 21:04:45 Jeff Lane  bug task added linux (Ubuntu Focal)
2020-07-30 21:40:08 Jeff Lane  linux (Ubuntu Focal): status New In Progress
2020-07-30 21:40:11 Jeff Lane  linux (Ubuntu Focal): importance Undecided Medium
2020-07-30 21:40:14 Jeff Lane  linux (Ubuntu Focal): assignee Jeff Lane (bladernr)
2020-07-31 01:27:24 Jeff Lane  description The bellow upstream commit fixes a bug in Ktls feature. It is applied cleanly above the ubuntu-focal tree and passed basic sanity testing. We would like it to be backported ubuntu-focal Thanks, Amir commit 41b14fb8724d5a4b382a63cb4a1a61880347ccb8 Author: Tariq Toukan <tariqt@mellanox.com> Date: Mon Jun 22 23:26:04 2020 +0300 net: Do not clear the sock TX queue in sk_set_socket() Clearing the sock TX queue in sk_set_socket() might cause unexpected out-of-order transmit when called from sock_orphan(), as outstanding packets can pick a different TX queue and bypass the ones already queued. This is undesired in general. More specifically, it breaks the in-order scheduling property guarantee for device-offloaded TLS sockets. Remove the call to sk_tx_queue_clear() in sk_set_socket(), and add it explicitly only where needed. Fixes: e022f0b4a03f ("net: Introduce sk_tx_queue_mapping") Signed-off-by: Tariq Toukan <tariqt@mellanox.com> Reviewed-by: Boris Pismenny <borisp@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> [IMPACT] Clearing the sock TX queue in sk_set_socket() might cause unexpected out-of-order transmit when called from sock_orphan(), as outstanding packets can pick a different TX queue and bypass the ones already queued. This is undesired in general. More specifically, it breaks the in-order scheduling property guarantee for device-offloaded TLS sockets. Remove the call to sk_tx_queue_clear() in sk_set_socket(), and add it explicitly only where needed. [FIXES] e022f0b4a03f "net: Introduce sk_tx_queue_mapping" This cleanly cherry picks into 5.4 from 5.8. It can be checked out in my branch here: https://git.launchpad.net/~bladernr/ubuntu/+source/linux/+git/focal 1889625-mxl-ktls-bugfix [REGRESSION RISK] [TEST]
2020-08-13 13:08:49 Amir Tzin description [IMPACT] Clearing the sock TX queue in sk_set_socket() might cause unexpected out-of-order transmit when called from sock_orphan(), as outstanding packets can pick a different TX queue and bypass the ones already queued. This is undesired in general. More specifically, it breaks the in-order scheduling property guarantee for device-offloaded TLS sockets. Remove the call to sk_tx_queue_clear() in sk_set_socket(), and add it explicitly only where needed. [FIXES] e022f0b4a03f "net: Introduce sk_tx_queue_mapping" This cleanly cherry picks into 5.4 from 5.8. It can be checked out in my branch here: https://git.launchpad.net/~bladernr/ubuntu/+source/linux/+git/focal 1889625-mxl-ktls-bugfix [REGRESSION RISK] [TEST] [IMPACT] Clearing the sock TX queue in sk_set_socket() might cause unexpected out-of-order transmit when called from sock_orphan(), as outstanding packets can pick a different TX queue and bypass the ones already queued. This is undesired in general. More specifically, it breaks the in-order scheduling property guarantee for device-offloaded TLS sockets. Remove the call to sk_tx_queue_clear() in sk_set_socket(), and add it explicitly only where needed. [FIXES] e022f0b4a03f "net: Introduce sk_tx_queue_mapping" This cleanly cherry picks into 5.4 from 5.8. It can be checked out in my branch here: https://git.launchpad.net/~bladernr/ubuntu/+source/linux/+git/focal 1889625-mxl-ktls-bugfix [REGRESSION RISK] low! [TEST] reproducing the bug is not trivial. in general terms: nic: ConnectX6-dx with crypto enabled send intense encrypted tcp traffic with tls offload between many clients and one server. * clients may run on the same machine. * clients continuously opens and closes connection to server at some point decryption errores might arise on some of the clients.
2020-09-17 19:56:07 Jeff Lane  linux (Ubuntu): status In Progress Invalid
2020-09-17 19:56:11 Jeff Lane  linux (Ubuntu Focal): status In Progress Invalid