Page MenuHomeFreeBSD

g_slice_access: deal with the first-open race
AbandonedPublic

Authored by avg on Feb 21 2018, 11:49 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mar 8 2024, 12:04 AM
Unknown Object (File)
Jan 26 2024, 10:46 AM
Unknown Object (File)
Jan 24 2024, 4:43 AM
Unknown Object (File)
Jan 16 2024, 7:30 PM
Unknown Object (File)
Dec 22 2023, 11:32 PM
Unknown Object (File)
Dec 22 2023, 9:22 AM
Unknown Object (File)
Dec 13 2023, 5:57 PM
Unknown Object (File)
Nov 14 2023, 12:57 PM
Subscribers

Details

Reviewers
marcel
mav
asomers
Summary

The problem is that g_access() must be called with the GEOM topology lock held.
And that gives a false impression that the lock is indeed held across the call.
But this isn't always true because many classes, ZVOL being one of the many,
need to perform I/O on the first open. So, they must drop and pick up the
topology lock in their access method.

That, of course, can break many assumptions. Specifically, g_slice_access()
adds an extra exclusive count on the first open. As described above, an
underlying geom may drop the topology lock and that would open a race with
another thread that would also request another extra exclusive count.

The workaround is to check whether this thread won or lost the first-open race
after calling g_access(). The losing thread decrements the exclusive count.

Ideally, the race should be eliminated or accounted for in the GEOM design.
There could be other bad consequences.

Test Plan

I believe that bug 225960 is a result of the described race. @asomers reports that the suggested change does help with the bug.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 15184
Build 15259: arc lint + arc unit