Race Condition SMP di Networking NetBSD ( Ketika Semua Tampak Benar, Tapi Kernel Tetap Mati )

Описание: Race Condition SMP di Networking NetBSD ( Ketika Semua Tampak Benar, Tapi Kernel Tetap Mati )







Premis Brutal ( Harus Diterima )
Race condition SMP bukan bug logika tunggal.
Ia adalah kesepakatan waktu yang gagal Di sistem 1 CPU kode “aman” urutan stabil Di SMP urutan tidak pernah dijanjikan NetBSD tidak menyelamatkanmu dari ini.

Kenapa Networking Paling Rawan SMP?
Karena networking itu interrupt driven multiproducer multiconsumer latency sensitive Dan karena RX interrupt softnet protocol thread socket layer

empat konteks eksekusi berbeda, semua menyentuh mbuf.

Model Eksekusi Nyata di NetBSD
Bukan “stack lurus”.
Yang terjadi

NIC RX interrupt di CPU 0

netisr di CPU 1

TCP input di CPU 2

user process di CPU 3

Semua pegang pointer yang sama tapi tidak sadar satu sama lain
Mitos Besar: “Softnet Itu Aman” Softnet bukan global lock.

Softnet hanya menjamin some serialization bukan eksklusivitas penuh

Kesalahan fatal “Kalau sudah masuk softnet, aman.” Salah.

Race Klasik RX Interrupt vs m_freem()
Skenario Nyata
CPU 0
RX interrupt
alloc mbuf
enqueue ke netisr

CPU 1
processing packet
error path

m_freem(m)

CPU 0
interrupt lagi

reuse mbuf memory

CPU 1
lanjut pakai pointer lama

use-after-free

Race Klasik Socket Close vs TCP Input
Gejala
panic saat socket ditutup traffic masih masuk
Skenario user close socket socket buffer dibersihkan TCP input masih refer ke mbuf
Lock salah tempat socket lock dilepas terlalu cepat TCP belum selesai

double free / dangling pointer

Locking Model NetBSD ( Sering Disalahpahami )
NetBSD punya mutex rwlock softint spl ( legacy ) pserialize ( RCU like )

Masalah terlalu banyak pilihan developer salah pilih pserialize Pisau Bermata Dua
pserialize cocok untuk read heavy lockless traversal

Kesalahan umum free object tanpa grace period reader masih jalan
NetBSD tidak memaafkan misuse pserialize.

Panic “Hantu” yang Sulit Direproduksi

Ciri khas race SMP panic jarang hanya di load tinggi tidak muncul di debug build

Kenapa?
timing berubah
debug printf memperbaiki race

Ini mimpi buruk engineer.

Studi Kasus Nyata: netisr Queue Corruption
Gejala
panic: kernel diagnostic assertion failed

Backtrace

netisr_dispatch()
ip_input()

Analisis
enqueue tanpa lock
dequeue di CPU lain

Bug
asumsi single producer
padahal multi RX queue

Solusi
per CPU queue
lock atau pserialize

Studi Kasus Nyata mbuf Reference Count

NetBSD mbuf tidak pakai refcount global

Kalau dua subsistem pegang mbuf salah satu free yang lain mati

FreeBSD punya UMA + refcount

NetBSD percaya kamu

Debugging Race SMP ( Real Tools )
Yang benar-benar dipakai

tambah KASSERT(m != NULL)

tambah KASSERT(cpu_intr_p() == false)

paksa single CPU (options MULTIPROCESSOR off)

bisect dengan delay artificial

Tidak ada ThreadSanitizer.

Teknik Brutal: “Disable SMP”

Untuk konfirmasi
boot kernel UP

jika panic hilang → race confirmed

Ini teknik tua, tapi efektif.

Filosofi NetBSD vs Lainnya
NetBSD memberi pisau tajam
OpenBSD memotong fitur berbahaya
FreeBSD memberi pelindung tambahan

NetBSD percaya engineer tahu apa yang dia lakukan dan Kadang itu optimis berlebihan.

Prinsip Bertahan Hidup di SMP NetBSD
Jangan share mbuf lintas CPU tanpa jelas ownership
Jangan free di context berbeda
Jangan percaya urutan eksekusi
Jangan optimasi sebelum benar
Debug di kondisi terburuk

Kesimpulan Tanpa Gula
Race condition SMP di networking NetBSD bukan bug satu baris bukan salah TCP hasil dari asumsi diam diam yang patah

Kalau kamu bisa menaklukkan ini kamu tidak cuma “pakai BSD”

kamu mengerti kernel concurrency sungguhan

NetBSD tidak ramah Tapi ia jujur tentang kerasnya dunia paralel.

#kuduskotakretek
#kudus
#kudushits
#kuduskekinian
#kudusexplore
#kudus24jam
#kudustinyworld
#umkudus
#linuxpemula
#linuxindonesia
#desktopenvironment
#distrolinux
#edukasiteknologi
#belajarlinux
#byte_sys