~ubuntu-mainline/ubuntu-mainline/+git/linux-ubuntu:focal/linux-gcp-tcpx

Last commit made on 2024-04-01
Get this branch:
git clone -b focal/linux-gcp-tcpx https://git.launchpad.net/~ubuntu-mainline/ubuntu-mainline/+git/linux-ubuntu
Members of Ubuntu Mainline can upload to this branch. Log in for directions.

Branch merges

Branch information

Name:
focal/linux-gcp-tcpx
Repository:
lp:~ubuntu-mainline/ubuntu-mainline/+git/linux-ubuntu

Recent commits

29db0e1... by John Cabaj

UBUNTU: Ubuntu-gcp-tcpx-5.15.0-1008.8

Signed-off-by: John Cabaj <email address hidden>

b39da45... by John Cabaj

UBUNTU: debian.gcp-tcpx/dkms-versions -- update from kernel-versions (main/2024.03.04)

BugLink: https://bugs.launchpad.net/bugs/1786013
Signed-off-by: John Cabaj <email address hidden>

93b5361... by John Cabaj

UBUNTU: link-to-tracker: update tracking bug

BugLink: https://bugs.launchpad.net/bugs/2055598
Properties: no-test-build
Signed-off-by: John Cabaj <email address hidden>

13e1baa... by John Cabaj

UBUNTU: Start new release

Ignore: yes
Signed-off-by: John Cabaj <email address hidden>

8a11872... by John Cabaj

UBUNTU: [Packaging] drop ABI data

BugLink: https://bugs.launchpad.net/bugs/1786013
Signed-off-by: John Cabaj <email address hidden>

cb1537c... by Eric Dumazet <email address hidden>

UBUNTU: SAUCE: (no-up) PRODKERNEL: net-tcpdirect-fastrak: abort SO_DEVMEM_DONTNEED sooner

BugLink: https://canonical.lightning.force.com/lightning/r/Case/5008e00000Cj1c9AAB/view (TCPDirect patches)

In case user provided wrong input, SO_DEVMEM_DONTNEED could
spin many times (2^32 or more) and lock cpu for many seconds.

Abort the loop immediately in case of an error.

Note the ABI does not report back number of pages that have
been released anyway, so tcpdirect never expected a failure there.

Test the unlikely() case first, to reduce indentation level
of the fast path.

