Re: [PATCH] locking bug in fib_semantics.c

From: Jarek Poplawski <redacted>
Date: Mon, 21 Aug 2006 10:16:43 +0200

On 17-08-2006 11:36, Alexey Kuznetsov wrote:

quoted

Hello!

[IPV4]: severe locking bug in fib_semantics.c

The patch is for net-2.6.19, but the bug is present in all the kernels
since yore.

Found in 2.4 by Yixin Pan [off-list ref]. Why do we need lockdep,
when sharp-sighted eyes are available? :-)

quoted

When I read fib_semantics.c of Linux-2.4.32, write_lock(&fib_info_lock) =
is used in fib_release_info() instead of write_lock_bh(&fib_info_lock).  =
Is the following case possible: a BH interrupts fib_release_info() while =
holding the write lock, and calls ip_check_fib_default() which calls =
read_lock(&fib_info_lock), and spin forever.

But I hope the real reason for this patch isn't exactly like that.
Could fib_release_info() be interrupted by BH really?

Absolutely, yes it can.  What makes you think it can't?

All of the call sites I have checked cause it to run with
BH's enabled, and that allows ip_fib_check_default() to
potentially run.  All we need is one such case to cause
the deadlock.

I was skeptical of this case too, until I checked how
fib_release_info() was called.