diff options
author | Bob Peterson <rpeterso@redhat.com> | 2021-08-19 20:51:23 +0200 |
---|---|---|
committer | Andreas Gruenbacher <agruenba@redhat.com> | 2021-10-20 19:33:08 +0200 |
commit | dc732906c2450939c319fec6e258aa89ecb5a632 (patch) | |
tree | 25a8e7ebcda582f2d387d5477b29b37b036e6eac /fs/gfs2/file.c | |
parent | gfs2: Clean up function may_grant (diff) | |
download | linux-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