Fixes: ac4a2b0ef821 ("PRODKERNEL: net-tcpdirect-fastrak: add SO_DEVMEM_DONTNEED setsockopt to release pages")
Tested: Ran syzbot repro
Reported-and-tested-by: <email address hidden>
Effort: net-tcpdirect-fastrak
Upstream-Plan: 232518966
Google-Bug-Id: 325732619
Signed-off-by: Eric Dumazet <email address hidden>
Change-Id: I4c64ec56bd0ea65d030a9e817e64517dc01333a6
Reviewed-on: https://cos-review.googlesource.com/c/third_party/kernel/+/65370
Reviewed-by: Mina Almasry <email address hidden>
Tested-by: Minh-Anh Nguyen <email address hidden>
(cherry picked from commit 5f36049745128640f8bbb0085c8a7f6a82873dfc https://cos.googlesource.com/third_party/kernel/+log/refs/heads/tcpd/R105)
Signed-off-by: John Cabaj <email address hidden>
Acked-by: Manuel Diewald <email address hidden>
Acked-by: Joseph Salisbury <email address hidden>
Signed-off-by: John Cabaj <email address hidden>

0b3d65c... by Minh Anh Nguyen

UBUNTU: SAUCE: (no-up) gve: add per-queue dmabuff binding flag

BugLink: https://canonical.lightning.force.com/lightning/r/Case/5008e00000Cj1c9AAB/view (TCPDirect patches)

Add a gVNIC flag that will indicate whether the given rx queue
is bounded to dmabuf memory or not.

Tested:
  # with RxDM on
  ethtool -S <ifname> | grep rx_dmabuf_bound
     rx_dmabuf_bound[0]: 0
     rx_dmabuf_bound[1]: 0
     rx_dmabuf_bound[2]: 0
     rx_dmabuf_bound[3]: 0
     rx_dmabuf_bound[4]: 0
     rx_dmabuf_bound[5]: 0
     rx_dmabuf_bound[6]: 0
     rx_dmabuf_bound[7]: 0
     rx_dmabuf_bound[8]: 1
     rx_dmabuf_bound[9]: 1
     rx_dmabuf_bound[10]: 1
     rx_dmabuf_bound[11]: 1
     rx_dmabuf_bound[12]: 1
     rx_dmabuf_bound[13]: 1
     rx_dmabuf_bound[14]: 1
     rx_dmabuf_bound[15]: 1

  # with RxDM off
  ethtool -S <ifname> | grep rx_dmabuf_bound
     rx_dmabuf_bound[0]: 0
     rx_dmabuf_bound[1]: 0
     rx_dmabuf_bound[2]: 0
     rx_dmabuf_bound[3]: 0
     rx_dmabuf_bound[4]: 0
     rx_dmabuf_bound[5]: 0
     rx_dmabuf_bound[6]: 0
     rx_dmabuf_bound[7]: 0
     rx_dmabuf_bound[8]: 0
     rx_dmabuf_bound[9]: 0
     rx_dmabuf_bound[10]: 0
     rx_dmabuf_bound[11]: 0
     rx_dmabuf_bound[12]: 0
     rx_dmabuf_bound[13]: 0
     rx_dmabuf_bound[14]: 0
     rx_dmabuf_bound[15]: 0

Google-Bug-Id: 291145287
Change-Id: Icd65af3b5f7ab5f66bc0674c614aa10333f9dc37
Reviewed-on: https://cos-review.googlesource.com/c/third_party/kernel/+/61694
Tested-by: Minh-Anh Nguyen <email address hidden>
Reviewed-by: Mina Almasry <email address hidden>
Reviewed-by: Praveen Kaligineedi <email address hidden>
(cherry picked from commit 736f2fb80a2970bd60ba06dd1444f578a096ede5 https://cos.googlesource.com/third_party/kernel/+log/refs/heads/tcpd/R105)
Signed-off-by: John Cabaj <email address hidden>
Acked-by: Manuel Diewald <email address hidden>
Acked-by: Joseph Salisbury <email address hidden>
Signed-off-by: John Cabaj <email address hidden>

5f17538... by Eric Dumazet <email address hidden>

UBUNTU: SAUCE: (no-up) tcp: initialise newsk->sk_pagepool for passive sockets

BugLink: https://canonical.lightning.force.com/lightning/r/Case/5008e00000Cj1c9AAB/view (TCPDirect patches)

tcp_init_sock() is not called for children (at accept() time)

Only for freshly allocated sockets, inet[6]_create() call tcp_init_sock() via

if (sk->sk_prot->init) {
    err = sk->sk_prot->init(sk);
    if (err) {
        sk_common_release(sk);
        goto out;
    }
}

But passive connections do not have such a call.

tcp_create_openreq_child() is clearing/resetting
all fields that must be cleared/reset
after the cloning from parent (listener) happened.

It is not clear why at accept() time we find the listener sk_pagepool
locked because this stuff matters only for established flows.

We must not assume user space would not do strange things.

Therefore the fix will be either in inet_csk_clone_lock()
if we want to extend sk_pagepool to other protocols,
or tcp_create_openreq_child() since only TCP calls xa_destroy() so far.

Fixes: 987df26c30c6 ("tcp: implement RX path for devmem sockets")
Change-Id: I3cc3770af224f790154ee56094ddfc4f7797428b
Signed-off-by: Eric Dumazet <email address hidden>
Reviewed-on: https://cos-review.googlesource.com/c/third_party/kernel/+/64590
Reviewed-by: Mina Almasry <email address hidden>
Tested-by: Mina Almasry <email address hidden>
(cherry picked from commit f8319337b01cf8edabafbdddd6b1d538a8c246da https://cos.googlesource.com/third_party/kernel/+log/refs/heads/tcpd/R105)
Signed-off-by: John Cabaj <email address hidden>
Acked-by: Manuel Diewald <email address hidden>
Acked-by: Joseph Salisbury <email address hidden>
Signed-off-by: John Cabaj <email address hidden>

7bcf337... by Eric Dumazet <email address hidden>

UBUNTU: SAUCE: (no-up) selftests/net: optmem_max became per netns

BugLink: https://canonical.lightning.force.com/lightning/r/Case/5008e00000Cj1c9AAB/view (TCPDirect patches)

/proc/sys/net/core/optmem_max is now per netns, change two tests
that were saving/changing/restoring its value on the parent netns.

Change-Id: Idacd74a41133cbb849cca0d608a02dcad97da92b
Signed-off-by: Eric Dumazet <email address hidden>
Reviewed-by: Willem de Bruijn <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit 18872ba8cd2406ffa835f9f6276e47ed86fbb5d6)
Reviewed-on: https://cos-review.googlesource.com/c/third_party/kernel/+/62584
Tested-by: Mina Almasry <email address hidden>
(cherry picked from commit 128a8bec61acef84adf608afa8590c0a81692796 https://cos.googlesource.com/third_party/kernel/+log/refs/heads/tcpd/R105)
Signed-off-by: John Cabaj <email address hidden>
Acked-by: Manuel Diewald <email address hidden>
Acked-by: Joseph Salisbury <email address hidden>
Signed-off-by: John Cabaj <email address hidden>

8365a5a... by Eric Dumazet <email address hidden>

UBUNTU: SAUCE: (no-up) net: Namespace-ify sysctl_optmem_max

BugLink: https://canonical.lightning.force.com/lightning/r/Case/5008e00000Cj1c9AAB/view (TCPDirect patches)

optmem_max being used in tx zerocopy,
we want to be able to control it on a netns basis.

Following patch changes two tests.

Tested:

oqq130:~# cat /proc/sys/net/core/optmem_max
131072
oqq130:~# echo 1000000 >/proc/sys/net/core/optmem_max
oqq130:~# cat /proc/sys/net/core/optmem_max
1000000
oqq130:~# unshare -n
oqq130:~# cat /proc/sys/net/core/optmem_max
131072
oqq130:~# exit
logout
oqq130:~# cat /proc/sys/net/core/optmem_max
1000000

Change-Id: Iec5bcddee62109cfe2725febadbfa4950654672a
Signed-off-by: Eric Dumazet <email address hidden>
Reviewed-by: Willem de Bruijn <email address hidden>
Acked-by: Neal Cardwell <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit f5769faeec36b9d5b9df2c3e4f05a76d04ffd9c9)
Reviewed-on: https://cos-review.googlesource.com/c/third_party/kernel/+/62583
Tested-by: Mina Almasry <email address hidden>
(cherry picked from commit 2f588762a5611884321e7244d8362315ad1f139f https://cos.googlesource.com/third_party/kernel/+log/refs/heads/tcpd/R105)
Signed-off-by: John Cabaj <email address hidden>
Acked-by: Manuel Diewald <email address hidden>
Acked-by: Joseph Salisbury <email address hidden>
Signed-off-by: John Cabaj <email address hidden>