* Re: bridge netfilter output bug on 2.6.39
From: David Miller @ 2011-05-24 17:30 UTC (permalink / raw)
To: eric.dumazet; +Cc: shemminger, herbert, netdev
In-Reply-To: <1306251543.3026.57.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 24 May 2011 17:39:03 +0200
> [PATCH] net: fix __dst_destroy_metrics_generic()
>
> dst_default_metrics is readonly, we dont want to kfree() it later.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Good catch, applied, thanks.
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree
From: Linus Torvalds @ 2011-05-24 17:29 UTC (permalink / raw)
To: Mike Frysinger
Cc: Stephen Rothwell, linux-next, linux-kernel, David S. Miller,
netdev, Andrew Morton, Mel Gorman, linux-mm, Alexander Viro,
linux-fsdevel, Paul E. McKenney, Dipankar Sarma, Balbi, Felipe
In-Reply-To: <BANLkTi=U8ikZo65AoxGznCopGMTFOUXWhQ@mail.gmail.com>
On Tue, May 24, 2011 at 10:10 AM, Mike Frysinger <vapier.adi@gmail.com> wrote:
>
> latest tree seems to only fail for me now on the musb driver. i can
> send out a patch later today if no one else has gotten to it yet.
Please do.
I did a
grep -L linux/prefetch.h $(git grep -l '[^a-z_]prefetchw*(' -- '*.[ch]')
but there are drivers out there that have that "prefetch()" pattern
without being about actual CPU prefetching at all (see for example
drivers/ide/cmd640.c), so once I got allyesconfig with my x86
detection hack going, I didn't bother with the few odd men out.
Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v4] CDC NCM: release interfaces fix in unbind()
From: David Miller @ 2011-05-24 17:28 UTC (permalink / raw)
To: alexey.orishko-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, oliver-GvhC2dPhHPQdnm+yROfE0A,
linux-usb-u79uwXL29TY76Z2rM5mHXA, gregkh-l3A5Bk7waGM,
alexey.orishko-0IS4wlFg1OjSUeElwK9/Pw
In-Reply-To: <1306250773-9177-1-git-send-email-alexey.orishko-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
From: Alexey Orishko <alexey.orishko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Tue, 24 May 2011 17:26:13 +0200
> Changes:
> - claim slave/data interface during bind() and release
> interfaces in unbind() unconditionally
> - in case of error during bind(), release claimed data
> interface in the same function
> - remove obsolited "*_claimed" entries from driver context
>
> Signed-off-by: Alexey Orishko <alexey.orishko-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-2.6] bnx2x: fix inverted condition
From: David Miller @ 2011-05-24 17:28 UTC (permalink / raw)
To: dmitry; +Cc: netdev, eilong
In-Reply-To: <1306238767.9193.1.camel@lb-tlvb-dmitry>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Tue, 24 May 2011 15:06:06 +0300
>
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: use synchronize_rcu_expedited()
From: David Miller @ 2011-05-24 17:28 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, paulmck
In-Reply-To: <1306228052.3026.16.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 24 May 2011 11:07:32 +0200
> synchronize_rcu() is very slow in various situations (HZ=100,
> CONFIG_NO_HZ=y, CONFIG_PREEMPT=n)
>
> Extract from my (mostly idle) 8 core machine :
...
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH v4 1/1] igmp: call ip_mc_clear_src() only when we have no users of ip_mc_list
From: David Miller @ 2011-05-24 17:28 UTC (permalink / raw)
To: vfalico
Cc: dlstevens, jmorris, kaber, kuznet, linux-kernel, mmarek, netdev,
netdev-owner, pekkas, yoshfuji
In-Reply-To: <20110524091505.GA21550@darkmag.usersys.redhat.com>
From: Veaceslav Falico <vfalico@redhat.com>
Date: Tue, 24 May 2011 11:15:05 +0200
> In igmp_group_dropped() we call ip_mc_clear_src(), which resets the number
> of source filters per mulitcast. However, igmp_group_dropped() is also
> called on NETDEV_DOWN, NETDEV_PRE_TYPE_CHANGE and NETDEV_UNREGISTER, which
> means that the group might get added back on NETDEV_UP, NETDEV_REGISTER and
> NETDEV_POST_TYPE_CHANGE respectively, leaving us with broken source
> filters.
>
> To fix that, we must clear the source filters only when there are no users
> in the ip_mc_list, i.e. in ip_mc_dec_group() and on device destroy.
>
> Acked-by: David L Stevens <dlstevens@us.ibm.com>
> Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Applied.
^ permalink raw reply
* Re: net: enable dynamic lro disabling for vlans
From: Ben Hutchings @ 2011-05-24 17:22 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, davem
In-Reply-To: <1306257314-3925-1-git-send-email-nhorman@tuxdriver.com>
On Tue, 2011-05-24 at 13:15 -0400, Neil Horman wrote:
> Hey there-
> Noted recently that, while physical devices have lro disabled when
> attached to a bridge, vlan devices do not.
Good point.
> This is because the vlan netdev has
> no get/set flags method in its ethtool_ops struct. This series adds those
> methods as passthrough calls to the underlying physical devices, so that whe
> dev_disable_lro is called on a vlan device, the physical device underneath has
> lro properly disabled.
But I don't think this is correct.
The get_flags() result should be masked with vlan_features. And
set_flags() shouldn't be allowed; the VLAN device should normally follow
the parent device and not the other way round. I think
dev_disable_lro() needs to handle VLAN devices explicitly, instead.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [patch 1/1] net: convert %p usage to %pK
From: David Miller @ 2011-05-24 17:18 UTC (permalink / raw)
To: shemminger
Cc: eric.dumazet, joe, mingo, akpm, netdev, drosenberg, a.p.zijlstra,
eparis, eugeneteo, jmorris, kees.cook, tgraf
In-Reply-To: <20110524074355.422e12f9@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 24 May 2011 07:43:55 -0700
> Couldn't the pointer be replaced by a socket index?
Well, it's a pointer exactly so we don't have to index into a table.
^ permalink raw reply
* [PATCH 2/2] net: add passthrough ethtool commands for get/set flags to vlan dev
From: Neil Horman @ 2011-05-24 17:15 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, davem
In-Reply-To: <1306257314-3925-1-git-send-email-nhorman@tuxdriver.com>
Add ethtool command to the vlan driver so that when dev_disable_lro is called on
a vlan device, the disablement can be correctly passed down to the underlying
hardware
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: davem@davemloft.net
---
net/8021q/vlan_dev.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index f247f5b..611839b 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -648,10 +648,24 @@ static struct rtnl_link_stats64 *vlan_dev_get_stats64(struct net_device *dev, st
return stats;
}
+static u32 vlan_ethtool_get_flags (struct net_device *vdev)
+{
+ const struct vlan_dev_info *vlan = vlan_dev_info(vdev);
+ return dev_ethtool_get_flags(vlan->real_dev);
+}
+
+static int vlan_ethtool_set_flags(struct net_device *vdev, u32 flags)
+{
+ const struct vlan_dev_info *vlan = vlan_dev_info(vdev);
+ return dev_ethtool_set_flags(vlan->real_dev, flags);
+}
+
static const struct ethtool_ops vlan_ethtool_ops = {
.get_settings = vlan_ethtool_get_settings,
.get_drvinfo = vlan_ethtool_get_drvinfo,
.get_link = ethtool_op_get_link,
+ .get_flags = vlan_ethtool_get_flags,
+ .set_flags = vlan_ethtool_set_flags,
};
static const struct net_device_ops vlan_netdev_ops = {
--
1.7.5.1
^ permalink raw reply related
* [PATCH 1/2] net: add dev_ethtool_set_flags helper
From: Neil Horman @ 2011-05-24 17:15 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, davem
In-Reply-To: <1306257314-3925-1-git-send-email-nhorman@tuxdriver.com>
Add a helper to check for presence of a set_flags method in an ethtool_ops
structure and conditionally call it
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: davem@davemloft.net
---
include/linux/netdevice.h | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index ca333e7..243781c 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2624,6 +2624,13 @@ static inline u32 dev_ethtool_get_flags(struct net_device *dev)
return dev->ethtool_ops->get_flags(dev);
}
+static inline int dev_ethtool_set_flags(struct net_device *dev, u32 flags)
+{
+ if (!dev->ethtool_ops || !dev->ethtool_ops->set_flags)
+ return 0;
+ return dev->ethtool_ops->set_flags(dev, flags);
+}
+
/* Logging, debugging and troubleshooting/diagnostic helpers. */
/* netdev_printk helpers, similar to dev_printk */
--
1.7.5.1
^ permalink raw reply related
* net: enable dynamic lro disabling for vlans
From: Neil Horman @ 2011-05-24 17:15 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, davem
Hey there-
Noted recently that, while physical devices have lro disabled when
attached to a bridge, vlan devices do not. This is because the vlan netdev has
no get/set flags method in its ethtool_ops struct. This series adds those
methods as passthrough calls to the underlying physical devices, so that whe
dev_disable_lro is called on a vlan device, the physical device underneath has
lro properly disabled.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: davem@davemloft.net
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree
From: Mike Frysinger @ 2011-05-24 17:10 UTC (permalink / raw)
To: Linus Torvalds
Cc: Stephen Rothwell, linux-next, linux-kernel, David S. Miller,
netdev, Andrew Morton, Mel Gorman, linux-mm, Alexander Viro,
linux-fsdevel, Paul E. McKenney, Dipankar Sarma, Balbi, Felipe
In-Reply-To: <BANLkTim-zRShhy49d7yn5WTJYzR6A2DtZQ@mail.gmail.com>
On Tue, May 24, 2011 at 00:10, Mike Frysinger wrote:
> On Tue, May 24, 2011 at 00:01, Linus Torvalds wrote:
>> On Mon, May 23, 2011 at 7:06 PM, Mike Frysinger wrote:
>>>
>>> more failures:
>>
>> Is this blackfin or something?
>
> let's go with "something" ...
>
>> I did an allyesconfig with a special x86 patch that should have caught
>> everything that didn't have the proper prefetch.h include, but non-x86
>> drivers would have passed that.
>
> the isp1362-hcd failure probably is before your
> 268bb0ce3e87872cb9290c322b0d35bce230d88f. i think i was reading a log
> that is a few days old (ive been traveling and am playing catch up
> atm). i'll refresh and see what's what still.
>
> the common musb code only allows it to be built if the arch glue is
> available, and there is no x86 glue. so an allyesconfig on x86
> wouldnt have picked up the failure. it'll bomb though for any target
> which does have the glue.
latest tree seems to only fail for me now on the musb driver. i can
send out a patch later today if no one else has gotten to it yet.
-mike
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: bridge netfilter output bug on 2.6.39
From: Eric Dumazet @ 2011-05-24 16:46 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, Herbert Xu, netdev
In-Reply-To: <1306254457.3026.69.camel@edumazet-laptop>
Le mardi 24 mai 2011 à 18:27 +0200, Eric Dumazet a écrit :
> Le mardi 24 mai 2011 à 17:39 +0200, Eric Dumazet a écrit :
>
> > I would say its more likely a problem with dst metrics changes
> >
> > In this crash, we dereference a NULL dst->_metrics 'pointer' in
> > dst_metric_raw(dst, RTAX_MTU);
>
> It seems bridge code uses one fake_rtable
>
> You probably want to properly init its _metric field.
>
> I can do the patch in one hour eventually, if nobody beats me.
>
>
Here is the patch :
[PATCH] bridge: initialize fake_rtable metrics
bridge netfilter code uses a fake_rtable, and we must init its _metric
field or risk NULL dereference later.
Ref: https://bugzilla.kernel.org/show_bug.cgi?id=35672
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Stephen Hemminger <shemminger@vyatta.com>
CC: Herbert Xu <herbert@gondor.apana.org.au>
---
net/bridge/br_netfilter.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index e1f5ec7..3fa1231 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -117,6 +117,10 @@ static struct dst_ops fake_dst_ops = {
* ipt_REJECT needs it. Future netfilter modules might
* require us to fill additional fields.
*/
+static const u32 br_dst_default_metrics[RTAX_MAX] = {
+ [RTAX_MTU - 1] = 1500,
+};
+
void br_netfilter_rtable_init(struct net_bridge *br)
{
struct rtable *rt = &br->fake_rtable;
@@ -124,7 +128,7 @@ void br_netfilter_rtable_init(struct net_bridge *br)
atomic_set(&rt->dst.__refcnt, 1);
rt->dst.dev = br->dev;
rt->dst.path = &rt->dst;
- dst_metric_set(&rt->dst, RTAX_MTU, 1500);
+ dst_init_metrics(&rt->dst, br_dst_default_metrics, true);
rt->dst.flags = DST_NOXFRM;
rt->dst.ops = &fake_dst_ops;
}
^ permalink raw reply related
* Re: [RFC Patch] bonding: move to net/ directory
From: Neil Horman @ 2011-05-24 16:33 UTC (permalink / raw)
To: Américo Wang
Cc: Andy Gospodarek, Linux Kernel Network Developers, David Miller,
Jay Vosburgh
In-Reply-To: <BANLkTikT2HJyGb_4BOF+Ds1AAcJV+HVQ-w@mail.gmail.com>
On Tue, May 24, 2011 at 10:00:23PM +0800, Américo Wang wrote:
> On Mon, May 23, 2011 at 11:13 PM, Andy Gospodarek <andy@greyhouse.net> wrote:
> > On Mon, May 23, 2011 at 08:45:14PM +0800, Américo Wang wrote:
> >> Hello, Jay, Andy,
> >>
> >> Is there any peculiar reason that bonding code has to stay
> >> in drivers/net/ directory?
> >>
> >> Since bonding and bridge are somewhat similar, both of
> >> which are used to "bond" two or more devices into one,
> >> and bridge code is already in net/bridge/, so I think it also
> >> makes sense to move bonding code into net/bonding/ too.
> >>
> >> This could also help to grep the source more easily. :)
> >>
> >> What do you think about the patch below?
> >> (Note, this patch is against net-next-2.6.)
> >>
> >
> > I would rather keep the code for bonding in drivers/net since it is
> > really a pure device (though not directly tied to any specific
> > hardware) rather than a device + forwarding or management code.
>
> Is this a reason strong enough to leave it to drivers/net/ ?
> I think it is generic enough to be moved to net/ directory... :-/
>
> >
> > It has bothered me for a long time that the code just to manage the VLAN
> > and bridge devices sits outside of drivers/net, but I've never proposed
> > a patch to move the files as I suspect the maintainers of that code
> > would like to keep it all together. Maybe it is time to do that.
> >
>
> You mean move net/8021q/ to drivers/net/8021q/ ?
>
This all sounds like change for the sake of change to me. I don't see any
compelling argument for moving bonding (or bridging or vlans, etc) around at
all. All of these software drivers have feet in multple subsystems, but that
just means that theres not going to be a compelling argument to move them any
place, at least not without an immediate subsequent argument that it really
belonged back where it was. Unless you can show a solid benefit to moving the
code, I don't see why any reorganization is needed.
Neil
> Thanks!
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: bridge netfilter output bug on 2.6.39
From: Eric Dumazet @ 2011-05-24 16:27 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, Herbert Xu, netdev
In-Reply-To: <1306251543.3026.57.camel@edumazet-laptop>
Le mardi 24 mai 2011 à 17:39 +0200, Eric Dumazet a écrit :
> I would say its more likely a problem with dst metrics changes
>
> In this crash, we dereference a NULL dst->_metrics 'pointer' in
> dst_metric_raw(dst, RTAX_MTU);
It seems bridge code uses one fake_rtable
You probably want to properly init its _metric field.
I can do the patch in one hour eventually, if nobody beats me.
^ permalink raw reply
* Re: INFO: suspicious rcu_dereference_check() usage.
From: Justin P. Mattock @ 2011-05-24 16:22 UTC (permalink / raw)
To: Dave Jones, linux-kernel@vger.kernel.org, netdev
In-Reply-To: <20110524155608.GA17977@redhat.com>
On 05/24/2011 08:56 AM, Dave Jones wrote:
> On Mon, May 23, 2011 at 11:50:46PM -0700, Justin Mattock wrote:
>
> > [ 2862.310349] WARNING: at net/ipv4/route.c:1668 ip_rt_bug+0x5c/0x62()
>
> Awesome, adding that WARN_ON paid off. This is the same bug I've been trying
> to reproduce the last few weeks. DaveM mentioned that it means we used
> an input route for packet output.
>
> > [ 2862.310414] Pid: 6153, comm: gcm-session Not tainted
> > 2.6.39-04906-g5e152b4-dirty #2
> > [ 2862.310417] Call Trace:
> > [ 2862.310424] [<ffffffff8104c634>] warn_slowpath_common+0x83/0x9b
> > [ 2862.310430] [<ffffffff8104c666>] warn_slowpath_null+0x1a/0x1c
> > [ 2862.310434] [<ffffffff814095c9>] ip_rt_bug+0x5c/0x62
> > [ 2862.310439] [<ffffffff814112a1>] dst_output+0x19/0x1d
> > [ 2862.310443] [<ffffffff81412aa0>] ip_local_out+0x20/0x25
> > [ 2862.310448] [<ffffffff814139c9>] ip_send_skb+0x19/0x58
> > [ 2862.310453] [<ffffffff8142fa4e>] udp_send_skb+0x239/0x29b
> > [ 2862.310458] [<ffffffff814310f0>] udp_sendmsg+0x5a1/0x7d4
> > [ 2862.310464] [<ffffffff81079408>] ? trace_hardirqs_off+0xd/0xf
> > [ 2862.310469] [<ffffffff8141139c>] ? ip_select_ident+0x3d/0x3d
> > [ 2862.310475] [<ffffffff810525b8>] ? local_bh_enable_ip+0xe/0x10
> > [ 2862.310481] [<ffffffff8148f131>] ? _raw_spin_unlock_bh+0x31/0x35
> > [ 2862.310486] [<ffffffff813d41a6>] ? release_sock+0x14c/0x155
> > [ 2862.310490] [<ffffffff814386ac>] inet_sendmsg+0x66/0x6f
> > [ 2862.310495] [<ffffffff813d02b0>] sock_sendmsg+0xe6/0x109
> > [ 2862.310501] [<ffffffff8107d63f>] ? lock_acquire+0xe1/0x109
> > [ 2862.310505] [<ffffffff8107d535>] ? lock_release+0x1aa/0x1d3
> > [ 2862.310512] [<ffffffff810ed549>] ? might_fault+0xa5/0xac
> > [ 2862.310516] [<ffffffff813ceb34>] ? copy_from_user+0x2f/0x31
> > [ 2862.310521] [<ffffffff813d1f34>] sys_sendto+0x132/0x174
> > [ 2862.310526] [<ffffffff81495cfa>] ? sysret_check+0x2e/0x69
> > [ 2862.310531] [<ffffffff8107b016>] ? trace_hardirqs_on_caller+0x13f/0x172
> > [ 2862.310537] [<ffffffff8109fd4d>] ? audit_syscall_entry+0x11c/0x148
> > [ 2862.310542] [<ffffffff8121debe>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> > [ 2862.310546] [<ffffffff81495cc2>] system_call_fastpath+0x16/0x1b
> > [ 2862.310549] ---[ end trace 2d2332adaa8bf2b5 ]---
> > [ 2863.373889] ip_rt_bug: 10.0.0.10 -> 255.255.255.255, ?
>
> The common thing between your bug and the trace I triggered was the
> destination ip reported. A clue maybe ?
>
> Dave
>
>
there was a bug for http://marc.info/?l=linux-kernel&m=129913127722786&w=2
but looking I see something in there with recv.c not route.c but
probably something
same or in the same vacinity. as for the sluggishness I have been
noticing the system doing so, but
never saw anything like the above, so if it is your WARN_ON then kudos
to you!
Justin P. Mattock
^ permalink raw reply
* Re: kernel BUG at net/ipv4/tcp_output.c:1006!
From: Eric Dumazet @ 2011-05-24 16:20 UTC (permalink / raw)
To: TB; +Cc: David Miller, linux-kernel, netdev
In-Reply-To: <4DDBD834.6080804@techboom.com>
Le mardi 24 mai 2011 à 12:09 -0400, TB a écrit :
> That's all I'm expecting :)
>
> However we've got 3 servers that hung with a blank screen and no network
> over the weekend and nothing unusual in the net console
Oh well, it could be anything ...
^ permalink raw reply
* Re: 2.6.38.x, 2.6.39 sfq? kernel panic in sfq_enqueue
From: Vadym Abramchuk @ 2011-05-24 16:09 UTC (permalink / raw)
To: netdev
On Tue, 24 May 2011 15:17:49 +0200, Eric Dumazet wrote:
> Le mardi 24 mai 2011 à 01:35 +0300, Denys Fedoryshchenko a écrit :
>> On Mon, 23 May 2011 17:05:46 +0200, Eric Dumazet wrote:
>> > Le lundi 23 mai 2011 à 17:27 +0300, Denys Fedoryshchenko a écrit :
>> >
>> >> > Thanks !
>> >> By objdump or he must recompile kernel with DEBUG_INFO and use
>> gdb?
>> >>
>> >>
>> >>
>> >
>> >
>> > Just objdump of sch_sfq.o (or sch_sfq.ko) file, (to keep existing
>> > offsets), thanks
>> Sorry for delay, i had to contact person who run that kernel :)
>>
>> www.nuclearcat.com/files/disasm.txt
>> www.nuclearcat.com/files/sch_sfq.ko
>>
>>
>
> Thanks !
>
> BTW, does this person have another bug trace to feed us ?
>
> I tried to reproduce it here but failed.
>
> full dmesg might help too
Greetings.
This error is at my server and I'm 'that' person.
Denys' help is useful, but I decided to join the netlist myself to
stop annoying him. :)
I haven't been using mailing lists for a while, so I hope this mail
will get to the right thread.
Right now, the machine is closed at the server room so I'll be able to
get some more
debug info only tomorrow.
What more info can I supply besides dmesg? Maybe I should rebuild the
kernel with some
debug options enabled?
WBR, Vadym
^ permalink raw reply
* Re: kernel BUG at net/ipv4/tcp_output.c:1006!
From: TB @ 2011-05-24 16:09 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, linux-kernel, netdev
In-Reply-To: <1305825086.3028.84.camel@edumazet-laptop>
On 11-05-19 01:11 PM, Eric Dumazet wrote:
> Le jeudi 19 mai 2011 à 13:08 -0400, TB a écrit :
>> On 11-05-13 04:01 PM, David Miller wrote:
>>> From: Eric Dumazet <eric.dumazet@gmail.com>
>>> Date: Fri, 13 May 2011 21:47:38 +0200
>>>
>>>> I suspect we should push commit 2fceec13375e5d98 (tcp: len check is
>>>> unnecessarily devastating, change to WARN_ON) to stable if not already
>>>> done...
>>>>
>>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2fceec13375e5d98
>>>>
>>>> David, is this commit in your stable queue ?
>>>
>>> No, but now it is.
>>
>> We've put this commit with the previous tcp_cubic patch on 60 of our
>> servers and we're waiting to see how it goes.
>
> Dont expect too much. It only permits to survive after logging messages,
> instead of halting machine ;)
That's all I'm expecting :)
However we've got 3 servers that hung with a blank screen and no network
over the weekend and nothing unusual in the net console
^ permalink raw reply
* Re: INFO: suspicious rcu_dereference_check() usage.
From: Dave Jones @ 2011-05-24 15:56 UTC (permalink / raw)
To: Justin Mattock; +Cc: linux-kernel@vger.kernel.org, netdev
In-Reply-To: <BANLkTinC=2wxtYD4YmePgOfoLSh9STD6Sw@mail.gmail.com>
On Mon, May 23, 2011 at 11:50:46PM -0700, Justin Mattock wrote:
> [ 2862.310349] WARNING: at net/ipv4/route.c:1668 ip_rt_bug+0x5c/0x62()
Awesome, adding that WARN_ON paid off. This is the same bug I've been trying
to reproduce the last few weeks. DaveM mentioned that it means we used
an input route for packet output.
> [ 2862.310414] Pid: 6153, comm: gcm-session Not tainted
> 2.6.39-04906-g5e152b4-dirty #2
> [ 2862.310417] Call Trace:
> [ 2862.310424] [<ffffffff8104c634>] warn_slowpath_common+0x83/0x9b
> [ 2862.310430] [<ffffffff8104c666>] warn_slowpath_null+0x1a/0x1c
> [ 2862.310434] [<ffffffff814095c9>] ip_rt_bug+0x5c/0x62
> [ 2862.310439] [<ffffffff814112a1>] dst_output+0x19/0x1d
> [ 2862.310443] [<ffffffff81412aa0>] ip_local_out+0x20/0x25
> [ 2862.310448] [<ffffffff814139c9>] ip_send_skb+0x19/0x58
> [ 2862.310453] [<ffffffff8142fa4e>] udp_send_skb+0x239/0x29b
> [ 2862.310458] [<ffffffff814310f0>] udp_sendmsg+0x5a1/0x7d4
> [ 2862.310464] [<ffffffff81079408>] ? trace_hardirqs_off+0xd/0xf
> [ 2862.310469] [<ffffffff8141139c>] ? ip_select_ident+0x3d/0x3d
> [ 2862.310475] [<ffffffff810525b8>] ? local_bh_enable_ip+0xe/0x10
> [ 2862.310481] [<ffffffff8148f131>] ? _raw_spin_unlock_bh+0x31/0x35
> [ 2862.310486] [<ffffffff813d41a6>] ? release_sock+0x14c/0x155
> [ 2862.310490] [<ffffffff814386ac>] inet_sendmsg+0x66/0x6f
> [ 2862.310495] [<ffffffff813d02b0>] sock_sendmsg+0xe6/0x109
> [ 2862.310501] [<ffffffff8107d63f>] ? lock_acquire+0xe1/0x109
> [ 2862.310505] [<ffffffff8107d535>] ? lock_release+0x1aa/0x1d3
> [ 2862.310512] [<ffffffff810ed549>] ? might_fault+0xa5/0xac
> [ 2862.310516] [<ffffffff813ceb34>] ? copy_from_user+0x2f/0x31
> [ 2862.310521] [<ffffffff813d1f34>] sys_sendto+0x132/0x174
> [ 2862.310526] [<ffffffff81495cfa>] ? sysret_check+0x2e/0x69
> [ 2862.310531] [<ffffffff8107b016>] ? trace_hardirqs_on_caller+0x13f/0x172
> [ 2862.310537] [<ffffffff8109fd4d>] ? audit_syscall_entry+0x11c/0x148
> [ 2862.310542] [<ffffffff8121debe>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [ 2862.310546] [<ffffffff81495cc2>] system_call_fastpath+0x16/0x1b
> [ 2862.310549] ---[ end trace 2d2332adaa8bf2b5 ]---
> [ 2863.373889] ip_rt_bug: 10.0.0.10 -> 255.255.255.255, ?
The common thing between your bug and the trace I triggered was the
destination ip reported. A clue maybe ?
Dave
^ permalink raw reply
* Re: [PATCH] net: use synchronize_rcu_expedited()
From: Eric Dumazet @ 2011-05-24 15:52 UTC (permalink / raw)
To: paulmck; +Cc: David Miller, netdev
In-Reply-To: <20110524154445.GC2266@linux.vnet.ibm.com>
Le mardi 24 mai 2011 à 08:44 -0700, Paul E. McKenney a écrit :
> On Tue, May 24, 2011 at 11:07:32AM +0200, Eric Dumazet wrote:
> > synchronize_rcu() is very slow in various situations (HZ=100,
> > CONFIG_NO_HZ=y, CONFIG_PREEMPT=n)
> >
> > Extract from my (mostly idle) 8 core machine :
> >
> > synchronize_rcu() in 99985 us
> > synchronize_rcu() in 79982 us
> > synchronize_rcu() in 87612 us
> > synchronize_rcu() in 79827 us
> > synchronize_rcu() in 109860 us
> > synchronize_rcu() in 98039 us
> > synchronize_rcu() in 89841 us
> > synchronize_rcu() in 79842 us
> > synchronize_rcu() in 80151 us
> > synchronize_rcu() in 119833 us
> > synchronize_rcu() in 99858 us
> > synchronize_rcu() in 73999 us
> > synchronize_rcu() in 79855 us
> > synchronize_rcu() in 79853 us
> >
> >
> > When we hold RTNL mutex, we would like to spend some cpu cycles but not
> > block too long other processes waiting for this mutex.
> >
> > We also want to setup/dismantle network features as fast as possible at
> > boot/shutdown time.
> >
> > This patch makes synchronize_net() call the expedited version if RTNL is
> > locked.
> >
> > synchronize_rcu_expedited() typical delay is about 20 us on my machine.
> >
> > synchronize_rcu_expedited() in 18 us
> > synchronize_rcu_expedited() in 18 us
> > synchronize_rcu_expedited() in 18 us
> > synchronize_rcu_expedited() in 18 us
> > synchronize_rcu_expedited() in 20 us
> > synchronize_rcu_expedited() in 16 us
> > synchronize_rcu_expedited() in 20 us
> > synchronize_rcu_expedited() in 18 us
> > synchronize_rcu_expedited() in 18 us
>
> Cool!!!
>
> Just out of curiosity, how many CPUs does your system have?
16 (2x4x2) [ processor.max_cstate=1 ]
I am now trying to optimize rcu_barrier(), if you have an idea to get an
expedited version as well ?
We can see in following trace 3 groups, spaced by one jiffie (HZ=100)
Maybe we can avoid sending a call_rcu() to a cpu that has no pending rcu
work ?
[ 835.189996] cpu0 synchronize_rcu_expedited() in 30 us
-> begin rcu_barrier() immediately
[ 835.259702] cpu15 rcu_barrier_callback()
[ 835.259705] cpu14 rcu_barrier_callback()
[ 835.259708] cpu7 rcu_barrier_callback()
[ 835.259711] cpu12 rcu_barrier_callback()
[ 835.259714] cpu8 rcu_barrier_callback()
[ 835.259716] cpu1 rcu_barrier_callback()
[ 835.259719] cpu0 rcu_barrier_callback()
[ 835.269691] cpu13 rcu_barrier_callback()
[ 835.269695] cpu11 rcu_barrier_callback()
[ 835.269698] cpu5 rcu_barrier_callback()
[ 835.269700] cpu6 rcu_barrier_callback()
[ 835.269702] cpu10 rcu_barrier_callback()
[ 835.269705] cpu3 rcu_barrier_callback()
[ 835.269707] cpu2 rcu_barrier_callback()
[ 835.279687] cpu4 rcu_barrier_callback()
[ 835.279689] cpu9 rcu_barrier_callback()
[ 835.279744] cpu0 rcu_barrier() in 89499 us
Thanks
^ permalink raw reply
* Re: [PATCH v4] CDC NCM: release interfaces fix in unbind()
From: Oliver Neukum @ 2011-05-24 15:48 UTC (permalink / raw)
To: Alexey Orishko
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-usb-u79uwXL29TY76Z2rM5mHXA, gregkh-l3A5Bk7waGM,
Alexey Orishko
In-Reply-To: <1306250773-9177-1-git-send-email-alexey.orishko-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
Am Dienstag, 24. Mai 2011, 17:26:13 schrieb Alexey Orishko:
> Changes:
> - claim slave/data interface during bind() and release
> interfaces in unbind() unconditionally
> - in case of error during bind(), release claimed data
> interface in the same function
> - remove obsolited "*_claimed" entries from driver context
>
> Signed-off-by: Alexey Orishko <alexey.orishko-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
Looking good.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] vlan: Do not support clearing VLAN_FLAG_REORDER_HDR
From: Ben Greear @ 2011-05-24 15:44 UTC (permalink / raw)
To: David Miller
Cc: ebiederm, shemminger, nicolas.2p.debian, jpirko, xiaosuo, netdev,
kaber, fubar, eric.dumazet, andy, jesse
In-Reply-To: <20110524.011942.393855175233217324.davem@davemloft.net>
On 05/23/2011 10:19 PM, David Miller wrote:
> From: ebiederm@xmission.com (Eric W. Biederman)
> Date: Mon, 23 May 2011 15:05:54 -0700
>
>> 3) What do we do with pf_packet and vlan hardware acceleration when
>> dumping not the vlan interface but the interface below the vlan
>> interface?
>>
>> Do we provide an option to keep the vlan header? Should that option
>> be on by default?
>>
>
> The vlan_tci in the V2 pf_packet auxdata was intended for this
> purpose.
>
> So no matter what variant of behavior is occurring, apps can properly
> reconstitute the VLAN header if they inspect the vlan_tci in the
> auxdata.
When using pf-packet on eth0, with no VLAN devices existing, would
you still be putting the VLAN tags in auxdata, or would the tags be
inline in the skb?
> The only thing that seems to be missing is an indication that a VLAN
> tag was present at all, ie. vlan_tx_tag_present(), in this manner an
> application could then differentiate between no VLAN header and a VLAN
> tag of zero.
For nested VLANs, the outside VLAN data is in the auxdata, and the rest
is inline in the packet?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] net: use synchronize_rcu_expedited()
From: Paul E. McKenney @ 2011-05-24 15:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1306228052.3026.16.camel@edumazet-laptop>
On Tue, May 24, 2011 at 11:07:32AM +0200, Eric Dumazet wrote:
> synchronize_rcu() is very slow in various situations (HZ=100,
> CONFIG_NO_HZ=y, CONFIG_PREEMPT=n)
>
> Extract from my (mostly idle) 8 core machine :
>
> synchronize_rcu() in 99985 us
> synchronize_rcu() in 79982 us
> synchronize_rcu() in 87612 us
> synchronize_rcu() in 79827 us
> synchronize_rcu() in 109860 us
> synchronize_rcu() in 98039 us
> synchronize_rcu() in 89841 us
> synchronize_rcu() in 79842 us
> synchronize_rcu() in 80151 us
> synchronize_rcu() in 119833 us
> synchronize_rcu() in 99858 us
> synchronize_rcu() in 73999 us
> synchronize_rcu() in 79855 us
> synchronize_rcu() in 79853 us
>
>
> When we hold RTNL mutex, we would like to spend some cpu cycles but not
> block too long other processes waiting for this mutex.
>
> We also want to setup/dismantle network features as fast as possible at
> boot/shutdown time.
>
> This patch makes synchronize_net() call the expedited version if RTNL is
> locked.
>
> synchronize_rcu_expedited() typical delay is about 20 us on my machine.
>
> synchronize_rcu_expedited() in 18 us
> synchronize_rcu_expedited() in 18 us
> synchronize_rcu_expedited() in 18 us
> synchronize_rcu_expedited() in 18 us
> synchronize_rcu_expedited() in 20 us
> synchronize_rcu_expedited() in 16 us
> synchronize_rcu_expedited() in 20 us
> synchronize_rcu_expedited() in 18 us
> synchronize_rcu_expedited() in 18 us
Cool!!!
Just out of curiosity, how many CPUs does your system have?
Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> CC: Ben Greear <greearb@candelatech.com>
> ---
> net/core/dev.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index bcb05cb..ec11d75 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -5954,7 +5954,10 @@ EXPORT_SYMBOL(free_netdev);
> void synchronize_net(void)
> {
> might_sleep();
> - synchronize_rcu();
> + if (rtnl_is_locked())
> + synchronize_rcu_expedited();
> + else
> + synchronize_rcu();
> }
> EXPORT_SYMBOL(synchronize_net);
>
>
>
^ permalink raw reply
* Re: bridge netfilter output bug on 2.6.39
From: Eric Dumazet @ 2011-05-24 15:39 UTC (permalink / raw)
To: Stephen Hemminger, David Miller; +Cc: Herbert Xu, netdev
In-Reply-To: <20110524074156.58eb30f8@nehalam>
Le mardi 24 mai 2011 à 07:41 -0700, Stephen Hemminger a écrit :
> Got this bug report against 2.6.39. Looks like ip_fragment() is now
> getting confused when called from bridge netfilter. Probably related to
> the changes to do ip_options_compile for the bridge input path.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=35672
>
> May 23 02:04:24 lxc kernel: [99498.329036] BUG: unable to handle kernel NULL
> pointer dereference at 00000004
> May 23 02:04:24 lxc kernel: [99498.330017] IP: [<c143d6bf>] dst_mtu+0xb/0x1c
> May 23 02:04:24 lxc kernel: [99498.330017] *pdpt = 000000001fb55001 *pde =
> 0000000000000000
> May 23 02:04:24 lxc kernel: [99498.330017] Oops: 0000 [#1] SMP
> May 23 02:04:24 lxc kernel: [99498.330017] last sysfs file:
> /sys/devices/virtual/vc/vcsa8/uevent
> May 23 02:04:24 lxc kernel: [99498.330017] Modules linked in: lp ppdev
> parport_pc parport fuse firewire_ohci firewire_core crc_itu_t intel_agp
> intel_gtt
> May 23 02:04:24 lxc kernel: [99498.330017]
> May 23 02:04:24 lxc kernel: [99498.330017] Pid: 0, comm: swapper Not tainted
> 2.6.39-lxc #2 . . /IP35 Pro XE(Intel P35-ICH9R)
> May 23 02:04:24 lxc kernel: [99498.330017] EIP: 0060:[<c143d6bf>] EFLAGS:
> 00010246 CPU: 0
> May 23 02:04:24 lxc kernel: [99498.330017] EIP is at dst_mtu+0xb/0x1c
> May 23 02:04:24 lxc kernel: [99498.330017] EAX: 00000000 EBX: e90b6b40 ECX:
> effc981c EDX: effc9000
> May 23 02:04:24 lxc kernel: [99498.330017] ESI: c1a0d84e EDI: dda6331e EBP:
> f080bb44 ESP: f080bb44
> May 23 02:04:24 lxc kernel: [99498.330017] DS: 007b ES: 007b FS: 00d8 GS: 0000
> SS: 0068
> May 23 02:04:24 lxc kernel: [99498.330017] Process swapper (pid: 0, ti=f080a000
> task=c172b7e0 task.ti=c1724000)
> May 23 02:04:24 lxc kernel: [99498.330017] Stack:
> May 23 02:04:24 lxc kernel: [99498.330017] f080bb8c c143e20d 00000004 f080bb88
> c141aab2 c14b46db effc9000 00000014
> May 23 02:04:24 lxc kernel: [99498.330017] c14b8a44 effc9000 e90b6b40 00000014
> effc981c e90b6b58 cd472800 e90b6b40
> May 23 02:04:24 lxc kernel: [99498.330017] c14b8a44 dda6331e f080bb98 c14b8aa0
> e90b6b40 f080bba8 c14b881a e90b6b40
> May 23 02:04:24 lxc kernel: [99498.330017] Call Trace:
> May 23 02:04:24 lxc kernel: [99498.330017] [<c143e20d>] ip_fragment+0xb5/0x66c
> May 23 02:04:24 lxc kernel: [99498.330017] [<c141aab2>] ?
> nf_hook_slow+0x43/0xd1
> May 23 02:04:24 lxc kernel: [99498.330017] [<c14b46db>] ? br_flood+0x83/0x83
> May 23 02:04:24 lxc kernel: [99498.330017] [<c14b8a44>] ?
> br_parse_ip_options+0x1b0/0x1b0
> May 23 02:04:24 lxc kernel: [99498.330017] [<c14b8a44>] ?
> br_parse_ip_options+0x1b0/0x1b0
> May 23 02:04:24 lxc kernel: [99498.330017] [<c14b8aa0>]
> br_nf_dev_queue_xmit+0x5c/0x68
> --
I would say its more likely a problem with dst metrics changes
In this crash, we dereference a NULL dst->_metrics 'pointer' in
dst_metric_raw(dst, RTAX_MTU);
Hmm, it seems __dst_destroy_metrics_generic() doesnt add the
DST_METRICS_READ_ONLY flag ?
[PATCH] net: fix __dst_destroy_metrics_generic()
dst_default_metrics is readonly, we dont want to kfree() it later.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Stephen Hemminger <shemminger@vyatta.com>
CC: Herbert Xu <herbert@gondor.apana.org.au>
---
net/core/dst.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dst.c b/net/core/dst.c
index 81a4fa1..1badc98 100644
--- a/net/core/dst.c
+++ b/net/core/dst.c
@@ -315,7 +315,7 @@ void __dst_destroy_metrics_generic(struct dst_entry *dst, unsigned long old)
{
unsigned long prev, new;
- new = (unsigned long) dst_default_metrics;
+ new = ((unsigned long) dst_default_metrics) | DST_METRICS_READ_ONLY;
prev = cmpxchg(&dst->_metrics, old, new);
if (prev == old)
kfree(__DST_METRICS_PTR(old));
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox