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
F135595173: D14458.diff
Tue, Nov 11, 3:47 AM
Unknown Object (File)
Tue, Nov 4, 3:26 AM
Unknown Object (File)
Mon, Nov 3, 12:12 PM
Unknown Object (File)
Mon, Nov 3, 7:43 AM
Unknown Object (File)
Mon, Nov 3, 7:43 AM
Unknown Object (File)
Mon, Nov 3, 3:52 AM
Unknown Object (File)
Wed, Oct 29, 3:07 PM
Unknown Object (File)
Mon, Oct 13, 6:53 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