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

On 2012年08月20日 13:33, Eric Dumazet wrote:

On Mon, 2012-08-20 at 12:40 +0800, Fan Du wrote:

quoted

Hi Eric

Please correct me if I'm wrong about below comments.

On 2012年08月19日 18:31, Eric Dumazet wrote:

quoted

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"

You are correct!

And one out of topic question:
The usage of xfrm_state_afinfo_lock/xfrm_km_lock is extremely
similar with xfrm_policy_afinfo_lock, except the former is not so
frequently read than that of the later.

Is it justified to convert RW xfrm_state_afinfo_lock/xfrm_km_lock into
RCU?

quoted

quoted

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.

I indeed misunderstood the code a bit.
Your explanation is crystal clear, thanks :)

-- 

Love each day!
--fan