* Re: netpoll + xmit_lock == deadlock
From: Herbert Xu @ 2009-07-31 13:02 UTC (permalink / raw)
To: Neil Horman; +Cc: Matt Mackall, David S. Miller, netdev, Matt Carlson
In-Reply-To: <20090731125654.GB18303@hmsreliant.think-freely.org>
On Fri, Jul 31, 2009 at 08:56:54AM -0400, Neil Horman wrote:
>
> > tg3_poll => tg3_poll_work => tg3_tx => netif_tx_lock
>
> Oh, goodness, thats just asking for disaster. Setting asside the netpoll issue
> for the moment, what if we take an rx interrupt on a cpu while in the middle of
> sending a frame? Whats to stop the NET_RX_SOFTIRQ after the hard interrupt and
> recursively taking the _xmit_lock? With or without netpoll, that seems prone to
> deadlock.
No that can't happen because BH is disabled in the xmit function.
This problem is specific to netpoll because it does things that
normally can't happen with BH off.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: netpoll + xmit_lock == deadlock
From: Neil Horman @ 2009-07-31 12:56 UTC (permalink / raw)
To: Herbert Xu; +Cc: Matt Mackall, David S. Miller, netdev, Matt Carlson
In-Reply-To: <20090731013017.GB25895@gondor.apana.org.au>
On Fri, Jul 31, 2009 at 09:30:17AM +0800, Herbert Xu wrote:
> On Wed, Jul 29, 2009 at 09:06:39PM -0400, Neil Horman wrote:
> >
> > but nothing in that path takes the xmit_lock. The poll_lock is taken in that
> > patch, but thats for recieve_side syncronization, not transmit side. Nothing in
> > the tg3 driver (to use your example), that I can see takes the xmit_lock in the
> > rx path either, so I'm not really sure where you comming from here.
>
> tg3_poll => tg3_poll_work => tg3_tx => netif_tx_lock
Oh, goodness, thats just asking for disaster. Setting asside the netpoll issue
for the moment, what if we take an rx interrupt on a cpu while in the middle of
sending a frame? Whats to stop the NET_RX_SOFTIRQ after the hard interrupt and
recursively taking the _xmit_lock? With or without netpoll, that seems prone to
deadlock.
Neil
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
^ permalink raw reply
* Re: neigh_periodic_timer expires too often
From: Eric Dumazet @ 2009-07-31 12:50 UTC (permalink / raw)
To: Luciano Coelho; +Cc: netdev@vger.kernel.org, Kristo Tero (Nokia-D/Tampere)
In-Reply-To: <4A72E204.3050704@nokia.com>
Luciano Coelho a écrit :
> Coelho Luciano (Nokia-D/Helsinki) wrote:
>> ext Eric Dumazet wrote:
>>
>>> So please test it and tell me/us you like it :)
>>>
>>
>> I applied your patch on top of the 2.6.28 I'm using and will start
>> testing it now. I can also try to test it on top of 2.6.31-rc4 plus
>> wireless-testing stuff, if needed.
>>
>> I'll tell you that I liked your patch in a moment (I actually already
>> liked it, but I'll wait until I know it works before I tell you ;)
>>
>
> Just a small update. We have run some very basic tests with 2.6.28.
> The patch seems to work fine and we don't see excessive wake-ups from
> neigh anymore (thanks Tero for helping with the tests). We will still
> run one of our full release test rounds in order to make sure that there
> are no regressions. I'll let you know when we have some more results.
>
Thanks for the update, I am running this patch on net-next-2.6 with no problem.
An 'easy' way to count how many time gc fired is to look at 10th columns of /proc/net/stat/arp_cache :
$ cat /proc/net/stat/arp_cache ; cat /proc/uptime ; sleep 150 ; cat /proc/net/stat/arp_cache
entries allocs destroys hash_grows lookups hits res_failed rcv_probes_mcast rcv_probes_ucast periodic_gc_runs forced_gc_runs unresolved_discards
000000fd 00000059 0000050e 00000001 00004552 0000032b 00000022 00000000 00000000 000013e5 00000000 00000000
000000fd 000000df 00000003 00000002 000005a5 0000014d 00000010 00000000 00000000 00000000 00000000 00000000
000000fd 000000cb 00000000 00000000 0000054f 00000141 00000011 00000000 00000000 00000000 00000000 00000000
000000fd 000000b2 00000000 00000001 000005ec 000001d7 0000001d 00000000 00000000 00000000 00000000 00000004
000000fd 000000de 00000000 00000001 000005f7 0000019b 00000027 00000000 00000000 00000000 00000000 00000000
000000fd 000000e5 00000000 00000000 000005db 0000018e 00000027 00000000 00000000 00000000 00000000 00000000
000000fd 000000d3 00000000 00000002 000005e4 0000018a 00000024 00000000 00000000 00000000 00000000 00000000
000000fd 000000c3 00000000 00000000 000005ba 000001a0 00000025 00000000 00000000 00000000 00000000 00000000
79173.78 0.31
entries allocs destroys hash_grows lookups hits res_failed rcv_probes_mcast rcv_probes_ucast periodic_gc_runs forced_gc_runs unresolved_discards
000000fd 00000059 0000050f 00000001 00004569 00000342 00000022 00000000 00000000 000013ee 00000000 00000000
000000fd 000000df 00000003 00000002 000005a8 00000150 00000010 00000000 00000000 00000000 00000000 00000000
000000fd 000000cb 00000000 00000000 00000550 00000142 00000011 00000000 00000000 00000000 00000000 00000000
000000fd 000000b2 00000000 00000001 000005ed 000001d8 0000001d 00000000 00000000 00000000 00000000 00000004
000000fd 000000de 00000000 00000001 000005f8 0000019c 00000027 00000000 00000000 00000000 00000000 00000000
000000fd 000000e6 00000000 00000000 000005df 00000190 00000027 00000000 00000000 00000000 00000000 00000000
000000fd 000000d3 00000000 00000002 000005e6 0000018c 00000024 00000000 00000000 00000000 00000000 00000000
000000fd 000000c3 00000000 00000000 000005bc 000001a1 00000025 00000000 00000000 00000000 00000000 00000000
In a 150 second interval, it was fired 10 times, even with a 256 slots hash table,
instead of 2560 times with pristine kernel.
On my dev machine, neigh_timer_handler is now at the bottom of powertop :)
Wakeups-from-idle per second : 2.5 interval: 10.0s
no ACPI power usage estimate available
Top causes for wakeups:
24.0% ( 4.0) <kernel core> : usb_hcd_poll_rh_status (rh_timer_func)
18.6% ( 3.1) <kernel core> : bnx2_timer (bnx2_timer)
12.0% ( 2.0) <kernel core> : clocksource_watchdog (clocksource_watchdog)
6.0% ( 1.0) <kernel core> : tg3_timer (tg3_timer)
6.0% ( 1.0) bond0 : queue_delayed_work (delayed_work_timer_fn)
6.0% ( 1.0) ntpd : hrtimer_start_range_ns (it_real_fn)
6.0% ( 1.0) <kernel core> : run_timer_softirq (htable_gc)
5.4% ( 0.9) hpsmhd : hrtimer_start_range_ns (hrtimer_wakeup)
3.0% ( 0.5) <interrupt> : cciss0
2.4% ( 0.4) <kernel core> : dev_watchdog (dev_watchdog)
1.8% ( 0.3) <kernel core> : queue_delayed_work (delayed_work_timer_fn)
1.2% ( 0.2) <(null)> : (hrtimer_wakeup)
1.2% ( 0.2) master : start_this_handle (commit_timeout)
1.2% ( 0.2) snmptrapd : hrtimer_start_range_ns (hrtimer_wakeup)
1.2% ( 0.2) pdflush : wb_kupdate (wb_timer_fn)
0.6% ( 0.1) <interrupt> : eth0
0.6% ( 0.1) master : hrtimer_start_range_ns (hrtimer_wakeup)
0.6% ( 0.1) ntpd : blk_plug_device (blk_unplug_timeout)
0.6% ( 0.1) syslogd : hrtimer_start (it_real_fn)
0.6% ( 0.1) init : hrtimer_start_range_ns (hrtimer_wakeup)
0.6% ( 0.1) ntpd : start_this_handle (commit_timeout)
0.6% ( 0.1) <kernel core> : neigh_timer_handler (neigh_timer_handler)
^ permalink raw reply
* Re: neigh_periodic_timer expires too often
From: Luciano Coelho @ 2009-07-31 12:22 UTC (permalink / raw)
To: ext Eric Dumazet; +Cc: netdev@vger.kernel.org, Kristo Tero (Nokia-D/Tampere)
In-Reply-To: <4A71AF1D.9020000@nokia.com>
Coelho Luciano (Nokia-D/Helsinki) wrote:
> ext Eric Dumazet wrote:
>
>> So please test it and tell me/us you like it :)
>>
>>
>
> I applied your patch on top of the 2.6.28 I'm using and will start
> testing it now. I can also try to test it on top of 2.6.31-rc4 plus
> wireless-testing stuff, if needed.
>
> I'll tell you that I liked your patch in a moment (I actually already
> liked it, but I'll wait until I know it works before I tell you ;)
>
Just a small update. We have run some very basic tests with 2.6.28.
The patch seems to work fine and we don't see excessive wake-ups from
neigh anymore (thanks Tero for helping with the tests). We will still
run one of our full release test rounds in order to make sure that there
are no regressions. I'll let you know when we have some more results.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] vlan: allow creating vlan when real device is not up
From: Patrick McHardy @ 2009-07-31 12:16 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, netdev
In-Reply-To: <20090730.131710.208062164.davem@davemloft.net>
David Miller wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Thu, 30 Jul 2009 11:23:21 -0700
>
>> There is no reason for the arbitrary restriction that device must be
>> up to create a vlan. This patch was added to Vyatta kernel to resolve startup
>> ordering issues where vlan's are created but real device was disabled.
>>
>> Note: the vlan already correctly inherits the operstate from real device; so
>> if vlan is created and real device is marked down, the vlan is marked
>> down.
>>
>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> Looks fine, added to net-next-2.6
>
> We can revert if Patrick or someone else finds a potential problem
> with allowing this.
It seems perfectly fine to me, we can get to the same state by
setting the lower device down after creating the VLAN device.
^ permalink raw reply
* [PATCH] sky2: Avoid transmits during sky2_down()
From: Mike McCormack @ 2009-07-31 11:57 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
Hi Stephen,
This patch supersedes my previous patch "sky2: Avoid transmitting
during sky2_restart".
I have reworked the patch to avoid crashes during both sky2_restart()
and sky2_set_ringparam().
Without this patch, the sky2 driver can be crashed by doing:
# pktgen eth1 & (transmit many packets on eth1)
# ethtool -G eth1 tx 510
I am aware you object to storing extra state, but I can't see a way
around this. Without remembering that we're restarting,
netif_wake_queue() is called in the ISR from sky2_tx_complete(), and
netif_tx_lock() is used in sky2_tx_done(). If anybody can see a way
around this, please let me know.
thanks,
Mike
----
During sky2_restart() or sky2_set_ringparam(), the tx queue needs to be
shutdown in sky2_down() to avoid accessing a NULL tx_ring.
Signed-off-by: Mike McCormack <mikem@ring3k.org>
---
drivers/net/sky2.c | 14 +++++++++++++-
drivers/net/sky2.h | 1 +
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index 661abd0..1415a83 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -1488,6 +1488,8 @@ static int sky2_up(struct net_device *dev)
sky2_set_vlan_mode(hw, port, sky2->vlgrp != NULL);
#endif
+ sky2->restarting = 0;
+
err = sky2_rx_start(sky2);
if (err)
goto err_out;
@@ -1500,6 +1502,9 @@ static int sky2_up(struct net_device *dev)
sky2_set_multicast(dev);
+ /* wake queue incase we are restarting */
+ netif_wake_queue(dev);
+
if (netif_msg_ifup(sky2))
printk(KERN_INFO PFX "%s: enabling interface\n", dev->name);
return 0;
@@ -1533,6 +1538,8 @@ static inline int tx_dist(unsigned tail, unsigned head)
/* Number of list elements available for next tx */
static inline int tx_avail(const struct sky2_port *sky2)
{
+ if (unlikely(sky2->restarting))
+ return 0;
return sky2->tx_pending - tx_dist(sky2->tx_cons, sky2->tx_prod);
}
@@ -1818,6 +1825,10 @@ static int sky2_down(struct net_device *dev)
if (netif_msg_ifdown(sky2))
printk(KERN_INFO PFX "%s: disabling interface\n", dev->name);
+ /* explicitly shut off tx incase we're restarting */
+ sky2->restarting = 1;
+ netif_tx_disable(dev);
+
/* Force flow control off */
sky2_write8(hw, SK_REG(port, GMAC_CTRL), GMC_PAUSE_OFF);
@@ -2359,7 +2370,7 @@ static inline void sky2_tx_done(struct
net_device *dev, u16 last)
{
struct sky2_port *sky2 = netdev_priv(dev);
- if (netif_running(dev)) {
+ if (likely(netif_running(dev) && !sky2->restarting)) {
netif_tx_lock(dev);
sky2_tx_complete(sky2, last);
netif_tx_unlock(dev);
@@ -4283,6 +4294,7 @@ static __devinit struct net_device
*sky2_init_netdev(struct sky2_hw *hw,
spin_lock_init(&sky2->phy_lock);
sky2->tx_pending = TX_DEF_PENDING;
sky2->rx_pending = RX_DEF_PENDING;
+ sky2->restarting = 0;
hw->dev[port] = dev;
diff --git a/drivers/net/sky2.h b/drivers/net/sky2.h
index b5549c9..4486b06 100644
--- a/drivers/net/sky2.h
+++ b/drivers/net/sky2.h
@@ -2051,6 +2051,7 @@ struct sky2_port {
u8 duplex; /* DUPLEX_HALF, DUPLEX_FULL */
u8 rx_csum;
u8 wol;
+ u8 restarting;
enum flow_control flow_mode;
enum flow_control flow_status;
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] xfrm: select sane defaults for xfrm[4|6] gc_thresh
From: Neil Horman @ 2009-07-31 11:48 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kuznet, pekkas, jmorris, yoshfuji, kaber
In-Reply-To: <20090730.185316.110755605.davem@davemloft.net>
On Thu, Jul 30, 2009 at 06:53:16PM -0700, David Miller wrote:
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Thu, 30 Jul 2009 21:11:30 -0400
>
> > Ok, version 2. I'm not sure exactly what went wrong, but I definately had it
> > built and running.
>
> As I said in my other email, the original patch does build and it
> probably runs too, it's just the warnings that you definitely didn't
> notice in the build at all.
>
> I've apply this new version, thanks.
>
Ah, that would explain it. Thanks for the update!
Neil
^ permalink raw reply
* Re: tty_register_device NULL pointer dereference in 2.6.31-rc4
From: Oliver Hartkopp @ 2009-07-31 11:20 UTC (permalink / raw)
To: Dave Young; +Cc: Alan Cox, Marcel Holtmann, Linux Netdev List, linux-bluetooth
In-Reply-To: <a8e1da0907310310h483cedeeg433947d51345246c@mail.gmail.com>
Dave Young wrote:
> On Fri, Jul 31, 2009 at 5:39 PM, Dave Young<hidave.darkstar@gmail.com> wrote:
>> On Thu, Jul 30, 2009 at 12:05:55PM +0200, Oliver Hartkopp wrote:
>>> Dave Young wrote:
>>>> On Wed, Jul 29, 2009 at 10:00 PM, Oliver Hartkopp<oliver@hartkopp.net> wrote:
>>>>> Hi Dave,
>>>>>
>>>>> i got it again - even with your patch (that's why it's 2.6.31-rc4-dirty in the
>>>>> attached screenshot).
>>>> Weird, the oops occurs between sock init and tty init routines. Could
>>>> you tell your bluez version and your configuration?
>>>>
>>> No problem:
>> Thanks.
>>
>> It's still reasonable, after rfcomm sock layer initialized, userspace do sock ioctl callback but tty layer was not initilized yet at this time.
>>
>> Could you confirm it by applying following debug patch on top of my previous patch? if you get more oops with it then above reason will be right.
>>
>> --- linux-2.6.orig/net/bluetooth/rfcomm/core.c 2009-07-31 17:14:07.000000000 +0800
>> +++ linux-2.6/net/bluetooth/rfcomm/core.c 2009-07-31 17:30:39.000000000 +0800
>> @@ -36,6 +36,7 @@
>> #include <linux/net.h>
>> #include <linux/mutex.h>
>> #include <linux/kthread.h>
>> +#include <linux/nmi.h>
>>
>> #include <net/sock.h>
>> #include <asm/uaccess.h>
>> @@ -2080,7 +2081,7 @@ static CLASS_ATTR(rfcomm_dlc, S_IRUGO, r
>> /* ---- Initialization ---- */
>> static int __init rfcomm_init(void)
>> {
>> - int ret;
>> + int ret, i;
>>
>> l2cap_load();
>>
>> @@ -2088,6 +2089,12 @@ static int __init rfcomm_init(void)
>> if (ret)
>> goto out_sock;
>>
>> + /* delay 5 seconds to trigger the tty bug */
>> + for (i = 0; i < 50; i++) {
>> + touch_nmi_watchdog();
>> + mdelay(100);
>
> Hi, for this case, msleep is better, you can just replace the above
> two lines with msleep(100)
>
Hi Dave,
applied this patch and replaced mdelay(100) with msleep(100).
I got two crashes and three proper boots.
The crashes look like the formerly posted screenshots.
When it boots properly i can see the delay in the boot process.
Does this help?
Regards,
Oliver
^ permalink raw reply
* Re: [PATCH V3] CAN: Add Flexcan CAN controller driver
From: Sascha Hauer @ 2009-07-31 11:20 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Socketcan-core, Linux Netdev List
In-Reply-To: <4A7200F3.3010608@grandegger.com>
On Thu, Jul 30, 2009 at 10:22:11PM +0200, Wolfgang Grandegger wrote:
> Wolfgang Grandegger wrote:
> > Sascha Hauer wrote:
> [...]
> >> errcnt = readl(®s->errcnt);
> >> rxerr = (errcnt >> 8) & 0xff;
> >> txerr = errcnt & 0xff;
> >> if ((rxerr >= 96 || txerr >= 96) && state == CAN_STATE_ERROR_ACTIVE)
> >> state = CAN_STATE_ERROR_WARNING;
> >
> > Yes, or do not handle the state in the "case 0" above appropriately. The
> > CAN spec only specifies the bus error states error active, error passive
> > and bus off. The warning is somehow optional but available on most CAN
> > controllers. Nevertheless, we should create a message if the ISR
> > realizes a state changes.
>
> FYI, I will be on holiday for the next 1.5 weeks.
Lucky you ;)
I just did some tests with the CAN cable disconnected. It turns out that
I get flooded by interrupts caused by ACK errors. The system is
completely unresponsive then. Unfortunately the ACK error interrupt
can't be disabled seperately, so we have to disable error interrupts
completely once we get an ACK error. I'm thinking about setting up a
timer and poll the error status register then.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: tty_register_device NULL pointer dereference in 2.6.31-rc4
From: Dave Young @ 2009-07-31 10:10 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Alan Cox, Marcel Holtmann, Linux Netdev List,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20090731093949.GA4867@darkstar>
On Fri, Jul 31, 2009 at 5:39 PM, Dave Young<hidave.darkstar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Jul 30, 2009 at 12:05:55PM +0200, Oliver Hartkopp wrote:
>> Dave Young wrote:
>> > On Wed, Jul 29, 2009 at 10:00 PM, Oliver Hartkopp<oliver@hartkopp.net> wrote:
>> >> Hi Dave,
>> >>
>> >> i got it again - even with your patch (that's why it's 2.6.31-rc4-dirty in the
>> >> attached screenshot).
>> >
>> > Weird, the oops occurs between sock init and tty init routines. Could
>> > you tell your bluez version and your configuration?
>> >
>>
>> No problem:
>
> Thanks.
>
> It's still reasonable, after rfcomm sock layer initialized, userspace do sock ioctl callback but tty layer was not initilized yet at this time.
>
> Could you confirm it by applying following debug patch on top of my previous patch? if you get more oops with it then above reason will be right.
>
> --- linux-2.6.orig/net/bluetooth/rfcomm/core.c 2009-07-31 17:14:07.000000000 +0800
> +++ linux-2.6/net/bluetooth/rfcomm/core.c 2009-07-31 17:30:39.000000000 +0800
> @@ -36,6 +36,7 @@
> #include <linux/net.h>
> #include <linux/mutex.h>
> #include <linux/kthread.h>
> +#include <linux/nmi.h>
>
> #include <net/sock.h>
> #include <asm/uaccess.h>
> @@ -2080,7 +2081,7 @@ static CLASS_ATTR(rfcomm_dlc, S_IRUGO, r
> /* ---- Initialization ---- */
> static int __init rfcomm_init(void)
> {
> - int ret;
> + int ret, i;
>
> l2cap_load();
>
> @@ -2088,6 +2089,12 @@ static int __init rfcomm_init(void)
> if (ret)
> goto out_sock;
>
> + /* delay 5 seconds to trigger the tty bug */
> + for (i = 0; i < 50; i++) {
> + touch_nmi_watchdog();
> + mdelay(100);
Hi, for this case, msleep is better, you can just replace the above
two lines with msleep(100)
> + }
> +
> ret = rfcomm_init_ttys();
> if (ret)
> goto out_tty;
>
--
Regards
dave
^ permalink raw reply
* Re: tty_register_device NULL pointer dereference in 2.6.31-rc4
From: Dave Young @ 2009-07-31 9:39 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Alan Cox, Marcel Holtmann, Linux Netdev List,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4A717083.5090101-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
On Thu, Jul 30, 2009 at 12:05:55PM +0200, Oliver Hartkopp wrote:
> Dave Young wrote:
> > On Wed, Jul 29, 2009 at 10:00 PM, Oliver Hartkopp<oliver-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org> wrote:
> >> Hi Dave,
> >>
> >> i got it again - even with your patch (that's why it's 2.6.31-rc4-dirty in the
> >> attached screenshot).
> >
> > Weird, the oops occurs between sock init and tty init routines. Could
> > you tell your bluez version and your configuration?
> >
>
> No problem:
Thanks.
It's still reasonable, after rfcomm sock layer initialized, userspace do sock ioctl callback but tty layer was not initilized yet at this time.
Could you confirm it by applying following debug patch on top of my previous patch? if you get more oops with it then above reason will be right.
--- linux-2.6.orig/net/bluetooth/rfcomm/core.c 2009-07-31 17:14:07.000000000 +0800
+++ linux-2.6/net/bluetooth/rfcomm/core.c 2009-07-31 17:30:39.000000000 +0800
@@ -36,6 +36,7 @@
#include <linux/net.h>
#include <linux/mutex.h>
#include <linux/kthread.h>
+#include <linux/nmi.h>
#include <net/sock.h>
#include <asm/uaccess.h>
@@ -2080,7 +2081,7 @@ static CLASS_ATTR(rfcomm_dlc, S_IRUGO, r
/* ---- Initialization ---- */
static int __init rfcomm_init(void)
{
- int ret;
+ int ret, i;
l2cap_load();
@@ -2088,6 +2089,12 @@ static int __init rfcomm_init(void)
if (ret)
goto out_sock;
+ /* delay 5 seconds to trigger the tty bug */
+ for (i = 0; i < 50; i++) {
+ touch_nmi_watchdog();
+ mdelay(100);
+ }
+
ret = rfcomm_init_ttys();
if (ret)
goto out_tty;
^ permalink raw reply
* [PATCH 2/2 net-next-2.6] cxgb3: fix Gen2 pci default settings
From: Divy Le Ray @ 2009-07-31 7:23 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, swise
In-Reply-To: <20090731072334.4325.34323.stgit@speedy5>
From: Divy Le Ray <divy@chelsio.com>
Modify control register settings to accommodate the bridge's max read requset
size.
Signed-off-by: Divy Le Ray <divy@chelsio.com>
---
drivers/net/cxgb3/t3_hw.c | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cxgb3/t3_hw.c b/drivers/net/cxgb3/t3_hw.c
index e78d341..526e144 100644
--- a/drivers/net/cxgb3/t3_hw.c
+++ b/drivers/net/cxgb3/t3_hw.c
@@ -3465,7 +3465,7 @@ static void config_pcie(struct adapter *adap)
{201, 321, 258, 450, 834, 1602}
};
- u16 val;
+ u16 val, devid;
unsigned int log2_width, pldsize;
unsigned int fst_trn_rx, fst_trn_tx, acklat, rpllmt;
@@ -3473,6 +3473,17 @@ static void config_pcie(struct adapter *adap)
adap->params.pci.pcie_cap_addr + PCI_EXP_DEVCTL,
&val);
pldsize = (val & PCI_EXP_DEVCTL_PAYLOAD) >> 5;
+
+ pci_read_config_word(adap->pdev, 0x2, &devid);
+ if (devid == 0x37) {
+ pci_write_config_word(adap->pdev,
+ adap->params.pci.pcie_cap_addr +
+ PCI_EXP_DEVCTL,
+ val & ~PCI_EXP_DEVCTL_READRQ &
+ ~PCI_EXP_DEVCTL_PAYLOAD);
+ pldsize = 0;
+ }
+
pci_read_config_word(adap->pdev,
adap->params.pci.pcie_cap_addr + PCI_EXP_LNKCTL,
&val);
^ permalink raw reply related
* [PATCH 1/2 net-next-2.6] cxgb3: fix EDC filename string
From: Divy Le Ray @ 2009-07-31 7:23 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, swise
From: Divy Le Ray <divy@chelsio.com>
Fix a cut'n paste error in the AEL2020 twinax EDC file name
Signed-off-by: Divy Le Ray <divy@chelsio.com>
---
drivers/net/cxgb3/cxgb3_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index ec05149..8b3e76c 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -993,7 +993,7 @@ static int bind_qsets(struct adapter *adap)
#define TPSRAM_NAME "cxgb3/t3%c_psram-%d.%d.%d.bin"
#define AEL2005_OPT_EDC_NAME "cxgb3/ael2005_opt_edc.bin"
#define AEL2005_TWX_EDC_NAME "cxgb3/ael2005_twx_edc.bin"
-#define AEL2020_TWX_EDC_NAME "cxgb3/ael2005_twx_edc.bin"
+#define AEL2020_TWX_EDC_NAME "cxgb3/ael2020_twx_edc.bin"
static inline const char *get_edc_fw_name(int edc_idx)
{
^ permalink raw reply related
* Re: pull request: wireless-next-2.6 2009-07-29
From: David Miller @ 2009-07-31 2:30 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20090729205423.GC10056@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 29 Jul 2009 16:54:23 -0400
> Here is another batch of wireless bits intended for 2.6.32... Once
> again, there is no particular theme to the bunch. This does cover the
> usual round of driver updates for iwlwifi, ath9k, and others. There are
> also some mac80211 and cfg80211 updates, including the final piece for
> cfg80211 to supplant wireless extensions -- hooray!
...
> P.S. There is a merge-test branch that contains sample merge conflict
> resolutions. They are mostly simple.
Pulled this in after doing a merge. Will push out after some
build checks.
Thanks!
^ permalink raw reply
* Re: [net-2.6 PATCH 3/3] ixgbe: Fix RSC completion delay causing Rx interrupts to stop
From: David Miller @ 2009-07-31 2:29 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, peter.p.waskiewicz.jr
In-Reply-To: <20090730222559.26121.13496.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 30 Jul 2009 15:26:00 -0700
> When a user disables interrupt throttling with ethtool on 82599 devices,
> the interrupt timer may not be re-enabled if hardware RSC is running. The
> RSC completions in hardware don't complete before the next ITR event tries
> to fire, so the ITR timer never gets re-armed. This patch increases the
> amount of time between interrupts when throttling is disabled (rx-usecs =
> 0) when the hardware RSC deature is enabled.
>
> Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 2/3] ixgbe: Fix usage of second flags bitmap when using LRO/RSC
From: David Miller @ 2009-07-31 2:29 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: netdev, gospo, peter.p.waskiewicz.jr, mallikarjuna.chilakala
In-Reply-To: <20090730222528.26121.30521.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 30 Jul 2009 15:25:28 -0700
> A second set of feature flag bits was added, and the hardware RSC engine
> flags were moved there. However, the code itself didn't make the move
> completely to use the new bitmap.
>
> Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Acked-by: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 1/3] ixgbe: Fix netpoll to be properly multiqueue aware
From: David Miller @ 2009-07-31 2:28 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, peter.p.waskiewicz.jr
In-Reply-To: <20090730222501.26121.2952.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 30 Jul 2009 15:25:09 -0700
> Our ndo_poll_controller callback is broken for anything but non-multiqueue
> setups. This fixes that issue.
>
> Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] xfrm: select sane defaults for xfrm[4|6] gc_thresh
From: David Miller @ 2009-07-31 1:53 UTC (permalink / raw)
To: nhorman; +Cc: netdev, kuznet, pekkas, jmorris, yoshfuji, kaber
In-Reply-To: <20090731011130.GA16769@localhost.localdomain>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Thu, 30 Jul 2009 21:11:30 -0400
> Ok, version 2. I'm not sure exactly what went wrong, but I definately had it
> built and running.
As I said in my other email, the original patch does build and it
probably runs too, it's just the warnings that you definitely didn't
notice in the build at all.
I've apply this new version, thanks.
^ permalink raw reply
* Re: [PATCH] xfrm: select sane defaults for xfrm[4|6] gc_thresh
From: David Miller @ 2009-07-31 1:34 UTC (permalink / raw)
To: nhorman; +Cc: netdev, kuznet, pekkas, jmorris, yoshfuji, kaber
In-Reply-To: <20090731001102.GA6068@localhost.localdomain>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Thu, 30 Jul 2009 20:11:02 -0400
> On Thu, Jul 30, 2009 at 02:25:54PM -0700, David Miller wrote:
>> From: David Miller <davem@davemloft.net>
>> Date: Thu, 30 Jul 2009 14:23:45 -0700 (PDT)
>>
>> Actually I had to revert, how the heck did you build test
>> this? :-/
>>
>> In file included from include/net/xfrm.h:21,
>> from net/ipv4/af_inet.c:113:
>> include/net/ip6_fib.h:28:1: warning: "FIB_TABLE_HASHSZ" redefined
>> In file included from net/ipv4/af_inet.c:102:
>> include/net/ip_fib.h:134:1: warning: this is the location of the previous definition
>>
>
> Thats bizzare, I've got it running on a system here at Red Hat if you want to
> take a look, it definatley built for me. Sorry about that, let me figure out
> what went south and I'll repost.
Sorry, bad phrasing on my part. It built, it just spits out those
warnings because ipv4 and ipv6 use the same macro name and it
gets redefined.
^ permalink raw reply
* Re: Bonding ALB sends bogus packets
From: Mark Smith @ 2009-07-31 1:30 UTC (permalink / raw)
To: Rick Jones
Cc: Stephen Hemminger, Jay Vosburgh, Ben Greear, bonding-devel,
netdev
In-Reply-To: <4A72314C.9080007@hp.com>
Hi Rick,
On Thu, 30 Jul 2009 16:48:28 -0700
Rick Jones <rick.jones2@hp.com> wrote:
> Mark Smith wrote:
> >
> > ETH_P_LOOP should probably have been avoided, as "LOOP" or "loopback"
> > is commonly used to refer to the Ethernet Configuration Testing
> > Protocol (google search for "Ethernet Loop protocol").
>
> I wonder how that relates to linkloop:
>
> http://sourceforge.net/projects/linkloop/
>
> http://fr2.rpmfind.net/linux/RPM/opensuse/factory/x86_64/usr_share_doc_packages_linkloop_Tree.html
>
> >
> > I'd suggest not using any form of ARP for this purpose. It'd place an
> > IPv4 requirement on the bonded interface, and various "empty" ARP
> > frames have meaning e.g. duplicate address detection. 802.2 test frames
> > or the original Ethernet V2.0 Configuration Testing Protocol have been
> > used for this bridge table address refresh purpose in the past.
>
> I can never remember if linkloop uses XID or Test frames :(
>
>From memory when I looked into it a year or so ago, linkloop
used 802.2 test frames.
When I decided to have a go at implementing ECTP for the Linux kernel
a couple of years ago, one thing I didn't want to was to duplicate
already existing layer 2 testing functionality in the kernel, which
meant comparing 802.2 test frames capability verses ECTP. 802.2 test
frames only do single hop unicast request/reply testing, obviously
requiring you to already know the test unicast address. ECTP, in
addition, provides broadcast and optionally multicast ECTP capable node
discovery, and the ability test a path of nodes, by providing a list of
unicast addresses to visit i.e. a strict source route. As I've found
IPv4 'broadcast pings' occasionally useful, I thought a layer 2
equivalent, not requiring IPv4 to be functioning, would also be quite
useful.
ECTP could also probably be used over any 802.2 capable network, by
using the SNAP encoding with an OUI of 0x000000 and then a protocol ID
of 0x9000.
(When you start looking into it, it's interesting how many layer 2
keepalive/testing protocols have been developed over the years,
including most recently the Ethernet OAM protocols. What is also
suprising is that the original Ethernet V2.0 Configuration Testing
Protocol tends to be more capable than any of them - they're usually
just single-hop request/reply testing)
Regards,
Mark.
^ permalink raw reply
* Re: netpoll + xmit_lock == deadlock
From: Herbert Xu @ 2009-07-31 1:30 UTC (permalink / raw)
To: Neil Horman; +Cc: Matt Mackall, David S. Miller, netdev, Matt Carlson
In-Reply-To: <20090730010639.GB4169@localhost.localdomain>
On Wed, Jul 29, 2009 at 09:06:39PM -0400, Neil Horman wrote:
>
> but nothing in that path takes the xmit_lock. The poll_lock is taken in that
> patch, but thats for recieve_side syncronization, not transmit side. Nothing in
> the tg3 driver (to use your example), that I can see takes the xmit_lock in the
> rx path either, so I'm not really sure where you comming from here.
tg3_poll => tg3_poll_work => tg3_tx => netif_tx_lock
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: netpoll + xmit_lock == deadlock
From: Herbert Xu @ 2009-07-31 1:27 UTC (permalink / raw)
To: Neil Horman; +Cc: Matt Mackall, David S. Miller, netdev, Matt Carlson
In-Reply-To: <20090730010222.GA4169@localhost.localdomain>
On Wed, Jul 29, 2009 at 09:02:22PM -0400, Neil Horman wrote:
>
> Under what conditions do you try to take the xmit_lock from within a drivers
> ->poll routine? Do you have an example?
tg3
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] xfrm: select sane defaults for xfrm[4|6] gc_thresh
From: Neil Horman @ 2009-07-31 1:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kuznet, pekkas, jmorris, yoshfuji, kaber
In-Reply-To: <20090730.142554.103113174.davem@davemloft.net>
On Thu, Jul 30, 2009 at 02:25:54PM -0700, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Thu, 30 Jul 2009 14:23:45 -0700 (PDT)
>
> > From: Neil Horman <nhorman@tuxdriver.com>
> > Date: Tue, 28 Jul 2009 20:34:33 -0400
> >
> >> Choose saner defaults for xfrm[4|6] gc_thresh values on init
> >
> > Looks great, applied to net-next-2.6
>
> Actually I had to revert, how the heck did you build test
> this? :-/
>
> In file included from include/net/xfrm.h:21,
> from net/ipv4/af_inet.c:113:
> include/net/ip6_fib.h:28:1: warning: "FIB_TABLE_HASHSZ" redefined
> In file included from net/ipv4/af_inet.c:102:
> include/net/ip_fib.h:134:1: warning: this is the location of the previous definition
>
Ok, version 2. I'm not sure exactly what went wrong, but I definately had it
built and running. My best guess is that I did a partial build in a tree, and
the dependency check decided that the ipv4 code didn't need to be rebuilt, and
so I didn't get the error. Anywho, The problem is that the ipv4 code had
FIB_TABLE_HASHSZ defined globally, which was causing namespace clashes with my
changes (which moved the privately ipv6 defined FIB_TABLE_HASHSZ to a global
visibility). I've fixed it by modifying the IPv6 definition and uses to be
FIB6_TABLE_HASHSZ. I just tested it (with a clean build), and it works fine.
Apologies for the noise.
Neil
Choose saner defaults for xfrm[4|6] gc_thresh values on init
Currently, the xfrm[4|6] code has hard-coded initial gc_thresh values (set to
1024). Given that the ipv4 and ipv6 routing caches are sized dynamically at
boot time, the static selections can be non-sensical. This patch dynamically
selects an appropriate gc threshold based on the corresponding main routing
table size, using the assumption that we should in the worst case be able to
handle as many connections as the routing table can.
For ipv4, the maximum route cache size is 16 * the number of hash buckets in the
route cache. Given that xfrm4 starts garbage collection at the gc_thresh and
prevents new allocations at 2 * gc_thresh, we set gc_thresh to half the maximum
route cache size.
For ipv6, its a bit trickier. there is no maximum route cache size, but the
ipv6 dst_ops gc_thresh is statically set to 1024. It seems sane to select a
simmilar gc_thresh for the xfrm6 code that is half the number of hash buckets in
the v6 route cache times 16 (like the v4 code does).
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
include/net/ip6_fib.h | 6 ++++++
include/net/xfrm.h | 2 +-
net/ipv4/route.c | 2 +-
net/ipv4/xfrm4_policy.c | 13 ++++++++++++-
net/ipv6/ip6_fib.c | 16 +++++-----------
net/ipv6/xfrm6_policy.c | 15 +++++++++++++++
6 files changed, 40 insertions(+), 14 deletions(-)
diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
index 7c5c0f7..15b492a 100644
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -22,6 +22,12 @@
#include <net/flow.h>
#include <net/netlink.h>
+#ifdef CONFIG_IPV6_MULTIPLE_TABLES
+#define FIB6_TABLE_HASHSZ 256
+#else
+#define FIB6_TABLE_HASHSZ 1
+#endif
+
struct rt6_info;
struct fib6_config
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 9e3a3f4..223e90a 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1280,7 +1280,7 @@ struct xfrm6_tunnel {
};
extern void xfrm_init(void);
-extern void xfrm4_init(void);
+extern void xfrm4_init(int rt_hash_size);
extern int xfrm_state_init(struct net *net);
extern void xfrm_state_fini(struct net *net);
extern void xfrm4_state_init(void);
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 278f46f..fafbe16 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -3442,7 +3442,7 @@ int __init ip_rt_init(void)
printk(KERN_ERR "Unable to create route proc files\n");
#ifdef CONFIG_XFRM
xfrm_init();
- xfrm4_init();
+ xfrm4_init(ip_rt_max_size);
#endif
rtnl_register(PF_INET, RTM_GETROUTE, inet_rtm_getroute, NULL);
diff --git a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c
index 018ac8b..00f7f80 100644
--- a/net/ipv4/xfrm4_policy.c
+++ b/net/ipv4/xfrm4_policy.c
@@ -290,10 +290,21 @@ static void __exit xfrm4_policy_fini(void)
xfrm_policy_unregister_afinfo(&xfrm4_policy_afinfo);
}
-void __init xfrm4_init(void)
+void __init xfrm4_init(int rt_max_size)
{
xfrm4_state_init();
xfrm4_policy_init();
+ /*
+ * Select a default value for the gc_thresh based on the main route
+ * table hash size. It seems to me the worst case scenario is when
+ * we have ipsec operating in transport mode, in which we create a
+ * dst_entry per socket. The xfrm gc algorithm starts trying to remove
+ * entries at gc_thresh, and prevents new allocations as 2*gc_thresh
+ * so lets set an initial xfrm gc_thresh value at the rt_max_size/2.
+ * That will let us store an ipsec connection per route table entry,
+ * and start cleaning when were 1/2 full
+ */
+ xfrm4_dst_ops.gc_thresh = rt_max_size/2;
sysctl_hdr = register_net_sysctl_table(&init_net, net_ipv4_ctl_path,
xfrm4_policy_table);
}
diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
index 52ee1dc..0e93ca5 100644
--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -164,12 +164,6 @@ static __inline__ void rt6_release(struct rt6_info *rt)
dst_free(&rt->u.dst);
}
-#ifdef CONFIG_IPV6_MULTIPLE_TABLES
-#define FIB_TABLE_HASHSZ 256
-#else
-#define FIB_TABLE_HASHSZ 1
-#endif
-
static void fib6_link_table(struct net *net, struct fib6_table *tb)
{
unsigned int h;
@@ -180,7 +174,7 @@ static void fib6_link_table(struct net *net, struct fib6_table *tb)
*/
rwlock_init(&tb->tb6_lock);
- h = tb->tb6_id & (FIB_TABLE_HASHSZ - 1);
+ h = tb->tb6_id & (FIB6_TABLE_HASHSZ - 1);
/*
* No protection necessary, this is the only list mutatation
@@ -231,7 +225,7 @@ struct fib6_table *fib6_get_table(struct net *net, u32 id)
if (id == 0)
id = RT6_TABLE_MAIN;
- h = id & (FIB_TABLE_HASHSZ - 1);
+ h = id & (FIB6_TABLE_HASHSZ - 1);
rcu_read_lock();
head = &net->ipv6.fib_table_hash[h];
hlist_for_each_entry_rcu(tb, node, head, tb6_hlist) {
@@ -382,7 +376,7 @@ static int inet6_dump_fib(struct sk_buff *skb, struct netlink_callback *cb)
arg.net = net;
w->args = &arg;
- for (h = s_h; h < FIB_TABLE_HASHSZ; h++, s_e = 0) {
+ for (h = s_h; h < FIB6_TABLE_HASHSZ; h++, s_e = 0) {
e = 0;
head = &net->ipv6.fib_table_hash[h];
hlist_for_each_entry(tb, node, head, tb6_hlist) {
@@ -1368,7 +1362,7 @@ void fib6_clean_all(struct net *net, int (*func)(struct rt6_info *, void *arg),
unsigned int h;
rcu_read_lock();
- for (h = 0; h < FIB_TABLE_HASHSZ; h++) {
+ for (h = 0; h < FIB6_TABLE_HASHSZ; h++) {
head = &net->ipv6.fib_table_hash[h];
hlist_for_each_entry_rcu(table, node, head, tb6_hlist) {
write_lock_bh(&table->tb6_lock);
@@ -1483,7 +1477,7 @@ static int fib6_net_init(struct net *net)
if (!net->ipv6.rt6_stats)
goto out_timer;
- net->ipv6.fib_table_hash = kcalloc(FIB_TABLE_HASHSZ,
+ net->ipv6.fib_table_hash = kcalloc(FIB6_TABLE_HASHSZ,
sizeof(*net->ipv6.fib_table_hash),
GFP_KERNEL);
if (!net->ipv6.fib_table_hash)
diff --git a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c
index 4acc308..4df7da6 100644
--- a/net/ipv6/xfrm6_policy.c
+++ b/net/ipv6/xfrm6_policy.c
@@ -323,6 +323,7 @@ static struct ctl_table_header *sysctl_hdr;
int __init xfrm6_init(void)
{
int ret;
+ unsigned int gc_thresh;
ret = xfrm6_policy_init();
if (ret)
@@ -331,6 +332,20 @@ int __init xfrm6_init(void)
ret = xfrm6_state_init();
if (ret)
goto out_policy;
+ /*
+ * We need a good default value for the xfrm6 gc threshold.
+ * In ipv4 we set it to the route hash table size * 8, which
+ * is half the size of the maximaum route cache for ipv4. It
+ * would be good to do the same thing for v6, except the table is
+ * constructed differently here. Here each table for a net namespace
+ * can have FIB_TABLE_HASHSZ entries, so lets go with the same
+ * computation that we used for ipv4 here. Also, lets keep the initial
+ * gc_thresh to a minimum of 1024, since, the ipv6 route cache defaults
+ * to that as a minimum as well
+ */
+ gc_thresh = FIB6_TABLE_HASHSZ * 8;
+ xfrm6_dst_ops.gc_thresh = (gc_thresh < 1024) ? 1024 : gc_thresh;
+
sysctl_hdr = register_net_sysctl_table(&init_net, net_ipv6_ctl_path,
xfrm6_policy_table);
out:
^ permalink raw reply related
* Re: [PATCH 1/4] [atm] fixed faulty check
From: Nathan Williams @ 2009-07-31 0:22 UTC (permalink / raw)
To: Stoyan Gaydarov; +Cc: linux-kernel, chas, David.Woodhouse, netdev
In-Reply-To: <1248949491-20796-1-git-send-email-sgayda2@uiuc.edu>
Stoyan Gaydarov wrote:
> This patche fixes a spelling error that has resulted from copy and pasting. The location of the error was found using a semantic patch but the semantic patch was not trying to find these errors. After looking things over it seemed logical that this change was needed. Please review it and then include the patch if it is in fact the correct change.
>
> Signed-off-by: Stoyan Gaydarov <sgayda2@uiuc.edu>
> ---
> drivers/atm/solos-pci.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
> index 9359613..307321b 100644
> --- a/drivers/atm/solos-pci.c
> +++ b/drivers/atm/solos-pci.c
> @@ -372,7 +372,7 @@ static int process_status(struct solos_card *card, int port, struct sk_buff *skb
> }
>
> snr = next_string(skb);
> - if (!str)
> + if (!snr)
> return -EIO;
> attn = next_string(skb);
> if (!attn)
Thanks Stoyan. Julia Lawall found this error a few days ago, which has been applied to net-next-2.6.
^ permalink raw reply
* Re: [PATCH] xfrm: select sane defaults for xfrm[4|6] gc_thresh
From: Neil Horman @ 2009-07-31 0:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kuznet, pekkas, jmorris, yoshfuji, kaber
In-Reply-To: <20090730.142554.103113174.davem@davemloft.net>
On Thu, Jul 30, 2009 at 02:25:54PM -0700, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Thu, 30 Jul 2009 14:23:45 -0700 (PDT)
>
> > From: Neil Horman <nhorman@tuxdriver.com>
> > Date: Tue, 28 Jul 2009 20:34:33 -0400
> >
> >> Choose saner defaults for xfrm[4|6] gc_thresh values on init
> >
> > Looks great, applied to net-next-2.6
>
> Actually I had to revert, how the heck did you build test
> this? :-/
>
> In file included from include/net/xfrm.h:21,
> from net/ipv4/af_inet.c:113:
> include/net/ip6_fib.h:28:1: warning: "FIB_TABLE_HASHSZ" redefined
> In file included from net/ipv4/af_inet.c:102:
> include/net/ip_fib.h:134:1: warning: this is the location of the previous definition
>
Thats bizzare, I've got it running on a system here at Red Hat if you want to
take a look, it definatley built for me. Sorry about that, let me figure out
what went south and I'll repost.
Neil
^ 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