Page MenuHomeFreeBSD

dummynet: use atomics to maintain pie_desc.ref_count
AbandonedPublic

Authored by mjg on Jan 26 2022, 8:24 PM.
Tags
None
Referenced Files
Unknown Object (File)
Dec 20 2023, 7:33 AM
Unknown Object (File)
Dec 10 2023, 1:25 PM
Unknown Object (File)
Aug 16 2023, 6:39 PM
Unknown Object (File)
Aug 14 2023, 10:45 PM
Unknown Object (File)
Aug 14 2023, 11:45 AM
Unknown Object (File)
Jun 28 2023, 8:23 AM
Unknown Object (File)
Jun 24 2023, 3:05 AM
Unknown Object (File)
May 6 2023, 10:41 AM

Details

Reviewers
None
Group Reviewers
network
Summary

The counter is a global, but previously used DN_BH_WLOCK/DN_BH_WUNLOCK is per vnet so it failed to provide the protection and in case of pie_callout_cleanup panicked on top of it as no vnet was set.

Note this this only restores bug-to-bug compatibility with pre-vnetification of the code.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

mjg requested review of this revision.Jan 26 2022, 8:24 PM

There's discussion of what looks to be the same issue in D33432
fqpie_callout_cleanup() seems to be affected as well.

It looks like ref_count is only ever evaluated (as opposed to updated) in unload_dn_sched(), where it's protected by the global sched_mtx lock. I think we can fix the problem by replacing the DN_BH_WLOCK() by the sched_mtx (possibly through a 'dummynet_lock_sched()' function, because sched_mtx is local to ip_dummynet.c).

fqpie_callout_cleanup() should exhibit the same issue

I propose something like D34059 instead.