[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5127BAD2.1040007@oracle.com>
Date: Fri, 22 Feb 2013 13:37:06 -0500
From: Sasha Levin <sasha.levin@...cle.com>
To: Antonio Quartulli <ordex@...istici.org>
CC: Marek Lindner <lindner_marek@...oo.de>,
Simon Wunderlich <siwu@....tu-chemnitz.de>,
"David S. Miller" <davem@...emloft.net>,
b.a.t.m.a.n@...ts.open-mesh.org, netdev@...r.kernel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Dave Jones <davej@...hat.com>
Subject: Re: batman-adv: gpf in batadv_slide_own_bcast_window
On 02/22/2013 12:06 PM, Antonio Quartulli wrote:
> Hi Sasha and thank you very much for reporting this issue.
>
> IIRC this is similar to a bug you already reported in the past.
> This bug should be the result of a race condition batman-adv has in the
> hard-interface handling code (this is why it has been triggered while removing
> eth0).
>
> Now that the rtnl-deadlock has been solved I think we can try to further
> investigate on this bug and try to find a solution..though it will not be easy
> as it probably requires another lock to protect the hard-interface during this
> operations.
>
> If you have any fix proposal feel free to contribute!
I'm confused about how batadv_orig_hash_del_if removes an interface from the
hashtable. I see the hashtable is using rcu to protect it, but when we
delete an entry we free it straight away by calling batadv_orig_node_del_if()
and not going through kfree_rcu().
Is there a reason behind doing that, or might it be the cause of the problem
we're seeing here?
Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists