Page MenuHomeFreeBSD

iflib_stop: drain rx tasks to prevent any data races
ClosedPublic

Authored by avg on Nov 10 2021, 1:58 PM.
Tags
None
Referenced Files
F83137841: D32926.id98310.diff
Mon, May 6, 8:27 PM
Unknown Object (File)
Fri, May 3, 4:05 PM
Unknown Object (File)
Tue, Apr 30, 1:32 AM
Unknown Object (File)
Mar 29 2024, 1:38 AM
Unknown Object (File)
Mar 25 2024, 5:37 AM
Unknown Object (File)
Jan 31 2024, 12:51 AM
Unknown Object (File)
Dec 22 2023, 11:45 PM
Unknown Object (File)
Nov 28 2023, 9:02 PM
Subscribers

Details

Summary

iflib_stop modifies iflib data structures that are used by _task_fn_rx,
most prominently the free lists. So, iflib_stop has to ensure that the
rx task threads are not active.

This should help to fix a crash seen when iflib_if_ioctl (e.g.,
SIOCSIFCAP) is called while there is already traffic flowing.

The crash has been seen on VMWare guests with vmxnet3 driver.

My guess is that on physical hardware the couple of 1ms delays that
iflib_stop has after disabling interrupts are enough for the queued work
to be completed before any iflib state is touched.

But on busy hypervisors the guests might not get enough CPU time to
complete the work, thus there can be a race between the taskqueue
threads and the work done to handle an ioctl, specifically in iflib_stop
and iflib_init_locked.

PR: 259458

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

avg requested review of this revision.Nov 10 2021, 1:58 PM

Do transmit task queues need to be drained as well?

Do transmit task queues need to be drained as well?

To be honest, I don't know.
Seems like it wouldn't / shouldn't hurt, but we have never seen any problems in the iflib tx path.

Maybe any of the iflib original authors and current active maintainers would like to comment on this as well?

This revision was not accepted when it landed; it landed in state Needs Review.Nov 19 2021, 8:01 AM
This revision was automatically updated to reflect the committed changes.