Page MenuHomeFreeBSD

cam_sim: harmonize code related to acquiring a mtx
ClosedPublic

Authored by bz on Sep 1 2020, 8:14 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Mar 7, 9:24 AM
Unknown Object (File)
Fri, Feb 28, 5:42 PM
Unknown Object (File)
Wed, Feb 19, 11:26 PM
Unknown Object (File)
Feb 6 2025, 5:46 PM
Unknown Object (File)
Feb 2 2025, 5:38 AM
Unknown Object (File)
Jan 31 2025, 9:19 PM
Unknown Object (File)
Jan 24 2025, 10:42 AM
Unknown Object (File)
Jan 9 2025, 1:42 PM
Subscribers

Details

Summary

cam_sim_free(), cam_sim_release(), and cam_sim_hold() all assign
a mtx variable during declaration and then if NULL or the mtx is
held may re-asign the variable and/or acquire/release a lock.

Harmonize the code, avoiding double assignments and make it look
the same for all three function (with cam_sim_free() not needing
an extra case).

No functional changes intended.

Reviewed by: ..
MFC after: ..
Test Plan

I came across this code trying to debug a hang on I believe
cam_sim_free_mtx (though it should not be) as the msleep()
seems to have never been woken up and found the locking
contracts quite confusing. I keep wondering if it should be
simplified a lot but that would require reading a lot of
consumers.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

bz requested review of this revision.Sep 1 2020, 8:14 PM

This looks fine to me.

though I wonder when mtx is NULL these days... I thought all the sims had been fixed.

This revision is now accepted and ready to land.Sep 2 2020, 7:00 PM

I don't see a point, but if you do -- I have no objections.

@imp NULL there is when SIM does not require external locking, for example, NVMe or CTL CAM frontend. It is a new feature for few years now rather than something that should be fixed.

Yeah, what Warner is thinking of is when sim->mtx == &Giant. I think we've removed all of that code.

This revision was automatically updated to reflect the committed changes.