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)
Mar 19 2024, 8:19 AM
Unknown Object (File)
Feb 17 2024, 11:42 PM
Unknown Object (File)
Jan 15 2024, 1:11 AM
Unknown Object (File)
Dec 20 2023, 5:38 AM
Unknown Object (File)
Dec 2 2023, 7:29 PM
Unknown Object (File)
Oct 1 2023, 12:27 AM
Unknown Object (File)
Sep 27 2023, 11:41 AM
Unknown Object (File)
Aug 24 2023, 11:38 PM
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.