Re: [PATCH net-next] xfrm: fix RCU bugs

[Eric Dumazet <eric.dumazet@gmail.com>]

On Mon, 2012-08-20 at 12:40 +0800, Fan Du wrote:
> Hi Eric
> 
> Please correct me if I'm wrong about below comments.
> 
> On 2012年08月19日 18:31, Eric Dumazet wrote:
> > From: Eric Dumazet<edumazet@google.com>
> >
> > This patch reverts commit 56892261ed1a (xfrm: Use rcu_dereference_bh to
> > deference pointer protected by rcu_read_lock_bh), and fixes bugs
> > introduced in commit 418a99ac6ad ( Replace rwlock on xfrm_policy_afinfo
> > with rcu )
> >
> > 1) We properly use RCU variant in this file, not a mix of RCU/RCU_BH
> >
> > 2) We must defer some writes after the synchronize_rcu() call or a reader
> >   can crash dereferencing NULL pointer.
> 
> Not exactly.
> 
> net/ipv4/xfrm4_policy.c
> static void __exit xfrm4_policy_fini(void)
>    -> xfrm_policy_unregister_afinfo
> 
> IMHO, ip stack can never be compiled as module, so is xfrm4_policy_fini
> freed up after system bootup? which means xfrm4_policy_fini can never be
> called.
> 
> so an dereferencing NULL pointer by a reader could not happen.
> 

Last famous words.

Anyway xfrm_policy_unregister_afinfo() is also called from
xfrm6_policy_fini(), and IPv6 is a module. The day we can rmmod it,
we uncover this bug.

RCU is complex (most people dont get it right, thats the truth),
and we should make it rock solid, or I can guarantee you
many patch attempts from future readers of this code.

You wont tell them :

"OK but dont worry we never call this function for real, why do you care
at all"

> >
> > 3) Now we use the xfrm_policy_afinfo_lock spinlock only from process
> > context, we no longer need to block BH in xfrm_policy_register_afinfo()
> > and xfrm_policy_unregister_afinfo()
> >
> I don't think it's related to what kinds of locks we are using.
> we call xfrm_policy_register_afinfo in process context, but actually
> what xfrm_policy_afinfo_lock protected can be used in soft irq context.
> that's why xx_bh is used in:

You did an RCU conversion and obviously have little idea of what
happened there.

This _bh stuff was needed because _before_ RCU, an rwlock was used.

And since read_lock() was used from BH handler, _all_ write_lock() had
to use the write_lock_bh() variant to avoid a possible deadlock.

But after RCU, this no longer is needed, as an rcu_read_lock() cannot
block a writer anymore in the lock/unlock section.

In fact, xfrm_policy_afinfo_lock could be replaced by a mutex. So _bh()
is absolutely not needed anymore.