summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/export-to-postgresql.py
diff options
context:
space:
mode:
authorAndreas Gruenbacher <agruenba@redhat.com>2024-04-09 14:54:26 +0300
committerAndreas Gruenbacher <agruenba@redhat.com>2024-04-24 20:46:38 +0300
commit7a1ad9d8120e3d510ee5de8924f14de089aa2e2d (patch)
treedc0e43baac75d7d453a1181dab461f0cfe129539 /tools/perf/scripts/python/export-to-postgresql.py
parentacf1f42faf5a27913eb7b8140cc255f1b3d14e48 (diff)
downloadlinux-7a1ad9d8120e3d510ee5de8924f14de089aa2e2d.tar.xz
gfs2: Fix lru_count accounting
Currently, gfs2_scan_glock_lru() decrements lru_count when a glock is moved onto the dispose list. When such a glock is then stolen from the dispose list while gfs2_dispose_glock_lru() doesn't hold the lru_lock, lru_count will be decremented again, so the counter will eventually go negative. This bug has existed in one form or another since at least commit 97cc1025b1a91 ("GFS2: Kill two daemons with one patch"). Fix this by only decrementing lru_count when we actually remove a glock and schedule for it to be unlocked and dropped. We also don't need to remove and then re-add glocks when we can just as well move them back onto the lru_list when necessary. In addition, return the number of glocks freed as we should, not the number of glocks moved onto the dispose list. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions