From: Jarek Poplawski <[EMAIL PROTECTED]> Date: Mon, 21 Aug 2006 10:16:43 +0200
> On 17-08-2006 11:36, Alexey Kuznetsov wrote: > > 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 <[EMAIL PROTECTED]>. Why do we need lockdep, > > when sharp-sighted eyes are available? :-) > > > >> 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. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html