- Original Message -
> 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_g
On Wed, Apr 04 2018, Andreas Grünbacher wrote:
> Herbert Xu schrieb am Mi. 4. Apr. 2018 um
> 17:51:
>
>> On Wed, Apr 04, 2018 at 11:46:28AM -0400, Bob Peterson wrote:
>> >
>> > The patches look good. The big question is whether to add them to this
>> > merge window while it's still open. Opinions
On Wed, Apr 04, 2018 at 11:46:28AM -0400, Bob Peterson wrote:
>
> The patches look good. The big question is whether to add them to this
> merge window while it's still open. Opinions?
We're still hashing out the rhashtable interface so I don't think
now is the time to rush things.
Thanks,
--
Em
- Original Message -
> 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_g
On 29 March 2018 at 14:24, Steven Whitehouse wrote:
> 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 dur
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
