Bug 1962191 - gfs2: Implement proper glock recursion
Summary: gfs2: Implement proper glock recursion
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: kernel
Version: unspecified
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: beta
: ---
Assignee: GFS2 Maintainers
QA Contact: cluster-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-05-19 13:33 UTC by Andreas Gruenbacher
Modified: 2023-08-10 17:08 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-11-19 07:27:41 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Andreas Gruenbacher 2021-05-19 13:33:01 UTC
GFS2 currently doesn't allow a glock to be taken by the same task more than once; trying to take the same glock a second time leads to a BUG in add_to_queue().  As a workaround, gfs2_glock_is_locked_by_me() is used in several places to check if the glock is held already, followed by checks like gfs2_glock_is_held_excl().

The problem with that is that gfs2_glock_is_held_excl checks gl->gl_state, so when a glock is held in LM_ST_SHARED or LM_ST_DEFERRED state by the current task, the node may still have the glock cached in LM_ST_EXCLUSIVE state.  In that situation, checking for gfs2_glock_is_held_excl() doesn't ensure that the glock will remain locked in LM_ST_EXCLUSIVE state.  A possible workaround would be to "upgrade" the current holder (which is returned by gfs2_glock_is_locked_by_me()) to LM_ST_EXCLUSIVE.  However, the lock would then remain locked in that state longer than necessary.  A better solution would be to recognize the self-recursion and to allow the task to hold the glock a second time.  In a LM_FLAG_TRY situation, we could even try to upgrade the glock.

This would reduce the number of gfs2_glock_is_locked_by_me() exceptions in the code.  I'm also convinced that gfs2_glock_is_locked_by_me() and gfs2_glock_is_held_*() are used in unsafe ways; reworking that would allow us to properly clean that up.

Examples are the locking in gfs2_update_time() and the retries in gfs2_fault() and gfs2_page_mkwrite() which would sometimes be avoidable.

Comment 2 RHEL Program Management 2022-11-19 07:27:41 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Comment 3 Andrew Price 2022-12-09 16:43:55 UTC
Reopening as no decision was made by a human to close this.


Note You need to log in before you can comment on or make changes to this bug.