On 29 March 2018 at 17:41, Herbert Xu wrote:
> On Thu, Mar 29, 2018 at 03:15:54PM +0200, Andreas Gruenbacher wrote:
>>
>> For all I know, Neil's latest plan is to get rhashtable_walk_peek
>> replaced and removed because it is unfixable. This patch removes the
>> o
On 29 March 2018 at 14:35, Herbert Xu wrote:
> On Thu, Mar 29, 2018 at 02:06:10PM +0200, 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 lock
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
Put a lockref unless the lockref is dead or its count would become zero.
This is the same as lockref_put_or_lock except that the lock is never
left held.
Signed-off-by: Andreas Gruenbacher
---
include/linux/lockref.h | 1 +
lib/lockref.c | 28
2 files
ction 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 Grue
glock in the seq file iterator functions instead.
Signed-off-by: Andreas Gruenbacher
---
fs/gfs2/glock.c | 47 ---
1 file changed, 28 insertions(+), 19 deletions(-)
diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
index 82fb5583445c..097bd3c0f270 100644
On 28 March 2018 at 23:53, NeilBrown wrote:
> Thank for this patch!
> The above looks a bit fragile to me.
> gfs2_glock_iter_next() (And hence gfs2_glock_seq_start()) will sometimes
> exit with gl_held true, and sometimes with it false.
> gfs2_glock_seq_stop() assumes that it is false.
> Normally
, keep track of the current glock in the seq file
iterator functions.
Signed-off-by: Andreas Gruenbacher
---
fs/gfs2/glock.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
index 82fb5583445c..f1fc353875d3 100644
--- a/fs
On 19 December 2017 at 00:38, Herbert Xu wrote:
> On Mon, Dec 18, 2017 at 02:31:21PM +0100, Andreas Gruenbacher wrote:
>> When iterating through an rhashtable is stopped with
>> rhashtable_walk_stop and then resumed with rhashtable_walk_start, there
>> currently is no w
#x27;t fit
previously will be revisited.
Signed-off-by: Andreas Gruenbacher
---
include/linux/rhashtable.h | 1 +
lib/rhashtable.c | 17 +
2 files changed, 18 insertions(+)
diff --git a/include/linux/rhashtable.h b/include/linux/rhashtable.h
index 361c08e35dbc..1a1608bc5
Clarify that rhashtable_walk_{stop,start} will not reset the iterator to
the beginning of the hash table. Confusion between rhashtable_walk_enter
and rhashtable_walk_start has already lead to a bug.
Signed-off-by: Andreas Gruenbacher
---
lib/rhashtable.c | 9 +
1 file changed, 5
Add rhashtable_lookup_get_insert_fast for fixed keys, similar to
rhashtable_lookup_get_insert_key for explicit keys.
Signed-off-by: Andreas Gruenbacher
Acked-by: Herbert Xu
---
include/linux/rhashtable.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/include/linux
On Wednesday 07 November 2007 20:42, Vlad Yasevich wrote:
> The reason is that 2 different hosts may have the same link-local
> address as long as they are on different links. If the sender is
> connected to both links then it may send the packet to the wrong
> destination.
Good point.
What's co
13 matches
Mail list logo
