On Tue, Apr 30, 2019 at 02:33:22PM +0200, Florian Westphal wrote:
> Following splat gets triggered when nfnetlink monitor is running while
> xtables-nft selftests are running:
>
> net/netfilter/nf_tables_api.c:1272 suspicious rcu_dereference_check() usage!
> other info that might help us debug this:
>
> 1 lock held by xtables-nft-mul/27006:
> #0: 00000000e0f85be9 (&net->nft.commit_mutex){+.+.}, at: nf_tables_valid_genid+0x1a/0x50
> Call Trace:
> nf_tables_fill_chain_info.isra.45+0x6cc/0x6e0
> nf_tables_chain_notify+0xf8/0x1a0
> nf_tables_commit+0x165c/0x1740
>
> nf_tables_fill_chain_info() can be called both from dumps (rcu read locked)
> or from the transaction path if a userspace process subscribed to nftables
> notifications.
>
> In the 'table dump' case, rcu_access_pointer() cannot be used: We do not
> hold transaction mutex so the pointer can be NULLed right after the check.
> Just unconditionally fetch the value, then have the helper return
> immediately if its NULL.
>
> In the notification case we don't hold the rcu read lock, but updates are
> prevented due to transaction mutex. Use rcu_dereference_check() to make lockdep
> aware of this.
Applied, thanks Florian.
