* [PATCH 23/25] netfilter: pass 'nf_hook_ops' instead of 'list_head' to nf_iterate()
From: pablo @ 2012-09-03 23:54 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1346716452-3080-1-git-send-email-pablo@netfilter.org>
From: Michael Wang <wangyun@linux.vnet.ibm.com>
Since 'list_for_each_continue_rcu' has already been replaced by
'list_for_each_entry_continue_rcu', pass 'list_head' to nf_iterate() as a
parameter can not benefit us any more.
This patch will replace 'list_head' with 'nf_hook_ops' as the parameter of
nf_iterate() to save code.
Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/core.c | 24 ++++++++++--------------
net/netfilter/nf_internals.h | 2 +-
net/netfilter/nf_queue.c | 6 +++---
3 files changed, 14 insertions(+), 18 deletions(-)
diff --git a/net/netfilter/core.c b/net/netfilter/core.c
index e61b3ac..0b119d9 100644
--- a/net/netfilter/core.c
+++ b/net/netfilter/core.c
@@ -126,42 +126,38 @@ unsigned int nf_iterate(struct list_head *head,
unsigned int hook,
const struct net_device *indev,
const struct net_device *outdev,
- struct list_head **i,
+ struct nf_hook_ops **elemp,
int (*okfn)(struct sk_buff *),
int hook_thresh)
{
unsigned int verdict;
- struct nf_hook_ops *elem = list_entry_rcu(*i, struct nf_hook_ops, list);
/*
* The caller must not block between calls to this
* function because of risk of continuing from deleted element.
*/
- list_for_each_entry_continue_rcu(elem, head, list) {
- if (hook_thresh > elem->priority)
+ list_for_each_entry_continue_rcu((*elemp), head, list) {
+ if (hook_thresh > (*elemp)->priority)
continue;
/* Optimization: we don't need to hold module
reference here, since function can't sleep. --RR */
repeat:
- verdict = elem->hook(hook, skb, indev, outdev, okfn);
+ verdict = (*elemp)->hook(hook, skb, indev, outdev, okfn);
if (verdict != NF_ACCEPT) {
#ifdef CONFIG_NETFILTER_DEBUG
if (unlikely((verdict & NF_VERDICT_MASK)
> NF_MAX_VERDICT)) {
NFDEBUG("Evil return from %p(%u).\n",
- elem->hook, hook);
+ (*elemp)->hook, hook);
continue;
}
#endif
- if (verdict != NF_REPEAT) {
- *i = &elem->list;
+ if (verdict != NF_REPEAT)
return verdict;
- }
goto repeat;
}
}
- *i = &elem->list;
return NF_ACCEPT;
}
@@ -174,14 +170,14 @@ int nf_hook_slow(u_int8_t pf, unsigned int hook, struct sk_buff *skb,
int (*okfn)(struct sk_buff *),
int hook_thresh)
{
- struct list_head *elem;
+ struct nf_hook_ops *elem;
unsigned int verdict;
int ret = 0;
/* We may already have this, but read-locks nest anyway */
rcu_read_lock();
- elem = &nf_hooks[pf][hook];
+ elem = list_entry_rcu(&nf_hooks[pf][hook], struct nf_hook_ops, list);
next_hook:
verdict = nf_iterate(&nf_hooks[pf][hook], skb, hook, indev,
outdev, &elem, okfn, hook_thresh);
@@ -193,8 +189,8 @@ next_hook:
if (ret == 0)
ret = -EPERM;
} else if ((verdict & NF_VERDICT_MASK) == NF_QUEUE) {
- int err = nf_queue(skb, elem, pf, hook, indev, outdev, okfn,
- verdict >> NF_VERDICT_QBITS);
+ int err = nf_queue(skb, &elem->list, pf, hook, indev, outdev,
+ okfn, verdict >> NF_VERDICT_QBITS);
if (err < 0) {
if (err == -ECANCELED)
goto next_hook;
diff --git a/net/netfilter/nf_internals.h b/net/netfilter/nf_internals.h
index 770f764..2886231 100644
--- a/net/netfilter/nf_internals.h
+++ b/net/netfilter/nf_internals.h
@@ -18,7 +18,7 @@ extern unsigned int nf_iterate(struct list_head *head,
unsigned int hook,
const struct net_device *indev,
const struct net_device *outdev,
- struct list_head **i,
+ struct nf_hook_ops **elemp,
int (*okfn)(struct sk_buff *),
int hook_thresh);
diff --git a/net/netfilter/nf_queue.c b/net/netfilter/nf_queue.c
index ce60cf0..29fe102 100644
--- a/net/netfilter/nf_queue.c
+++ b/net/netfilter/nf_queue.c
@@ -287,7 +287,7 @@ int nf_queue(struct sk_buff *skb,
void nf_reinject(struct nf_queue_entry *entry, unsigned int verdict)
{
struct sk_buff *skb = entry->skb;
- struct list_head *elem = &entry->elem->list;
+ struct nf_hook_ops *elem = entry->elem;
const struct nf_afinfo *afinfo;
int err;
@@ -297,7 +297,7 @@ void nf_reinject(struct nf_queue_entry *entry, unsigned int verdict)
/* Continue traversal iff userspace said ok... */
if (verdict == NF_REPEAT) {
- elem = elem->prev;
+ elem = list_entry(elem->list.prev, struct nf_hook_ops, list);
verdict = NF_ACCEPT;
}
@@ -323,7 +323,7 @@ void nf_reinject(struct nf_queue_entry *entry, unsigned int verdict)
local_bh_enable();
break;
case NF_QUEUE:
- err = __nf_queue(skb, elem, entry->pf, entry->hook,
+ err = __nf_queue(skb, &elem->list, entry->pf, entry->hook,
entry->indev, entry->outdev, entry->okfn,
verdict >> NF_VERDICT_QBITS);
if (err < 0) {
--
1.7.10.4
^ permalink raw reply related
* [PATCH 24/25] netfilter: pass 'nf_hook_ops' instead of 'list_head' to nf_queue()
From: pablo @ 2012-09-03 23:54 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1346716452-3080-1-git-send-email-pablo@netfilter.org>
From: Michael Wang <wangyun@linux.vnet.ibm.com>
Since 'list_for_each_continue_rcu' has already been replaced by
'list_for_each_entry_continue_rcu', pass 'list_head' to nf_queue() as a
parameter can not benefit us any more.
This patch will replace 'list_head' with 'nf_hook_ops' as the parameter of
nf_queue() and __nf_queue() to save code.
Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/core.c | 4 ++--
net/netfilter/nf_internals.h | 2 +-
net/netfilter/nf_queue.c | 8 ++++----
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/net/netfilter/core.c b/net/netfilter/core.c
index 0b119d9..68912dad 100644
--- a/net/netfilter/core.c
+++ b/net/netfilter/core.c
@@ -189,8 +189,8 @@ next_hook:
if (ret == 0)
ret = -EPERM;
} else if ((verdict & NF_VERDICT_MASK) == NF_QUEUE) {
- int err = nf_queue(skb, &elem->list, pf, hook, indev, outdev,
- okfn, verdict >> NF_VERDICT_QBITS);
+ int err = nf_queue(skb, elem, pf, hook, indev, outdev, okfn,
+ verdict >> NF_VERDICT_QBITS);
if (err < 0) {
if (err == -ECANCELED)
goto next_hook;
diff --git a/net/netfilter/nf_internals.h b/net/netfilter/nf_internals.h
index 2886231..3deec99 100644
--- a/net/netfilter/nf_internals.h
+++ b/net/netfilter/nf_internals.h
@@ -24,7 +24,7 @@ extern unsigned int nf_iterate(struct list_head *head,
/* nf_queue.c */
extern int nf_queue(struct sk_buff *skb,
- struct list_head *elem,
+ struct nf_hook_ops *elem,
u_int8_t pf, unsigned int hook,
struct net_device *indev,
struct net_device *outdev,
diff --git a/net/netfilter/nf_queue.c b/net/netfilter/nf_queue.c
index 29fe102..8d2cf9e 100644
--- a/net/netfilter/nf_queue.c
+++ b/net/netfilter/nf_queue.c
@@ -118,7 +118,7 @@ static void nf_queue_entry_release_refs(struct nf_queue_entry *entry)
* through nf_reinject().
*/
static int __nf_queue(struct sk_buff *skb,
- struct list_head *elem,
+ struct nf_hook_ops *elem,
u_int8_t pf, unsigned int hook,
struct net_device *indev,
struct net_device *outdev,
@@ -155,7 +155,7 @@ static int __nf_queue(struct sk_buff *skb,
*entry = (struct nf_queue_entry) {
.skb = skb,
- .elem = list_entry(elem, struct nf_hook_ops, list),
+ .elem = elem,
.pf = pf,
.hook = hook,
.indev = indev,
@@ -225,7 +225,7 @@ static void nf_bridge_adjust_segmented_data(struct sk_buff *skb)
#endif
int nf_queue(struct sk_buff *skb,
- struct list_head *elem,
+ struct nf_hook_ops *elem,
u_int8_t pf, unsigned int hook,
struct net_device *indev,
struct net_device *outdev,
@@ -323,7 +323,7 @@ void nf_reinject(struct nf_queue_entry *entry, unsigned int verdict)
local_bh_enable();
break;
case NF_QUEUE:
- err = __nf_queue(skb, &elem->list, entry->pf, entry->hook,
+ err = __nf_queue(skb, elem, entry->pf, entry->hook,
entry->indev, entry->outdev, entry->okfn,
verdict >> NF_VERDICT_QBITS);
if (err < 0) {
--
1.7.10.4
^ permalink raw reply related
* [PATCH 22/25] netfilter: remove xt_NOTRACK
From: pablo @ 2012-09-03 23:54 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1346716452-3080-1-git-send-email-pablo@netfilter.org>
From: Cong Wang <xiyou.wangcong@gmail.com>
It was scheduled to be removed for a long time.
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netfilter@vger.kernel.org
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
Documentation/feature-removal-schedule.txt | 8 -----
arch/m68k/configs/amiga_defconfig | 1 -
arch/m68k/configs/apollo_defconfig | 1 -
arch/m68k/configs/atari_defconfig | 1 -
arch/m68k/configs/bvme6000_defconfig | 1 -
arch/m68k/configs/hp300_defconfig | 1 -
arch/m68k/configs/mac_defconfig | 1 -
arch/m68k/configs/multi_defconfig | 1 -
arch/m68k/configs/mvme147_defconfig | 1 -
arch/m68k/configs/mvme16x_defconfig | 1 -
arch/m68k/configs/q40_defconfig | 1 -
arch/m68k/configs/sun3_defconfig | 1 -
arch/m68k/configs/sun3x_defconfig | 1 -
arch/mips/configs/ar7_defconfig | 1 -
arch/mips/configs/bcm47xx_defconfig | 1 -
arch/mips/configs/ip22_defconfig | 1 -
arch/mips/configs/jazz_defconfig | 1 -
arch/mips/configs/malta_defconfig | 1 -
arch/mips/configs/markeins_defconfig | 1 -
arch/mips/configs/nlm_xlp_defconfig | 1 -
arch/mips/configs/nlm_xlr_defconfig | 1 -
arch/mips/configs/rm200_defconfig | 1 -
arch/powerpc/configs/pmac32_defconfig | 1 -
arch/powerpc/configs/ppc64_defconfig | 1 -
arch/powerpc/configs/ppc64e_defconfig | 1 -
arch/powerpc/configs/ppc6xx_defconfig | 1 -
arch/tile/configs/tilegx_defconfig | 1 -
arch/tile/configs/tilepro_defconfig | 1 -
net/netfilter/Kconfig | 13 -------
net/netfilter/Makefile | 1 -
net/netfilter/xt_NOTRACK.c | 53 ----------------------------
31 files changed, 102 deletions(-)
delete mode 100644 net/netfilter/xt_NOTRACK.c
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index afaff31..b4aab82 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -353,14 +353,6 @@ Why: Internal alias support has been present in module-init-tools for some
Who: Wey-Yi Guy <wey-yi.w.guy@intel.com>
----------------------------
-
-What: xt_NOTRACK
-Files: net/netfilter/xt_NOTRACK.c
-When: April 2011
-Why: Superseded by xt_CT
-Who: Netfilter developer team <netfilter-devel@vger.kernel.org>
-
----------------------------
What: IRQF_DISABLED
diff --git a/arch/m68k/configs/amiga_defconfig b/arch/m68k/configs/amiga_defconfig
index e93fdae..90d3109 100644
--- a/arch/m68k/configs/amiga_defconfig
+++ b/arch/m68k/configs/amiga_defconfig
@@ -67,7 +67,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m
diff --git a/arch/m68k/configs/apollo_defconfig b/arch/m68k/configs/apollo_defconfig
index 66b26c1..8f4f657 100644
--- a/arch/m68k/configs/apollo_defconfig
+++ b/arch/m68k/configs/apollo_defconfig
@@ -67,7 +67,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m
diff --git a/arch/m68k/configs/atari_defconfig b/arch/m68k/configs/atari_defconfig
index 1513325..4571d33 100644
--- a/arch/m68k/configs/atari_defconfig
+++ b/arch/m68k/configs/atari_defconfig
@@ -65,7 +65,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m
diff --git a/arch/m68k/configs/bvme6000_defconfig b/arch/m68k/configs/bvme6000_defconfig
index 67bb6fc..12f2117 100644
--- a/arch/m68k/configs/bvme6000_defconfig
+++ b/arch/m68k/configs/bvme6000_defconfig
@@ -65,7 +65,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m
diff --git a/arch/m68k/configs/hp300_defconfig b/arch/m68k/configs/hp300_defconfig
index 3e35ce5..215389a 100644
--- a/arch/m68k/configs/hp300_defconfig
+++ b/arch/m68k/configs/hp300_defconfig
@@ -66,7 +66,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m
diff --git a/arch/m68k/configs/mac_defconfig b/arch/m68k/configs/mac_defconfig
index ae81e2d..cb9dfb3 100644
--- a/arch/m68k/configs/mac_defconfig
+++ b/arch/m68k/configs/mac_defconfig
@@ -61,7 +61,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m
diff --git a/arch/m68k/configs/multi_defconfig b/arch/m68k/configs/multi_defconfig
index 55d394e..8d5def4 100644
--- a/arch/m68k/configs/multi_defconfig
+++ b/arch/m68k/configs/multi_defconfig
@@ -80,7 +80,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m
diff --git a/arch/m68k/configs/mvme147_defconfig b/arch/m68k/configs/mvme147_defconfig
index af77374..e2af46f 100644
--- a/arch/m68k/configs/mvme147_defconfig
+++ b/arch/m68k/configs/mvme147_defconfig
@@ -64,7 +64,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m
diff --git a/arch/m68k/configs/mvme16x_defconfig b/arch/m68k/configs/mvme16x_defconfig
index cdb70d6..7c9402b 100644
--- a/arch/m68k/configs/mvme16x_defconfig
+++ b/arch/m68k/configs/mvme16x_defconfig
@@ -65,7 +65,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m
diff --git a/arch/m68k/configs/q40_defconfig b/arch/m68k/configs/q40_defconfig
index 46bed78..19d23db 100644
--- a/arch/m68k/configs/q40_defconfig
+++ b/arch/m68k/configs/q40_defconfig
@@ -61,7 +61,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m
diff --git a/arch/m68k/configs/sun3_defconfig b/arch/m68k/configs/sun3_defconfig
index 86f7772..ca6c0b4 100644
--- a/arch/m68k/configs/sun3_defconfig
+++ b/arch/m68k/configs/sun3_defconfig
@@ -62,7 +62,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m
diff --git a/arch/m68k/configs/sun3x_defconfig b/arch/m68k/configs/sun3x_defconfig
index 2882614..c80941c 100644
--- a/arch/m68k/configs/sun3x_defconfig
+++ b/arch/m68k/configs/sun3x_defconfig
@@ -62,7 +62,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m
diff --git a/arch/mips/configs/ar7_defconfig b/arch/mips/configs/ar7_defconfig
index 6cd5a51..80e012f 100644
--- a/arch/mips/configs/ar7_defconfig
+++ b/arch/mips/configs/ar7_defconfig
@@ -56,7 +56,6 @@ CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_FTP=m
CONFIG_NF_CONNTRACK_IRC=m
CONFIG_NF_CONNTRACK_TFTP=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
CONFIG_NETFILTER_XT_MATCH_MAC=m
diff --git a/arch/mips/configs/bcm47xx_defconfig b/arch/mips/configs/bcm47xx_defconfig
index ad15fb1..b6fde2b 100644
--- a/arch/mips/configs/bcm47xx_defconfig
+++ b/arch/mips/configs/bcm47xx_defconfig
@@ -96,7 +96,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
diff --git a/arch/mips/configs/ip22_defconfig b/arch/mips/configs/ip22_defconfig
index d160656..936ec5a 100644
--- a/arch/mips/configs/ip22_defconfig
+++ b/arch/mips/configs/ip22_defconfig
@@ -87,7 +87,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TPROXY=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
diff --git a/arch/mips/configs/jazz_defconfig b/arch/mips/configs/jazz_defconfig
index 92a60ae..0315ee3 100644
--- a/arch/mips/configs/jazz_defconfig
+++ b/arch/mips/configs/jazz_defconfig
@@ -60,7 +60,6 @@ CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
diff --git a/arch/mips/configs/malta_defconfig b/arch/mips/configs/malta_defconfig
index 5527abb..cd732e5 100644
--- a/arch/mips/configs/malta_defconfig
+++ b/arch/mips/configs/malta_defconfig
@@ -86,7 +86,6 @@ CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TPROXY=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
diff --git a/arch/mips/configs/markeins_defconfig b/arch/mips/configs/markeins_defconfig
index 9c9a123..636f82b 100644
--- a/arch/mips/configs/markeins_defconfig
+++ b/arch/mips/configs/markeins_defconfig
@@ -59,7 +59,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
diff --git a/arch/mips/configs/nlm_xlp_defconfig b/arch/mips/configs/nlm_xlp_defconfig
index 28c6b27..84624b1 100644
--- a/arch/mips/configs/nlm_xlp_defconfig
+++ b/arch/mips/configs/nlm_xlp_defconfig
@@ -108,7 +108,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TPROXY=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
diff --git a/arch/mips/configs/nlm_xlr_defconfig b/arch/mips/configs/nlm_xlr_defconfig
index 138f698..44b4734 100644
--- a/arch/mips/configs/nlm_xlr_defconfig
+++ b/arch/mips/configs/nlm_xlr_defconfig
@@ -109,7 +109,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TPROXY=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
diff --git a/arch/mips/configs/rm200_defconfig b/arch/mips/configs/rm200_defconfig
index 2c0230e..59d9d2f 100644
--- a/arch/mips/configs/rm200_defconfig
+++ b/arch/mips/configs/rm200_defconfig
@@ -68,7 +68,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
diff --git a/arch/powerpc/configs/pmac32_defconfig b/arch/powerpc/configs/pmac32_defconfig
index f8b394a..29767a8 100644
--- a/arch/powerpc/configs/pmac32_defconfig
+++ b/arch/powerpc/configs/pmac32_defconfig
@@ -55,7 +55,6 @@ CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m
diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig
index db27c82..06b5624 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -92,7 +92,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TPROXY=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
diff --git a/arch/powerpc/configs/ppc64e_defconfig b/arch/powerpc/configs/ppc64e_defconfig
index 7bd1763..f55c276 100644
--- a/arch/powerpc/configs/ppc64e_defconfig
+++ b/arch/powerpc/configs/ppc64e_defconfig
@@ -66,7 +66,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TPROXY=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
diff --git a/arch/powerpc/configs/ppc6xx_defconfig b/arch/powerpc/configs/ppc6xx_defconfig
index c47f2be..be1cb6e 100644
--- a/arch/powerpc/configs/ppc6xx_defconfig
+++ b/arch/powerpc/configs/ppc6xx_defconfig
@@ -167,7 +167,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TPROXY=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
diff --git a/arch/tile/configs/tilegx_defconfig b/arch/tile/configs/tilegx_defconfig
index 0270620..8c5eff6 100644
--- a/arch/tile/configs/tilegx_defconfig
+++ b/arch/tile/configs/tilegx_defconfig
@@ -134,7 +134,6 @@ CONFIG_NETFILTER_XT_TARGET_IDLETIMER=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TEE=m
CONFIG_NETFILTER_XT_TARGET_TPROXY=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
diff --git a/arch/tile/configs/tilepro_defconfig b/arch/tile/configs/tilepro_defconfig
index c11de27..e7a3dfc 100644
--- a/arch/tile/configs/tilepro_defconfig
+++ b/arch/tile/configs/tilepro_defconfig
@@ -132,7 +132,6 @@ CONFIG_NETFILTER_XT_TARGET_IDLETIMER=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
-CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TEE=m
CONFIG_NETFILTER_XT_TARGET_TPROXY=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index 052836e..3f4b3b4 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -670,19 +670,6 @@ config NETFILTER_XT_TARGET_NFQUEUE
To compile it as a module, choose M here. If unsure, say N.
-config NETFILTER_XT_TARGET_NOTRACK
- tristate '"NOTRACK" target support'
- depends on IP_NF_RAW || IP6_NF_RAW
- depends on NF_CONNTRACK
- help
- The NOTRACK target allows a select rule to specify
- which packets *not* to enter the conntrack/NAT
- subsystem with all the consequences (no ICMP error tracking,
- no protocol helpers for the selected packets).
-
- If you want to compile it as a module, say M here and read
- <file:Documentation/kbuild/modules.txt>. If unsure, say `N'.
-
config NETFILTER_XT_TARGET_RATEEST
tristate '"RATEEST" target support'
depends on NETFILTER_ADVANCED
diff --git a/net/netfilter/Makefile b/net/netfilter/Makefile
index 403ea812..98244d4 100644
--- a/net/netfilter/Makefile
+++ b/net/netfilter/Makefile
@@ -85,7 +85,6 @@ obj-$(CONFIG_NETFILTER_XT_TARGET_LED) += xt_LED.o
obj-$(CONFIG_NETFILTER_XT_TARGET_LOG) += xt_LOG.o
obj-$(CONFIG_NETFILTER_XT_TARGET_NFLOG) += xt_NFLOG.o
obj-$(CONFIG_NETFILTER_XT_TARGET_NFQUEUE) += xt_NFQUEUE.o
-obj-$(CONFIG_NETFILTER_XT_TARGET_NOTRACK) += xt_NOTRACK.o
obj-$(CONFIG_NETFILTER_XT_TARGET_RATEEST) += xt_RATEEST.o
obj-$(CONFIG_NETFILTER_XT_TARGET_SECMARK) += xt_SECMARK.o
obj-$(CONFIG_NETFILTER_XT_TARGET_TPROXY) += xt_TPROXY.o
diff --git a/net/netfilter/xt_NOTRACK.c b/net/netfilter/xt_NOTRACK.c
deleted file mode 100644
index 9d78218..0000000
--- a/net/netfilter/xt_NOTRACK.c
+++ /dev/null
@@ -1,53 +0,0 @@
-/* This is a module which is used for setting up fake conntracks
- * on packets so that they are not seen by the conntrack/NAT code.
- */
-#include <linux/module.h>
-#include <linux/skbuff.h>
-
-#include <linux/netfilter/x_tables.h>
-#include <net/netfilter/nf_conntrack.h>
-
-MODULE_DESCRIPTION("Xtables: Disabling connection tracking for packets");
-MODULE_LICENSE("GPL");
-MODULE_ALIAS("ipt_NOTRACK");
-MODULE_ALIAS("ip6t_NOTRACK");
-
-static unsigned int
-notrack_tg(struct sk_buff *skb, const struct xt_action_param *par)
-{
- /* Previously seen (loopback)? Ignore. */
- if (skb->nfct != NULL)
- return XT_CONTINUE;
-
- /* Attach fake conntrack entry.
- If there is a real ct entry correspondig to this packet,
- it'll hang aroun till timing out. We don't deal with it
- for performance reasons. JK */
- skb->nfct = &nf_ct_untracked_get()->ct_general;
- skb->nfctinfo = IP_CT_NEW;
- nf_conntrack_get(skb->nfct);
-
- return XT_CONTINUE;
-}
-
-static struct xt_target notrack_tg_reg __read_mostly = {
- .name = "NOTRACK",
- .revision = 0,
- .family = NFPROTO_UNSPEC,
- .target = notrack_tg,
- .table = "raw",
- .me = THIS_MODULE,
-};
-
-static int __init notrack_tg_init(void)
-{
- return xt_register_target(¬rack_tg_reg);
-}
-
-static void __exit notrack_tg_exit(void)
-{
- xt_unregister_target(¬rack_tg_reg);
-}
-
-module_init(notrack_tg_init);
-module_exit(notrack_tg_exit);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 25/25] netfilter: properly annotate ipv4_netfilter_{init,fini}()
From: pablo @ 2012-09-03 23:54 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1346716452-3080-1-git-send-email-pablo@netfilter.org>
From: Jan Beulich <JBeulich@suse.com>
Despite being just a few bytes of code, they should still have proper
annotations.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/ipv4/netfilter.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/netfilter.c b/net/ipv4/netfilter.c
index f1643c0..4c0cf63 100644
--- a/net/ipv4/netfilter.c
+++ b/net/ipv4/netfilter.c
@@ -188,12 +188,12 @@ static const struct nf_afinfo nf_ip_afinfo = {
.route_key_size = sizeof(struct ip_rt_info),
};
-static int ipv4_netfilter_init(void)
+static int __init ipv4_netfilter_init(void)
{
return nf_register_afinfo(&nf_ip_afinfo);
}
-static void ipv4_netfilter_fini(void)
+static void __exit ipv4_netfilter_fini(void)
{
nf_unregister_afinfo(&nf_ip_afinfo);
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 00/25] Netfilter updates for net-next
From: David Miller @ 2012-09-04 0:39 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1346716452-3080-1-git-send-email-pablo@netfilter.org>
From: pablo@netfilter.org
Date: Tue, 4 Sep 2012 01:53:47 +0200
> The following patchset contains updates for your net-next tree, the most
> relevant thing here is the new IPv6 NAT support from Patrick McHardy.
> More specifically, they are:
>
> * Several patches to prepare IPv6 NAT support, including one to improve
> IPv6 fragmentation handling for Netfilter and IPVS from Patrick McHardy
> and Jesper Dangaard respectively.
>
> * IPv6 NAT support for source/destination NAT, masquerading, redirection
> and network mapping, again from Patrick.
>
> * A new target that allows stateless Network Prefix Translation (NPT)
> for IPv6, also from Patrick.
>
> * Changes in existing helpers to support IPv6 NAT, mostly and Patrick and
> a couple from myself.
>
> * Removal of xt_NOTRACK that has now been superseded by the CT target, from
> Cong Wang.
>
> * Minor cleanups from Jan Beulich, Michael Wang and myself.
>
> You can pull these changes from:
>
> git://1984.lsi.us.es/nf-next master
Pulled and pushed out to net-next, thanks!
^ permalink raw reply
* Re: [PATCH net-next 4/7] openvswitch: Reset upper layer protocol info on internal devices.
From: Jesse Gross @ 2012-09-04 0:57 UTC (permalink / raw)
To: David Miller
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
Chris Wright
In-Reply-To: <1342823210-3308-5-git-send-email-jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
On Fri, Jul 20, 2012 at 3:26 PM, Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org> wrote:
> It's possible that packets that are sent on internal devices (from
> the OVS perspective) have already traversed the local IP stack.
> After they go through the internal device, they will again travel
> through the IP stack which may get confused by the presence of
> existing information in the skb. The problem can be observed
> when switching between namespaces. This clears out that information
> to avoid problems but deliberately leaves other metadata alone.
> This is to provide maximum flexibility in chaining together OVS
> and other Linux components.
>
> Signed-off-by: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
It was recently discovered that the bug that this patch fixes is
causing problems in the real world. Can you please queue this for
stable in 3.4/3.5? It's currently in Linus's tree as
7fe99e2d434eafeac0c57b279a77e5de39212636.
^ permalink raw reply
* Re: [PATCH net-next 4/7] openvswitch: Reset upper layer protocol info on internal devices.
From: David Miller @ 2012-09-04 1:00 UTC (permalink / raw)
To: jesse-l0M0P4e3n4LQT0dZR+AlfA
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
chrisw-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <CAEP_g=-giF74zveQgLsrAwS0kp2P3cj_O7mHaKKLVfKwQCNBag-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
Date: Mon, 3 Sep 2012 17:57:39 -0700
> On Fri, Jul 20, 2012 at 3:26 PM, Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org> wrote:
>> It's possible that packets that are sent on internal devices (from
>> the OVS perspective) have already traversed the local IP stack.
>> After they go through the internal device, they will again travel
>> through the IP stack which may get confused by the presence of
>> existing information in the skb. The problem can be observed
>> when switching between namespaces. This clears out that information
>> to avoid problems but deliberately leaves other metadata alone.
>> This is to provide maximum flexibility in chaining together OVS
>> and other Linux components.
>>
>> Signed-off-by: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
>
> It was recently discovered that the bug that this patch fixes is
> causing problems in the real world. Can you please queue this for
> stable in 3.4/3.5? It's currently in Linus's tree as
> 7fe99e2d434eafeac0c57b279a77e5de39212636.
>
What vendor is shipping openvswitch enabled and requires the fix to
be in -stable before they'll ship it to customers?
That goes into what is 'real world'
^ permalink raw reply
* Re: [PATCH net-next 4/7] openvswitch: Reset upper layer protocol info on internal devices.
From: Jesse Gross @ 2012-09-04 1:07 UTC (permalink / raw)
To: David Miller
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
chrisw-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <20120903.210055.1839817610578900310.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Mon, Sep 3, 2012 at 6:00 PM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
> From: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
> Date: Mon, 3 Sep 2012 17:57:39 -0700
>
>> On Fri, Jul 20, 2012 at 3:26 PM, Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org> wrote:
>>> It's possible that packets that are sent on internal devices (from
>>> the OVS perspective) have already traversed the local IP stack.
>>> After they go through the internal device, they will again travel
>>> through the IP stack which may get confused by the presence of
>>> existing information in the skb. The problem can be observed
>>> when switching between namespaces. This clears out that information
>>> to avoid problems but deliberately leaves other metadata alone.
>>> This is to provide maximum flexibility in chaining together OVS
>>> and other Linux components.
>>>
>>> Signed-off-by: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
>>
>> It was recently discovered that the bug that this patch fixes is
>> causing problems in the real world. Can you please queue this for
>> stable in 3.4/3.5? It's currently in Linus's tree as
>> 7fe99e2d434eafeac0c57b279a77e5de39212636.
>>
>
> What vendor is shipping openvswitch enabled and requires the fix to
> be in -stable before they'll ship it to customers?
>
> That goes into what is 'real world'
Fedora is running into it I believe. Chris Wright asked for it so he
might be able to elaborate more on their plans.
^ permalink raw reply
* Re: [PATCH net] net: usbnet: fix softirq storm on suspend
From: Ming Lei @ 2012-09-04 4:19 UTC (permalink / raw)
To: Bjørn Mork
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
Oliver Neukum
In-Reply-To: <1346660778-24539-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
On Mon, Sep 3, 2012 at 4:26 PM, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> wrote:
> Suspending an open usbnet device results in constant
> rescheduling of usbnet_bh.
>
> commit 65841fd5 "usbnet: handle remote wakeup asap"
> refactored the usbnet_bh code to allow sharing the
> urb allocate and submit code with usbnet_resume. In
> this process, a test for, and immediate return on,
> ENOLINK from rx_submit was unintentionally dropped.
>
> The rx queue will not grow if rx_submit fails,
> making usbnet_bh reschedule itself. This results
> in a softirq storm if the error is persistent.
> rx_submit translates the usb_submit_urb error
> EHOSTUNREACH into ENOLINK, so this is an expected
> and persistent error for a suspended device. The
> old code tested for this condition and avoided
> rescheduling. Putting this test back.
>
> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v3.5
> Cc: Ming Lei <ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> Cc: Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org>
> Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
> ---
> Sorry for not noticing this before, but commit 65841fd5
> makes usbnet autosuspend completely unusable. The device
> is suspended fine, but burning one CPU core at full load
> uses a tiny bit more power making the power saving
> negative...
I am wondering how you can reproduce the issue.
usbnet_terminate_urbs is called inside usbnet_suspend to
consume all URBs and SKBs, and rx_alloc_submit can't be
called during the period because of !netif_device_present().
Once usbnet_terminate_urbs and netif_device_attach() are
completed, who will schedule tasklet to trigger rx_alloc_submit?
>
> I hope this can go into 3.6 and 3.5-stable ASAP. It is
> a hard to notice regression, but all the same a serious
> one.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] ipv4: Improve the scaling of the ARP cache for multicast destinations.
From: Bob Gilligan @ 2012-09-04 4:22 UTC (permalink / raw)
To: Nicolas de Pesloüan; +Cc: David Miller, netdev
In-Reply-To: <50435E6B.5040007@gmail.com>
On 9/2/12 6:26 AM, Nicolas de Pesloüan wrote:
> Le 31/08/2012 21:21, Bob Gilligan a écrit :
>> On 8/30/12 6:06 PM, David Miller wrote:
>>> From: Bob Gilligan<gilligan@aristanetworks.com>
>>> Date: Thu, 30 Aug 2012 17:55:04 -0700
>>>
>>>> The mapping from multicast IPv4 address to MAC address can just as
>>>> easily be done at the time a packet is to be sent. With this change,
>>>> we maintain one ARP cache entry for each interface that has at least
>>>> one multicast group member. All routes to IPv4 multicast destinations
>>>> via a particular interface use the same ARP cache entry. This entry
>>>> does not store the MAC address to use. Instead, packets for multicast
>>>> destinations go to a new output function that maps the destination
>>>> IPv4 multicast address into the MAC address and forms the MAC header.
>>>
>>> Doing an ARP MC mapping on every packet is much more expensive than
>>> doing a copy of the hard header cache.
>>>
>>> I do not believe the memory consumption issue you use to justify this
>>> change is a real issue.
>
> My two cents:
>
> Why do we need a per interface neighbor cache for multicast? Isn't the
> target MAC expected to be the same for a give target multicast IP
> address, whatever the egress interface?
>
> Can't we store the target MAC for multicast address on a neighbor cache
> entry with a fake dev value meaning "multicast"?
>
> Can't we detect the fact that the IP destination address is multicast
> and search only the neighbor cache entries that have this fake dev
> value, instead of the egress interface?
>
> This should reduce memory consumption (not N-squared anymore) without
> significantly increasing the CPU usage.
>
> Do I miss something?
Sounds like you are suggesting the converse of my proposed patch: One
"special" Neighbor Cache Entry per multicast group instead of one per
interface. Unfortunately, I don't think this will work. Different MAC
types have different frame formats and different multicast address
mappings, so can't share a common neighbor cache entry.
Bob.
>
> Nicolas.
^ permalink raw reply
* Re: [PATCH 0/8] csiostor: Chelsio FCoE offload driver submission
From: Naresh Kumar Inna @ 2012-09-04 5:13 UTC (permalink / raw)
To: David Miller
Cc: JBottomley@parallels.com, linux-scsi@vger.kernel.org,
Dimitrios Michailidis, netdev@vger.kernel.org, Chethan Seshadri
In-Reply-To: <503922C0.7000707@chelsio.com>
On 8/26/2012 12:38 AM, Naresh Kumar Inna wrote:
> On 8/25/2012 12:40 AM, David Miller wrote:
>> From: Naresh Kumar Inna <naresh@chelsio.com>
>> Date: Sat, 25 Aug 2012 00:34:35 +0530
>>
>>> Thanks for reviewing. Is your comment with respect to any particular
>>> module parameter[s] in this driver or all of them?
>>
>> All of them.
>>
>
> So are module parameters being obsoleted? You mentioned about using
> generic kernel facilities for tuning driver knobs. Could you please
> elaborate a bit more?
>
> Thanks,
> Naresh.
> --
Hi Dave,
Removing all the module parameters from the driver would put us at a
disadvantage with respect to tuning the driver and hardware. I have not
not been able to find alternatives, considering every other driver uses
module parameters. Could you provide pointers to the generic kernel
facilities you mentioned in your last post?
Thanks,
Naresh.
^ permalink raw reply
* Re: [PATCH 0/8] csiostor: Chelsio FCoE offload driver submission
From: David Miller @ 2012-09-04 5:34 UTC (permalink / raw)
To: naresh; +Cc: JBottomley, linux-scsi, dm, netdev, chethan
In-Reply-To: <50458DF4.1030907@chelsio.com>
From: Naresh Kumar Inna <naresh@chelsio.com>
Date: Tue, 4 Sep 2012 10:43:24 +0530
> Removing all the module parameters from the driver would put us at a
> disadvantage with respect to tuning the driver and hardware. I have not
> not been able to find alternatives, considering every other driver uses
> module parameters. Could you provide pointers to the generic kernel
> facilities you mentioned in your last post?
Adding module parameters is a cop-out. It's what you do if you want
to put zero effort into providing good interfaces for your driver.
If an appropriate generic mechanism doesn't exist yet, you simply add
one.
When people add crazy module parameter knobs to networking drivers, we
ask them to extend either ethtool or netlink, as appropriate.
^ permalink raw reply
* Re: [net-next.git 5/7] stmmac: add sysFs support
From: Giuseppe CAVALLARO @ 2012-09-04 6:35 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, David S. Miller
In-Reply-To: <1346684957.2688.15.camel@bwh-desktop.uk.solarflarecom.com>
Hello Ben
On 9/3/2012 5:09 PM, Ben Hutchings wrote:
> On Mon, 2012-09-03 at 15:36 +0200, Giuseppe CAVALLARO wrote:
>> Hello Ben,
>>
>> On 9/3/2012 2:44 PM, Ben Hutchings wrote:
>>> On Mon, 2012-09-03 at 09:47 +0200, Giuseppe CAVALLARO wrote:
>>>> This patch adds the sysFs support.
>>>> Some internal driver parameters can be tuned by using some
>>>> entries exposed via sysFS. There parameter currently are,
>>>> for example, for internal timers used to mitigate the rx/tx
>>>> interrupts or for EEE.
>>> [...]
>>>
>>> Why are you not exposing these through the standard ethtool operations?
>>>
>>> Ben.
>>
>> yes I want to expose them via ethtool and I'll do this as soon as I have
>> clear with ethtool parameters have to be used (
>> http://marc.info/?l=linux-netdev&m=134561966226677&w=2 ).
>
> Sorry, I meant to reply to that but didn't get round to it.
No problem at all :-) ... we are discussing about that in the thread.
>
>> For the reception side, I have the RI Watchdog Timer count field and I
>> do not know what is the appropriate ethtool parameter to use.
>> From the Synopsys databook, the RI Watchdog Timer count indicates the
>> number of system clock cycles. When the it runs out, the receive
>> interrupt bit is set and the timer is stopped.
>> No idea if it can be actually covered, for example, with
>> rx_coalesce_usecs_irq.
>
> As I understand it, interrupt moderation time is supposed to be the
> minimum time between completion IRQs, not a minimum delay from
> completion-with-IRQ-armed to assertion of the IRQ. The timer should
> start running again immediately after the associated IRQ is asserted.
> But I don't know whether it's universally implemented this way.
Yes this is the point and my initial doubt.
> The field names including '_irq' are to be used if the hardware can use
> a different moderation time while the IRQ is still masked (i.e. NAPI or
> hard interrupt handler is still running). I think most hardware doesn't
> support this.
Indeed, the watchdog represents the number of system clock cycles to
delay the RX interrupt after a packet arrives so IIUC I can use the
rx_coalesce_usecs.
>> For the transmission I have a SW timer that periodically calls the tx
>> function (stmmac_tx) and a threshold to also set the "Interrupt on
>> completion" bit in the TDES when a frame is transmitted.
>> I wonder (but not sure) if in this case I could be: tx_coalesce_usec and
>> tx_mac_coalesced_frames.
>> From the kernel documentation IIUC these seem to have other meaning.
>
> The semantics don't seem to match the documentation exactly but I think
> this is probably close enough.
So IIUC I can use the ethtool coalesce parameters above for the stmmac.
I mean: tx_coalesce_usec and tx_mac_coalesced_frames.
Anyway I'm happy to remove the sysFS (rightly rejected by David) and use
the standard ethtool. So I'll provide new patches after testing all.
Thanks again for your feedback, and let me know if I missed something.
Regards
Peppe
>
> Ben.
>
>> No problem, to extend ethtool to cover these kind of parameters if
>> necessary.
>
^ permalink raw reply
* Re: [RFC PATCH 0/2] RFC: Caching IPv6 exthdr in skb->cb[]
From: Julian Anastasov @ 2012-09-04 7:26 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Patrick McHardy, Hans Schillstrom, Hans Schillstrom, netdev,
netfilter-devel, Pablo Neira Ayuso
In-Reply-To: <20120903211504.8851.6894.stgit@dragon>
Hello,
On Mon, 3 Sep 2012, Jesper Dangaard Brouer wrote:
> Hi Patrick and Hans,
>
> This is my followup to:
> [PATCH 2/3] ipvs: Fix faulty IPv6 extension header handling in IPVS
>
> Where you proposed improving the overall architecture of IPv6
> extension header parsing not only for IPVS but for other related
> Netfilter subsystems as well.
>
> We discussed using/extending inet6_skb_parm/IP6CB. There was not
> enough room for extending inet6_skb_parm directly, so I have
> introduced a struct inet6_skb_exthdr_cache/IP6CB_EXTHDR, which extend
> IP6CB.
>
> The question is if this approach will work. Can netfilter be allowed
> to modify data after inet6_skb_parm/IP6CB, given all the different
> HOOKs ?
Yes, as long as we do not reach the protocol
receiving handlers, eg. tcp_v4_rcv. But the problem is
that many modules can use this CB part but nobody knows
if it is valid - it is not reset.
If data is part of IP6CB it is reset in ipv6_rcv
with memset(IP6CB(skb), 0, sizeof(struct inet6_skb_parm));
One option is to extend this memset to cover this
new IP6CB_EXTHDR part if CONFIG_NF_DEFRAG_IPV6 is defined.
I.e. we can create new struct inet6_skb_parm_exthdr, DCCP, TCP
will continue to use/extend inet6_skb_parm but
ipv6_find_hdr_cb will know that their part is reset. Then
above memset can become:
memset(IP6CB_EXTHDR(skb), 0, sizeof(struct inet6_skb_parm_exthdr));
struct inet6_skb_parm_exthdr {
struct inet6_skb_parm h6;
#if IS_ENABLED(CONFIG_NF_DEFRAG_IPV6)
__u16 thoff; ...
...
#endif
};
Not sure if it should depend only on
CONFIG_NF_DEFRAG_IPV6.
> If we find this is a valid approach, then I'll update the IPVS patches
> to also use this.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH net] net: usbnet: fix softirq storm on suspend
From: Bjørn Mork @ 2012-09-04 7:49 UTC (permalink / raw)
To: Ming Lei
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
Oliver Neukum
In-Reply-To: <CACVXFVNykwxe-PYP_nin32htFmrFL4d=3DEhZMo3UwTEpb81+A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Ming Lei <ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> writes:
> On Mon, Sep 3, 2012 at 4:26 PM, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> wrote:
>
>> Sorry for not noticing this before, but commit 65841fd5
>> makes usbnet autosuspend completely unusable. The device
>> is suspended fine, but burning one CPU core at full load
>> uses a tiny bit more power making the power saving
>> negative...
>
> I am wondering how you can reproduce the issue.
That's easy:
- Take any usbnet device supporting remote wakeup (and of course with a
minidriver supporting it as well),
- enable autosuspend,
- ip link set dev ethX/usbX/wwanX up
And watch ksoftirqd/X use 100% of one of your CPU cores.
I'd very much like to hear the details if you are unable to reproduce
the bug using this simple test.
> usbnet_terminate_urbs is called inside usbnet_suspend to
> consume all URBs and SKBs, and rx_alloc_submit can't be
> called during the period because of !netif_device_present().
Huh???? We do support suspending a USB device while the network device
is up and running. That's the whole idea here, isn't it? I.e.
netif_device_present() is *expected* to be true while the USB device is
suspended.
> Once usbnet_terminate_urbs and netif_device_attach() are
> completed, who will schedule tasklet to trigger rx_alloc_submit?
That's a good question. It sure would be nice if that never happened
without waking the device first. But there are just too many call sites
for me to follow:
bjorn@nemi:/usr/local/src/git/linux$ grep tasklet_schedule drivers/net/usb/usbnet.c
tasklet_schedule(&dev->bh);
* but tasklet_schedule() doesn't. hope the failure is rare.
tasklet_schedule (&dev->bh);
tasklet_schedule(&dev->bh);
tasklet_schedule(&dev->bh);
tasklet_schedule (&dev->bh);
tasklet_schedule (&dev->bh);
tasklet_schedule (&dev->bh);
tasklet_schedule (&dev->bh);
tasklet_schedule (&dev->bh);
tasklet_schedule (&dev->bh);
And I do believe the code before your change demonstrated that the
original authors had the same view. There was an explicit exception for
just this case, and I do assume that was put there for a good
reason. usbnet_bh() will be called while the device is suspended, and we
must avoid making it reschedule itself in this case.
Anyway, the ENOLINK test was there. You removed it with no explanation
whatsoever. It is *your* call to verify and explain to us why this test
is unnecessary, not mine.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] netfilter: take care of timewait sockets
From: Eric Dumazet @ 2012-09-04 7:55 UTC (permalink / raw)
To: Florian Westphal, David Miller; +Cc: Sami Farin, netdev
In-Reply-To: <1346629684.2563.78.camel@edumazet-glaptop>
On Mon, 2012-09-03 at 01:48 +0200, Eric Dumazet wrote:
> Sami Farin reported crashes in xt_LOG because it assumes skb->sk is a
> full blown socket.
>
> But with TCP early demux, we can have skb->sk pointing to a timewait
> socket.
>
> Same fix is needed in netfnetlink_log
>
> Diagnosed-by: Florian Westphal <fw@strlen.de>
> Reported-by: Sami Farin <hvtaifwkbgefbaei@gmail.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> net/netfilter/nfnetlink_log.c | 14 +++++++------
> net/netfilter/xt_LOG.c | 33 ++++++++++++++++----------------
> 2 files changed, 25 insertions(+), 22 deletions(-)
>
> diff --git a/net/netfilter/nfnetlink_log.c b/net/netfilter/nfnetlink_log.c
> index 14e2f39..5cfb5be 100644
> --- a/net/netfilter/nfnetlink_log.c
> +++ b/net/netfilter/nfnetlink_log.c
> @@ -381,6 +381,7 @@ __build_packet_message(struct nfulnl_instance *inst,
> struct nlmsghdr *nlh;
> struct nfgenmsg *nfmsg;
> sk_buff_data_t old_tail = inst->skb->tail;
> + struct sock *sk;
>
> nlh = nlmsg_put(inst->skb, 0, 0,
> NFNL_SUBSYS_ULOG << 8 | NFULNL_MSG_PACKET,
> @@ -499,18 +500,19 @@ __build_packet_message(struct nfulnl_instance *inst,
> }
>
> /* UID */
> - if (skb->sk) {
> - read_lock_bh(&skb->sk->sk_callback_lock);
> - if (skb->sk->sk_socket && skb->sk->sk_socket->file) {
> - struct file *file = skb->sk->sk_socket->file;
> + sk = skb->sk;
> + if (sk && sk->sk_state != TCP_TIME_WAIT) {
> + read_lock_bh(&sk->sk_callback_lock);
> + if (sk->sk_socket && sk->sk_socket->file) {
> + struct file *file = sk->sk_socket->file;
> __be32 uid = htonl(file->f_cred->fsuid);
> __be32 gid = htonl(file->f_cred->fsgid);
> - read_unlock_bh(&skb->sk->sk_callback_lock);
> + read_unlock_bh(&sk->sk_callback_lock);
> if (nla_put_be32(inst->skb, NFULA_UID, uid) ||
> nla_put_be32(inst->skb, NFULA_GID, gid))
> goto nla_put_failure;
> } else
> - read_unlock_bh(&skb->sk->sk_callback_lock);
> + read_unlock_bh(&sk->sk_callback_lock);
> }
>
> /* local sequence number */
> diff --git a/net/netfilter/xt_LOG.c b/net/netfilter/xt_LOG.c
> index ff5f75f..2a4f969 100644
> --- a/net/netfilter/xt_LOG.c
> +++ b/net/netfilter/xt_LOG.c
> @@ -145,6 +145,19 @@ static int dump_tcp_header(struct sbuff *m, const struct sk_buff *skb,
> return 0;
> }
>
> +static void dump_sk_uid_gid(struct sbuff *m, struct sock *sk)
> +{
> + if (!sk || sk->sk_state == TCP_TIME_WAIT)
> + return;
> +
> + read_lock_bh(&sk->sk_callback_lock);
> + if (sk->sk_socket && sk->sk_socket->file)
> + sb_add(m, "UID=%u GID=%u ",
> + sk->sk_socket->file->f_cred->fsuid,
> + sk->sk_socket->file->f_cred->fsgid);
> + read_unlock_bh(&sk->sk_callback_lock);
> +}
> +
> /* One level of recursion won't kill us */
> static void dump_ipv4_packet(struct sbuff *m,
> const struct nf_loginfo *info,
> @@ -361,14 +374,8 @@ static void dump_ipv4_packet(struct sbuff *m,
> }
>
> /* Max length: 15 "UID=4294967295 " */
> - if ((logflags & XT_LOG_UID) && !iphoff && skb->sk) {
> - read_lock_bh(&skb->sk->sk_callback_lock);
> - if (skb->sk->sk_socket && skb->sk->sk_socket->file)
> - sb_add(m, "UID=%u GID=%u ",
> - skb->sk->sk_socket->file->f_cred->fsuid,
> - skb->sk->sk_socket->file->f_cred->fsgid);
> - read_unlock_bh(&skb->sk->sk_callback_lock);
> - }
> + if ((logflags & XT_LOG_UID) && !iphoff)
> + dump_sk_uid_gid(m, skb->sk);
>
> /* Max length: 16 "MARK=0xFFFFFFFF " */
> if (!iphoff && skb->mark)
> @@ -717,14 +724,8 @@ static void dump_ipv6_packet(struct sbuff *m,
> }
>
> /* Max length: 15 "UID=4294967295 " */
> - if ((logflags & XT_LOG_UID) && recurse && skb->sk) {
> - read_lock_bh(&skb->sk->sk_callback_lock);
> - if (skb->sk->sk_socket && skb->sk->sk_socket->file)
> - sb_add(m, "UID=%u GID=%u ",
> - skb->sk->sk_socket->file->f_cred->fsuid,
> - skb->sk->sk_socket->file->f_cred->fsgid);
> - read_unlock_bh(&skb->sk->sk_callback_lock);
> - }
> + if ((logflags & XT_LOG_UID) && recurse)
> + dump_sk_uid_gid(m, skb->sk);
>
> /* Max length: 16 "MARK=0xFFFFFFFF " */
> if (!recurse && skb->mark)
>
Hi David
This patch was marked "Not applicable" in Patchwork
( http://patchwork.ozlabs.org/patch/181275/ )
It seems a mistake, since it should be applied ?
Tell me if I should resend it
Thanks
^ permalink raw reply
* Re: [PATCH net] net: usbnet: fix softirq storm on suspend
From: Bjørn Mork @ 2012-09-04 8:05 UTC (permalink / raw)
To: Ming Lei
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
Oliver Neukum
In-Reply-To: <87y5kqcjnp.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> writes:
> And I do believe the code before your change demonstrated that the
> original authors had the same view. There was an explicit exception for
> just this case, and I do assume that was put there for a good
> reason. usbnet_bh() will be called while the device is suspended, and we
> must avoid making it reschedule itself in this case.
>
> Anyway, the ENOLINK test was there. You removed it with no explanation
> whatsoever. It is *your* call to verify and explain to us why this test
> is unnecessary, not mine.
For your convienience, all the reasons why this code ended up like it
was are documented in the netdev patchwork:
http://patchwork.ozlabs.org/patch/59488/
There were different proposed solutions circulating, before the test for
ENOLINK was chosen. No-one challenged the fact that some test for a
suspended device was needed here.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] net: usbnet: fix softirq storm on suspend
From: Ming Lei @ 2012-09-04 9:38 UTC (permalink / raw)
To: Bjørn Mork
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
Oliver Neukum
In-Reply-To: <87y5kqcjnp.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
On Tue, Sep 4, 2012 at 3:49 PM, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> wrote:
>
> That's easy:
>
> - Take any usbnet device supporting remote wakeup (and of course with a
> minidriver supporting it as well),
> - enable autosuspend,
> - ip link set dev ethX/usbX/wwanX up
>
> And watch ksoftirqd/X use 100% of one of your CPU cores.
>
> I'd very much like to hear the details if you are unable to reproduce
> the bug using this simple test.
I have no such kind of devices, and can't reproduce the problem with
a cdc-ether gadget built by one omap3 beagleboard.
>> Once usbnet_terminate_urbs and netif_device_attach() are
>> completed, who will schedule tasklet to trigger rx_alloc_submit?
>
> That's a good question. It sure would be nice if that never happened
> without waking the device first. But there are just too many call sites
> for me to follow:
To be honest, your patch is correct, and I am just curious about
the reason why tasklet is scheduled after the device is suspended.
>
> bjorn@nemi:/usr/local/src/git/linux$ grep tasklet_schedule drivers/net/usb/usbnet.c
> tasklet_schedule(&dev->bh);
> * but tasklet_schedule() doesn't. hope the failure is rare.
> tasklet_schedule (&dev->bh);
> tasklet_schedule(&dev->bh);
> tasklet_schedule(&dev->bh);
> tasklet_schedule (&dev->bh);
> tasklet_schedule (&dev->bh);
> tasklet_schedule (&dev->bh);
> tasklet_schedule (&dev->bh);
> tasklet_schedule (&dev->bh);
> tasklet_schedule (&dev->bh);
Could you add some debug info inside the caller to see which one
cause the tasklet to be scheduled?
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] sctp: use list_move_tail instead of list_del/list_add_tail
From: Wei Yongjun @ 2012-09-04 9:58 UTC (permalink / raw)
To: vyasevich, sri, davem; +Cc: yongjun_wei, linux-sctp, netdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Using list_move_tail() instead of list_del() + list_add_tail().
spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
net/sctp/outqueue.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
index e7aa177c..d10cbf1 100644
--- a/net/sctp/outqueue.c
+++ b/net/sctp/outqueue.c
@@ -589,9 +589,8 @@ static int sctp_outq_flush_rtx(struct sctp_outq *q, struct sctp_packet *pkt,
* next chunk.
*/
if (chunk->tsn_gap_acked) {
- list_del(&chunk->transmitted_list);
- list_add_tail(&chunk->transmitted_list,
- &transport->transmitted);
+ list_move_tail(&chunk->transmitted_list,
+ &transport->transmitted);
continue;
}
@@ -655,9 +654,8 @@ redo:
/* The append was successful, so add this chunk to
* the transmitted list.
*/
- list_del(&chunk->transmitted_list);
- list_add_tail(&chunk->transmitted_list,
- &transport->transmitted);
+ list_move_tail(&chunk->transmitted_list,
+ &transport->transmitted);
/* Mark the chunk as ineligible for fast retransmit
* after it is retransmitted.
^ permalink raw reply related
* [PATCH] xfrm: Workaround incompatibility of ESN and async crypto
From: Steffen Klassert @ 2012-09-04 10:03 UTC (permalink / raw)
To: David Miller, Herbert Xu; +Cc: netdev
ESN for esp is defined in RFC 4303. This RFC assumes that the
sequence number counters are always up to date. However,
this is not true if an async crypto algorithm is employed.
If the sequence number counters are not up to date on sequence
number check, we may incorrectly update the upper 32 bit of
the sequence number. This leads to a DOS.
We workaround this by comparing the upper sequence number,
(used for authentication) with the upper sequence number
computed after the async processing. We drop the packet
if these numbers are different.
To do this, we introduce a recheck function that does this
check in the ESN case.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
include/net/xfrm.h | 3 +++
net/xfrm/xfrm_input.c | 2 +-
net/xfrm/xfrm_replay.c | 15 +++++++++++++++
3 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 976a81a..639dd13 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -273,6 +273,9 @@ struct xfrm_replay {
int (*check)(struct xfrm_state *x,
struct sk_buff *skb,
__be32 net_seq);
+ int (*recheck)(struct xfrm_state *x,
+ struct sk_buff *skb,
+ __be32 net_seq);
void (*notify)(struct xfrm_state *x, int event);
int (*overflow)(struct xfrm_state *x, struct sk_buff *skb);
};
diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index 54a0dc2..ab2bb42 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -212,7 +212,7 @@ resume:
/* only the first xfrm gets the encap type */
encap_type = 0;
- if (async && x->repl->check(x, skb, seq)) {
+ if (async && x->repl->recheck(x, skb, seq)) {
XFRM_INC_STATS(net, LINUX_MIB_XFRMINSTATESEQERROR);
goto drop_unlock;
}
diff --git a/net/xfrm/xfrm_replay.c b/net/xfrm/xfrm_replay.c
index 2f6d11d..3efb07d 100644
--- a/net/xfrm/xfrm_replay.c
+++ b/net/xfrm/xfrm_replay.c
@@ -420,6 +420,18 @@ err:
return -EINVAL;
}
+static int xfrm_replay_recheck_esn(struct xfrm_state *x,
+ struct sk_buff *skb, __be32 net_seq)
+{
+ if (unlikely(XFRM_SKB_CB(skb)->seq.input.hi !=
+ htonl(xfrm_replay_seqhi(x, net_seq)))) {
+ x->stats.replay_window++;
+ return -EINVAL;
+ }
+
+ return xfrm_replay_check_esn(x, skb, net_seq);
+}
+
static void xfrm_replay_advance_esn(struct xfrm_state *x, __be32 net_seq)
{
unsigned int bitnr, nr, i;
@@ -479,6 +491,7 @@ static void xfrm_replay_advance_esn(struct xfrm_state *x, __be32 net_seq)
static struct xfrm_replay xfrm_replay_legacy = {
.advance = xfrm_replay_advance,
.check = xfrm_replay_check,
+ .recheck = xfrm_replay_check,
.notify = xfrm_replay_notify,
.overflow = xfrm_replay_overflow,
};
@@ -486,6 +499,7 @@ static struct xfrm_replay xfrm_replay_legacy = {
static struct xfrm_replay xfrm_replay_bmp = {
.advance = xfrm_replay_advance_bmp,
.check = xfrm_replay_check_bmp,
+ .recheck = xfrm_replay_check_bmp,
.notify = xfrm_replay_notify_bmp,
.overflow = xfrm_replay_overflow_bmp,
};
@@ -493,6 +507,7 @@ static struct xfrm_replay xfrm_replay_bmp = {
static struct xfrm_replay xfrm_replay_esn = {
.advance = xfrm_replay_advance_esn,
.check = xfrm_replay_check_esn,
+ .recheck = xfrm_replay_recheck_esn,
.notify = xfrm_replay_notify_bmp,
.overflow = xfrm_replay_overflow_esn,
};
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH net] net: usbnet: fix softirq storm on suspend
From: Bjørn Mork @ 2012-09-04 10:36 UTC (permalink / raw)
To: Ming Lei; +Cc: netdev, linux-usb, Oliver Neukum
In-Reply-To: <CACVXFVMEqF9+e10oRuTHjkKQOnPnJMXxapXZ9rYG9qWRpZPLKw@mail.gmail.com>
Ming Lei <ming.lei@canonical.com> writes:
> On Tue, Sep 4, 2012 at 3:49 PM, Bjørn Mork <bjorn@mork.no> wrote:
>>
>> That's easy:
>>
>> - Take any usbnet device supporting remote wakeup (and of course with a
>> minidriver supporting it as well),
>> - enable autosuspend,
>> - ip link set dev ethX/usbX/wwanX up
>>
>> And watch ksoftirqd/X use 100% of one of your CPU cores.
>>
>> I'd very much like to hear the details if you are unable to reproduce
>> the bug using this simple test.
>
> I have no such kind of devices, and can't reproduce the problem with
> a cdc-ether gadget built by one omap3 beagleboard.
I believe any Ericsson or Gobi modem would do, and most likely other USB
networking devices too.
I haven't explored the gadget. Doesn't it support remote wakeup? Well,
it doesn't really have to just for testing this. You just have to fake
the remote wakeup support, either in the gadget or in the device
driver. It doesn't matter whether it works or not. The point is making
the driver suspend the USB device while the network device is running.
>>> Once usbnet_terminate_urbs and netif_device_attach() are
>>> completed, who will schedule tasklet to trigger rx_alloc_submit?
>>
>> That's a good question. It sure would be nice if that never happened
>> without waking the device first. But there are just too many call sites
>> for me to follow:
>
> To be honest, your patch is correct, and I am just curious about
> the reason why tasklet is scheduled after the device is suspended.
>
>>
>> bjorn@nemi:/usr/local/src/git/linux$ grep tasklet_schedule drivers/net/usb/usbnet.c
>> tasklet_schedule(&dev->bh);
>> * but tasklet_schedule() doesn't. hope the failure is rare.
>> tasklet_schedule (&dev->bh);
>> tasklet_schedule(&dev->bh);
>> tasklet_schedule(&dev->bh);
>> tasklet_schedule (&dev->bh);
>> tasklet_schedule (&dev->bh);
>> tasklet_schedule (&dev->bh);
>> tasklet_schedule (&dev->bh);
>> tasklet_schedule (&dev->bh);
>> tasklet_schedule (&dev->bh);
>
> Could you add some debug info inside the caller to see which one
> cause the tasklet to be scheduled?
Goode idea. I replaced the tasklet_schedule() calls with
#define DBG_TASKLET(bh) { \
pr_err("%s scheduling tasklet %p\n", __func__, bh); \
tasklet_schedule(bh); \
}
and added a useless WARN_ON around the test:
if (temp < RX_QLEN(dev)) {
if (WARN_ON_ONCE(rx_alloc_submit(dev, GFP_ATOMIC) == -ENOLINK))
return;
and got:
Sep 4 12:22:48 nemi kernel: [50270.964818] qmi_wwan 2-4:1.8: wdm1_resume
Sep 4 12:22:48 nemi kernel: [50270.964832] qmi_wwan 2-4:1.19: wdm2_resume
Sep 4 12:22:48 nemi kernel: [50270.964845] usbnet_open scheduling tasklet ffff88014a8529d0
Sep 4 12:22:48 nemi kernel: [50270.964857] qmi_wwan 2-4:1.8: qmi_wwan_manage_power() pmcount=0, on=1
Sep 4 12:22:48 nemi kernel: [50270.964921] qmi_wwan 2-4:1.8: wwan1: rxqlen 0 --> 10
Sep 4 12:22:48 nemi kernel: [50270.964926] usbnet_bh scheduling tasklet ffff88014a8529d0
Sep 4 12:22:48 nemi kernel: [50270.964962] qmi_wwan 2-4:1.8: wwan1: rxqlen 10 --> 20
Sep 4 12:22:48 nemi kernel: [50270.964966] usbnet_bh scheduling tasklet ffff88014a8529d0
Sep 4 12:22:48 nemi kernel: [50270.965016] qmi_wwan 2-4:1.8: wwan1: rxqlen 20 --> 30
Sep 4 12:22:48 nemi kernel: [50270.965020] usbnet_bh scheduling tasklet ffff88014a8529d0
Sep 4 12:22:48 nemi kernel: [50270.965057] qmi_wwan 2-4:1.8: wwan1: rxqlen 30 --> 40
Sep 4 12:22:48 nemi kernel: [50270.965061] usbnet_bh scheduling tasklet ffff88014a8529d0
Sep 4 12:22:48 nemi kernel: [50270.965097] qmi_wwan 2-4:1.8: wwan1: rxqlen 40 --> 50
Sep 4 12:22:48 nemi kernel: [50270.965101] usbnet_bh scheduling tasklet ffff88014a8529d0
Sep 4 12:22:48 nemi kernel: [50270.965136] qmi_wwan 2-4:1.8: wwan1: rxqlen 50 --> 60
Sep 4 12:22:48 nemi kernel: [50270.972270] defer_bh scheduling tasklet ffff88014a8529d0
Sep 4 12:22:48 nemi kernel: [50271.040290] defer_bh scheduling tasklet ffff88014a8529d0
Sep 4 12:22:48 nemi kernel: [50271.240286] defer_bh scheduling tasklet ffff88014a8529d0
Sep 4 12:22:49 nemi kernel: [50272.040536] defer_bh scheduling tasklet ffff88014a8529d0
Sep 4 12:22:51 nemi kernel: [50274.040121] qmi_wwan 2-4:1.19: wdm2_suspend
Sep 4 12:22:51 nemi kernel: [50274.040234] qmi_wwan 2-4:1.8: wdm1_suspend
Sep 4 12:22:51 nemi kernel: [50274.040263] defer_bh scheduling tasklet ffff88014a8529d0
Sep 4 12:22:51 nemi kernel: [50274.040599] ------------[ cut here ]------------
Sep 4 12:22:51 nemi kernel: [50274.040612] WARNING: at /usr/local/src/git/linux/drivers/net/usb/usbnet.c:1271 tasklet_action+0x76/0xc4()
Sep 4 12:22:51 nemi kernel: [50274.040617] Hardware name: 2776LEG
Sep 4 12:22:51 nemi kernel: [50274.040620] Modules linked in: qmi_wwan(O) usbnet(O) nfnetlink_log nfnetlink option nls_utf8 isofs usb_storage uas usbmon cdc_wdm(O) mii rfcomm bnep xt_multiport iptable_filter ip_tables cpufreq_userspace cpufreq_stats cpufreq_conservative cpufreq_powersave binfmt_misc xt_hl ip6table_filter ip6_tables x_tables fuse nfsd nfs_acl nfs lockd fscache sunrpc 8021q garp stp llc tun ext2 loop snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm arc4 iwldvm mac80211 snd_page_alloc thinkpad_acpi nvram snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq coretemp kvm_intel mei btusb qcserial kvm usb_wwan usbserial bluetooth crc16 snd_timer snd_seq_device i915 microcode iwlwifi psmouse serio_raw snd evdev lpc_ich drm_kms_helper i2c_i801 mfd_core cfg80211 drm i2c_algo_bit i2c_core acpi_cpufreq wmi soundcore rfkill battery ac mperf processor button video ext3 mbcache jbd sha256_generic ablk_helper cryptd aes_x86_64 aes_generic cbc dm_crypt dm_mod nbd s
Sep 4 12:22:51 nemi kernel: g sd_mod crc_t10dif sr_mod cdrom thermal thermal_sys ahci libahci libata uhci_hcd ehci_hcd scsi_mod e1000e usbcore usb_common [last unloaded: usbnet]
Sep 4 12:22:51 nemi kernel: [50274.040857] Pid: 7758, comm: kworker/0:0 Tainted: G W O 3.6.0-rc4+ #32
Sep 4 12:22:51 nemi kernel: [50274.040861] Call Trace:
Sep 4 12:22:51 nemi kernel: [50274.040865] <IRQ> [<ffffffff8103e0ed>] ? warn_slowpath_common+0x78/0x8c
Sep 4 12:22:51 nemi kernel: [50274.040883] [<ffffffff810457b2>] ? tasklet_action+0x76/0xc4
Sep 4 12:22:51 nemi kernel: [50274.040890] [<ffffffff810451e5>] ? __do_softirq+0xd9/0x1d1
Sep 4 12:22:51 nemi kernel: [50274.040898] [<ffffffff8109f761>] ? handle_irq_event_percpu+0x172/0x191
Sep 4 12:22:51 nemi kernel: [50274.040908] [<ffffffff81371bfc>] ? call_softirq+0x1c/0x30
Sep 4 12:22:51 nemi kernel: [50274.040918] [<ffffffff8100fa4b>] ? do_softirq+0x3f/0x79
Sep 4 12:22:51 nemi kernel: [50274.040924] [<ffffffff81044f9e>] ? irq_exit+0x44/0xb1
Sep 4 12:22:51 nemi kernel: [50274.040931] [<ffffffff8100f326>] ? do_IRQ+0x94/0xaa
Sep 4 12:22:51 nemi kernel: [50274.040941] [<ffffffff8136b5ea>] ? common_interrupt+0x6a/0x6a
Sep 4 12:22:51 nemi kernel: [50274.040944] <EOI> [<ffffffff8126fa99>] ? dev_get_drvdata+0x15/0x19
Sep 4 12:22:51 nemi kernel: [50274.040969] [<ffffffffa04ee4ca>] ? usb_wwan_suspend+0x70/0xd7 [usb_wwan]
Sep 4 12:22:51 nemi kernel: [50274.040983] [<ffffffffa02aa5d0>] ? usb_serial_suspend+0x35/0x74 [usbserial]
Sep 4 12:22:51 nemi kernel: [50274.041010] [<ffffffffa00d313b>] ? usb_suspend_both+0x8e/0x19c [usbcore]
Sep 4 12:22:51 nemi kernel: [50274.041035] [<ffffffffa00d3271>] ? usb_runtime_suspend+0x28/0x4c [usbcore]
Sep 4 12:22:51 nemi kernel: [50274.041043] [<ffffffff81277943>] ? __rpm_callback+0x33/0x57
Sep 4 12:22:51 nemi kernel: [50274.041050] [<ffffffff81277ee1>] ? rpm_suspend+0x30e/0x53c
Sep 4 12:22:51 nemi kernel: [50274.041059] [<ffffffff81278e1a>] ? pm_runtime_set_autosuspend_delay+0x4b/0x4b
Sep 4 12:22:51 nemi kernel: [50274.041066] [<ffffffff81278e8e>] ? pm_runtime_work+0x74/0x94
Sep 4 12:22:51 nemi kernel: [50274.041075] [<ffffffff81055d3d>] ? process_one_work+0x1ff/0x311
Sep 4 12:22:51 nemi kernel: [50274.041083] [<ffffffff8105604a>] ? worker_thread+0x1fb/0x2fb
Sep 4 12:22:51 nemi kernel: [50274.041091] [<ffffffff81055e4f>] ? process_one_work+0x311/0x311
Sep 4 12:22:51 nemi kernel: [50274.041099] [<ffffffff81055e4f>] ? process_one_work+0x311/0x311
Sep 4 12:22:51 nemi kernel: [50274.041106] [<ffffffff81059861>] ? kthread+0x81/0x89
Sep 4 12:22:51 nemi kernel: [50274.041115] [<ffffffff81371b04>] ? kernel_thread_helper+0x4/0x10
Sep 4 12:22:51 nemi kernel: [50274.041123] [<ffffffff810597e0>] ? kthread_freezable_should_stop+0x53/0x53
Sep 4 12:22:51 nemi kernel: [50274.041130] [<ffffffff81371b00>] ? gs_change+0x13/0x13
Sep 4 12:22:51 nemi kernel: [50274.041135] ---[ end trace 8293423100f8e272 ]---
Sep 4 12:22:53 nemi kernel: [50276.048112] qmi_wwan 2-4:1.8: wwan1: Delaying transmission for resumption
Sep 4 12:22:53 nemi kernel: [50276.097673] qmi_wwan 2-4:1.8: wdm1_resume
Sep 4 12:22:53 nemi kernel: [50276.097743] usbnet_resume scheduling tasklet ffff88014a8529d0
Sep 4 12:22:53 nemi kernel: [50276.097754] qmi_wwan 2-4:1.19: wdm2_resume
Sep 4 12:22:53 nemi kernel: [50276.097789] defer_bh scheduling tasklet ffff88014a8529d0
Sep 4 12:22:53 nemi kernel: [50276.097847] qmi_wwan 2-4:1.8: wwan1: rxqlen 10 --> 20
Sep 4 12:22:53 nemi kernel: [50276.097851] usbnet_bh scheduling tasklet ffff88014a8529d0
Sep 4 12:22:53 nemi kernel: [50276.097890] qmi_wwan 2-4:1.8: wwan1: rxqlen 20 --> 30
Sep 4 12:22:53 nemi kernel: [50276.097895] usbnet_bh scheduling tasklet ffff88014a8529d0
Sep 4 12:22:53 nemi kernel: [50276.097930] qmi_wwan 2-4:1.8: wwan1: rxqlen 30 --> 40
Sep 4 12:22:53 nemi kernel: [50276.097935] usbnet_bh scheduling tasklet ffff88014a8529d0
Sep 4 12:22:53 nemi kernel: [50276.097970] qmi_wwan 2-4:1.8: wwan1: rxqlen 40 --> 50
Sep 4 12:22:53 nemi kernel: [50276.097974] usbnet_bh scheduling tasklet ffff88014a8529d0
Sep 4 12:22:53 nemi kernel: [50276.098010] qmi_wwan 2-4:1.8: wwan1: rxqlen 50 --> 60
Sep 4 12:22:56 nemi kernel: [50278.824340] qmi_wwan 2-4:1.19: wdm2_suspend
Sep 4 12:22:56 nemi kernel: [50278.824441] defer_bh scheduling tasklet ffff88014a8529d0
Sep 4 12:22:56 nemi kernel: [50278.824708] qmi_wwan 2-4:1.8: wdm1_suspend
Sep 4 12:22:56 nemi kernel: [50278.824833] defer_bh scheduling tasklet ffff88014a8529d0
Sep 4 12:22:56 nemi kernel: [50278.824916] ------------[ cut here ]------------
Sep 4 12:22:56 nemi kernel: [50278.824929] WARNING: at /usr/local/src/git/linux/drivers/net/usb/usbnet.c:1271 tasklet_action+0x76/0xc4()
Sep 4 12:22:56 nemi kernel: [50278.824933] Hardware name: 2776LEG
Sep 4 12:22:56 nemi kernel: [50278.824936] Modules linked in: qmi_wwan(O) usbnet(O) nfnetlink_log nfnetlink option nls_utf8 isofs usb_storage uas usbmon cdc_wdm(O) mii rfcomm bnep xt_multiport iptable_filter ip_tables cpufreq_userspace cpufreq_stats cpufreq_conservative cpufreq_powersave binfmt_misc xt_hl ip6table_filter ip6_tables x_tables fuse nfsd nfs_acl nfs lockd fscache sunrpc 8021q garp stp llc tun ext2 loop snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm arc4 iwldvm mac80211 snd_page_alloc thinkpad_acpi nvram snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq coretemp kvm_intel mei btusb qcserial kvm usb_wwan usbserial bluetooth crc16 snd_timer snd_seq_device i915 microcode iwlwifi psmouse serio_raw snd evdev lpc_ich drm_kms_helper i2c_i801 mfd_core cfg80211 drm i2c_algo_bit i2c_core acpi_cpufreq wmi soundcore rfkill battery ac mperf processor button video ext3 mbcache jbd sha256_generic ablk_helper cryptd aes_x86_64 aes_generic cbc dm_crypt dm_mod nbd s
Sep 4 12:22:56 nemi kernel: g sd_mod crc_t10dif sr_mod cdrom thermal thermal_sys ahci libahci libata uhci_hcd ehci_hcd scsi_mod e1000e usbcore usb_common [last unloaded: usbnet]
Sep 4 12:22:56 nemi kernel: [50278.825189] Pid: 0, comm: swapper/0 Tainted: G W O 3.6.0-rc4+ #32
Sep 4 12:22:56 nemi kernel: [50278.825193] Call Trace:
Sep 4 12:22:56 nemi kernel: [50278.825197] <IRQ> [<ffffffff8103e0ed>] ? warn_slowpath_common+0x78/0x8c
Sep 4 12:22:56 nemi kernel: [50278.825215] [<ffffffff810457b2>] ? tasklet_action+0x76/0xc4
Sep 4 12:22:56 nemi kernel: [50278.825222] [<ffffffff810451e5>] ? __do_softirq+0xd9/0x1d1
Sep 4 12:22:56 nemi kernel: [50278.825231] [<ffffffff8109f761>] ? handle_irq_event_percpu+0x172/0x191
Sep 4 12:22:56 nemi kernel: [50278.825241] [<ffffffff81371bfc>] ? call_softirq+0x1c/0x30
Sep 4 12:22:56 nemi kernel: [50278.825250] [<ffffffff8100fa4b>] ? do_softirq+0x3f/0x79
Sep 4 12:22:56 nemi kernel: [50278.825257] [<ffffffff81044f9e>] ? irq_exit+0x44/0xb1
Sep 4 12:22:56 nemi kernel: [50278.825264] [<ffffffff8100f326>] ? do_IRQ+0x94/0xaa
Sep 4 12:22:56 nemi kernel: [50278.825274] [<ffffffff8136b5ea>] ? common_interrupt+0x6a/0x6a
Sep 4 12:22:56 nemi kernel: [50278.825277] <EOI> [<ffffffffa0179150>] ? acpi_idle_enter_bm+0x276/0x2ad [processor]
Sep 4 12:22:56 nemi kernel: [50278.825314] [<ffffffffa017914c>] ? acpi_idle_enter_bm+0x272/0x2ad [processor]
Sep 4 12:22:56 nemi kernel: [50278.825325] [<ffffffff8129046f>] ? cpuidle_enter_state+0xa/0x30
Sep 4 12:22:56 nemi kernel: [50278.825332] [<ffffffff81290bba>] ? cpuidle_idle_call+0xd4/0x14e
Sep 4 12:22:56 nemi kernel: [50278.825340] [<ffffffff81014c19>] ? cpu_idle+0xae/0xf7
Sep 4 12:22:56 nemi kernel: [50278.825349] [<ffffffff816a9ccb>] ? start_kernel+0x3b8/0x3c3
Sep 4 12:22:56 nemi kernel: [50278.825357] [<ffffffff816a974c>] ? kernel_init+0x1c9/0x1c9
Sep 4 12:22:56 nemi kernel: [50278.825365] [<ffffffff816a93e1>] ? x86_64_start_kernel+0x102/0x10f
Sep 4 12:22:56 nemi kernel: [50278.825371] ---[ end trace 8293423100f8e273 ]---
Sep 4 12:22:56 nemi kernel: [50279.502537] qmi_wwan 2-4:1.8: qmi_wwan_manage_power() pmcount=1, on=0
Sep 4 12:22:57 nemi kernel: [50279.549214] qmi_wwan 2-4:1.8: wdm1_resume
Sep 4 12:22:57 nemi kernel: [50279.549229] qmi_wwan 2-4:1.19: wdm2_resume
Sep 4 12:22:59 nemi kernel: [50281.824317] qmi_wwan 2-4:1.19: wdm2_suspend
Sep 4 12:22:59 nemi kernel: [50281.824335] qmi_wwan 2-4:1.8: wdm1_suspend
So the code trigging this seems to be
static enum skb_state defer_bh(struct usbnet *dev, struct sk_buff *skb,
struct sk_buff_head *list, enum skb_state state)
{
unsigned long flags;
enum skb_state old_state;
struct skb_data *entry = (struct skb_data *) skb->cb;
spin_lock_irqsave(&list->lock, flags);
old_state = entry->state;
entry->state = state;
__skb_unlink(skb, list);
spin_unlock(&list->lock);
spin_lock(&dev->done.lock);
__skb_queue_tail(&dev->done, skb);
if (dev->done.qlen == 1)
tasklet_schedule(&dev->bh);
spin_unlock_irqrestore(&dev->done.lock, flags);
return old_state;
}
Hmm, I should probably dump stack here as well.. Anyway, it's a start.
I certainly have no clue if this coode could or should be changed. I
just don't understand all the finer details. So I don't think I am
going to try refining this any further. The old strategy worked before
3.5 and it works after my fix.
Bjørn
^ permalink raw reply
* Question regarding kernel panic in net/ipv4/tcp_output.c
From: smka2012 @ 2012-09-04 11:55 UTC (permalink / raw)
To: netdev
Hi,
I recently had a severe issue with multiple servers that stopped working at the same time. By using the stacktrace, I could locate the following line in the tcp_retransmit_skb function of the tcp_output.c kernel source that led to a kernel panic on all servers. I am using Debian 6.0 with the kernel version 2.6.32-45.
(gdb) list *(tcp_retransmit_skb+0x66)
0x1a93 is in tcp_retransmit_skb (net/ipv4/tcp_output.c:1905).
1900 if (atomic_read(&sk->sk_wmem_alloc) >
1901 min(sk->sk_wmem_queued + (sk->sk_wmem_queued >> 2), sk->sk_sndbuf))
1902 return -EAGAIN;
1903
1904 if (before(TCP_SKB_CB(skb)->seq, tp->snd_una)) {
--->
1905 if (before(TCP_SKB_CB(skb)->end_seq, tp->snd_una))
1906 BUG();
<---
1907 if (tcp_trim_head(sk, skb, tp->snd_una - TCP_SKB_CB(skb)->seq))
1908 return -ENOMEM;
1909 }
Now I am interested in getting to know what can lead to a situation that the condition in line 1905 evaluates true and why the kernel goes into the BUG() function in that case and does not only return an error. All servers reached this line of code. They all were connected to a switch that broke the same time. However, I cannot say if the switch broke before the servers and eventually affected the servers or if the switch was also itself affected by some external event.
Thank you very much for your help.
Kind Regards,
Sascha
^ permalink raw reply
* Re: Question regarding kernel panic in net/ipv4/tcp_output.c
From: Eric Dumazet @ 2012-09-04 12:23 UTC (permalink / raw)
To: smka2012; +Cc: netdev
In-Reply-To: <trinity-daf22487-c4bf-4a4e-ae69-ed50d70f6169-1346759712289@3capp-webde-bs16>
On Tue, 2012-09-04 at 13:55 +0200, smka2012@email.de wrote:
> Hi,
>
> I recently had a severe issue with multiple servers that stopped
> working at the same time. By using the stacktrace, I could locate the
> following line in the tcp_retransmit_skb function of the tcp_output.c
> kernel source that led to a kernel panic on all servers. I am using
> Debian 6.0 with the kernel version 2.6.32-45.
>
> (gdb) list *(tcp_retransmit_skb+0x66)
> 0x1a93 is in tcp_retransmit_skb (net/ipv4/tcp_output.c:1905).
> 1900 if (atomic_read(&sk->sk_wmem_alloc) >
> 1901 min(sk->sk_wmem_queued + (sk->sk_wmem_queued >> 2),
> sk->sk_sndbuf))
> 1902 return -EAGAIN;
> 1903
> 1904 if (before(TCP_SKB_CB(skb)->seq, tp->snd_una)) {
>
> --->
> 1905 if (before(TCP_SKB_CB(skb)->end_seq, tp->snd_una))
> 1906 BUG();
> <---
>
> 1907 if (tcp_trim_head(sk, skb, tp->snd_una - TCP_SKB_CB(skb)->seq))
> 1908 return -ENOMEM;
> 1909 }
>
> Now I am interested in getting to know what can lead to a situation
> that the condition in line 1905 evaluates true and why the kernel goes
> into the BUG() function in that case and does not only return an
> error. All servers reached this line of code. They all were connected
> to a switch that broke the same time. However, I cannot say if the
> switch broke before the servers and eventually affected the servers or
> if the switch was also itself affected by some external event.
>
> Thank you very much for your help.
>
> Kind Regards,
> Sascha
> --
You can see this BUG() as an early notification of a hard to
debug/diagnose bug.
We shouldnt take this path at all.
If we do, we have an earlier bug that we should fix anyway, because
machine is going to crash.
It would be nice you sent the stack trace you had.
^ permalink raw reply
* Re: [PATCH] xfrm: Workaround incompatibility of ESN and async crypto
From: Herbert Xu @ 2012-09-04 12:31 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David Miller, netdev
In-Reply-To: <20120904100329.GA13023@secunet.com>
On Tue, Sep 04, 2012 at 12:03:29PM +0200, Steffen Klassert wrote:
> ESN for esp is defined in RFC 4303. This RFC assumes that the
> sequence number counters are always up to date. However,
> this is not true if an async crypto algorithm is employed.
>
> If the sequence number counters are not up to date on sequence
> number check, we may incorrectly update the upper 32 bit of
> the sequence number. This leads to a DOS.
>
> We workaround this by comparing the upper sequence number,
> (used for authentication) with the upper sequence number
> computed after the async processing. We drop the packet
> if these numbers are different.
>
> To do this, we introduce a recheck function that does this
> check in the ESN case.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
It took me a while to understand the problem but Steffen was
correct again as usual.
Thanks,
--
Email: Herbert Xu <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
* should kernel IGMP rejoin on link up ?
From: Simon Paillard @ 2012-09-04 12:19 UTC (permalink / raw)
To: netdev
Hello,
Here is a scenario where IMO the kernel is not doing the job, where a host
running linux kernel is connected to a switch with igmp snooping enabled:
- nominal case: an interface is member of a multicast group, reports are
performed
- failure of link (like cable disconnected)
- the switch flushes the multicast membership for that port
- link is back
- kernel waits for switch query to report membership
-> The application miss packets until next General Query (default value in RFC:
125 seconds)
I cannot find in IGMPv2 RFC a specification of the behaviour to follow in such
a case, but :
- having a very little query interval would affect all the network, and polling
is not a clean way.
- it's imo not the application job to check for link failure and issue again
joins
So I wonder if the kernel should rejoin when interface link flag is up
(ip_mc_rejoin_groups() is already used by bonding code when a new interface is
up).
The next question, if you agree that should be the kernel job, is where the fix
should be located.
Thanks.
PS: I know little about MLD in IPv6, I didn't see in bonding code something
related to MLD, but I guess the same question applies.
(Please CC me on replies)
--
Simon Paillard
^ 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