Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sun, 29 Mar 2020 21:52:23 -0700 (PDT)
Message-Id: <20200329.215223.1631308723332593306.davem@davemloft.net>
To:     cai@lca.pw
Cc:     kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, kuba@kernel.org,
        eric.dumazet@gmail.com, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] ipv4: fix a RCU-list lock in fib_triestat_seq_show
From:   David Miller <davem@davemloft.net>
In-Reply-To: <20200325220100.7863-1-cai@lca.pw>
References: <20200325220100.7863-1-cai@lca.pw>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

From: Qian Cai <cai@lca.pw>
Date: Wed, 25 Mar 2020 18:01:00 -0400

> fib_triestat_seq_show() calls hlist_for_each_entry_rcu(tb, head,
> tb_hlist) without rcu_read_lock() will trigger a warning,
> 
>  net/ipv4/fib_trie.c:2579 RCU-list traversed in non-reader section!!
> 
>  other info that might help us debug this:
> 
>  rcu_scheduler_active = 2, debug_locks = 1
>  1 lock held by proc01/115277:
>   #0: c0000014507acf00 (&p->lock){+.+.}-{3:3}, at: seq_read+0x58/0x670
> 
>  Call Trace:
>   dump_stack+0xf4/0x164 (unreliable)
>   lockdep_rcu_suspicious+0x140/0x164
>   fib_triestat_seq_show+0x750/0x880
>   seq_read+0x1a0/0x670
>   proc_reg_read+0x10c/0x1b0
>   __vfs_read+0x3c/0x70
>   vfs_read+0xac/0x170
>   ksys_read+0x7c/0x140
>   system_call+0x5c/0x68
> 
> Fix it by adding a pair of rcu_read_lock/unlock() and use
> cond_resched_rcu() to avoid the situation where walking of a large
> number of items  may prevent scheduling for a long time.
> 
> Signed-off-by: Qian Cai <cai@lca.pw>

Applied and queued up for -stable, thanks.