Re: [Cluster-devel] [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek

From: Steven Whitehouse
Date: Thu Mar 29 2018 - 08:24:18 EST


Hi,

Can we solve the problem another way, by not taking refs on the glocks when we are iterating over them for the debugfs files? I assume that is the main issue here.

We didn't used to take refs since the rcu locking was enough during the walk itself. We used to only keep track of the hash bucket and offset within the bucket when we dropped the rcu lock between calls to the iterator. I may have lost track of why that approach did not work?

Steve.


On 29/03/18 13:06, Andreas Gruenbacher wrote:
Here's a second version of the patch (now a patch set) to eliminate
rhashtable_walk_peek in gfs2.

The first patch introduces lockref_put_not_zero, the inverse of
lockref_get_not_zero.

The second patch eliminates rhashtable_walk_peek in gfs2. In
gfs2_glock_iter_next, the new lockref function from patch one is used to
drop a lockref count as long as the count doesn't drop to zero. This is
almost always the case; if there is a risk of dropping the last
reference, we must defer that to a work queue because dropping the last
reference may sleep.

Thanks,
Andreas

Andreas Gruenbacher (2):
lockref: Add lockref_put_not_zero
gfs2: Stop using rhashtable_walk_peek

fs/gfs2/glock.c | 47 ++++++++++++++++++++++++++++-------------------
include/linux/lockref.h | 1 +
lib/lockref.c | 28 ++++++++++++++++++++++++++++
3 files changed, 57 insertions(+), 19 deletions(-)