Page MenuHomeFreeBSD

bpf: don't move an already-detached bpf_if in bpf_vmove
Needs ReviewPublic

Authored by seuros on Sat, Aug 8, 7:47 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Sep 6, 10:53 AM
Unknown Object (File)
Fri, Sep 4, 1:33 AM
Unknown Object (File)
Thu, Sep 3, 7:56 AM
Unknown Object (File)
Wed, Sep 2, 11:19 AM
Unknown Object (File)
Sun, Aug 30, 12:14 PM
Unknown Object (File)
Fri, Aug 28, 9:17 PM
Unknown Object (File)
Mon, Aug 24, 8:41 AM
Unknown Object (File)
Mon, Aug 24, 8:29 AM
Subscribers

Details

Summary

if_vmove() unconditionally called bpf_vmove(), even after bpfdetach()
has replaced if_bpf with the dead_bpf_if sentinel. bpf_vmove() then
treated the sentinel as a live bpf_if and corrupted its list linkage,
panicking under QUEUE_MACRO_DEBUG on epair vnet teardown.

panic: bpf_vmove: Bad link elm ... next->prev != elm

Exported the sentinel via bpf_dead_if() so bpf_vmove() can recognize it
and skip it.

MFC: 1 week

Test Plan
  1. Create a VNET jail and give it one peer of an epair(4):

    jail -c name=t vnet persist ifconfig epair0 create ifconfig epair0a vnet t
  1. Inside the jail, bring the interface up and generate some traffic (anything that attaches bpf works dhclient, tcpdump -i epair0a, ect.)
  1. Destroy the jail:

    jail -r t

I was configuring forgejo, blackship and a test runner.. Happens in current and 15.1

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 75462
Build 72345: arc lint + arc unit

Event Timeline

seuros requested review of this revision.Sat, Aug 8, 7:47 PM

How can I reproduce the problem?

I was writing the instructions in the test plan.

I have a blackship manifest that reproduce it 100%

Btw the system has WITNESS , INVARIANTS enabled.