diff options
author | Qian Cai <cai@lca.pw> | 2020-03-25 18:01:00 -0400 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2020-04-13 10:34:14 +0200 |
commit | 545d7421fb06364bd17305c5fb9565e7f1e7995e (patch) | |
tree | cc58ba73c67ec60778b4adae8c2297fecb7834bf /lib/audit.c | |
parent | 4520f06b03ae667e442da1ab9351fd28cd7ac598 (diff) | |
download | linux-stable-545d7421fb06364bd17305c5fb9565e7f1e7995e.tar.gz linux-stable-545d7421fb06364bd17305c5fb9565e7f1e7995e.tar.bz2 linux-stable-545d7421fb06364bd17305c5fb9565e7f1e7995e.zip |
ipv4: fix a RCU-list lock in fib_triestat_seq_show
[ Upstream commit fbe4e0c1b298b4665ee6915266c9d6c5b934ef4a ]
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>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'lib/audit.c')
0 files changed, 0 insertions, 0 deletions