* Re: [PATCH -next] drivers/net: Makefile, fix netconsole link order
From: Andrew Morton @ 2011-09-10 0:00 UTC (permalink / raw)
To: Lin Ming; +Cc: David S. Miller, lkml, netdev, Jeff Kirsher
In-Reply-To: <1315298129.16061.24.camel@snb>
On Tue, 06 Sep 2011 16:35:29 +0800
Lin Ming <ming.m.lin@intel.com> wrote:
> Commit 88491d8(drivers/net: Kconfig & Makefile cleanup) causes a
> regression that netconsole does not work if netconsole and network
> device driver are build into kernel, because netconsole is linked before
> network device driver.
>
> Fixes it by moving netconsole.o after network device driver.
>
> Signed-off-by: Lin Ming <ming.m.lin@intel.com>
> ---
> drivers/net/Makefile | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index fa877cd..ec15311 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -14,7 +14,6 @@ obj-$(CONFIG_MACVTAP) += macvtap.o
> obj-$(CONFIG_MII) += mii.o
> obj-$(CONFIG_MDIO) += mdio.o
> obj-$(CONFIG_NET) += Space.o loopback.o
> -obj-$(CONFIG_NETCONSOLE) += netconsole.o
> obj-$(CONFIG_PHYLIB) += phy/
> obj-$(CONFIG_RIONET) += rionet.o
> obj-$(CONFIG_TUN) += tun.o
> @@ -66,3 +65,9 @@ obj-$(CONFIG_USB_USBNET) += usb/
> obj-$(CONFIG_USB_ZD1201) += usb/
> obj-$(CONFIG_USB_IPHETH) += usb/
> obj-$(CONFIG_USB_CDC_PHONET) += usb/
> +
> +#
> +# If netconsole and network device driver are build-in,
> +# netconsole must be linked after network device driver
> +#
> +obj-$(CONFIG_NETCONSOLE) += netconsole.o
It would be preferable to fix this with initcall ordering. Perhaps by
switching init_netconsole() to subsys_initcall.
^ permalink raw reply
* Re: [PATCH -next] drivers/net: Makefile, fix netconsole link order
From: Lin Ming @ 2011-09-10 2:43 UTC (permalink / raw)
To: Andrew Morton
Cc: David S. Miller, lkml, netdev@vger.kernel.org, Kirsher, Jeffrey T
In-Reply-To: <20110909170027.c4bf6151.akpm@linux-foundation.org>
On Sat, 2011-09-10 at 08:00 +0800, Andrew Morton wrote:
> On Tue, 06 Sep 2011 16:35:29 +0800
> Lin Ming <ming.m.lin@intel.com> wrote:
>
> > Commit 88491d8(drivers/net: Kconfig & Makefile cleanup) causes a
> > regression that netconsole does not work if netconsole and network
> > device driver are build into kernel, because netconsole is linked before
> > network device driver.
> >
> > Fixes it by moving netconsole.o after network device driver.
> >
> > Signed-off-by: Lin Ming <ming.m.lin@intel.com>
> > ---
> > drivers/net/Makefile | 7 ++++++-
> > 1 files changed, 6 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> > index fa877cd..ec15311 100644
> > --- a/drivers/net/Makefile
> > +++ b/drivers/net/Makefile
> > @@ -14,7 +14,6 @@ obj-$(CONFIG_MACVTAP) += macvtap.o
> > obj-$(CONFIG_MII) += mii.o
> > obj-$(CONFIG_MDIO) += mdio.o
> > obj-$(CONFIG_NET) += Space.o loopback.o
> > -obj-$(CONFIG_NETCONSOLE) += netconsole.o
> > obj-$(CONFIG_PHYLIB) += phy/
> > obj-$(CONFIG_RIONET) += rionet.o
> > obj-$(CONFIG_TUN) += tun.o
> > @@ -66,3 +65,9 @@ obj-$(CONFIG_USB_USBNET) += usb/
> > obj-$(CONFIG_USB_ZD1201) += usb/
> > obj-$(CONFIG_USB_IPHETH) += usb/
> > obj-$(CONFIG_USB_CDC_PHONET) += usb/
> > +
> > +#
> > +# If netconsole and network device driver are build-in,
> > +# netconsole must be linked after network device driver
> > +#
> > +obj-$(CONFIG_NETCONSOLE) += netconsole.o
>
> It would be preferable to fix this with initcall ordering. Perhaps by
> switching init_netconsole() to subsys_initcall.
subsys_initcall is defined as __define_initcall("4",fn,4).
In !MODULE case, device driver module_int() is defined as
__define_initcall("6",fn,6)
If we use subsys_initcall for init_netconsole, it will still be called
before network device driver is initialized.
How about late_initcall?
(Not tested yet)
>From 11f4f035e96ff430192d0a75552dd715acb5f3b8 Mon Sep 17 00:00:00 2001
From: Lin Ming <ming.m.lin@intel.com>
Date: Sat, 10 Sep 2011 10:36:10 +0800
Subject: [PATCH] drivers/net: Makefile, fix netconsole link order
Commit 88491d8(drivers/net: Kconfig & Makefile cleanup) causes a
regression that netconsole does not work if netconsole and network
device driver are build into kernel, because netconsole is linked before
network device driver.
Fixes it by switching init_netconsole() to late_initcall if it's
build-in.
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
---
drivers/net/netconsole.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index dfc8272..914be29 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -799,5 +799,9 @@ static void __exit cleanup_netconsole(void)
}
}
+#ifdef MODULE
module_init(init_netconsole);
module_exit(cleanup_netconsole);
+#else
+late_initcall(init_netconsole);
+#endif /* !MODULE */
--
1.7.2.3
^ permalink raw reply related
* Re: Backporting the Linux kernel, for good - was: Re: semantic patch inference
From: Julia Lawall @ 2011-09-10 3:12 UTC (permalink / raw)
To: Jesper Andersen
Cc: Luis R. Rodriguez, Hauke Mehrtens, linux-wireless,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CA+RMdsmEJRv8i81o_GD6o7Bn0MpQJMidghTnt3f-QEeU6V6eNQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sat, 10 Sep 2011, Jesper Andersen wrote:
> I'm in Singapore now and will head for Denmark tomorrow so I can't promise
> very instant reponses.
>
> I haven't read the full thread just yet, but I just wanted to clarify one
> thing:
>
> On Saturday, September 10, 2011, Julia Lawall wrote:
> >
> > There was also the question about one or multiple types of changes. I
> > think this is not a problem, but Jesper should confirm. If a patch
> > contains
> > two changes and one can be generalized and the other one cannot for some
> > reason, does spdiff give up on the whole thing, or does it do what it can?
> >
> >
> It's a little difficult to answer this precisely, so let me instead give an
> example and then you can say in what way my example falls short of what you
> thought of.
>
> Suppose we have two functions that changed:
>
> f1=
> void foo() {
> bar(x->dev);
> foz(117);
> }
>
> f2=
> void goo() {
> if(b) bar(y->dev);
> }
>
>
> And the new versions are:
>
> f1'=
> void foo() {
> bar(x);
> foz(117, 42);
> }
>
> f2'=
> void goo() {
> if(b) bar(y);
> }
>
> In this example there are basically three changes:
>
> x->dev becomes x
> y->dev becomes y
> foz(117) becomes foz(117', 42)
>
> In this case spdiff will find: (I just ran it to be sure)
> @@
> expression X0;
> @@
> - bar(X0->dev);
> + bar(X0);
>
> So the one ungeneralizable change was simply not included. Does this cover
> your question Julia?
That seems good. But perhaps the user would like to know about the
elements that were not generalizable as well.
julia
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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 -next] drivers/net: Makefile, fix netconsole link order
From: Andrew Morton @ 2011-09-10 4:10 UTC (permalink / raw)
To: Lin Ming
Cc: David S. Miller, lkml, netdev@vger.kernel.org, Kirsher, Jeffrey T
In-Reply-To: <1315622612.2425.16.camel@hp6530s>
On Sat, 10 Sep 2011 10:43:32 +0800 Lin Ming <ming.m.lin@intel.com> wrote:
> On Sat, 2011-09-10 at 08:00 +0800, Andrew Morton wrote:
>
> > > +obj-$(CONFIG_NETCONSOLE) += netconsole.o
> >
> > It would be preferable to fix this with initcall ordering. Perhaps by
> > switching init_netconsole() to subsys_initcall.
>
> subsys_initcall is defined as __define_initcall("4",fn,4).
> In !MODULE case, device driver module_int() is defined as
> __define_initcall("6",fn,6)
oop, yes, I am chronologically challenged.
> If we use subsys_initcall for init_netconsole, it will still be called
> before network device driver is initialized.
>
> How about late_initcall?
>
> (Not tested yet)
>
> >From 11f4f035e96ff430192d0a75552dd715acb5f3b8 Mon Sep 17 00:00:00 2001
> From: Lin Ming <ming.m.lin@intel.com>
> Date: Sat, 10 Sep 2011 10:36:10 +0800
> Subject: [PATCH] drivers/net: Makefile, fix netconsole link order
>
> Commit 88491d8(drivers/net: Kconfig & Makefile cleanup) causes a
> regression that netconsole does not work if netconsole and network
> device driver are build into kernel, because netconsole is linked before
> network device driver.
>
> Fixes it by switching init_netconsole() to late_initcall if it's
> build-in.
>
> Signed-off-by: Lin Ming <ming.m.lin@intel.com>
> ---
> drivers/net/netconsole.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
> index dfc8272..914be29 100644
> --- a/drivers/net/netconsole.c
> +++ b/drivers/net/netconsole.c
> @@ -799,5 +799,9 @@ static void __exit cleanup_netconsole(void)
> }
> }
>
> +#ifdef MODULE
> module_init(init_netconsole);
> module_exit(cleanup_netconsole);
> +#else
> +late_initcall(init_netconsole);
> +#endif /* !MODULE */
That should work, unless any net driver is weirdly also using
late_initcall. But if there are such drivers, they would have failed
with the old Makefile ordering.
^ permalink raw reply
* Re: [PATCH -next] drivers/net: Makefile, fix netconsole link order
From: Lin Ming @ 2011-09-10 4:26 UTC (permalink / raw)
To: Andrew Morton
Cc: David S. Miller, lkml, netdev@vger.kernel.org, Kirsher, Jeffrey T
In-Reply-To: <20110909211029.69dfd68d.akpm@linux-foundation.org>
On Sat, 2011-09-10 at 12:10 +0800, Andrew Morton wrote:
> On Sat, 10 Sep 2011 10:43:32 +0800 Lin Ming <ming.m.lin@intel.com> wrote:
>
> > On Sat, 2011-09-10 at 08:00 +0800, Andrew Morton wrote:
> >
> > > > +obj-$(CONFIG_NETCONSOLE) += netconsole.o
> > >
> > > It would be preferable to fix this with initcall ordering. Perhaps by
> > > switching init_netconsole() to subsys_initcall.
> >
> > subsys_initcall is defined as __define_initcall("4",fn,4).
> > In !MODULE case, device driver module_int() is defined as
> > __define_initcall("6",fn,6)
>
> oop, yes, I am chronologically challenged.
>
> > If we use subsys_initcall for init_netconsole, it will still be called
> > before network device driver is initialized.
> >
> > How about late_initcall?
> >
> > (Not tested yet)
> >
> > >From 11f4f035e96ff430192d0a75552dd715acb5f3b8 Mon Sep 17 00:00:00 2001
> > From: Lin Ming <ming.m.lin@intel.com>
> > Date: Sat, 10 Sep 2011 10:36:10 +0800
> > Subject: [PATCH] drivers/net: Makefile, fix netconsole link order
> >
> > Commit 88491d8(drivers/net: Kconfig & Makefile cleanup) causes a
> > regression that netconsole does not work if netconsole and network
> > device driver are build into kernel, because netconsole is linked before
> > network device driver.
> >
> > Fixes it by switching init_netconsole() to late_initcall if it's
> > build-in.
> >
> > Signed-off-by: Lin Ming <ming.m.lin@intel.com>
> > ---
> > drivers/net/netconsole.c | 4 ++++
> > 1 files changed, 4 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
> > index dfc8272..914be29 100644
> > --- a/drivers/net/netconsole.c
> > +++ b/drivers/net/netconsole.c
> > @@ -799,5 +799,9 @@ static void __exit cleanup_netconsole(void)
> > }
> > }
> >
> > +#ifdef MODULE
> > module_init(init_netconsole);
> > module_exit(cleanup_netconsole);
> > +#else
> > +late_initcall(init_netconsole);
> > +#endif /* !MODULE */
>
> That should work, unless any net driver is weirdly also using
> late_initcall. But if there are such drivers, they would have failed
> with the old Makefile ordering.
Yes.
BTW, may I get your ACK after testing this patch?
Thanks.
^ permalink raw reply
* skge: transmit queue 0 timed out
From: Bart Van Assche @ 2011-09-10 9:27 UTC (permalink / raw)
To: netdev
In-Reply-To: <CAO+b5-p=9NXJrT1h6KQG9BpP=mDp8XjMZsCxsk=WkuBZ_KhtKA@mail.gmail.com>
Hello,
Anyone who can tell me whether I should worry about the kernel warning
shown below ? I've observed that warning for the first time with
3.1-rc5 and hadn't seen it yet with 3.1-rc4 or any older kernel.
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x24f/0x260()
Hardware name: P5Q DELUXE
NETDEV WATCHDOG: eth0 (skge): transmit queue 0 timed out
Modules linked in: snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device
af_packet rdma_ucm rdma_cm iw_cm ib_addr ib_ipoib ib_cm ib_sa
ib_uverbs ib_umad mlx4_ib ib_mad ib_core microcode
cpufreq_conservative cpufreq_userspaceq mperf dm_mod
snd_hda_codec_hdmi snd_hda_codec_analog snd_hda_intel snd_hda_codec
snd_hwdep snd_pcm snd_timer snd sr_mod mlx4_core sg cdrom soundcore
i2c_i801 snd_page_alloc i2c_core pcspkr button uhci_hcd ehci_hcd sxt3
mbcache jbd fan ata_generic ata_piix pata_marvell ahci libahci libata
scsi_mod thermal processor thermal_sys hwmon
Pid: 6260, comm: wish Not tainted 3.1.0-rc4-scst-debug+ #2
Call Trace:
<IRQ> [<ffffffff8104564f>] warn_slowpath_common+0x7f/0xc0
[<ffffffff81045746>] warn_slowpath_fmt+0x46/0x50
[<ffffffff813268df>] dev_watchdog+0x24f/0x260
[<ffffffff8105602a>] run_timer_softirq+0x19a/0x3f0
[<ffffffff81055f97>] ? run_timer_softirq+0x107/0x3f0
[<ffffffff81326690>] ? pfifo_fast_init+0xa0/0xa0
[<ffffffff8104cecd>] __do_softirq+0xcd/0x250
[<ffffffff813e5cec>] call_softirq+0x1c/0x30
[<ffffffff810043bd>] do_softirq+0x8d/0xc0
[<ffffffff8104d36e>] irq_exit+0xae/0xe0
[<ffffffff813e637e>] smp_apic_timer_interrupt+0x6e/0x99
[<ffffffff813e4570>] apic_timer_interrupt+0x70/0x80
<EOI> [<ffffffff813dbe0a>] ? retint_swapgs+0xe/0x13
---[ end trace fbbed52d2a66b808 ]---
Bart.
^ permalink raw reply
* Re: Memory leak in ip_dst_cache
From: Neil Horman @ 2011-09-10 13:04 UTC (permalink / raw)
To: Kumar S; +Cc: Eric Dumazet, netdev
In-Reply-To: <1315608825.98066.YahooMailNeo@web113914.mail.gq1.yahoo.com>
On Fri, Sep 09, 2011 at 03:53:45PM -0700, Kumar S wrote:
> Yes Eric, this command doesn't work on 2.6.24. Which timer are you suspecting?
>
He means that the timer that starts the the workqueue which calls dst_gc_task is
either delayed indefinately, or otherwise not run, which means that the route
cache will never be scanned for old entries. The implication being that, while
the dst entries aren't leaked per-se, but never expired, so they just sit
around. You can check this by instrumenting gc_dst_task with a printk or two
and watch to see if it ever pops up.
If you only have 512Mb of ram and want to really restrict you're cache size, you
should definately consider backporting the route cache rebuild patch to disable
the route cache usage entirely. It shouldn't be too hard to do.
Neil
>
^ permalink raw reply
* [PATCH] mac_esp: remove redundant mutual exclusion
From: Finn Thain @ 2011-09-10 15:01 UTC (permalink / raw)
To: David Miller; +Cc: linux-m68k, netdev
Mutual exclusion is redundant here because all the paths in the call graph
leading to esp_driver_ops.send_dma_cmd() happen under spin_lock_irqsave/
spin_lock_irqrestore. Remove it.
Tested on a Mac Quadra 660av and a Mac LC 630.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
---
Part of this patch relates to Geert's m68k generic hard irq conversion
work. Under genirq, the disable_irq() in mac_esp leads to deadlock. It
wasn't a problem before because the m68k disable_irq() implementation is
equivalent to genirq's disable_irq_nosync().
Index: linux-m68k/drivers/scsi/mac_esp.c
===================================================================
--- linux-m68k.orig/drivers/scsi/mac_esp.c 2011-08-28 00:33:13.000000000 +1000
+++ linux-m68k/drivers/scsi/mac_esp.c 2011-08-28 00:35:48.000000000 +1000
@@ -230,9 +230,6 @@ static void mac_esp_send_pdma_cmd(struct
u32 dma_count, int write, u8 cmd)
{
struct mac_esp_priv *mep = MAC_ESP_GET_PRIV(esp);
- unsigned long flags;
-
- local_irq_save(flags);
mep->error = 0;
@@ -270,8 +267,6 @@ static void mac_esp_send_pdma_cmd(struct
esp_count = n;
}
} while (esp_count);
-
- local_irq_restore(flags);
}
/*
@@ -353,8 +348,6 @@ static void mac_esp_send_pio_cmd(struct
struct mac_esp_priv *mep = MAC_ESP_GET_PRIV(esp);
u8 *fifo = esp->regs + ESP_FDATA * 16;
- disable_irq(esp->host->irq);
-
cmd &= ~ESP_CMD_DMA;
mep->error = 0;
@@ -431,8 +424,6 @@ static void mac_esp_send_pio_cmd(struct
scsi_esp_cmd(esp, ESP_CMD_TI);
}
}
-
- enable_irq(esp->host->irq);
}
static int mac_esp_irq_pending(struct esp *esp)
^ permalink raw reply
* [PATCH] macmace: disable only the dma interrupt
From: Finn Thain @ 2011-09-10 15:02 UTC (permalink / raw)
To: David Miller; +Cc: linux-m68k, netdev
Don't disable all interrupts, just disable the relevant one.
Also move a couple of printk calls outside of local_irq_save/restore.
Tested on a Quadra 660av.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Index: linux-m68k/drivers/net/macmace.c
===================================================================
--- linux-m68k.orig/drivers/net/macmace.c 2011-08-28 00:33:33.000000000 +1000
+++ linux-m68k/drivers/net/macmace.c 2011-08-28 00:36:10.000000000 +1000
@@ -458,8 +458,9 @@ static int mace_xmit_start(struct sk_buf
local_irq_save(flags);
netif_stop_queue(dev);
if (!mp->tx_count) {
- printk(KERN_ERR "macmace: tx queue running but no free buffers.\n");
local_irq_restore(flags);
+ printk(KERN_ERR
+ "macmace: tx queue running but no free buffers.\n");
return NETDEV_TX_BUSY;
}
mp->tx_count--;
@@ -563,10 +564,8 @@ static irqreturn_t mace_interrupt(int ir
struct mace_data *mp = netdev_priv(dev);
volatile struct mace *mb = mp->mace;
int intr, fs;
- unsigned long flags;
- /* don't want the dma interrupt handler to fire */
- local_irq_save(flags);
+ disable_irq(mp->dma_intr);
intr = mb->ir; /* read interrupt register */
mace_handle_misc_intrs(dev, intr);
@@ -604,7 +603,7 @@ static irqreturn_t mace_interrupt(int ir
if (mp->tx_count)
netif_wake_queue(dev);
- local_irq_restore(flags);
+ enable_irq(mp->dma_intr);
return IRQ_HANDLED;
}
@@ -615,11 +614,12 @@ static void mace_tx_timeout(struct net_d
volatile struct mace *mb = mp->mace;
unsigned long flags;
+ printk(KERN_ERR "macmace: transmit timeout - resetting\n");
+
local_irq_save(flags);
/* turn off both tx and rx and reset the chip */
mb->maccc = 0;
- printk(KERN_ERR "macmace: transmit timeout - resetting\n");
mace_txdma_reset(dev);
mace_reset(dev);
^ permalink raw reply
* [PATCH] fib:fix BUG_ON in fib_nl_newrule when add new fib rule
From: Wanlong Gao @ 2011-09-10 17:19 UTC (permalink / raw)
To: linux-kernel, netdev; +Cc: davem, eric.dumazet, omarapazanadi, Gao feng
From: Gao feng <gaofeng@cn.fujitsu.com>
add new fib rule can cause BUG_ON
the reproduce shell is
#ip rule add pref 38
#ip rule add pref 38
#ip rule add to 192.168.3.0/24 goto 38
#ip rule del pref 38
#ip rule add to 192.168.3.0/24 goto 38
#ip rule add pref 38
then the BUG_ON will happen
add a var unresolved in struct fib_rule
and use it to identify whether this rule is unresolved
Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
---
include/net/fib_rules.h | 1 +
net/core/fib_rules.c | 5 ++++-
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/include/net/fib_rules.h b/include/net/fib_rules.h
index 075f1e3..e4bae01 100644
--- a/include/net/fib_rules.h
+++ b/include/net/fib_rules.h
@@ -19,6 +19,7 @@ struct fib_rule {
u32 flags;
u32 table;
u8 action;
+ u8 unresolved;
u32 target;
struct fib_rule __rcu *ctarget;
char iifname[IFNAMSIZ];
diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
index e7ab0c0..aa20560 100644
--- a/net/core/fib_rules.c
+++ b/net/core/fib_rules.c
@@ -384,9 +384,11 @@ static int fib_nl_newrule(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg)
*/
list_for_each_entry(r, &ops->rules_list, list) {
if (r->action == FR_ACT_GOTO &&
- r->target == rule->pref) {
+ r->target == rule->pref &&
+ r->unresolved) {
BUG_ON(rtnl_dereference(r->ctarget) != NULL);
rcu_assign_pointer(r->ctarget, rule);
+ r->unresolved = 0;
if (--ops->unresolved_rules == 0)
break;
}
@@ -488,6 +490,7 @@ static int fib_nl_delrule(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg)
list_for_each_entry(tmp, &ops->rules_list, list) {
if (rtnl_dereference(tmp->ctarget) == rule) {
rcu_assign_pointer(tmp->ctarget, NULL);
+ tmp->unresolved = 1;
ops->unresolved_rules++;
}
}
--
1.7.6
^ permalink raw reply related
* Re: [PATCH] mac_esp: remove redundant mutual exclusion
From: David Miller @ 2011-09-10 18:28 UTC (permalink / raw)
To: fthain; +Cc: linux-m68k, netdev
In-Reply-To: <alpine.LNX.2.00.1109110038500.5327@nippy.intranet>
From: Finn Thain <fthain@telegraphics.com.au>
Date: Sun, 11 Sep 2011 01:01:34 +1000 (EST)
> Mutual exclusion is redundant here because all the paths in the call graph
> leading to esp_driver_ops.send_dma_cmd() happen under spin_lock_irqsave/
> spin_lock_irqrestore. Remove it.
>
> Tested on a Mac Quadra 660av and a Mac LC 630.
>
> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
This patch should be CC:'d to linux-scsi not netdev
I understand how the networking maintainer is very responsive
and the SCSI maintainer generally takes forever, so your
Freudian slip will go unjudged :-)
^ permalink raw reply
* Re: [PATCH] macmace: disable only the dma interrupt
From: David Miller @ 2011-09-10 18:30 UTC (permalink / raw)
To: fthain; +Cc: linux-m68k, netdev
In-Reply-To: <alpine.LNX.2.00.1109110042210.5327@nippy.intranet>
From: Finn Thain <fthain@telegraphics.com.au>
Date: Sun, 11 Sep 2011 01:02:16 +1000 (EST)
> Don't disable all interrupts, just disable the relevant one.
>
> Also move a couple of printk calls outside of local_irq_save/restore.
>
> Tested on a Quadra 660av.
>
> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Using disable_irq() is very expensive, and when done from an interrupt
handler can deadlock especially on SMP (which I understand might not
be relevant here).
I really can't see why you'd do things this way, especially since
interrupt handlers under Linux now unconditionally always run with cpu
interrupts disabled.
^ permalink raw reply
* Re: [PATCH] fib:fix BUG_ON in fib_nl_newrule when add new fib rule
From: Eric Dumazet @ 2011-09-11 7:12 UTC (permalink / raw)
To: Wanlong Gao; +Cc: linux-kernel, netdev, davem, omarapazanadi, Gao feng
In-Reply-To: <1315675150-3012-1-git-send-email-wanlong.gao@gmail.com>
Le dimanche 11 septembre 2011 à 01:19 +0800, Wanlong Gao a écrit :
> From: Gao feng <gaofeng@cn.fujitsu.com>
>
> add new fib rule can cause BUG_ON
> the reproduce shell is
>
> #ip rule add pref 38
> #ip rule add pref 38
> #ip rule add to 192.168.3.0/24 goto 38
> #ip rule del pref 38
> #ip rule add to 192.168.3.0/24 goto 38
> #ip rule add pref 38
>
> then the BUG_ON will happen
> add a var unresolved in struct fib_rule
> and use it to identify whether this rule is unresolved
>
> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
> ---
> include/net/fib_rules.h | 1 +
> net/core/fib_rules.c | 5 ++++-
> 2 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/include/net/fib_rules.h b/include/net/fib_rules.h
> index 075f1e3..e4bae01 100644
> --- a/include/net/fib_rules.h
> +++ b/include/net/fib_rules.h
> @@ -19,6 +19,7 @@ struct fib_rule {
> u32 flags;
> u32 table;
> u8 action;
> + u8 unresolved;
> u32 target;
> struct fib_rule __rcu *ctarget;
> char iifname[IFNAMSIZ];
> diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
> index e7ab0c0..aa20560 100644
> --- a/net/core/fib_rules.c
> +++ b/net/core/fib_rules.c
> @@ -384,9 +384,11 @@ static int fib_nl_newrule(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg)
> */
> list_for_each_entry(r, &ops->rules_list, list) {
> if (r->action == FR_ACT_GOTO &&
> - r->target == rule->pref) {
> + r->target == rule->pref &&
> + r->unresolved) {
> BUG_ON(rtnl_dereference(r->ctarget) != NULL);
> rcu_assign_pointer(r->ctarget, rule);
> + r->unresolved = 0;
> if (--ops->unresolved_rules == 0)
> break;
> }
> @@ -488,6 +490,7 @@ static int fib_nl_delrule(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg)
> list_for_each_entry(tmp, &ops->rules_list, list) {
> if (rtnl_dereference(tmp->ctarget) == rule) {
> rcu_assign_pointer(tmp->ctarget, NULL);
> + tmp->unresolved = 1;
> ops->unresolved_rules++;
> }
> }
Hmm, good catch, but you add 'unresolved' field but dont init it
correctly to 1 in all cases.
Following will break :
ip rule add pref 100
ip rule add to 192.168.3.0/24 goto 200
ip rule add pref 200
Normally, we should have
unresolved = (ctarget == NULL);
What about following patch instead ?
diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
index e7ab0c0..3231b46 100644
--- a/net/core/fib_rules.c
+++ b/net/core/fib_rules.c
@@ -384,8 +384,8 @@ static int fib_nl_newrule(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg)
*/
list_for_each_entry(r, &ops->rules_list, list) {
if (r->action == FR_ACT_GOTO &&
- r->target == rule->pref) {
- BUG_ON(rtnl_dereference(r->ctarget) != NULL);
+ r->target == rule->pref &&
+ rtnl_dereference(r->ctarget) == NULL) {
rcu_assign_pointer(r->ctarget, rule);
if (--ops->unresolved_rules == 0)
break;
^ permalink raw reply related
* kernel.org extended outage - wait or use alternatives?
From: Jan Ceuleers @ 2011-09-11 8:04 UTC (permalink / raw)
To: netdev
David,
I'm a mere observer of kernel development rather than an active
participant in it. My observation is that networking development has all
but come to a standstill while we wait for master.kernel.org to come back.
Linus is now using a github.com account; any reason why the same could
not apply to net and net-next, so that development can proceed?
Thanks, Jan
^ permalink raw reply
* Re: kernel.org extended outage - wait or use alternatives?
From: Eric Dumazet @ 2011-09-11 8:24 UTC (permalink / raw)
To: Jan Ceuleers; +Cc: netdev
In-Reply-To: <4E6C6BAA.3020701@computer.org>
Le dimanche 11 septembre 2011 à 10:04 +0200, Jan Ceuleers a écrit :
> David,
>
> I'm a mere observer of kernel development rather than an active
> participant in it. My observation is that networking development has all
> but come to a standstill while we wait for master.kernel.org to come back.
>
> Linus is now using a github.com account; any reason why the same could
> not apply to net and net-next, so that development can proceed?
>
As an active kernel developer, I would vote for being thankful for this
pause. Its always a good thing to relax and enjoy your time ;)
I actually lost my main development trees because of nasty disk
corruptions in 3.1-rc4, and wrong habit of not doing any backups... Oh
well...
More than a repository for net and net-next, we really want a working
netdev mailing list.
Anyway, everything is queued and you dont have to worry.
http://patchwork.ozlabs.org/project/netdev/list/
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Michael S. Tsirkin @ 2011-09-11 9:38 UTC (permalink / raw)
To: Roopa Prabhu
Cc: netdev, dragos.tatulea, arnd, dwang2, benve, kaber, sri, davem,
eric.dumazet, mchan, kvm
In-Reply-To: <CA8F8DED.33CF5%roprabhu@cisco.com>
On Fri, Sep 09, 2011 at 09:33:33AM -0700, Roopa Prabhu wrote:
>
>
>
> On 9/8/11 10:55 PM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > On Thu, Sep 08, 2011 at 07:53:11PM -0700, Roopa Prabhu wrote:
> >>>> Phase 1: Goal: Enable hardware filtering for all macvlan modes
> >>>> - In macvlan passthru mode the single guest virtio-nic connected will
> >>>> receive traffic that he requested for
> >>>> - In macvlan non-passthru mode all guest virtio-nics sharing the
> >>>> physical nic will see all other guest traffic
> >>>> but the filtering at guest virtio-nic
> >>>
> >>> I don't think guests currently filter anything.
> >>>
> >> I was referring to Qemu-kvm virtio-net in
> >> virtion_net_receive->receive_filter. I think It only passes pkts that the
> >> guest OS is interested. It uses the filter table that I am passing to
> >> macvtap in this patch.
> >
> > This happens after userspace thread gets woken up and data
> > is copied there. So relying on filtering at that level is
> > going to be very inefficient on a system with
> > multiple active guests. Further, and for that reason, vhost-net
> > doesn't do filtering at all, relying on the backends
> > to pass it correct packets.
>
> Ok thanks for the info. So in which case, phase 1 is best for PASSTHRU mode
> and for non-PASSTHRU when there is a single guest connected to a VF.
> For non-PASSTHRU multi guest sharing the same VF, Phase 1 is definitely
> better than putting the VF in promiscuous mode.
> But to address the concern you mention above, in phase 2 when we have more
> than one guest sharing the VF,
It's probably more interesting for a card without SRIOV support.
> we will have to add filter lookup in macvlan
> to filter pkts for each guest.
Any chance to enable hardware filters for that?
> This will need some performance tests too.
>
> Will start investigating the netlink interface comments for phase 1 first.
>
> Thanks!
> -Roopa
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Michael S. Tsirkin @ 2011-09-11 9:44 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Sridhar Samudrala, netdev, dragos.tatulea, arnd, dwang2, benve,
kaber, davem, eric.dumazet, mchan, kvm
In-Reply-To: <CA8ECF75.33BFF%roprabhu@cisco.com>
On Thu, Sep 08, 2011 at 08:00:53PM -0700, Roopa Prabhu wrote:
>
>
>
> On 9/8/11 12:33 PM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > On Thu, Sep 08, 2011 at 12:23:56PM -0700, Roopa Prabhu wrote:
> >>>
> >>> I think the main usecase for passthru mode is to assign a SR-IOV VF to
> >>> a single guest.
> >>>
> >> Yes and for the passthru usecase this patch should be enough to enable
> >> filtering in hw (eventually like I indicated before I need to fix vlan
> >> filtering too).
> >
> > So with filtering in hw, and in sriov VF case, VFs
> > actually share a filtering table. How will that
> > be partitioned?
>
> AFAIK, though it might maintain a single filter table space in hw, hw does
> know which filter belongs to which VF. And the OS driver does not need to do
> anything special. The VF driver exposes a VF netdev. And any uc/mc addresses
> registered with a VF netdev are registered with the hw by the driver. And hw
> will filter and send only pkts that the VF has expressed interest in.
>
> No special filter partitioning in hw is required.
>
> Thanks,
> Roopa
Yes, but what I mean is, if the size of the single filter table
is limited, we need to decide how many addresses is
each guest allowed. If we let one guest ask for
as many as it wants, it can lock others out.
--
MST
^ permalink raw reply
* Re: [PATCH] macmace: disable only the dma interrupt
From: Finn Thain @ 2011-09-11 10:02 UTC (permalink / raw)
To: David Miller; +Cc: linux-m68k, netdev
In-Reply-To: <20110910.143046.520109083086760748.davem@davemloft.net>
On Sat, 10 Sep 2011, David Miller wrote:
> From: Finn Thain <fthain@telegraphics.com.au>
> Date: Sun, 11 Sep 2011 01:02:16 +1000 (EST)
>
> > Don't disable all interrupts, just disable the relevant one.
> >
> > Also move a couple of printk calls outside of local_irq_save/restore.
> >
> > Tested on a Quadra 660av.
> >
> > Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
>
> Using disable_irq() is very expensive, and when done from an interrupt
> handler can deadlock especially on SMP (which I understand might not be
> relevant here).
>
> I really can't see why you'd do things this way, especially since
> interrupt handlers under Linux now unconditionally always run with cpu
> interrupts disabled.
I wasn't aware of this (I was under the impression that a higher priority
interrupt could be serviced). Please disregard this patch.
Finn
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Roopa Prabhu @ 2011-09-11 13:18 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Sridhar Samudrala, netdev, dragos.tatulea, arnd, dwang2, benve,
kaber, davem, eric.dumazet, mchan, kvm
In-Reply-To: <20110911094449.GF27096@redhat.com>
On 9/11/11 2:44 AM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>>
>> AFAIK, though it might maintain a single filter table space in hw, hw does
>> know which filter belongs to which VF. And the OS driver does not need to do
>> anything special. The VF driver exposes a VF netdev. And any uc/mc addresses
>> registered with a VF netdev are registered with the hw by the driver. And hw
>> will filter and send only pkts that the VF has expressed interest in.
>>
>> No special filter partitioning in hw is required.
>>
>> Thanks,
>> Roopa
>
> Yes, but what I mean is, if the size of the single filter table
> is limited, we need to decide how many addresses is
> each guest allowed. If we let one guest ask for
> as many as it wants, it can lock others out.
Yes true. In these cases ie when the number of unicast addresses being
registered is more than it can handle, The VF driver will put the VF in
promiscuous mode (Or at least its supposed to do. I think all drivers do
that).
Thanks,
Roopa
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Roopa Prabhu @ 2011-09-11 13:18 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev, dragos.tatulea, arnd, dwang2, benve, kaber, sri, davem,
eric.dumazet, mchan, kvm
In-Reply-To: <20110911093832.GD27096@redhat.com>
On 9/11/11 2:38 AM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Fri, Sep 09, 2011 at 09:33:33AM -0700, Roopa Prabhu wrote:
>>
>>
>>
>> On 9/8/11 10:55 PM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>>
>>> On Thu, Sep 08, 2011 at 07:53:11PM -0700, Roopa Prabhu wrote:
>>>>>> Phase 1: Goal: Enable hardware filtering for all macvlan modes
>>>>>> - In macvlan passthru mode the single guest virtio-nic connected will
>>>>>> receive traffic that he requested for
>>>>>> - In macvlan non-passthru mode all guest virtio-nics sharing the
>>>>>> physical nic will see all other guest traffic
>>>>>> but the filtering at guest virtio-nic
>>>>>
>>>>> I don't think guests currently filter anything.
>>>>>
>>>> I was referring to Qemu-kvm virtio-net in
>>>> virtion_net_receive->receive_filter. I think It only passes pkts that the
>>>> guest OS is interested. It uses the filter table that I am passing to
>>>> macvtap in this patch.
>>>
>>> This happens after userspace thread gets woken up and data
>>> is copied there. So relying on filtering at that level is
>>> going to be very inefficient on a system with
>>> multiple active guests. Further, and for that reason, vhost-net
>>> doesn't do filtering at all, relying on the backends
>>> to pass it correct packets.
>>
>> Ok thanks for the info. So in which case, phase 1 is best for PASSTHRU mode
>> and for non-PASSTHRU when there is a single guest connected to a VF.
>> For non-PASSTHRU multi guest sharing the same VF, Phase 1 is definitely
>> better than putting the VF in promiscuous mode.
>> But to address the concern you mention above, in phase 2 when we have more
>> than one guest sharing the VF,
>
> It's probably more interesting for a card without SRIOV support.
>
If its an SRIOV card I am assuming people likely using PASSTHRU mode.
Non-SRIOV cards will use any of the non-PASSTHRU mode.
>> we will have to add filter lookup in macvlan
>> to filter pkts for each guest.
>
> Any chance to enable hardware filters for that?
>
NAFAIK. Am not sure how you would do it too. Its still a single device from
where the host receives traffic from.
Thanks,
Roopa
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Michael S. Tsirkin @ 2011-09-11 18:52 UTC (permalink / raw)
To: Roopa Prabhu
Cc: netdev, dragos.tatulea, arnd, dwang2, benve, kaber, sri, davem,
eric.dumazet, mchan, kvm
In-Reply-To: <CA92031A.33DE1%roprabhu@cisco.com>
On Sun, Sep 11, 2011 at 06:18:02AM -0700, Roopa Prabhu wrote:
>
>
>
> On 9/11/11 2:38 AM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > On Fri, Sep 09, 2011 at 09:33:33AM -0700, Roopa Prabhu wrote:
> >>
> >>
> >>
> >> On 9/8/11 10:55 PM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >>
> >>> On Thu, Sep 08, 2011 at 07:53:11PM -0700, Roopa Prabhu wrote:
> >>>>>> Phase 1: Goal: Enable hardware filtering for all macvlan modes
> >>>>>> - In macvlan passthru mode the single guest virtio-nic connected will
> >>>>>> receive traffic that he requested for
> >>>>>> - In macvlan non-passthru mode all guest virtio-nics sharing the
> >>>>>> physical nic will see all other guest traffic
> >>>>>> but the filtering at guest virtio-nic
> >>>>>
> >>>>> I don't think guests currently filter anything.
> >>>>>
> >>>> I was referring to Qemu-kvm virtio-net in
> >>>> virtion_net_receive->receive_filter. I think It only passes pkts that the
> >>>> guest OS is interested. It uses the filter table that I am passing to
> >>>> macvtap in this patch.
> >>>
> >>> This happens after userspace thread gets woken up and data
> >>> is copied there. So relying on filtering at that level is
> >>> going to be very inefficient on a system with
> >>> multiple active guests. Further, and for that reason, vhost-net
> >>> doesn't do filtering at all, relying on the backends
> >>> to pass it correct packets.
> >>
> >> Ok thanks for the info. So in which case, phase 1 is best for PASSTHRU mode
> >> and for non-PASSTHRU when there is a single guest connected to a VF.
> >> For non-PASSTHRU multi guest sharing the same VF, Phase 1 is definitely
> >> better than putting the VF in promiscuous mode.
> >> But to address the concern you mention above, in phase 2 when we have more
> >> than one guest sharing the VF,
> >
> > It's probably more interesting for a card without SRIOV support.
> >
> If its an SRIOV card I am assuming people likely using PASSTHRU mode.
> Non-SRIOV cards will use any of the non-PASSTHRU mode.
>
>
> >> we will have to add filter lookup in macvlan
> >> to filter pkts for each guest.
> >
> > Any chance to enable hardware filters for that?
> >
> NAFAIK. Am not sure how you would do it too. Its still a single device from
> where the host receives traffic from.
>
> Thanks,
> Roopa
VMDQ cards might let you program mac addresses for individula rings.
--
MST
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Michael S. Tsirkin @ 2011-09-11 19:03 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Sridhar Samudrala, netdev, dragos.tatulea, arnd, dwang2, benve,
kaber, davem, eric.dumazet, mchan, kvm
In-Reply-To: <CA920319.33DE1%roprabhu@cisco.com>
On Sun, Sep 11, 2011 at 06:18:01AM -0700, Roopa Prabhu wrote:
>
>
>
> On 9/11/11 2:44 AM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> >>
> >> AFAIK, though it might maintain a single filter table space in hw, hw does
> >> know which filter belongs to which VF. And the OS driver does not need to do
> >> anything special. The VF driver exposes a VF netdev. And any uc/mc addresses
> >> registered with a VF netdev are registered with the hw by the driver. And hw
> >> will filter and send only pkts that the VF has expressed interest in.
> >>
> >> No special filter partitioning in hw is required.
> >>
> >> Thanks,
> >> Roopa
> >
> > Yes, but what I mean is, if the size of the single filter table
> > is limited, we need to decide how many addresses is
> > each guest allowed. If we let one guest ask for
> > as many as it wants, it can lock others out.
>
> Yes true. In these cases ie when the number of unicast addresses being
> registered is more than it can handle, The VF driver will put the VF in
> promiscuous mode (Or at least its supposed to do. I think all drivers do
> that).
>
>
> Thanks,
> Roopa
Right, so that works at least but likely performs worse
than a hardware filter. So we better allocate it in
some fair way, as a minimum. Maybe a way for
the admin to control that allocation is useful.
--
MST
^ permalink raw reply
* Re: r8169 hard-freezes the system on big network loads
From: Michael Brade @ 2011-09-11 20:16 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, nic_swsd
In-Reply-To: <20110823131726.GA21092@electric-eye.fr.zoreil.com>
On Tuesday 23 August 2011 15:17:26 Francois Romieu wrote:
> Francois Romieu <romieu@fr.zoreil.com> :
> [...]
>
> > Yes. There is enough data for me to reproduce the bug with the
> > exact same chipset.
>
> I can not generate a single rx error and the driver refuses to crash :o/
>
> Can you apply the patch below on top of 3.1.0-rc3 and see if it makes
> a difference ?
Sorry for the delay, I have had only two days for email in the last few weeks
and additionally kernel.org was and still is down.
Does it have to be 3.1.0-rc3 or is 3.0.1 ok as well? If so, I have another bad
news: 3.0.1 still crashes with this patch. It took me a lot longer to crash it
but eventually it did happen. Not sure why it took longer, I guess I didn't
generate enough throughput.
If you want me to use 3.1.0 then we'll have to wait until git.kernel.org is
back...
thanks,
Michael
> Thanks.
>
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index 02339b3..c54ed17 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -5326,10 +5326,6 @@ static int rtl8169_rx_interrupt(struct net_device
> *dev, dev->stats.rx_length_errors++;
> if (status & RxCRC)
> dev->stats.rx_crc_errors++;
> - if (status & RxFOVF) {
> - rtl8169_schedule_work(dev, rtl8169_reset_task);
> - dev->stats.rx_fifo_errors++;
> - }
> rtl8169_mark_to_asic(desc, rx_buf_sz);
> } else {
> struct sk_buff *skb;
^ permalink raw reply
* [PATCH resend] fib:fix BUG_ON in fib_nl_newrule when add new fib rule
From: Wanlong Gao @ 2011-09-12 1:36 UTC (permalink / raw)
To: linux-kernel, netdev; +Cc: davem, Gao feng, Gao feng, Eric Dumazet
In-Reply-To: <1315675150-3012-1-git-send-email-wanlong.gao@gmail.com>
From: Gao feng <gaofeng@cn.fujitsu.com>
add new fib rule can cause BUG_ON happen
the reproduce shell is
ip rule add pref 38
ip rule add pref 38
ip rule add to 192.168.3.0/24 goto 38
ip rule del pref 38
ip rule add to 192.168.3.0/24 goto 38
ip rule add pref 38
then the BUG_ON will happen
del BUG_ON and use (ctarget == NULL) identify whether this rule is unresolved
Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/fib_rules.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
index e7ab0c0..3231b46 100644
--- a/net/core/fib_rules.c
+++ b/net/core/fib_rules.c
@@ -384,8 +384,8 @@ static int fib_nl_newrule(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg)
*/
list_for_each_entry(r, &ops->rules_list, list) {
if (r->action == FR_ACT_GOTO &&
- r->target == rule->pref) {
- BUG_ON(rtnl_dereference(r->ctarget) != NULL);
+ r->target == rule->pref &&
+ rtnl_dereference(r->ctarget) == NULL) {
rcu_assign_pointer(r->ctarget, rule);
if (--ops->unresolved_rules == 0)
break;
--
1.7.6
^ permalink raw reply related
* Re: Memory leak in ip_dst_cache
From: Kumar S @ 2011-09-12 3:38 UTC (permalink / raw)
To: Neil Horman; +Cc: Eric Dumazet, netdev
In-Reply-To: <20110910130416.GA2005@neilslaptop.think-freely.org>
Thanks Neil. I did try with prink(). I do see entries getting aged out, but they are not getting deallocated. This seems to be happening because of "ref_cnt". When the route entries are added the ref_cnt is set to 1. Looks this is causing trouble clearing the entries completely. If I set the ref_cnt to 0, I can see it working. Now I'm trying to understand whether this is right. Please let me know if you have any thoughts on it.
----- Original Message -----
From: Neil Horman <nhorman@tuxdriver.com>
To: Kumar S <ps2kumar@yahoo.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>; netdev <netdev@vger.kernel.org>
Sent: Saturday, September 10, 2011 6:04 AM
Subject: Re: Memory leak in ip_dst_cache
On Fri, Sep 09, 2011 at 03:53:45PM -0700, Kumar S wrote:
> Yes Eric, this command doesn't work on 2.6.24. Which timer are you suspecting?
>
He means that the timer that starts the the workqueue which calls dst_gc_task is
either delayed indefinately, or otherwise not run, which means that the route
cache will never be scanned for old entries. The implication being that, while
the dst entries aren't leaked per-se, but never expired, so they just sit
around. You can check this by instrumenting gc_dst_task with a printk or two
and watch to see if it ever pops up.
If you only have 512Mb of ram and want to really restrict you're cache size, you
should definately consider backporting the route cache rebuild patch to disable
the route cache usage entirely. It shouldn't be too hard to do.
Neil
>
--
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
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