Page MenuHomeFreeBSD

ufs: try to elide the interlock in ufs_itimes
ClosedPublic

Authored by mjg on Sep 10 2022, 9:33 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Nov 14, 10:15 PM
Unknown Object (File)
Oct 26 2024, 1:45 AM
Unknown Object (File)
Oct 25 2024, 9:21 PM
Unknown Object (File)
Oct 12 2024, 12:15 PM
Unknown Object (File)
Oct 12 2024, 12:15 PM
Unknown Object (File)
Oct 12 2024, 12:15 PM
Unknown Object (File)
Oct 12 2024, 12:14 PM
Unknown Object (File)
Oct 12 2024, 11:53 AM
Subscribers

Diff Detail

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

Event Timeline

mjg requested review of this revision.Sep 10 2022, 9:33 PM
mjg created this revision.

Then why checking for v_usecount > 1 at all? It can go to 1 at any time.

I'm guessing the original code was avoiding the call, expecting for it to happen in ufs_inactive later. This retains the ultimately racy nature, except avoids the interlock.

I agree, it probably was an attempt for micro-optimization, I do not see any other reason. Then, since inactivation is not guaranteed to occur now, while close is, I think the check for v_usecount should be removed.

mjg retitled this revision from ufs: do a lockless usecount check in ufs_close to ufs: try to elide the interlock in ufs_itimes.
mjg edited the summary of this revision. (Show Details)
This revision is now accepted and ready to land.Sep 13 2022, 10:17 AM

With updates, looks good.

This revision was automatically updated to reflect the committed changes.