Re: lockdep warning
On Fri, 22 Feb 2008, Anders Eriksson wrote: I found this is a newly booted 2.6.25-rc2's syslog. Feb 21 20:46:33 tippex BUG: rwlock wrong owner on CPU#0, runscript.sh/2633, d2c04084 Feb 21 20:46:33 tippex Pid: 2633, comm: runscript.sh Not tainted 2.6.25-rc2 #3 Feb 21 20:46:33 tippex [c02342d0] rwlock_bug+0x50/0x60 Feb 21 20:46:33 tippex [c0234356] _raw_write_unlock+0x56/0x60 Feb 21 20:46:33 tippex [c040365d] _write_unlock+0x1d/0x50 Feb 21 20:46:33 tippex [c03289be] neigh_timer_handler+0x18e/0x2d0 Feb 21 20:46:33 tippex [c0125449] run_timer_softirq+0x119/0x180 Feb 21 20:46:33 tippex [c013856d] ? lock_release_holdtime+0x5d/0x80 Feb 21 20:46:33 tippex [c0328830] ? neigh_timer_handler+0x0/0x2d0 Feb 21 20:46:33 tippex [c0121a64] __do_softirq+0x54/0xb0 Feb 21 20:46:33 tippex [c0121af5] do_softirq+0x35/0x40 Feb 21 20:46:33 tippex [c0121cb4] irq_exit+0x44/0x50 Feb 21 20:46:33 tippex [c0105757] do_IRQ+0x47/0x80 Feb 21 20:46:33 tippex [c01039c3] common_interrupt+0x23/0x28 Feb 21 20:46:33 tippex === This needs to be CCed to netdev. Any chance that git revert 69cc64d8d92 makes this report go away? -- Jiri Kosina SUSE Labs -- 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
Re: lockdep warning
On Fri, 22 Feb 2008, Anders Eriksson wrote:
This needs to be CCed to netdev.
Any chance that
git revert 69cc64d8d92
makes this report go away?
I'll have to install a git repo to check, or maybe you can send me the diff
to
reverse vs. 2.6.25-rc2?
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 7bb6a9a..a16cf1e 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -834,12 +834,18 @@ static void neigh_timer_handler(unsigned long arg)
}
if (neigh-nud_state (NUD_INCOMPLETE | NUD_PROBE)) {
struct sk_buff *skb = skb_peek(neigh-arp_queue);
-
+ /* keep skb alive even if arp_queue overflows */
+ if (skb)
+ skb_get(skb);
+ write_unlock(neigh-lock);
neigh-ops-solicit(neigh, skb);
atomic_inc(neigh-probes);
- }
+ if (skb)
+ kfree_skb(skb);
+ } else {
out:
- write_unlock(neigh-lock);
+ write_unlock(neigh-lock);
+ }
if (notify)
neigh_update_notify(neigh);
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index c663fa5..8e17f65 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -368,6 +368,7 @@ static void arp_solicit(struct neighbour *neigh, struct
sk_buff *skb)
if (!(neigh-nud_stateNUD_VALID))
printk(KERN_DEBUG trying to ucast probe in
NUD_INVALID\n);
dst_ha = neigh-ha;
+ read_lock_bh(neigh-lock);
} else if ((probes -= neigh-parms-app_probes) 0) {
#ifdef CONFIG_ARPD
neigh_app_ns(neigh);
@@ -377,6 +378,8 @@ static void arp_solicit(struct neighbour *neigh, struct
sk_buff *skb)
arp_send(ARPOP_REQUEST, ETH_P_ARP, target, dev, saddr,
dst_ha, dev-dev_addr, NULL);
+ if (dst_ha)
+ read_unlock_bh(neigh-lock);
}
static int arp_ignore(struct in_device *in_dev, __be32 sip, __be32 tip)
--
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
Re: lockdep warning
[EMAIL PROTECTED] said: Any chance that git revert 69cc64d8d92 makes this report go away? I've tested the patch and I no longer get that lock thing in my syslog. /A -- 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
Re: lockdep warning
On Fri, 22 Feb 2008, Anders Eriksson wrote: Any chance that git revert 69cc64d8d92 makes this report go away? I've tested the patch and I no longer get that lock thing in my syslog. Thanks for verification. Hmm, I don't immediately see how this patch could make neigh-lock owner to change between lock and unlock ... I have skimmed through the solicit methods, and they don't seem to be doing anything nasty to neigh ... The scenario I was thinking about is that before 69cc64d8d92, if any of the _solicit methods could do anything bad to neigh struct, this warning wouldn't trigger, because the lock has been dropped before calling _solicit() and reacquired later, so no mismatch on -current could happen, but now as long as the lock is held during _solicit() call, this would trigger on the next unlock. But I am not able to see anything like that in the code. Dave, do you have any idea? (the thread started at http://lkml.org/lkml/2008/2/22/105). -- Jiri Kosina SUSE Labs -- 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
