[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20101025.125347.28807251.davem@davemloft.net>
Date: Mon, 25 Oct 2010 12:53:47 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: eric.dumazet@...il.com
Cc: ben@...adent.org.uk, netdev@...r.kernel.org,
beatrice.barbe@...il.com, 599816@...s.debian.org
Subject: Re: Nested GRE locking bug
From: Eric Dumazet <eric.dumazet@...il.com>
Date: Tue, 19 Oct 2010 11:02:36 +0200
> Le mardi 19 octobre 2010 à 01:53 -0700, David Miller a écrit :
>> From: Eric Dumazet <eric.dumazet@...il.com>
>> Date: Thu, 14 Oct 2010 06:11:59 +0200
>>
>> > net-next-2.6 contains a fix for this, adding the perc_cpu
>> > xmit_recursion limit. We might push it to net-2.6
>>
>> We need to think a bit more about this.
>>
>> We are essentially now saying that one can only configure
>> tunnels 3 levels deep, and no more.
>>
>> I can guarentee you someone out there uses at least 4,
>> perhaps more.
>>
>> And those people will be broken by the new limit.
>>
>> So putting this into net-2.6 with such a low limit will
>> be quite dangerous.
>
> Well limit is actually 4, but I get your point ;)
I'll commit the following to upstream, and submit a combined
patch to -stable.
--------------------
net: Increase xmit RECURSION_LIMIT to 10.
Three is definitely too low, and we know from reports that GRE tunnels
stacked as deeply as 37 levels cause stack overflows, so pick some
reasonable value between those two.
Signed-off-by: David S. Miller <davem@...emloft.net>
---
net/core/dev.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 78b5a89..2c7da3a 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2213,7 +2213,7 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
}
static DEFINE_PER_CPU(int, xmit_recursion);
-#define RECURSION_LIMIT 3
+#define RECURSION_LIMIT 10
/**
* dev_queue_xmit - transmit a buffer
--
1.7.3.2
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists