netdev
[Top] [All Lists]

Re: 2.6.13-rc5-mm1: BUG: rwlock recursion on CPU#0

To: Harald Welte <laforge@xxxxxxxxxxxxx>
Subject: Re: 2.6.13-rc5-mm1: BUG: rwlock recursion on CPU#0
From: Zwane Mwaikambo <zwane@xxxxxxxxxxxxxxxx>
Date: Mon, 15 Aug 2005 08:25:51 -0600 (MDT)
Cc: Andrew Morton <akpm@xxxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>, netdev@xxxxxxxxxxx, "Rafael J. Wysocki" <rjw@xxxxxxx>
In-reply-to: <20050815093714.GB4439@rama.de.gnumonks.org>
References: <200508141448.36562.rjw@sisk.pl> <Pine.LNX.4.61.0508141940200.6740@montezuma.fsmlabs.com> <20050815093714.GB4439@rama.de.gnumonks.org>
Sender: netdev-bounce@xxxxxxxxxxx
On Mon, 15 Aug 2005, Harald Welte wrote:

> On Sun, Aug 14, 2005 at 08:15:53PM -0600, Zwane Mwaikambo wrote:
> 
> > Is the following patch correct? ip_conntrack_event_cache should never be 
> > called with ip_conntrack_lock held and ct_add_counters does not need to be 
> > called with ip_conntrack_lock held.
> 
> No, it's not correct.  ct_add_countes has to be called from within
> write_lock_bh() on ip_conntrack_lock.
> 
> So if you keep the ct_add_counters() call where it is and only apply the
> rest of your patch (i.e. deferring of ip_conntrack_event_cache() call),
> then I think your patch would work.
> 
> However, the whole eventcache needs to be audited, it's called from a
> number of places.
> 
> As Patrick wrote he's working on a solution, I'm not going to intervene
> or replicate his work.  As a interim solution I'd suggest disabling
> CONFIG_IP_NF_CT_ACCT [which can't be vital anyway, since it was only
> added in net-2.6.14 (and thus -mm)].

Thanks for the explanation Harald, i based the ct_add_counters assumption 
on other callers of it.

Thanks,
        Zwane


<Prev in Thread] Current Thread [Next in Thread>