summaryrefslogtreecommitdiffstats
path: root/fs/gfs2/file.c
diff options
context:
space:
mode:
authorBob Peterson <rpeterso@redhat.com>2021-08-19 20:51:23 +0200
committerAndreas Gruenbacher <agruenba@redhat.com>2021-10-20 19:33:08 +0200
commitdc732906c2450939c319fec6e258aa89ecb5a632 (patch)
tree25a8e7ebcda582f2d387d5477b29b37b036e6eac /fs/gfs2/file.c
parentgfs2: Clean up function may_grant (diff)
downloadlinux-dc732906c2450939c319fec6e258aa89ecb5a632.tar.xz
linux-dc732906c2450939c319fec6e258aa89ecb5a632.zip
gfs2: Introduce flag for glock holder auto-demotion
This patch introduces a new HIF_MAY_DEMOTE flag and infrastructure that will allow glocks to be demoted automatically on locking conflicts. When a locking request comes in that isn't compatible with the locking state of an active holder and that holder has the HIF_MAY_DEMOTE flag set, the holder will be demoted before the incoming locking request is granted. Note that this mechanism demotes active holders (with the HIF_HOLDER flag set), while before we were only demoting glocks without any active holders. This allows processes to keep hold of locks that may form a cyclic locking dependency; the core glock logic will then break those dependencies in case a conflicting locking request occurs. We'll use this to avoid giving up the inode glock proactively before faulting in pages. Processes that allow a glock holder to be taken away indicate this by calling gfs2_holder_allow_demote(), which sets the HIF_MAY_DEMOTE flag. Later, they call gfs2_holder_disallow_demote() to clear the flag again, and then they check if their holder is still queued: if it is, they are still holding the glock; if it isn't, they can re-acquire the glock (or abort). Signed-off-by: Bob Peterson <rpeterso@redhat.com> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Diffstat (limited to 'fs/gfs2/file.c')
0 files changed, 0 insertions, 0 deletions