lkml.org 
[lkml]   [2020]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] ipv4: fix a RCU-list lock in fib_triestat_seq_show
Date


> On Mar 25, 2020, at 12:13 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> I would prefer :
>
> diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
> index ff0c24371e3309b3068980f46d1ed743337d2a3e..4b98ffb27136d3b43f179d6b1b42fe84586acc06 100644
> --- a/net/ipv4/fib_trie.c
> +++ b/net/ipv4/fib_trie.c
> @@ -2581,6 +2581,7 @@ static int fib_triestat_seq_show(struct seq_file *seq, void *v)
> struct hlist_head *head = &net->ipv4.fib_table_hash[h];
> struct fib_table *tb;
>
> + rcu_read_lock();
> hlist_for_each_entry_rcu(tb, head, tb_hlist) {
> struct trie *t = (struct trie *) tb->tb_data;
> struct trie_stat stat;
> @@ -2596,6 +2597,7 @@ static int fib_triestat_seq_show(struct seq_file *seq, void *v)
> trie_show_usage(seq, t->stats);
> #endif
> }
> + rcu_read_unlock();
> }
>
> return 0;

I have no strong opinion either way. My initial thought was to save 255 extra lock/unlock with a single lock/unlock, but I am not sure how time-consuming for each iteration of the outer loop could be. If it could take a bit too long, it does make a lot of sense to reduce the critical section.
\
 
 \ /
  Last update: 2020-03-25 18:36    [W:0.056 / U:20.728 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site