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)
Sep 18 2024, 12:26 PM
Unknown Object (File)
Sep 7 2024, 5:45 PM
Unknown Object (File)
Jul 1 2024, 12:11 AM
Unknown Object (File)
Jun 27 2024, 5:24 AM
Unknown Object (File)
May 15 2024, 4:14 AM
Unknown Object (File)
May 11 2024, 8:37 AM
Unknown Object (File)
May 2 2024, 12:59 PM
Unknown Object (File)
Dec 20 2023, 7:33 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.