gro_max_sizePerubahan lain menyasar operasi penambahan dan penghapusan aturan FIB IPv4/IPv6—struktur yang membantu kernel menentukan jalur penerusan paket. Sebelumnya, operasi tersebut lebih banyak bergantung pada serialisasi melalui RTNL, mekanisme penguncian global yang dapat menjadi hambatan ketika banyak namespace jaringan dimodifikasi secara bersamaan.
Linux 7.3 memindahkan sebagian perlindungan itu ke mutex per-fib_rules_ops jika memungkinkan. RTNL tetap diperlukan dalam kondisi tertentu, termasuk jalur fib_unmerge() saat aturan IPv4 pertama dibuat.
Dalam pengujian sintetis yang membuat 4.096 namespace dan memasukkan 1.024 aturan ke masing-masing namespace secara paralel, waktu operasi IPv4 turun dari 22,752 detik menjadi 0,918 detik—sekitar 24,8 kali lebih cepat. Pada IPv6, waktunya turun dari 35,181 detik menjadi 1,214 detik, atau sekitar 29 kali lebih cepat.
Ini adalah hasil pada skenario kontensi ekstrem, bukan janji bahwa proses memulai container pada penggunaan normal akan selalu menjadi puluhan kali lebih cepat.
Di luar perubahan kode, merge window ini juga menyoroti tantangan baru dalam pengembangan kernel. Maintainer jaringan Linux, Jakub Kicinski, menghitung ada 632 patch net dan 648 patch net-next. Ia memperkirakan sekitar sepertiga hingga setengah patch net-next merupakan perbaikan kecil, pembersihan kode, atau klarifikasi berprioritas rendah yang dibuat dengan bantuan AI—setara dengan sekitar 216 hingga 324 patch.
Kicinski dan Paolo Abeni menggambarkan kondisi tersebut sebagai situasi ketika mereka “completely overwhelmed”. Masalahnya bukan sekadar jumlah patch, tetapi waktu yang diperlukan untuk memeriksa apakah perubahan kecil benar-benar aman pada kode jaringan yang memiliki banyak interaksi dan jalur pengecualian.
Sebagai tanggapan, Meta menyediakan anggaran dan akses ke beberapa model AI frontier untuk melakukan tinjauan awal terhadap setiap patch. Penggunaan beberapa model ditujukan untuk mengurangi risiko halusinasi atau kesalahan yang mungkin muncul jika hanya mengandalkan satu model. Otomasi yang direncanakan mencakup pengelolaan Patchwork, masukan proses yang umum, penyuntingan pesan commit, dan kemungkinan menerapkan patch yang sebelumnya sudah ditinjau oleh orang tepercaya.
Namun, maintainer tidak menganggap AI cukup untuk menggantikan manusia pada jalur yang jarang terjadi dan rentan terhadap race condition. Contohnya mencakup penanganan error serta timeout PCIe, ketika urutan pemanggilan API dan proses pemulihan perangkat harus diperiksa dengan sangat cermat.
Selain BIG TCP dan perubahan RTNL, penggabungan jaringan Linux 7.3 mencakup beberapa pekerjaan lain:
SCM_RIGHTS kini dapat memberikan pelaporan yang lebih jelas ketika LSM menolak file descriptor tertentu. Dengan SO_RIGHTS_NOTRUNC, penerima dapat mengetahui descriptor yang ditolak beserta errno, alih-alih kehilangan sisa array setelah kegagalan pertama. Release candidate pertama Linux 7.3 diperkirakan hadir sekitar 30 Agustus 2026, sedangkan rilis stabil diproyeksikan pada akhir Oktober, dengan catatan jadwal tetap bergantung pada jalannya siklus pengembangan.
Pengguna distribusi dengan jadwal rilis tetap kemungkinan harus menunggu lebih lama. Distribusi biasanya memilih, melakukan backport, menguji, lalu mengirimkan kernel sesuai jadwal mereka sendiri. Distribusi rolling release dapat mengemasnya lebih cepat, tetapi belum ada bukti bahwa CachyOS telah menetapkan tanggal adopsi Linux 7.3; image Agustus mereka masih menggunakan Linux 7.1.