Page MenuHomeFreeBSD

usb_ethernet: avoid ioctl and watchdog tick link up/down race condition.
Needs ReviewPublic

Authored by ali.abdallah_suse.com on Wed, May 13, 11:06 AM.
Tags
Referenced Files
F157041780: D56985.diff
Mon, May 18, 2:25 AM
Unknown Object (File)
Sat, May 16, 6:02 AM
Unknown Object (File)
Sat, May 16, 6:02 AM
Unknown Object (File)
Sat, May 16, 6:02 AM
Unknown Object (File)
Fri, May 15, 10:31 PM
Unknown Object (File)
Fri, May 15, 5:25 PM
Unknown Object (File)
Fri, May 15, 6:03 AM
Unknown Object (File)
Fri, May 15, 6:02 AM
This revision needs review, but there are no reviewers specified.

Details

Reviewers
None
Summary

usb ethernet tick task will check the link status, also
SIOCGIFMEDIA/SIOCSIFMEDIA will check the link status. mutex is shared
between usb_ethernet code, miibus, usb_process, and chip driver (ex.
if_ure).

The problem is that usb_request.c:usbd_do_request_flags unconditionally
releases the mutex. So if we have tick code running, ioctl waiting to
acquire the mutex, the release of the mutex by usbd_do_request_flags
causes the ioctl code to run, racing with the tick code, causing
linkup/down (see bsc#252165).

To avoid that, we stop the tick watchog on SIOCGIFMEDIA/SIOCSIFMEDIA
ioctl if we are the only pending one, then we restore it back when
no more ioctl are left, actually there is no point to run the tick
watchdog code if we are going to check the link status in the ioctl code
anyway. In addition we use ioctl_cv condition variable
to serialize ioctl to avoid two ioctl's racing.

Unlike https://reviews.freebsd.org/D55682 (see also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252165#c62) where the proposed solution works only for if_ure, this solves the issue at the usb_ethernet code level, avoid touching various other chip drivers if_muge, if_axge, if_rue, etc...)

Test Plan

Tested on RTL8153 if_ure and AX88179 if_axge usb ethernets

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

Thank you for your effort on this.

I tested this patch in two different environments:

  • 16-current on Raspberry PI4(arm64) + axe(AX88772 ASIX Electronics Corp.)
  • 15.0-RELEASE on Raspberry PI zero 2W(arm64) + ure(Lenovo Lenovo USB-C to LAN)

Unfortunately, the link up/down issue still reproduces.

Steps to Reproduce:
Machine A (Remote): Run ping [Unassigned Local IP].
Machine B (Target): Run the route -n monitor command in multiple separate instances (tested with up to 100 instances).

Result: NG (Failed)

For reference, the following patches previously fixed this issue (by changing *_ifmedia_upd, *_ifmedia_sts, etc.):

ure: https://reviews.freebsd.org/D56138

axe: https://reviews.freebsd.org/D55925

axge: https://reviews.freebsd.org/D55631

If you cannot reproduce this on your end, please let me know.