* [BUG, NET] deadlock tearing down a bridged interface
@ 2008-07-18 7:37 Dave Chinner
2008-07-18 15:44 ` Ben Greear
0 siblings, 1 reply; 10+ messages in thread
From: Dave Chinner @ 2008-07-18 7:37 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev
Folks,
I just deadlocked networking on a 2.6.24 kernel. Basically I
was trying to restart the bridge interface I use for UML sessions
because it wasn't passing packets. This happens occasionally
when I leave a UML session too long in gdb, so I bounced the
bridge to get it working again.
Unfortunately, a UML session (2.6.25-rc9) was halting at the same
time, and instead of giving me a 'device busy' error, the
UML session stopped at:
Asking all remaining processes to terminate...done.
All processes ended within 1 seconds....done.
Saving random seed...done.
Deconfiguring network interfaces...
It appears to be stuck closing the tunnel interface it was using:
uml-linux D ffffffff804297c0 0 7437 7428
ffff8100798efe70 0000000000000086 0000000000000000 ffff81005348b400
ffff81003d820800 ffff81007df9a800 ffff81003d820a50 0000000100000000
00000000ffffffff ffff81003d820800 0000000000000000 0000000000000000
Call Trace:
[<ffffffff8024a85d>] lock_hrtimer_base+0x1b/0x3c
[<ffffffff804145f2>] __mutex_lock_slowpath+0x68/0xa3
[<ffffffff80414458>] mutex_lock+0xa/0xb
[<ffffffff803adcfe>] netdev_run_todo+0x14/0x21a
[<ffffffff885901dd>] :tun:tun_chr_close+0x70/0x76
[<ffffffff802990c7>] __fput+0xa1/0x16c
[<ffffffff802968f3>] filp_close+0x5d/0x65
[<ffffffff80297aca>] sys_close+0x8d/0xca
[<ffffffff8020be2e>] system_call+0x7e/0x83
At the same time that this command was running:
brctl delbr br0
dmesg showed:
unregister_netdevice: waiting for br0 to become free. Usage count = 7
unregister_netdevice: waiting for br0 to become free. Usage count = 7
unregister_netdevice: waiting for br0 to become free. Usage count = 7
unregister_netdevice: waiting for br0 to become free. Usage count = 7
unregister_netdevice: waiting for br0 to become free. Usage count = 7
unregister_netdevice: waiting for br0 to become free. Usage count = 7
....
brctl is stuck here:
brctl D ffffffff804297c0 0 8457 8448
ffff81004d8a3d98 0000000000000082 0000000000000286 ffffffff8023e0ea
ffff81000f941800 ffff81007d531000 ffff81000f941a50 000000014d8a3da8
000000012f98b3a2 000000012f98bbea 0000000000000286 ffffffff8023e280
Call Trace:
[<ffffffff8023e0ea>] lock_timer_base+0x26/0x4c
[<ffffffff8023e280>] __mod_timer+0xc3/0xd1
[<ffffffff8041423d>] schedule_timeout+0x8a/0xad
[<ffffffff8023ddde>] process_timeout+0x0/0x5
[<ffffffff80414238>] schedule_timeout+0x85/0xad
[<ffffffff8023e2a2>] msleep+0x14/0x1e
[<ffffffff803ade06>] netdev_run_todo+0x11c/0x21a
[<ffffffff88580599>] :bridge:br_del_bridge+0x4c/0x50
[<ffffffff88581281>] :bridge:br_ioctl_deviceless_stub+0x177/0x1e2
[<ffffffff80223598>] do_page_fault+0x352/0x6ca
[<ffffffff803a0ab6>] sock_ioctl+0x12c/0x200
[<ffffffff802a3849>] do_ioctl+0x21/0x6b
[<ffffffff802a3ad6>] vfs_ioctl+0x243/0x25c
[<ffffffff80296861>] fd_install+0x25/0x5a
[<ffffffff802a3b40>] sys_ioctl+0x51/0x71
[<ffffffff8020be2e>] system_call+0x7e/0x83
This is as much as I could get before sufficient stuff locked
up and I had to reboot.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [BUG, NET] deadlock tearing down a bridged interface
2008-07-18 7:37 [BUG, NET] deadlock tearing down a bridged interface Dave Chinner
@ 2008-07-18 15:44 ` Ben Greear
2008-07-19 1:17 ` Dave Chinner
0 siblings, 1 reply; 10+ messages in thread
From: Ben Greear @ 2008-07-18 15:44 UTC (permalink / raw)
To: linux-kernel, netdev
Dave Chinner wrote:
> Folks,
>
> I just deadlocked networking on a 2.6.24 kernel. Basically I
> was trying to restart the bridge interface I use for UML sessions
> because it wasn't passing packets. This happens occasionally
> when I leave a UML session too long in gdb, so I bounced the
> bridge to get it working again.
>
We have been chasing a refcount bug in 2.6.25 that only happens when
IPv6 module is loaded. If you are not actually using ipv6, try removing
it's
module from your /lib/modules/* directory and see if that fixes your
problem.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [BUG, NET] deadlock tearing down a bridged interface
2008-07-18 15:44 ` Ben Greear
@ 2008-07-19 1:17 ` Dave Chinner
2008-07-19 17:01 ` Ben Greear
0 siblings, 1 reply; 10+ messages in thread
From: Dave Chinner @ 2008-07-19 1:17 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-kernel, netdev
On Fri, Jul 18, 2008 at 08:44:58AM -0700, Ben Greear wrote:
> Dave Chinner wrote:
>> Folks,
>>
>> I just deadlocked networking on a 2.6.24 kernel. Basically I
>> was trying to restart the bridge interface I use for UML sessions
>> because it wasn't passing packets. This happens occasionally
>> when I leave a UML session too long in gdb, so I bounced the
>> bridge to get it working again.
>>
> We have been chasing a refcount bug in 2.6.25 that only happens when
> IPv6 module is loaded.
Which causes what problem? The deadlock I reported or the bridge occasionally
hanging? Is that a problem in 2.6.24?
The deadlock is the one I'm concerned about - it appears that
netdev_run_todo() can only wait on a single interface at a time,
so if we are tearing down two interfaces concurrently where one
has a reference on the other a deadlock is just waiting to happen...
> If you are not actually using ipv6, try removing it's
> module from your /lib/modules/* directory and see if that fixes your
> problem.
I'll try it, but a) it's not 2.6.25 and b) I don't tend to triage problems
on my main workstation so I'm not likely to try to reproduce this
deadlock unless absolutely necessary.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [BUG, NET] deadlock tearing down a bridged interface
2008-07-19 1:17 ` Dave Chinner
@ 2008-07-19 17:01 ` Ben Greear
2008-07-20 6:04 ` [RFC] netdev: debugging option Stephen Hemminger
2008-07-20 6:07 ` [BUG, NET] deadlock tearing down a bridged interface Stephen Hemminger
0 siblings, 2 replies; 10+ messages in thread
From: Ben Greear @ 2008-07-19 17:01 UTC (permalink / raw)
To: Ben Greear, linux-kernel, netdev
Dave Chinner wrote:
> On Fri, Jul 18, 2008 at 08:44:58AM -0700, Ben Greear wrote:
>
>> Dave Chinner wrote:
>>
>>> Folks,
>>>
>>> I just deadlocked networking on a 2.6.24 kernel. Basically I
>>> was trying to restart the bridge interface I use for UML sessions
>>> because it wasn't passing packets. This happens occasionally
>>> when I leave a UML session too long in gdb, so I bounced the
>>> bridge to get it working again.
>>>
>>>
>> We have been chasing a refcount bug in 2.6.25 that only happens when
>> IPv6 module is loaded.
>>
>
> Which causes what problem? The deadlock I reported or the bridge occasionally
> hanging? Is that a problem in 2.6.24?
>
> The deadlock is the one I'm concerned about - it appears that
> netdev_run_todo() can only wait on a single interface at a time,
> so if we are tearing down two interfaces concurrently where one
> has a reference on the other a deadlock is just waiting to happen...
>
Our problem is the refcount hang while trying to remove a netdevice. It
appears
to be an ipv6 related leakage of some sort, and not directly related to
bridges.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* [RFC] netdev: debugging option
2008-07-19 17:01 ` Ben Greear
@ 2008-07-20 6:04 ` Stephen Hemminger
2008-07-20 7:05 ` David Miller
2008-07-20 6:07 ` [BUG, NET] deadlock tearing down a bridged interface Stephen Hemminger
1 sibling, 1 reply; 10+ messages in thread
From: Stephen Hemminger @ 2008-07-20 6:04 UTC (permalink / raw)
To: Ben Greear; +Cc: Ben Greear, linux-kernel, netdev
This adds a debugging option for network devices. It could grow to add other
uses, but for now just add some messages about device reference counting.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/include/linux/netdevice.h 2008-07-19 15:04:59.000000000 -0700
+++ b/include/linux/netdevice.h 2008-07-19 22:09:21.000000000 -0700
@@ -1236,6 +1236,14 @@ extern int netdev_budget;
/* Called by rtnetlink.c:rtnl_unlock() */
extern void netdev_run_todo(void);
+#ifdef CONFIG_DEBUG_NETDEV
+extern int netdev_debug;
+extern void __dev_hold(struct net_device *, const char *);
+extern void __dev_put(struct net_device *, const char *);
+
+#define dev_hold(dev) __dev_hold(dev, __FUNCTION__)
+#define dev_put(dev) __dev_put(dev, __FUNCTION__)
+#else
/**
* dev_put - release reference to device
* @dev: network device
@@ -1257,6 +1265,8 @@ static inline void dev_hold(struct net_d
{
atomic_inc(&dev->refcnt);
}
+#endif
+
/* Carrier loss detection, dial on demand. The functions netif_carrier_on
* and _off may be called from IRQ context, but it is caller
--- a/lib/Kconfig.debug 2008-07-19 15:03:14.000000000 -0700
+++ b/lib/Kconfig.debug 2008-07-19 15:04:50.000000000 -0700
@@ -428,6 +428,13 @@ config DEBUG_KOBJECT
If you say Y here, some extra kobject debugging messages will be sent
to the syslog.
+config DEBUG_NETDEV
+ bool "network device debugging"
+ depends on DEBUG_KERNEL
+ help
+ This option enables extra checking on usage and reference counting
+ of network devices.
+
config DEBUG_HIGHMEM
bool "Highmem debugging"
depends on DEBUG_KERNEL && HIGHMEM
--- a/net/core/dev.c 2008-07-19 15:12:06.000000000 -0700
+++ b/net/core/dev.c 2008-07-19 22:12:06.000000000 -0700
@@ -4091,6 +4091,30 @@ static void netdev_wait_allrefs(struct n
}
}
+#ifdef CONFIG_DEBUG_NETDEV
+/* This is for debugging reference counting of devices */
+int netdev_debug __read_mostly;
+
+void __dev_hold(struct net_device *dev, const char *func)
+{
+ atomic_inc(&dev->refcnt);
+ if (unlikely(netdev_debug))
+ printk(KERN_DEBUG "%s: dev_hold %d %s\n",
+ dev->name, atomic_read(&dev->refcnt), func);
+}
+EXPORT_SYMBOL(__dev_hold);
+
+void __dev_put(struct net_device *dev, const char *func)
+{
+ BUG_ON(atomic_read(&dev->refcnt) == 0);
+ if (unlikely(netdev_debug))
+ printk(KERN_DEBUG "%s: dev_put %d %s\n",
+ dev->name, atomic_read(&dev->refcnt), func);
+ atomic_dec(&dev->refcnt);
+}
+EXPORT_SYMBOL(__dev_put);
+#endif
+
/* The sequence is:
*
* rtnl_lock();
--- a/net/core/sysctl_net_core.c 2008-07-19 15:12:21.000000000 -0700
+++ b/net/core/sysctl_net_core.c 2008-07-19 15:29:53.000000000 -0700
@@ -140,6 +140,17 @@ static struct ctl_table net_core_table[]
.mode = 0644,
.proc_handler = &proc_dointvec
},
+#ifdef CONFIG_DEBUG_NETDEV
+ {
+ .ctl_name = CTL_UNNUMBERED,
+ .procname = "netdev_debug",
+ .data = &netdev_debug,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec
+ },
+
+#endif
{ .ctl_name = 0 }
};
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [BUG, NET] deadlock tearing down a bridged interface
2008-07-19 17:01 ` Ben Greear
2008-07-20 6:04 ` [RFC] netdev: debugging option Stephen Hemminger
@ 2008-07-20 6:07 ` Stephen Hemminger
1 sibling, 0 replies; 10+ messages in thread
From: Stephen Hemminger @ 2008-07-20 6:07 UTC (permalink / raw)
To: Ben Greear; +Cc: Ben Greear, linux-kernel, netdev
It looks something related icmp6_dst_alloc creating a reference
(in rt6_info), but these entries are not being cleaned up.
Possibly related to icmp6_dst_gc.
This is what happens if a bridge is created, then brought up.
and then bridge module is attempted to be removed.
[ 148.814733] br0: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature.
[ 148.814944] br0: dev_hold 1 register_netdevice
[ 148.814972] br0: dev_hold 2 neigh_parms_alloc
[ 148.814976] br0: dev_hold 3 inetdev_init
[ 148.815875] br0: dev_hold 4 neigh_parms_alloc
[ 148.815880] br0: dev_hold 5 ipv6_add_dev
[ 165.885715] br0: dev_hold 6 dev_get_by_index
[ 165.886940] br0: dev_hold 7 dev_get_by_index
[ 165.886947] br0: dev_put 7 free_fib_info
[ 165.886952] br0: dev_hold 7 fib_check_nh
[ 165.886986] br0: dev_hold 8 fib_check_nh
[ 165.886991] br0: dev_put 8 free_fib_info
[ 165.887006] br0: dev_hold 8 fib_check_nh
[ 165.887011] br0: dev_put 8 free_fib_info
[ 165.887026] br0: dev_hold 8 fib_check_nh
[ 165.887030] br0: dev_put 8 free_fib_info
[ 165.887043] br0: dev_hold 8 dev_get_by_index
[ 165.887060] br0: dev_hold 9 dev_get_by_index
[ 165.887084] br0: dev_hold 10 dev_get_by_index
[ 165.887089] br0: dev_put 10 dst_destroy
[ 165.888480] br0: dev_put 9 free_fib_info
[ 165.888497] br0: dev_put 8 free_fib_info
[ 165.889359] br0: dev_hold 8 dev_get_by_index
[ 165.889378] br0: dev_hold 9 fib_check_nh
[ 165.889394] br0: dev_hold 10 fib_check_nh
[ 165.889399] br0: dev_put 10 free_fib_info
[ 165.889412] br0: dev_hold 10 fib_check_nh
[ 165.889417] br0: dev_put 10 free_fib_info
[ 165.889432] br0: dev_hold 10 fib_check_nh
[ 165.889437] br0: dev_put 10 free_fib_info
[ 165.894973] br0: dev_hold 10 icmp6_dst_alloc
[ 165.894983] br0: dev_hold 11 neigh_create
[ 165.895005] br0: dev_hold 12 dev_get_by_index
[ 165.895011] br0: dev_hold 13 __mkroute_output
[ 165.895017] br0: dev_hold 14 neigh_create
[ 165.895022] br0: dev_put 14 ip_route_output_slow
[ 166.086518] br0: dev_hold 14 ip_dev_find
[ 166.086524] br0: dev_put 14 ip_route_output_slow
[ 166.086527] br0: dev_hold 14 dev_get_by_index
[ 166.086530] br0: dev_hold 15 __mkroute_output
[ 166.086536] br0: dev_hold 16 neigh_create
[ 166.086539] br0: dev_put 16 ip_route_output_slow
[ 166.086564] br0: dev_hold 16 netif_rx
[ 166.086575] br0: dev_put 16 process_backlog
[ 166.110517] br0: dev_hold 16 netif_rx
[ 166.110528] br0: dev_put 16 process_backlog
[ 166.342516] br0: dev_hold 16 netif_rx
[ 166.342527] br0: dev_put 16 process_backlog
[ 166.414459] br0: dev_hold 16 icmp6_dst_alloc
[ 166.414465] br0: dev_hold 17 neigh_create
[ 166.598525] br0: dev_hold 18 netif_rx
[ 166.598537] br0: dev_put 18 process_backlog
[ 166.798613] br0: dev_hold 18 netif_rx
[ 166.798624] br0: dev_put 18 process_backlog
[ 167.250500] br0: dev_hold 18 netif_rx
[ 167.250511] br0: dev_put 18 process_backlog
[ 167.414464] br0: dev_hold 18 icmp6_dst_alloc
[ 167.414470] br0: dev_hold 19 neigh_create
[ 167.610510] br0: dev_hold 20 netif_rx
[ 167.610521] br0: dev_put 20 process_backlog
[ 167.610656] br0: dev_hold 20 netif_rx
[ 167.610664] br0: dev_put 20 process_backlog
[ 167.866495] br0: dev_hold 20 netif_rx
[ 167.866506] br0: dev_put 20 process_backlog
[ 167.938575] br0: dev_hold 20 netif_rx
[ 167.938586] br0: dev_put 20 process_backlog
[ 168.118511] br0: dev_hold 20 netif_rx
[ 168.118522] br0: dev_put 20 process_backlog
[ 168.118662] br0: dev_hold 20 netif_rx
[ 168.118670] br0: dev_put 20 process_backlog
[ 168.322535] br0: dev_hold 20 netif_rx
[ 168.322546] br0: dev_put 20 process_backlog
[ 169.390505] br0: dev_hold 20 netif_rx
[ 169.390516] br0: dev_put 20 process_backlog
[ 169.462506] br0: dev_hold 20 netif_rx
[ 169.462517] br0: dev_put 20 process_backlog
[ 170.078564] br0: dev_hold 20 netif_rx
[ 170.078576] br0: dev_put 20 process_backlog
[ 171.414377] br0: dev_hold 20 icmp6_dst_alloc
[ 171.602486] br0: dev_hold 21 netif_rx
[ 171.602499] br0: dev_put 21 process_backlog
[ 172.122369] br0: dev_hold 21 icmp6_dst_alloc
[ 175.414312] br0: dev_hold 22 icmp6_dst_alloc
[ 176.414294] br0: no IPv6 routers present
[ 179.754147] br0: dev_hold 23 ip_dev_find
[ 179.754153] br0: dev_put 23 ip_route_output_slow
[ 179.754157] br0: dev_hold 23 ip_route_output_slow
[ 179.754162] br0: dev_hold 24 __mkroute_output
[ 179.754168] br0: dev_hold 25 neigh_create
[ 179.754174] br0: dev_put 25 ip_route_output_slow
[ 179.754202] br0: dev_hold 25 netif_rx
[ 179.754214] br0: dev_put 25 process_backlog
[ 179.754239] br0: dev_hold 25 netif_rx
[ 179.754248] br0: dev_put 25 process_backlog
[ 179.754268] br0: dev_hold 25 netif_rx
[ 179.754277] br0: dev_put 25 process_backlog
[ 179.754297] br0: dev_hold 25 netif_rx
[ 179.754306] br0: dev_put 25 process_backlog
[ 179.754323] br0: dev_hold 25 netif_rx
[ 179.754331] br0: dev_put 25 process_backlog
[ 179.754707] br0: dev_hold 25 netif_rx
[ 179.754716] br0: dev_put 25 process_backlog
[ 181.754187] br0: dev_hold 25 netif_rx
[ 181.754195] br0: dev_put 25 process_backlog
[ 181.754209] br0: dev_hold 25 netif_rx
[ 181.754216] br0: dev_put 25 process_backlog
[ 181.754230] br0: dev_hold 25 netif_rx
[ 181.754238] br0: dev_put 25 process_backlog
[ 181.754252] br0: dev_hold 25 netif_rx
[ 181.754260] br0: dev_put 25 process_backlog
[ 181.754273] br0: dev_hold 25 netif_rx
[ 181.754280] br0: dev_put 25 process_backlog
[ 181.754458] br0: dev_hold 25 netif_rx
[ 181.754467] br0: dev_put 25 process_backlog
[ 181.754481] br0: dev_hold 25 netif_rx
[ 181.754489] br0: dev_put 25 process_backlog
[ 181.754503] br0: dev_hold 25 netif_rx
[ 181.754510] br0: dev_put 25 process_backlog
[ 181.754524] br0: dev_hold 25 netif_rx
[ 181.754532] br0: dev_put 25 process_backlog
[ 181.754546] br0: dev_hold 25 netif_rx
[ 181.754554] br0: dev_put 25 process_backlog
[ 183.754140] br0: dev_hold 25 netif_rx
[ 183.754149] br0: dev_put 25 process_backlog
[ 183.754163] br0: dev_hold 25 netif_rx
[ 183.754172] br0: dev_put 25 process_backlog
[ 183.754185] br0: dev_hold 25 netif_rx
[ 183.754193] br0: dev_put 25 process_backlog
[ 183.754206] br0: dev_hold 25 netif_rx
[ 183.754214] br0: dev_put 25 process_backlog
[ 183.754227] br0: dev_hold 25 netif_rx
[ 183.754235] br0: dev_put 25 process_backlog
[ 188.854636] br0: dev_put 24 free_fib_info
[ 188.855481] br0: dev_put 23 dst_destroy
[ 188.855547] br0: dev_put 22 dst_destroy
[ 188.855610] br0: dev_put 21 dst_destroy
[ 188.855675] br0: dev_put 20 neigh_destroy
[ 188.855739] br0: dev_put 19 dst_destroy
[ 188.855803] br0: dev_put 18 neigh_destroy
[ 188.855866] br0: dev_put 17 dst_destroy
[ 188.855931] br0: dev_put 16 neigh_destroy
[ 188.855994] br0: dev_put 15 dst_destroy
[ 188.856075] br0: dev_put 14 dst_destroy
[ 188.856145] br0: dev_put 13 dst_destroy
[ 188.865683] br0: dev_put 12 neigh_destroy
[ 188.865750] br0: dev_put 11 dst_destroy
[ 188.865813] br0: dev_put 10 neigh_destroy
[ 188.865876] br0: dev_put 9 dst_destroy
[ 188.866002] br0: dev_put 8 neigh_destroy
[ 188.866065] br0: dev_put 7 dst_destroy
[ 243.751561] br0: dev_hold 7 ip_dev_find
[ 243.751564] br0: dev_put 7 ip_route_output_slow
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC] netdev: debugging option
2008-07-20 6:04 ` [RFC] netdev: debugging option Stephen Hemminger
@ 2008-07-20 7:05 ` David Miller
2008-08-04 16:37 ` Stephen Hemminger
0 siblings, 1 reply; 10+ messages in thread
From: David Miller @ 2008-07-20 7:05 UTC (permalink / raw)
To: shemminger; +Cc: greearb, linux-kernel, netdev
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Sat, 19 Jul 2008 23:04:24 -0700
> This adds a debugging option for network devices. It could grow to add other
> uses, but for now just add some messages about device reference counting.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
I think this is useful but it could use some minor
mods before we put it in.
For example, this thing will spam the logs in at least two
common cases:
1) Lots of routing cache replacements
2) For older drivers using netif_rx() (and therefore, every
current tunnel), every RX packet will trigger a log message
So we really need to add some kind of run time enable and also a
filter of some sort, even if it's just on device.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC] netdev: debugging option
2008-07-20 7:05 ` David Miller
@ 2008-08-04 16:37 ` Stephen Hemminger
2008-08-04 21:31 ` David Miller
0 siblings, 1 reply; 10+ messages in thread
From: Stephen Hemminger @ 2008-08-04 16:37 UTC (permalink / raw)
To: David Miller; +Cc: greearb, linux-kernel, netdev
On Sun, 20 Jul 2008 00:05:09 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Sat, 19 Jul 2008 23:04:24 -0700
>
> > This adds a debugging option for network devices. It could grow to add other
> > uses, but for now just add some messages about device reference counting.
> >
> > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> I think this is useful but it could use some minor
> mods before we put it in.
>
> For example, this thing will spam the logs in at least two
> common cases:
>
> 1) Lots of routing cache replacements
>
> 2) For older drivers using netif_rx() (and therefore, every
> current tunnel), every RX packet will trigger a log message
Fixed by later patch.
> So we really need to add some kind of run time enable and also a
> filter of some sort, even if it's just on device.
The sysctl in the patch is default off, so unless it is turned on,
the log is quiet
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC] netdev: debugging option
2008-08-04 16:37 ` Stephen Hemminger
@ 2008-08-04 21:31 ` David Miller
2008-08-04 22:34 ` Stephen Hemminger
0 siblings, 1 reply; 10+ messages in thread
From: David Miller @ 2008-08-04 21:31 UTC (permalink / raw)
To: shemminger; +Cc: greearb, linux-kernel, netdev
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 4 Aug 2008 09:37:42 -0700
> On Sun, 20 Jul 2008 00:05:09 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
>
> > From: Stephen Hemminger <shemminger@vyatta.com>
> > Date: Sat, 19 Jul 2008 23:04:24 -0700
> >
> > So we really need to add some kind of run time enable and also a
> > filter of some sort, even if it's just on device.
>
> The sysctl in the patch is default off, so unless it is turned on,
> the log is quiet
I get a feeling you think I can just apply your patch now.
You can't respond to my gripes more than a week later and expect
the patch to still be in my inbox ready to apply. I delete the
patch from my mailbox as soon as I have major issues with it.
If you think your reply means that the patch should be applied you
need to resubmit it.
Thanks.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC] netdev: debugging option
2008-08-04 21:31 ` David Miller
@ 2008-08-04 22:34 ` Stephen Hemminger
0 siblings, 0 replies; 10+ messages in thread
From: Stephen Hemminger @ 2008-08-04 22:34 UTC (permalink / raw)
To: David Miller; +Cc: greearb, linux-kernel, netdev
On Mon, 04 Aug 2008 14:31:28 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Mon, 4 Aug 2008 09:37:42 -0700
>
> > On Sun, 20 Jul 2008 00:05:09 -0700 (PDT)
> > David Miller <davem@davemloft.net> wrote:
> >
> > > From: Stephen Hemminger <shemminger@vyatta.com>
> > > Date: Sat, 19 Jul 2008 23:04:24 -0700
> > >
> > > So we really need to add some kind of run time enable and also a
> > > filter of some sort, even if it's just on device.
> >
> > The sysctl in the patch is default off, so unless it is turned on,
> > the log is quiet
>
> I get a feeling you think I can just apply your patch now.
>
> You can't respond to my gripes more than a week later and expect
> the patch to still be in my inbox ready to apply. I delete the
> patch from my mailbox as soon as I have major issues with it.
>
Okay, I prioritize my mail replies, and this was on the tickler file of
(things to get back to when the smoke clears). Just didn't want to let
it die.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2008-08-04 22:34 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-07-18 7:37 [BUG, NET] deadlock tearing down a bridged interface Dave Chinner
2008-07-18 15:44 ` Ben Greear
2008-07-19 1:17 ` Dave Chinner
2008-07-19 17:01 ` Ben Greear
2008-07-20 6:04 ` [RFC] netdev: debugging option Stephen Hemminger
2008-07-20 7:05 ` David Miller
2008-08-04 16:37 ` Stephen Hemminger
2008-08-04 21:31 ` David Miller
2008-08-04 22:34 ` Stephen Hemminger
2008-07-20 6:07 ` [BUG, NET] deadlock tearing down a bridged interface Stephen Hemminger
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.