* Re: [PATCH] irq: Add node_affinity CPU masks for smarter irqbalance hints
From: Eric Dumazet @ 2009-11-25 10:30 UTC (permalink / raw)
To: Andi Kleen
Cc: David Miller, peter.p.waskiewicz.jr, peterz, arjan, yong.zhang0,
linux-kernel, arjan, netdev
In-Reply-To: <4B0C4624.9080607@gmail.com>
Eric Dumazet a écrit :
> Andi Kleen a écrit :
>> They are typically allocated with dma_alloc_coherent(), which does
>> allocate a continuous area. In theory you could do interleaving
>> with IOMMus, but just putting it on the same node as the device
>> is probably better.
>
> There are two parts, biggest one allocated with vmalloc()
> (to hold struct ixgbe_rx_buffer array, 32 bytes or more per entry),
> only used by driver (not adapter)
>
> and one allocated with pci_alloc_consistent()
> (to hold ixgbe_adv_tx_desc array, 16 bytes per entry)
>
> vmalloc() one could be spreaded on many nodes.
> I am not speaking about the pci_alloc_consistent() one :)
>
BTW, I found my Nehalem dev machine behaves strangly, defeating all
my NUMA tweaks. (This is an HP DL380 G6)
It has two sockets, populated with two E5530 @2.4GH.
Each cpu has 2x4GB RAM modules.
It claims having two memory nodes, but all cpus are on Node 0
dmesg | grep -i node
[ 0.000000] SRAT: PXM 0 -> APIC 0 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 1 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 2 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 3 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 4 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 5 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 6 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 7 -> Node 0
[ 0.000000] SRAT: Node 0 PXM 0 0-e0000000
[ 0.000000] SRAT: Node 0 PXM 0 100000000-220000000
[ 0.000000] SRAT: Node 1 PXM 1 220000000-420000000
[ 0.000000] Bootmem setup node 0 0000000000000000-0000000220000000
[ 0.000000] NODE_DATA [0000000000001000 - 0000000000004fff]
[ 0.000000] Bootmem setup node 1 0000000220000000-000000041ffff000
[ 0.000000] NODE_DATA [0000000220000000 - 0000000220003fff]
[ 0.000000] [ffffea0000000000-ffffea00087fffff] PMD -> [ffff880028600000-ffff8800305fffff] on node 0
[ 0.000000] [ffffea0008800000-ffffea00107fffff] PMD -> [ffff880220200000-ffff8802281fffff] on node 1
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[5] active PFN ranges
[ 0.000000] On node 0 totalpages: 2094543
[ 0.000000] On node 1 totalpages: 2097151
[ 0.000000] NR_CPUS:16 nr_cpumask_bits:16 nr_cpu_ids:16 nr_node_ids:2
[ 0.000000] SLUB: Genslabs=14, HWalign=64, Order=0-3, MinObjects=0, CPUs=16, Nodes=2
[ 0.004756] Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[ 0.007213] CPU 0/0x0 -> Node 0
[ 0.398104] CPU 1/0x10 -> Node 0
[ 0.557854] CPU 2/0x4 -> Node 0
[ 0.717606] CPU 3/0x14 -> Node 0
[ 0.877357] CPU 4/0x2 -> Node 0
[ 1.037109] CPU 5/0x12 -> Node 0
[ 1.196860] CPU 6/0x6 -> Node 0
[ 1.356611] CPU 7/0x16 -> Node 0
[ 1.516365] CPU 8/0x1 -> Node 0
[ 1.676114] CPU 9/0x11 -> Node 0
[ 1.835865] CPU 10/0x5 -> Node 0
[ 1.995616] CPU 11/0x15 -> Node 0
[ 2.155367] CPU 12/0x3 -> Node 0
[ 2.315119] CPU 13/0x13 -> Node 0
[ 2.474870] CPU 14/0x7 -> Node 0
[ 2.634621] CPU 15/0x17 -> Node 0
# cat /proc/buddyinfo
Node 0, zone DMA 2 2 2 1 1 1 1 0 1 1 3
Node 0, zone DMA32 5 11 4 5 4 12 1 4 4 5 834
Node 0, zone Normal 4109 120 98 153 67 35 21 15 11 10 109
Node 1, zone Normal 7 17 10 12 7 14 5 7 6 5 2004
This is with net-next-2.6, I'll try linux-2.6
^ permalink raw reply
* Re: [PATCH] irq: Add node_affinity CPU masks for smarter irqbalance hints
From: Andi Kleen @ 2009-11-25 10:37 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andi Kleen, David Miller, peter.p.waskiewicz.jr, peterz, arjan,
yong.zhang0, linux-kernel, arjan, netdev
In-Reply-To: <4B0D0742.2050301@gmail.com>
Works here
>
> dmesg | grep -i node
> [ 0.000000] SRAT: PXM 0 -> APIC 0 -> Node 0
> [ 0.000000] SRAT: PXM 0 -> APIC 1 -> Node 0
> [ 0.000000] SRAT: PXM 0 -> APIC 2 -> Node 0
> [ 0.000000] SRAT: PXM 0 -> APIC 3 -> Node 0
> [ 0.000000] SRAT: PXM 0 -> APIC 4 -> Node 0
> [ 0.000000] SRAT: PXM 0 -> APIC 5 -> Node 0
> [ 0.000000] SRAT: PXM 0 -> APIC 6 -> Node 0
> [ 0.000000] SRAT: PXM 0 -> APIC 7 -> Node 0
You seem to only have 8 CPUs (one socket) Normally a dual socket nehalem
should have 16 with HyperThreading enabled.
For some reason the BIOS is not reporting the other CPU.
You could double check with acpidmp / iasl -d if that's
what the BIOS really reports, but normally it should work.
> [ 0.000000] SRAT: Node 0 PXM 0 0-e0000000
> [ 0.000000] SRAT: Node 0 PXM 0 100000000-220000000
> [ 0.000000] SRAT: Node 1 PXM 1 220000000-420000000
-Andi
^ permalink raw reply
* [PATCH 3/3] xfrm: Use the user specified truncation length in ESP and AH
From: Martin Willi @ 2009-11-25 10:29 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, netdev
In-Reply-To: <cover.1259142145.git.martin@strongswan.org>
Instead of using the hardcoded truncation for authentication
algorithms, use the truncation length specified on xfrm_state.
Signed-off-by: Martin Willi <martin@strongswan.org>
---
net/ipv4/ah4.c | 2 +-
net/ipv4/esp4.c | 2 +-
net/ipv6/ah6.c | 2 +-
net/ipv6/esp6.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/ah4.c b/net/ipv4/ah4.c
index 5c66270..b7be5ed 100644
--- a/net/ipv4/ah4.c
+++ b/net/ipv4/ah4.c
@@ -261,7 +261,7 @@ static int ah_init_state(struct xfrm_state *x)
}
ahp->icv_full_len = aalg_desc->uinfo.auth.icv_fullbits/8;
- ahp->icv_trunc_len = aalg_desc->uinfo.auth.icv_truncbits/8;
+ ahp->icv_trunc_len = x->aalg->alg_trunc_len/8;
BUG_ON(ahp->icv_trunc_len > MAX_AH_AUTH_LEN);
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 12f7287..1948895 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -530,7 +530,7 @@ static int esp_init_authenc(struct xfrm_state *x)
}
err = crypto_aead_setauthsize(
- aead, aalg_desc->uinfo.auth.icv_truncbits / 8);
+ aead, x->aalg->alg_trunc_len / 8);
if (err)
goto free_key;
}
diff --git a/net/ipv6/ah6.c b/net/ipv6/ah6.c
index c1589e2..0c2ae68 100644
--- a/net/ipv6/ah6.c
+++ b/net/ipv6/ah6.c
@@ -469,7 +469,7 @@ static int ah6_init_state(struct xfrm_state *x)
}
ahp->icv_full_len = aalg_desc->uinfo.auth.icv_fullbits/8;
- ahp->icv_trunc_len = aalg_desc->uinfo.auth.icv_truncbits/8;
+ ahp->icv_trunc_len = x->aalg->alg_trunc_len/8;
BUG_ON(ahp->icv_trunc_len > MAX_AH_AUTH_LEN);
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index af597c7..668a46b 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -473,7 +473,7 @@ static int esp_init_authenc(struct xfrm_state *x)
}
err = crypto_aead_setauthsize(
- aead, aalg_desc->uinfo.auth.icv_truncbits / 8);
+ aead, x->aalg->alg_trunc_len / 8);
if (err)
goto free_key;
}
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/3] xfrm: Store aalg in xfrm_state with a user specified truncation length
From: Martin Willi @ 2009-11-25 10:29 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, netdev
In-Reply-To: <cover.1259142145.git.martin@strongswan.org>
Adding a xfrm_state requires an authentication algorithm specified
either as xfrm_algo or as xfrm_algo_auth with a specific truncation
length. For compatibility, both attributes are dumped to userspace,
and we also accept both attributes, but prefer the new syntax.
If no truncation length is specified, or the authentication algorithm
is specified using xfrm_algo, the truncation length from the algorithm
description in the kernel is used.
Signed-off-by: Martin Willi <martin@strongswan.org>
---
include/net/xfrm.h | 12 ++++-
net/xfrm/xfrm_state.c | 2 +-
net/xfrm/xfrm_user.c | 129 ++++++++++++++++++++++++++++++++++++++++++++++---
3 files changed, 133 insertions(+), 10 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 223e90a..762327d 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -160,7 +160,7 @@ struct xfrm_state
struct xfrm_lifetime_cfg lft;
/* Data for transformer */
- struct xfrm_algo *aalg;
+ struct xfrm_algo_auth *aalg;
struct xfrm_algo *ealg;
struct xfrm_algo *calg;
struct xfrm_algo_aead *aead;
@@ -1541,12 +1541,22 @@ static inline int xfrm_alg_len(struct xfrm_algo *alg)
return sizeof(*alg) + ((alg->alg_key_len + 7) / 8);
}
+static inline int xfrm_alg_auth_len(struct xfrm_algo_auth *alg)
+{
+ return sizeof(*alg) + ((alg->alg_key_len + 7) / 8);
+}
+
#ifdef CONFIG_XFRM_MIGRATE
static inline struct xfrm_algo *xfrm_algo_clone(struct xfrm_algo *orig)
{
return kmemdup(orig, xfrm_alg_len(orig), GFP_KERNEL);
}
+static inline struct xfrm_algo_auth *xfrm_algo_auth_clone(struct xfrm_algo_auth *orig)
+{
+ return kmemdup(orig, xfrm_alg_auth_len(orig), GFP_KERNEL);
+}
+
static inline void xfrm_states_put(struct xfrm_state **states, int n)
{
int i;
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index f2f7c63..67121ce 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1110,7 +1110,7 @@ static struct xfrm_state *xfrm_state_clone(struct xfrm_state *orig, int *errp)
x->props.saddr = orig->props.saddr;
if (orig->aalg) {
- x->aalg = xfrm_algo_clone(orig->aalg);
+ x->aalg = xfrm_algo_auth_clone(orig->aalg);
if (!x->aalg)
goto error;
}
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index b95a2d6..fb42d77 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -62,6 +62,22 @@ static int verify_one_alg(struct nlattr **attrs, enum xfrm_attr_type_t type)
return 0;
}
+static int verify_auth_trunc(struct nlattr **attrs)
+{
+ struct nlattr *rt = attrs[XFRMA_ALG_AUTH_TRUNC];
+ struct xfrm_algo_auth *algp;
+
+ if (!rt)
+ return 0;
+
+ algp = nla_data(rt);
+ if (nla_len(rt) < xfrm_alg_auth_len(algp))
+ return -EINVAL;
+
+ algp->alg_name[CRYPTO_MAX_ALG_NAME - 1] = '\0';
+ return 0;
+}
+
static int verify_aead(struct nlattr **attrs)
{
struct nlattr *rt = attrs[XFRMA_ALG_AEAD];
@@ -128,7 +144,8 @@ static int verify_newsa_info(struct xfrm_usersa_info *p,
err = -EINVAL;
switch (p->id.proto) {
case IPPROTO_AH:
- if (!attrs[XFRMA_ALG_AUTH] ||
+ if ((!attrs[XFRMA_ALG_AUTH] &&
+ !attrs[XFRMA_ALG_AUTH_TRUNC]) ||
attrs[XFRMA_ALG_AEAD] ||
attrs[XFRMA_ALG_CRYPT] ||
attrs[XFRMA_ALG_COMP])
@@ -139,10 +156,12 @@ static int verify_newsa_info(struct xfrm_usersa_info *p,
if (attrs[XFRMA_ALG_COMP])
goto out;
if (!attrs[XFRMA_ALG_AUTH] &&
+ !attrs[XFRMA_ALG_AUTH_TRUNC] &&
!attrs[XFRMA_ALG_CRYPT] &&
!attrs[XFRMA_ALG_AEAD])
goto out;
if ((attrs[XFRMA_ALG_AUTH] ||
+ attrs[XFRMA_ALG_AUTH_TRUNC] ||
attrs[XFRMA_ALG_CRYPT]) &&
attrs[XFRMA_ALG_AEAD])
goto out;
@@ -152,6 +171,7 @@ static int verify_newsa_info(struct xfrm_usersa_info *p,
if (!attrs[XFRMA_ALG_COMP] ||
attrs[XFRMA_ALG_AEAD] ||
attrs[XFRMA_ALG_AUTH] ||
+ attrs[XFRMA_ALG_AUTH_TRUNC] ||
attrs[XFRMA_ALG_CRYPT])
goto out;
break;
@@ -161,6 +181,7 @@ static int verify_newsa_info(struct xfrm_usersa_info *p,
case IPPROTO_ROUTING:
if (attrs[XFRMA_ALG_COMP] ||
attrs[XFRMA_ALG_AUTH] ||
+ attrs[XFRMA_ALG_AUTH_TRUNC] ||
attrs[XFRMA_ALG_AEAD] ||
attrs[XFRMA_ALG_CRYPT] ||
attrs[XFRMA_ENCAP] ||
@@ -176,6 +197,8 @@ static int verify_newsa_info(struct xfrm_usersa_info *p,
if ((err = verify_aead(attrs)))
goto out;
+ if ((err = verify_auth_trunc(attrs)))
+ goto out;
if ((err = verify_one_alg(attrs, XFRMA_ALG_AUTH)))
goto out;
if ((err = verify_one_alg(attrs, XFRMA_ALG_CRYPT)))
@@ -229,6 +252,66 @@ static int attach_one_algo(struct xfrm_algo **algpp, u8 *props,
return 0;
}
+static int attach_auth(struct xfrm_algo_auth **algpp, u8 *props,
+ struct nlattr *rta)
+{
+ struct xfrm_algo *ualg;
+ struct xfrm_algo_auth *p;
+ struct xfrm_algo_desc *algo;
+
+ if (!rta)
+ return 0;
+
+ ualg = nla_data(rta);
+
+ algo = xfrm_aalg_get_byname(ualg->alg_name, 1);
+ if (!algo)
+ return -ENOSYS;
+ *props = algo->desc.sadb_alg_id;
+
+ p = kmalloc(sizeof(*p) + (ualg->alg_key_len + 7) / 8, GFP_KERNEL);
+ if (!p)
+ return -ENOMEM;
+
+ strcpy(p->alg_name, algo->name);
+ p->alg_key_len = ualg->alg_key_len;
+ p->alg_trunc_len = algo->uinfo.auth.icv_truncbits;
+ memcpy(p->alg_key, ualg->alg_key, (ualg->alg_key_len + 7) / 8);
+
+ *algpp = p;
+ return 0;
+}
+
+static int attach_auth_trunc(struct xfrm_algo_auth **algpp, u8 *props,
+ struct nlattr *rta)
+{
+ struct xfrm_algo_auth *p, *ualg;
+ struct xfrm_algo_desc *algo;
+
+ if (!rta)
+ return 0;
+
+ ualg = nla_data(rta);
+
+ algo = xfrm_aalg_get_byname(ualg->alg_name, 1);
+ if (!algo)
+ return -ENOSYS;
+ if (ualg->alg_trunc_len > algo->uinfo.auth.icv_fullbits)
+ return -EINVAL;
+ *props = algo->desc.sadb_alg_id;
+
+ p = kmemdup(ualg, xfrm_alg_auth_len(ualg), GFP_KERNEL);
+ if (!p)
+ return -ENOMEM;
+
+ strcpy(p->alg_name, algo->name);
+ if (!p->alg_trunc_len)
+ p->alg_trunc_len = algo->uinfo.auth.icv_truncbits;
+
+ *algpp = p;
+ return 0;
+}
+
static int attach_aead(struct xfrm_algo_aead **algpp, u8 *props,
struct nlattr *rta)
{
@@ -332,10 +415,14 @@ static struct xfrm_state *xfrm_state_construct(struct net *net,
if ((err = attach_aead(&x->aead, &x->props.ealgo,
attrs[XFRMA_ALG_AEAD])))
goto error;
- if ((err = attach_one_algo(&x->aalg, &x->props.aalgo,
- xfrm_aalg_get_byname,
- attrs[XFRMA_ALG_AUTH])))
+ if ((err = attach_auth_trunc(&x->aalg, &x->props.aalgo,
+ attrs[XFRMA_ALG_AUTH_TRUNC])))
goto error;
+ if (!x->props.aalgo) {
+ if ((err = attach_auth(&x->aalg, &x->props.aalgo,
+ attrs[XFRMA_ALG_AUTH])))
+ goto error;
+ }
if ((err = attach_one_algo(&x->ealg, &x->props.ealgo,
xfrm_ealg_get_byname,
attrs[XFRMA_ALG_CRYPT])))
@@ -548,6 +635,24 @@ static int copy_sec_ctx(struct xfrm_sec_ctx *s, struct sk_buff *skb)
return 0;
}
+static int copy_to_user_auth(struct xfrm_algo_auth *auth, struct sk_buff *skb)
+{
+ struct xfrm_algo *algo;
+ struct nlattr *nla;
+
+ nla = nla_reserve(skb, XFRMA_ALG_AUTH,
+ sizeof(*algo) + (auth->alg_key_len + 7) / 8);
+ if (!nla)
+ return -EMSGSIZE;
+
+ algo = nla_data(nla);
+ strcpy(algo->alg_name, auth->alg_name);
+ memcpy(algo->alg_key, auth->alg_key, (auth->alg_key_len + 7) / 8);
+ algo->alg_key_len = auth->alg_key_len;
+
+ return 0;
+}
+
/* Don't change this without updating xfrm_sa_len! */
static int copy_to_user_state_extra(struct xfrm_state *x,
struct xfrm_usersa_info *p,
@@ -563,8 +668,13 @@ static int copy_to_user_state_extra(struct xfrm_state *x,
if (x->aead)
NLA_PUT(skb, XFRMA_ALG_AEAD, aead_len(x->aead), x->aead);
- if (x->aalg)
- NLA_PUT(skb, XFRMA_ALG_AUTH, xfrm_alg_len(x->aalg), x->aalg);
+ if (x->aalg) {
+ if (copy_to_user_auth(x->aalg, skb))
+ goto nla_put_failure;
+
+ NLA_PUT(skb, XFRMA_ALG_AUTH_TRUNC,
+ xfrm_alg_auth_len(x->aalg), x->aalg);
+ }
if (x->ealg)
NLA_PUT(skb, XFRMA_ALG_CRYPT, xfrm_alg_len(x->ealg), x->ealg);
if (x->calg)
@@ -2117,8 +2227,11 @@ static inline size_t xfrm_sa_len(struct xfrm_state *x)
size_t l = 0;
if (x->aead)
l += nla_total_size(aead_len(x->aead));
- if (x->aalg)
- l += nla_total_size(xfrm_alg_len(x->aalg));
+ if (x->aalg) {
+ l += nla_total_size(sizeof(struct xfrm_algo) +
+ (x->aalg->alg_key_len + 7) / 8);
+ l += nla_total_size(xfrm_alg_auth_len(x->aalg));
+ }
if (x->ealg)
l += nla_total_size(xfrm_alg_len(x->ealg));
if (x->calg)
--
1.6.3.3
^ permalink raw reply related
* [PATCH] xfrm: Add SHA384 and SHA512 HMAC authentication algorithms to XFRM
From: Martin Willi @ 2009-11-25 10:58 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, netdev
These algorithms use a truncation of 192/256 bits, as specified
in RFC4868.
Signed-off-by: Martin Willi <martin@strongswan.org>
---
net/xfrm/xfrm_algo.c | 34 ++++++++++++++++++++++++++++++++++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/net/xfrm/xfrm_algo.c b/net/xfrm/xfrm_algo.c
index faf54c6..480afda 100644
--- a/net/xfrm/xfrm_algo.c
+++ b/net/xfrm/xfrm_algo.c
@@ -200,6 +200,40 @@ static struct xfrm_algo_desc aalg_list[] = {
}
},
{
+ .name = "hmac(sha384)",
+
+ .uinfo = {
+ .auth = {
+ .icv_truncbits = 192,
+ .icv_fullbits = 384,
+ }
+ },
+
+ .desc = {
+ .sadb_alg_id = SADB_X_AALG_SHA2_384HMAC,
+ .sadb_alg_ivlen = 0,
+ .sadb_alg_minbits = 384,
+ .sadb_alg_maxbits = 384
+ }
+},
+{
+ .name = "hmac(sha512)",
+
+ .uinfo = {
+ .auth = {
+ .icv_truncbits = 256,
+ .icv_fullbits = 512,
+ }
+ },
+
+ .desc = {
+ .sadb_alg_id = SADB_X_AALG_SHA2_512HMAC,
+ .sadb_alg_ivlen = 0,
+ .sadb_alg_minbits = 512,
+ .sadb_alg_maxbits = 512
+ }
+},
+{
.name = "hmac(rmd160)",
.compat = "rmd160",
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] irq: Add node_affinity CPU masks for smarter irqbalance hints
From: Peter Zijlstra @ 2009-11-25 11:18 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Peter P Waskiewicz Jr, Yong Zhang, linux-kernel@vger.kernel.org,
arjan@linux.jf.intel.com, davem@davemloft.net,
netdev@vger.kernel.org, Jesse Barnes
In-Reply-To: <alpine.LFD.2.00.0911241027140.24119@localhost.localdomain>
While we're dicking about with irq affinities, maybe we ought to
consider cpuset integration as well. There's various folks who want to
use exclusive cpusets to isolate workloads.
^ permalink raw reply
* Re: [RFC PATCH 00/10] Remove skb_dma_map/unmap calls
From: Ajit Khaparde @ 2009-11-25 11:30 UTC (permalink / raw)
To: Alexander Duyck; +Cc: mcarlson, mchan, sathyap, subbus, davem, netdev
In-Reply-To: <20091125011111.32704.3009.stgit@gitlad.jf.intel.com>
On 24/11/09 17:20 -0800, Alexander Duyck wrote:
> This patch series removes the skb_dma_map and skb_dma_unmap function calls.
> The reason for this change is because the use of skb_dma_map/unmap can lead
> to serious issues when HW IOMMU is enabled. This is because each mapping
> of the skb with a HW IOMMU enabled results in a new set of DMA mappings.
> This in turn leads to issues when skbs are cloned for uses such as
> bridging or pktgen because each transmitting device will update the skb
> shared info structure resulting in some mappings being overwritten, and others
> being freed multiple times.
If this is the case can the members related to the dma mapping stuff
(skb_shinfo(skb)->dma_maps) be moved out of this shared info structure and
we retain this "good" abstraction provided by this skb_dma_map/unmap api?
>
> I am looking for input specifically on the tg3, be2net, and bnx2 driver
> patches as I am not very familiar with them and I am not certain if
> additional changes are required.
> be2net: remove use of skb_dma_map/unmap
>
> drivers/net/benet/be_main.c | 37 ++++++---
We have pulled the be2net specific patch for testing and review.
We will send an update once done with it.
-Ajit
^ permalink raw reply
* Re: [PATCH] irq: Add node_affinity CPU masks for smarter irqbalance hints
From: Eric Dumazet @ 2009-11-25 11:35 UTC (permalink / raw)
To: Andi Kleen
Cc: David Miller, peter.p.waskiewicz.jr, peterz, arjan, yong.zhang0,
linux-kernel, arjan, netdev
In-Reply-To: <20091125103713.GF29096@one.firstfloor.org>
Andi Kleen a écrit :
> Works here
>> dmesg | grep -i node
>> [ 0.000000] SRAT: PXM 0 -> APIC 0 -> Node 0
>> [ 0.000000] SRAT: PXM 0 -> APIC 1 -> Node 0
>> [ 0.000000] SRAT: PXM 0 -> APIC 2 -> Node 0
>> [ 0.000000] SRAT: PXM 0 -> APIC 3 -> Node 0
>> [ 0.000000] SRAT: PXM 0 -> APIC 4 -> Node 0
>> [ 0.000000] SRAT: PXM 0 -> APIC 5 -> Node 0
>> [ 0.000000] SRAT: PXM 0 -> APIC 6 -> Node 0
>> [ 0.000000] SRAT: PXM 0 -> APIC 7 -> Node 0
>
> You seem to only have 8 CPUs (one socket) Normally a dual socket nehalem
> should have 16 with HyperThreading enabled.
>
> For some reason the BIOS is not reporting the other CPU.
>
> You could double check with acpidmp / iasl -d if that's
> what the BIOS really reports, but normally it should work.
>
Good Lord, I had a CONFIG_NR_CPUS=16 in my .config.
Changing to to 32 or 64 seems better :)
# dmesg | grep -i node
[ 0.000000] SRAT: PXM 0 -> APIC 0 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 1 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 2 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 3 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 4 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 5 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 6 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 7 -> Node 0
[ 0.000000] SRAT: PXM 1 -> APIC 16 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 17 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 18 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 19 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 20 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 21 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 22 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 23 -> Node 1
[ 0.000000] SRAT: Node 0 PXM 0 0-e0000000
[ 0.000000] SRAT: Node 0 PXM 0 100000000-220000000
[ 0.000000] SRAT: Node 1 PXM 1 220000000-420000000
[ 0.000000] Bootmem setup node 0 0000000000000000-0000000220000000
[ 0.000000] NODE_DATA [0000000000001000 - 0000000000005fff]
[ 0.000000] Bootmem setup node 1 0000000220000000-000000041ffff000
[ 0.000000] NODE_DATA [0000000220000000 - 0000000220004fff]
[ 0.000000] [ffffea0000000000-ffffea00087fffff] PMD -> [ffff880028600000-ffff8800305fffff] on node 0
[ 0.000000] [ffffea0008800000-ffffea00107fffff] PMD -> [ffff880220200000-ffff8802281fffff] on node 1
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[5] active PFN ranges
[ 0.000000] On node 0 totalpages: 2094543
[ 0.000000] On node 1 totalpages: 2097151
[ 0.000000] NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:32 nr_node_ids:2
[ 0.000000] SLUB: Genslabs=14, HWalign=64, Order=0-3, MinObjects=0, CPUs=32, Nodes=2
[ 0.004830] Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[ 0.007291] CPU 0/0x0 -> Node 0
[ 0.398106] CPU 1/0x10 -> Node 1
[ 0.557857] CPU 2/0x4 -> Node 0
[ 0.717609] CPU 3/0x14 -> Node 1
[ 0.877359] CPU 4/0x2 -> Node 0
[ 1.037112] CPU 5/0x12 -> Node 1
[ 1.196862] CPU 6/0x6 -> Node 0
[ 1.356614] CPU 7/0x16 -> Node 1
[ 1.516368] CPU 8/0x1 -> Node 0
[ 1.676117] CPU 9/0x11 -> Node 1
[ 1.835867] CPU 10/0x5 -> Node 0
[ 1.995619] CPU 11/0x15 -> Node 1
[ 2.155370] CPU 12/0x3 -> Node 0
[ 2.315122] CPU 13/0x13 -> Node 1
[ 2.474873] CPU 14/0x7 -> Node 0
[ 2.634624] CPU 15/0x17 -> Node 1
Thanks Andi
^ permalink raw reply
* Re: [PATCH 1/1] Defer skb allocation for both mergeable buffers and big packets in virtio_net
From: Michael S. Tsirkin @ 2009-11-25 11:40 UTC (permalink / raw)
To: Rusty Russell
Cc: Shirley Ma, Eric Dumazet, Avi Kivity, netdev, kvm, linux-kernel,
Hollis Blanchard
In-Reply-To: <200911252050.21907.rusty@rustcorp.com.au>
On Wed, Nov 25, 2009 at 08:50:21PM +1030, Rusty Russell wrote:
> On Wed, 25 Nov 2009 07:45:30 pm Michael S. Tsirkin wrote:
> > Hmm, is it really worth it to save a header copy if it's linear? We are
> > going to access it anyway, and it fits into one cacheline nicely. On
> > the other hand we have more code making life harder for compiler and
> > processor.
>
> Not sure: I think there would be many places where it would be useful.
>
> We do a similar thing in the kernel to inspect non-linear packets, and
> it's served us well.
You mean this gives measureable speedup? Okay ...
> Cheers,
> Rusty.
^ permalink raw reply
* Re: TCP sockets stalling - help! (long)
From: Ilpo Järvinen @ 2009-11-25 11:48 UTC (permalink / raw)
To: Asdo; +Cc: Netdev, e1000-devel
In-Reply-To: <4B0CB1B8.8030402@shiftmail.org>
On Wed, 25 Nov 2009, Asdo wrote:
> Hi netdev and e1000 people,
>
> I have a weird problem here.
>
> We have a Linux "Storage" server acting as a Samba, SCP and SFTP fileserver.
> All clients are Windows: XP and Vista, 32 and 64 bits. The building has
> gigabit network. We transfer up to many TB at a time.
>
> I have tried from many clients to the same Server and there is always the same
> problem: after hours that a transfer is running the TCP socket suddenly
> stalls: 0 bytes/sec. It doesn't slow down, it stalls suddenly. It never
> disconnects though.
>
> From that moment onward, the TCP socket stays in a stalling condition forever
> (I saw myself at least 10 hours) and both sides see it Established forever.
> This is in case of no other networking activity on the same network card.
> In case of other networking activity someone told me that he did see the
> transfer restart (=continue) by itself (it was an SFTP that time). I think I
> saw this phenomenon myself once during the tcpdump at the bottom of this
> email.
>
> This problem happens on every protocol (Samba, SCP, SFTP) and apparently any
> client (for sure I tested on at least 1 Vista 64bit and 1 XP 32bit).
>
> Also happens in the middle of transferring one file, so not necessarily at
> file change. The files are being pushed from the clients to the linux Server.
>
> The gigabit switch between the machines was changed 2 times (the brands also
> were different) without results.
>
> I was able to obtain apparently reliable nonstop transfer if I performed 6
> simultaneous transfers with Samba from the same client to the same server.
> OTOH with just 1 - 3 simultaneous transfers only all of them will eventually
> stall. Note that with 2 transfers the speed of each one is already smaller
> than the speed of a single transfer (approx 40+40MB/sec vs 60MB/sec) however
> with 6 transfers it's obviously much smaller (approx 6x12MB/sec). The bug
> looks like some kind of a race condition to me.
>
> On Samba another strange fact is that if there are multiple transfers (i.e. 2)
> from the same client to the same server (please note that in this case with
> Samba all transfers pass through the same TCP socket) the two transfers stall
> *independently* one to the other. First after a random time you see one
> stalling, and eventually after another random time also the other one stalls.
> This tells that the socket actually kinda works... I can even stop one stalled
> transfer from the client (the stop operation *works* and gets a reply from the
> Samba server: I see messages sniffing the Ethernet), and start it again and it
> would run, and the TCP socket is always the same when I restart the transfer.
>
> I obtained apparently reliable transfers with Samba if I introduced rate
> limiting on our SMC 8024L2 gigabit switch . Even if the rate limiting was set
> so high (930Mbps) that the transfer speed was actually not influenced, the
> Samba transfer (1 single transfer, not multiple) apparently worked reliably.
> Maybe this helps with the race condition by separating packets better. The
> SFTP protocol hanged anyway though, even on rate limiting, however consider
> that SFTP from windows goes very slow at 15Mbps due to a problem of encryption
> performance of WinSCP, so that one is really way lower than the rate limit and
> its packets might not get separated.
>
> The server is a linux Ubuntu 9.10 with kernel ubuntu 2.6.31-14-server . The
> ethernets are two integrated Intels (I tested both ethernet ports):
> Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller
> (Copper) (rev 01)
> the driver is kernel's e1000
>
> This is the stack trace of server processes (Server side) during an SFTP
> stall:
>
> root 327 [CUT] \_ sshd: myuser [priv]
> 1011 380 [CUT] \_ sshd: myuser
> 1011 382 [CUT] \_ /usr/lib/openssh/sftp-server
>
> root@mystorage:/proc# cat /proc/327/stack (this is sshd)
> [<ffffffff814b428a>] unix_stream_data_wait+0xaa/0x110
> [<ffffffff814b50cd>] unix_stream_recvmsg+0x36d/0x570
> [<ffffffff81426399>] sock_aio_read+0x149/0x150
> [<ffffffff8111e232>] do_sync_read+0xf2/0x130
> [<ffffffff8111e8e1>] vfs_read+0x181/0x1a0
> [<ffffffff8111edec>] sys_read+0x4c/0x80
> [<ffffffff81011fc2>] system_call_fastpath+0x16/0x1b
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> root@mystorage:/proc# cat /proc/380/stack (this is the second sshd)
> [<ffffffff8112e644>] poll_schedule_timeout+0x34/0x50
> [<ffffffff8112ef4f>] do_select+0x58f/0x6b0
> [<ffffffff8112f8b5>] core_sys_select+0x185/0x2b0
> [<ffffffff8112fc32>] sys_select+0x42/0x110
> [<ffffffff81011fc2>] system_call_fastpath+0x16/0x1b
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> root@mystorage:/proc# cat /proc/382/stack (this is sftp-server)
> [<ffffffff8112e644>] poll_schedule_timeout+0x34/0x50
> [<ffffffff8112ef4f>] do_select+0x58f/0x6b0
> [<ffffffff8112f8b5>] core_sys_select+0x185/0x2b0
> [<ffffffff8112fc32>] sys_select+0x42/0x110
> [<ffffffff81011fc2>] system_call_fastpath+0x16/0x1b
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> so everything seems normal, it just seems the socket is waiting for data...
>
> I am really puzzled because... I don't know how the Samba protocol works, but
> for SFTP which I believe is a simple protocol, I believe the client is just
> pushing raw bytes onto a simple TCP socket so it should keep doing that while
> it receives Acks. OTOH if it does not receive Acks the socket would
> disconnect. However in my case during a stall the socket stays Established (I
> checked at BOTH sides!) but the client stops pushing bytes to the server.
> (That's for a stall in the middle of a file on SFTP protocol, which *does*
> happen) How on earth can that be?? (update: see tcpdump below, it might
> explain)
>
> I am also thinking at a hardware problem. The server is running on a Tyan
> mainboard S5396WA2NRF and we had another problem with this computer (mobo?),
> apparently hardware related, with 3ware disk controllers, same problem as this
> guy also running another Tyan:
> http://www.webhostingtalk.com/archive/index.php/t-449670.html
> which I thought might be reconducible to a lost interrupt. Even on a lost
> interrupt I can't understand how to solve the Ack puzzle... this is not a TOE
> network card!
>
> This is what I did try up to now (and didn't help):
> Changed some Samba parameters trying various values (clearly not useful for
> SFTP btw). I ended up with a pretty common configuration, which anyway didn't
> help:
> socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=8192 SO_SNDBUF=8192
> read raw = yes
> write raw = yes
> kernel oplocks = yes
> max xmit = 2048
> getwd cache = yes
>
>
> Changed the following parameters in /proc/sys/net:
> 1 -> 0 > ipv6/bindv6only (for Samba but it was bound already and I couldn't
> reboot. SFTP tests were done in IPv4 though)
> 1 -> 0 > tcp_sack
> 1 -> 0 > tcp_dsack
> 0 -> 1 > tcp_low_latency
> 2 -> 0 > tcp_frto
> cubic -> reno > tcp_congestion_control
> 3 -> 6 > tcp_retries1
> 3 -> 10 > tcp_tso_win_divisor
> 1 -> 0 > tcp_slow_start_after_idle
>
>
> Then I disabled the following offloads using ethtool:
> rx-checksumming on --> off
> tx-checksumming on --> off
> scatter-gather on --> off
> tcp-segmentation-offload: on --> off
> generic-segmentation-offload: on --> off
>
> Nothing helped.
>
>
> This is the SFTP socket when it's running (Server side):
> # cat /proc/net/tcp
> 2: 0F12A8C0:0016 2612A8C0:C0C6 01 00000000:00000000 02:000AB698 00000000
> 0 0 267816 4 ffff88084b1e6180 24 4 1 11 -1
>
> Later on, when it has been stuck for a while:
> # cat /proc/net/tcp
> 2: 0F12A8C0:0016 2612A8C0:C0C6 01 00000000:00000000 02:0002AC6B 00000000
> 0 0 267816 2 ffff88084b1e6180 27 4 1 21 -1
> (numbers reference:
> http://www.mjmwired.net/kernel/Documentation/networking/proc_net_tcp.txt )
>
> as you can see from the last values, the timeout and window have enlarged a
> bit, but nothing dramatic. Apparently they are very similar.
This end has no data to send (the numbers after " 01 ", first one is the
size of the send queue), so it is correct behavior from TCP side.
> This is another SFTP stall after I disabled the offloading via ethtool:
> (different transfer, different socket from above)
> 2: 0F12A8C0:0016 2512A8C0:09BC 01 00000000:00000000 02:000602F4 00000000
> 0 0 5301100 2 ffff88084ac02080 28 4 0 13 -1
> so the values are similar again, apart the ack.pingpong which has become 0
> (something to do with offloading?)
Likewise, no data to send here either at the moment you took this snippet.
> This night I decided to actually tcpdump some traffic at the server side. This
> dump has a chance of being incorrect/misleading because the client I could use
> was already transferring other stuff to the server via Samba. I used SFTP
> protocol for this test but due to the simultaneous Samba transfer I could not
> obtain a long SFTP hangup. The longest hangup I obtained is 1 minute. I hope
> this is really a manifestation of the bug in question, and not a simple
> temporary starvation at server side.
>
> Here is the relevant excerpt:
> 00:54:36.303031 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [P.], seq
> 12309129:12309229, ack 997119732, win 65535, length 100
> 00:54:36.303216 IP 192.168.18.37.3418 > 192.168.18.15.22: Flags [P.], seq
> 997119732:997120040, ack 12309229, win 64871, length 308
> 00:54:36.303450 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [P.], seq
> 12309229:12309297, ack 997120040, win 65535, length 68
> 00:54:36.303566 IP 192.168.18.37.3418 > 192.168.18.15.22: Flags [P.], seq
> 997120040:997120228, ack 12309297, win 64803, length 188
> 00:54:36.303645 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [P.], seq
> 12309297:12309365, ack 997120228, win 65535, length 68
> 00:54:36.304414 IP 192.168.18.37.3418 > 192.168.18.15.22: Flags [P.], seq
> 997120228:997120432, ack 12309365, win 64735, length 204
> 00:54:36.345583 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [.], ack
> 997120432, win 65535, length 0 *** PROBLEM IS HERE ***
> 00:55:27.171687 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [P.], seq
> 12309365:12309425, ack 997120432, win 65535, length 60
> 00:55:27.342682 IP 192.168.18.37.3418 > 192.168.18.15.22: Flags [P.], seq
> 997120432:997120944, ack 12309425, win 64675, length 512
> 00:55:27.342726 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [.], ack
> 997120944, win 65535, length 0
> 00:55:27.342775 IP 192.168.18.37.3418 > 192.168.18.15.22: Flags [.], seq
> 997120944:997122404, ack 12309425, win 64675, length 1460
> 00:55:27.342787 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [.], ack
> 997122404, win 65535, length 0
> 00:55:27.342792 IP 192.168.18.37.3418 > 192.168.18.15.22: Flags [P.], seq
> 997122404:997122612, ack 12309425, win 64675, length 208
> 00:55:27.342795 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [.], ack
> 997122612, win 65535, length 0
>
> It seems to me the TCP stack at the Server returns an ack to the client but
> waits 1 minutes before being able to give the further 60 bytes to the client
> (these are application-generated bytes, right?) which are probably needed at
> client-side for the functioning of the SFTP protocol.
> I suspect the SFTP-server application receives the last client data just at
> the end of the minute of delay (at 00:55:27.1something)
> Probably if the dump was made without concomitant Samba activity, the
> sftp-server application would have never received such last client bytes and
> that's why the hangup lasts forever.
> However the TCP socket remains established because the TCP stack works and
> acks are sent properly
> Could this be a good interpretation of the bug?
>
> I don't know what are those 60 bytes though, can you confirm is it a part of
> the SFTP or SSH protocol?
>
> I observed other similar micro-hangups:
> ...
> 00:50:59.210115 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [.], ack
> 3346661444, win 65535, length 0
> 00:51:14.137978 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [P.], seq
> 7757313:7757457, ack 3346661444, win 65535, length 144
> ...
> 00:52:02.495785 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [P.], seq
> 8612969:8613037, ack 3711382248, win 65535, length 68
> 00:52:02.507752 IP 192.168.18.37.3418 > 192.168.18.15.22: Flags [P.], seq
> 3711382248:3711382452, ack 8613037, win 65399, length 204
> 00:52:02.545585 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [.], ack
> 3711382452, win 65535, length 0
> 00:52:14.568489 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [P.], seq
> 8613037:8613097, ack 3711382452, win 65535, length 60
> 00:52:14.572162 IP 192.168.18.37.3418 > 192.168.18.15.22: Flags [P.], seq
> 3711382452:3711382964, ack 8613097, win 65339, length 512
> 00:52:14.572184 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [.], ack
> 3711382964, win 65535, length 0
> 00:52:14.572312 IP 192.168.18.37.3418 > 192.168.18.15.22: Flags [.], seq
> 3711382964:3711384424, ack 8613097, win 65339, length 1460
> ...
> 00:55:30.464957 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [.], ack
> 1040635920, win 65535, length 0
> 00:55:32.230205 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [P.], seq
> 12410749:12410809, ack 1040635920, win 65535, length 60
> ...
> 00:55:54.404027 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [.], ack
> 1362376840, win 65535, length 0
> 00:56:08.349224 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [P.], seq
> 13157437:13157497, ack 1362376840, win 65535, length 60
> ...
> 00:56:28.494333 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [.], ack
> 1424904580, win 65535, length 0
> 00:56:31.450352 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [P.], seq
> 13307333:13307393, ack 1424904580, win 65535, length 60
>
> Update: actually I just found a disk performance problem at Server side so
> that the disks couldn't go faster than 70MB/sec (stripe_cache_size was too low
> and readahead was too low), and I'm thinking if this could be the reason for
> indeed triggering the bug: if there was a starvation of the TCP/IP stack or
> network card driver at the wrong time (because i.e. the CPUs are doing
> something else like accessing the disks), could that prevent the 60-bytes
> packet from ever being transmitted...? (in case of no other incoming ethernet
> packets which can give the TCPIP or e1000 driver a second chance to run)
...I'd next try strace the sftp server to see what it was doing
during the stall.
--
i.
^ permalink raw reply
* Re: [PATCH] irq: Add node_affinity CPU masks for smarter irqbalance hints
From: Andi Kleen @ 2009-11-25 11:50 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andi Kleen, David Miller, peter.p.waskiewicz.jr, peterz, arjan,
yong.zhang0, linux-kernel, arjan, netdev
In-Reply-To: <4B0D1667.8050506@gmail.com>
On Wed, Nov 25, 2009 at 12:35:03PM +0100, Eric Dumazet wrote:
> > You seem to only have 8 CPUs (one socket) Normally a dual socket nehalem
> > should have 16 with HyperThreading enabled.
> >
> > For some reason the BIOS is not reporting the other CPU.
> >
> > You could double check with acpidmp / iasl -d if that's
> > what the BIOS really reports, but normally it should work.
> >
>
> Good Lord, I had a CONFIG_NR_CPUS=16 in my .config.
That should be enough for a two socket (2S x 4C x 2T) today,
but of course that will eventually change too.
> Changing to to 32 or 64 seems better :)
That looks weird. It should have worked with CONFIG_NR_CPUS==16 too,
because you only have 16 CPUs and the NR_CPUS should affect APIC
ranges etc.
Something still fishy. I would properly report it.
BTW kernel should give some error message in any case when
there are not enough CPUs I guess.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: [PATCH 0/3] xfrm: Custom truncation lengths for authentication algorithms
From: Herbert Xu @ 2009-11-25 12:10 UTC (permalink / raw)
To: Martin Willi; +Cc: linux-crypto, netdev, David S. Miller
In-Reply-To: <cover.1259142145.git.martin@strongswan.org>
On Wed, Nov 25, 2009 at 11:29:50AM +0100, Martin Willi wrote:
> The following patchset adds support for defining truncation lengths
> for authentication algorithms in userspace. The main purpose for this
> is to support SHA256 in IPsec using the standardized 128 bit
> instead of the currently used 96 bit truncation.
>
> Martin Willi (3):
> xfrm: Define new XFRM netlink auth attribute with specified
> truncation bits
> xfrm: Store aalg in xfrm_state with a user specified truncation
> length
> xfrm: Use the user specified truncation length in ESP and AH
Looks great to me. Thanks Martin!
--
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: Add SHA384 and SHA512 HMAC authentication algorithms to XFRM
From: Herbert Xu @ 2009-11-25 12:11 UTC (permalink / raw)
To: Martin Willi; +Cc: linux-crypto, netdev, David S. Miller
In-Reply-To: <1259146719-16359-1-git-send-email-martin@strongswan.org>
On Wed, Nov 25, 2009 at 11:58:39AM +0100, Martin Willi wrote:
> These algorithms use a truncation of 192/256 bits, as specified
> in RFC4868.
>
> Signed-off-by: Martin Willi <martin@strongswan.org>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
--
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: TCP sockets stalling - help! (long)
From: Asdo @ 2009-11-25 13:07 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: e1000-devel, Netdev
In-Reply-To: <alpine.DEB.2.00.0911251344520.7024@wel-95.cs.helsinki.fi>
Ilpo Järvinen wrote:
> ...I'd next try strace the sftp server to see what it was doing
> during the stall.
>
Thanks for your help Ilpo
Isn't the strace equivalent to the stack trace I obtained via cat
/proc/pid/stack reported previously? That was at the time of the stall
I'm thinking the strace would slow down sftp-server very deeply...
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply
* Re: dmfe/tulip device id overlap
From: Ben Hutchings @ 2009-11-25 13:08 UTC (permalink / raw)
To: Brandon Philips
Cc: netdev, Tobias Ringstrom, Grant Grundler, Kyle McMartin, davem
In-Reply-To: <20091125043603.GK14043@jenkins.home.ifup.org>
[-- Attachment #1: Type: text/plain, Size: 666 bytes --]
On Tue, 2009-11-24 at 20:36 -0800, Brandon Philips wrote:
> Hello All-
>
> dmfe and tulip have an overlap of device IDs and it has been discussed
> before without resolution[1][2].
>
> The device ID in particular is:
>
> { 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
> { 0x1282, 0x9102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
>
> Users of Fedora[3] and openSUSE[4] are feeling pain from this but
> Ubuntu users are avoiding the issue do to the patch below.
[...]
Also an open bug in Debian (#515533). Thanks for pushing this issue.
Ben.
--
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [patch]USB autosuspend for cdc-ether
From: Steve.Glendinning-sdUf+H5yV5I @ 2009-11-25 13:29 UTC (permalink / raw)
To: Oliver Neukum
Cc: David S. Miller, David Brownell, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz, Torgny Johansson
In-Reply-To: <200911250939.33127.oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org> wrote on 25/11/2009 08:39:33:
> Hi,
>
> this version should fix what you mentioned.
Thanks, it does.
checkpatch.pl still shows 31 errors though, mostly trailing whitespace,
and the patch doesn't cleanly apply to net-next-2.6. Two hunks fail to
apply in cdc_ether.c.
Steve
--
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
* Adding IP(v6) address with scope link creates global address
From: Andreas Henriksson @ 2009-11-25 13:59 UTC (permalink / raw)
To: netdev
Hello!
"Jedasothi" reported problems setting scope with iproute on newly added
ipv6 addresses in:
https://bugs.launchpad.net/ubuntu/+source/iproute/+bug/487745
> To reproduce bug run
> ip addr add '::4/64' scope link dev eth0
>
> This results in a line seen with
> ip addr show eth0
> inet6 ::4/64 scope global tentative
>
> The label "global" is seen instead of "link".
This works for me on ipv4 and seems to be only a problem with ipv6.
I think this is a kernel bug. The scope seems to be passed into the
kernel via netlink as specified on the command line.
Looking at the kernel, inet6_rtm_newaddr [1] calls inet6_addr_add [2]
without passing the ifa_scope struct member and then the scope is
generated from the address within the inet6_addr_add function.
It would be nice if someone could verify this and while at it
also whip up a patch and forward to the right person. ;)
[1]: http://lxr.linux.no/#linux+v2.6.31/net/ipv6/addrconf.c#L3263
[2]: http://lxr.linux.no/#linux+v2.6.31/net/ipv6/addrconf.c#L2081
--
Andreas Henriksson
^ permalink raw reply
* [PATCH] Frame Relay/DLCI coding style corrections.
From: Rudy Matela @ 2009-11-25 14:01 UTC (permalink / raw)
To: mike.mclagan, netdev; +Cc: trivial, linux-kernel
Frame Relay/DLCI coding style corrections.
Added a space separating some keywords (if/while) from the following
parenthesis to conform to the CodingStyle.
Signed-off-by: Rudy Matela <rudy.matela@gmail.com>
---
diff --git a/drivers/net/wan/dlci.c b/drivers/net/wan/dlci.c
index 15d353f..421d071 100644
--- a/drivers/net/wan/dlci.c
+++ b/drivers/net/wan/dlci.c
@@ -77,7 +77,7 @@ static int dlci_header(struct sk_buff *skb, struct net_device *dev,
dlp = netdev_priv(dev);
hdr.control = FRAD_I_UI;
- switch(type)
+ switch (type)
{
case ETH_P_IP:
hdr.IP_NLPID = FRAD_P_IP;
@@ -130,7 +130,7 @@ static void dlci_receive(struct sk_buff *skb, struct net_device *dev)
dev->stats.rx_errors++;
}
else
- switch(hdr->IP_NLPID)
+ switch (hdr->IP_NLPID)
{
case FRAD_P_PADDING:
if (hdr->NLPID != FRAD_P_SNAP)
@@ -208,7 +208,7 @@ static int dlci_config(struct net_device *dev, struct dlci_conf __user *conf, in
if (!get)
{
- if(copy_from_user(&config, conf, sizeof(struct dlci_conf)))
+ if (copy_from_user(&config, conf, sizeof(struct dlci_conf)))
return -EFAULT;
if (config.flags & ~DLCI_VALID_FLAGS)
return(-EINVAL);
@@ -222,7 +222,7 @@ static int dlci_config(struct net_device *dev, struct dlci_conf __user *conf, in
if (get)
{
- if(copy_to_user(conf, &dlp->config, sizeof(struct dlci_conf)))
+ if (copy_to_user(conf, &dlp->config, sizeof(struct dlci_conf)))
return -EFAULT;
}
@@ -238,7 +238,7 @@ static int dlci_dev_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
dlp = netdev_priv(dev);
- switch(cmd)
+ switch (cmd)
{
case DLCI_GET_SLAVE:
if (!*(short *)(dev->dev_addr))
@@ -417,7 +417,7 @@ static int dlci_ioctl(unsigned int cmd, void __user *arg)
if (!capable(CAP_NET_ADMIN))
return(-EPERM);
- if(copy_from_user(&add, arg, sizeof(struct dlci_add)))
+ if (copy_from_user(&add, arg, sizeof(struct dlci_add)))
return -EFAULT;
switch (cmd)
@@ -426,7 +426,7 @@ static int dlci_ioctl(unsigned int cmd, void __user *arg)
err = dlci_add(&add);
if (!err)
- if(copy_to_user(arg, &add, sizeof(struct dlci_add)))
+ if (copy_to_user(arg, &add, sizeof(struct dlci_add)))
return -EFAULT;
break;
^ permalink raw reply related
* Re: large packet loss take2 2.6.31.x
From: Caleb Cushing @ 2009-11-25 14:06 UTC (permalink / raw)
To: Jarek Poplawski
Cc: e1000-devel, netdev, Frans Pop, Jesse Brandeburg, linux-kernel,
Andi Kleen, Jeff Kirsher
In-Reply-To: <20091124111946.GA7883@ff.dom.local>
> Alas it's not all information I asked. E.g. "netstat -s before faulty
> kernel" and "netstat -s after faulty kernel" seem to be the same file:
> netstat_after.slave4.log.gz.
sorry I guess I misunderstood what you wanted? (or maybe I just dorked
it when I created all the files) I upped a netstat -s from a good
kernel shortly after reboot.
> Anyway, since there are problems with
> getting stats from the router we still can't compare them, or check
> for the dropped stats. (Btw, could you check for /proc/net/softnet_stat
> yet?)
router? good kernel? bad kernel?
> So, it might be the kernel problem you reported, but there is not
> enough data to prove it. Then my proposal is to try to repeat this
> problem in more "testing friendly" conditions - preferably against
> some other, more up-to-date linux box, if possible?
yeah 2.6.31.6 works on my laptop fine I'll just have to see about
getting a direct connection to it. probably do that after I bring the
other NIC back from home, on thanksgiving.
--
Caleb Cushing
http://xenoterracide.blogspot.com
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply
* [PATCH net-next-2.6] pktgen: NUMA aware
From: Eric Dumazet @ 2009-11-25 15:01 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List, Andi Kleen
Now my Nehalem dev machine is truly NUMA, time for new patches :)
David, this applies on last pktgen version (after last patches you added in net-2.6).
Thanks
[PATCH net-next-2.6] pktgen: NUMA aware
pktgen threads are bound to given CPU, we can allocate memory for
these threads in a NUMA aware way.
After a pktgen session on two threads, we can check flows memory was
allocated on right node, instead of a not related one.
# grep pktgen_thread_write /proc/vmallocinfo
0xffffc90007204000-0xffffc90007385000 1576960 pktgen_thread_write+0x3a4/0x6b0 [pktgen] pages=384 vmalloc N0=384
0xffffc90007386000-0xffffc90007507000 1576960 pktgen_thread_write+0x3a4/0x6b0 [pktgen] pages=384 vmalloc N1=384
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/pktgen.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 6e79e96..f4f4c50 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -3622,6 +3622,7 @@ static int pktgen_add_device(struct pktgen_thread *t, const char *ifname)
{
struct pktgen_dev *pkt_dev;
int err;
+ int node = cpu_to_node(t->cpu);
/* We don't allow a device to be on several threads */
@@ -3631,12 +3632,13 @@ static int pktgen_add_device(struct pktgen_thread *t, const char *ifname)
return -EBUSY;
}
- pkt_dev = kzalloc(sizeof(struct pktgen_dev), GFP_KERNEL);
+ pkt_dev = kzalloc_node(sizeof(struct pktgen_dev), GFP_KERNEL, node);
if (!pkt_dev)
return -ENOMEM;
strcpy(pkt_dev->odevname, ifname);
- pkt_dev->flows = vmalloc(MAX_CFLOWS * sizeof(struct flow_state));
+ pkt_dev->flows = vmalloc_node(MAX_CFLOWS * sizeof(struct flow_state),
+ node);
if (pkt_dev->flows == NULL) {
kfree(pkt_dev);
return -ENOMEM;
@@ -3698,7 +3700,8 @@ static int __init pktgen_create_thread(int cpu)
struct proc_dir_entry *pe;
struct task_struct *p;
- t = kzalloc(sizeof(struct pktgen_thread), GFP_KERNEL);
+ t = kzalloc_node(sizeof(struct pktgen_thread), GFP_KERNEL,
+ cpu_to_node(cpu));
if (!t) {
printk(KERN_ERR "pktgen: ERROR: out of memory, can't "
"create new thread.\n");
^ permalink raw reply related
* Re: TCP sockets stalling - help! (long)
From: Asdo @ 2009-11-25 15:36 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: e1000-devel, Netdev
In-Reply-To: <4B0D2C0E.9050101@shiftmail.org>
[-- Attachment #1.1: Type: text/plain, Size: 3381 bytes --]
Asdo wrote:
> Ilpo Järvinen wrote:
>
>> ...I'd next try strace the sftp server to see what it was doing
>> during the stall.
>>
>>
> Thanks for your help Ilpo
>
> Isn't the strace equivalent to the stack trace I obtained via cat
> /proc/pid/stack reported previously? That was at the time of the stall
>
> I'm thinking the strace would slow down sftp-server very deeply...
>
I found out that if I attach the strace I can see at least the last
function call.
The SFTP it's hanged right now so I did that:
root@mystorage:/root# strace -p 11475
Process 11475 attached - interrupt to quit
select(5, [3], [], NULL, NULL
(stuck here forever... doesn't move)
(it's strange the first option of select is 5, shouldn't it be 4 from
man select? A bug of strace maybe?)
root@mystorage:/root# cat /proc/11475/stack
[<ffffffff8112e644>] poll_schedule_timeout+0x34/0x50
[<ffffffff8112ef4f>] do_select+0x58f/0x6b0
[<ffffffff8112f8b5>] core_sys_select+0x185/0x2b0
[<ffffffff8112fc32>] sys_select+0x42/0x110
[<ffffffff8101225b>] tracesys+0xd9/0xde
[<ffffffffffffffff>] 0xffffffffffffffff
And this is from cat /proc/net/tcp
2: 0F12A8C0:0016 2512A8C0:0FBD 01 00000000:00000000 02:00009144
00000000 0 0 5326251 2 ffff88085408ce00 26 4 1 9 4
The select refers to open files so here they are:
root@mystorage:/proc/11475/fd# ll
total 0
lr-x------ 1 ccosentino wetlab 64 2009-11-25 14:43 0 -> pipe:[5326309]
l-wx------ 1 ccosentino wetlab 64 2009-11-25 14:43 1 -> pipe:[5326310]
l-wx------ 1 ccosentino wetlab 64 2009-11-25 14:43 2 -> pipe:[5326311]
lr-x------ 1 ccosentino wetlab 64 2009-11-25 14:43 3 -> pipe:[5326309]
l-wx------ 1 ccosentino wetlab 64 2009-11-25 14:43 4 -> pipe:[5326310]
l-wx------ 1 ccosentino wetlab 64 2009-11-25 14:43 5 ->
/path/to/file_being_saved.filepart
I tried to send SIGSTOP and then SIGCONT to see if I could make it make
a loop and then reenter into the select. I'm not sure it really did
that, what do you think? This is the strace:
root@mystorage:/root# strace -p 11475 2>&1 | tee sftpstrace.dmp
Process 11475 attached - interrupt to quit
select(5, [3], [], NULL, NULL) = ? ERESTARTNOHAND (To be restarted)
--- SIGSTOP (Stopped (signal)) @ 0 (0) ---
--- SIGSTOP (Stopped (signal)) @ 0 (0) ---
select(5, [3], [], NULL, NULL) = ? ERESTARTNOHAND (To be restarted)
--- SIGCONT (Continued) @ 0 (0) ---
select(5, [3], [], NULL, NULL
(hanged again here)
Do you think this info is enough or I really have to strace it since the
beginning?
If it is a race condition it might not happen if the sftp-server is
deeply slowed down by the strace.
If I had a way to make it continue right now we could get the rest of
the strace... But it's not so easy, I tried starting a Samba transfer
but it did not unlock the SFTP this time. SIGSTOP + SIGCONT also didn't
work.
BTW people using the Storage also experienced data loss while pushing
files in it: appartently data disappeared from the middle of a file they
were saving to the Storage.
To me looks like another hint that application-level data which has been
received via network by TCP stack is trapped there and not being pushed
to the application.
Or the data might even be trapped into the anonymous sockets between
sshd and sftp-server.
Thanks for your help
[-- Attachment #2: Type: text/plain, Size: 354 bytes --]
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
[-- Attachment #3: Type: text/plain, Size: 164 bytes --]
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
^ permalink raw reply
* netfilter hooks for IFB device
From: François Delawarde @ 2009-11-25 15:30 UTC (permalink / raw)
To: netdev
Hi,
I'm interested in adding optional netfilter hooks to the IFB device
(enabled by module param), in order to have full IMQ functionality (to
use CONNMARKs and others) without having to add any iptables or
netfilter target.
I'm aiming for something very simple inspired by this older IMQ
implementation:
http://pupa.da.ru/imq/imq.c
The only thing is, I have no idea what to do in the callback function
once the netfilter hooks are registered.
How can I 'steal' the packet in the hook and make it pass through
ifb_xmit to have it enqueued?
Thanks,
François.
^ permalink raw reply
* Re: [patch]USB autosuspend for cdc-ether
From: Oliver Neukum @ 2009-11-25 16:21 UTC (permalink / raw)
To: Steve.Glendinning-sdUf+H5yV5I
Cc: David S. Miller, David Brownell, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz, Torgny Johansson
In-Reply-To: <OF4FE9C59B.DA63AAE2-ON80257679.0046C1C2-80257679.004A1287-sdUf+H5yV5I@public.gmane.org>
Am Mittwoch, 25. November 2009 14:29:00 schrieb Steve.Glendinning-sdUf+H5yV5I@public.gmane.org:
> Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org> wrote on 25/11/2009 08:39:33:
> > Hi,
> >
> > this version should fix what you mentioned.
>
> Thanks, it does.
>
> checkpatch.pl still shows 31 errors though, mostly trailing whitespace,
> and the patch doesn't cleanly apply to net-next-2.6. Two hunks fail to
> apply in cdc_ether.c.
Here we go again. The script complains still a bt but that's necessary
to keep a uniform style. Happy with this version?
Against net-next-2.6.
Regards
Oliver
--
commit ab6d67f2f64f087c15c9899447cc297f7fd2e7b2
Author: Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
Date: Wed Nov 25 16:45:58 2009 +0100
usbnet & cdc-ether: autosuspend for online devices
using remote wakeup and delayed transmission to allow
online device to go into usb autosuspend
minimal alternate support for devices that don't support
remote wakeup
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 71e65fc..b9493ef 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -411,6 +411,12 @@ static int cdc_bind(struct usbnet *dev, struct usb_interface *intf)
return 0;
}
+static int cdc_manage_power(struct usbnet *dev, int on)
+{
+ dev->intf->needs_remote_wakeup = on;
+ return 0;
+}
+
static const struct driver_info cdc_info = {
.description = "CDC Ethernet Device",
.flags = FLAG_ETHER,
@@ -418,6 +424,7 @@ static const struct driver_info cdc_info = {
.bind = cdc_bind,
.unbind = usbnet_cdc_unbind,
.status = cdc_status,
+ .manage_power = cdc_manage_power,
};
static const struct driver_info mbm_info = {
@@ -578,6 +585,7 @@ static struct usb_driver cdc_driver = {
.disconnect = usbnet_disconnect,
.suspend = usbnet_suspend,
.resume = usbnet_resume,
+ .supports_autosuspend = 1,
};
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 378da8c..83cdd46 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -353,7 +353,8 @@ static void rx_submit (struct usbnet *dev, struct urb *urb, gfp_t flags)
if (netif_running (dev->net)
&& netif_device_present (dev->net)
- && !test_bit (EVENT_RX_HALT, &dev->flags)) {
+ && !test_bit (EVENT_RX_HALT, &dev->flags)
+ && !test_bit (EVENT_DEV_ASLEEP, &dev->flags)) {
switch (retval = usb_submit_urb (urb, GFP_ATOMIC)) {
case -EPIPE:
usbnet_defer_kevent (dev, EVENT_RX_HALT);
@@ -611,15 +612,39 @@ EXPORT_SYMBOL_GPL(usbnet_unlink_rx_urbs);
/*-------------------------------------------------------------------------*/
// precondition: never called in_interrupt
+static void usbnet_terminate_urbs(struct usbnet *dev)
+{
+ DECLARE_WAIT_QUEUE_HEAD_ONSTACK(unlink_wakeup);
+ DECLARE_WAITQUEUE(wait, current);
+ int temp;
+
+ /* ensure there are no more active urbs */
+ add_wait_queue(&unlink_wakeup, &wait);
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ dev->wait = &unlink_wakeup;
+ temp = unlink_urbs(dev, &dev->txq) +
+ unlink_urbs(dev, &dev->rxq);
+
+ /* maybe wait for deletions to finish. */
+ while (!skb_queue_empty(&dev->rxq)
+ && !skb_queue_empty(&dev->txq)
+ && !skb_queue_empty(&dev->done)) {
+ schedule_timeout(UNLINK_TIMEOUT_MS);
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ if (netif_msg_ifdown(dev))
+ devdbg(dev, "waited for %d urb completions",
+ temp);
+ }
+ set_current_state(TASK_RUNNING);
+ dev->wait = NULL;
+ remove_wait_queue(&unlink_wakeup, &wait);
+}
int usbnet_stop (struct net_device *net)
{
struct usbnet *dev = netdev_priv(net);
struct driver_info *info = dev->driver_info;
- int temp;
int retval;
- DECLARE_WAIT_QUEUE_HEAD_ONSTACK (unlink_wakeup);
- DECLARE_WAITQUEUE (wait, current);
netif_stop_queue (net);
@@ -641,25 +666,8 @@ int usbnet_stop (struct net_device *net)
info->description);
}
- if (!(info->flags & FLAG_AVOID_UNLINK_URBS)) {
- /* ensure there are no more active urbs */
- add_wait_queue(&unlink_wakeup, &wait);
- dev->wait = &unlink_wakeup;
- temp = unlink_urbs(dev, &dev->txq) +
- unlink_urbs(dev, &dev->rxq);
-
- /* maybe wait for deletions to finish. */
- while (!skb_queue_empty(&dev->rxq)
- && !skb_queue_empty(&dev->txq)
- && !skb_queue_empty(&dev->done)) {
- msleep(UNLINK_TIMEOUT_MS);
- if (netif_msg_ifdown(dev))
- devdbg(dev, "waited for %d urb completions",
- temp);
- }
- dev->wait = NULL;
- remove_wait_queue(&unlink_wakeup, &wait);
- }
+ if (!(info->flags & FLAG_AVOID_UNLINK_URBS))
+ usbnet_terminate_urbs(dev);
usb_kill_urb(dev->interrupt);
@@ -672,7 +680,10 @@ int usbnet_stop (struct net_device *net)
dev->flags = 0;
del_timer_sync (&dev->delay);
tasklet_kill (&dev->bh);
- usb_autopm_put_interface(dev->intf);
+ if (info->manage_power)
+ info->manage_power(dev, 0);
+ else
+ usb_autopm_put_interface(dev->intf);
return 0;
}
@@ -753,6 +764,12 @@ int usbnet_open (struct net_device *net)
// delay posting reads until we're fully open
tasklet_schedule (&dev->bh);
+ if (info->manage_power) {
+ retval = info->manage_power(dev, 1);
+ if (retval < 0)
+ goto done;
+ usb_autopm_put_interface(dev->intf);
+ }
return retval;
done:
usb_autopm_put_interface(dev->intf);
@@ -881,11 +898,16 @@ kevent (struct work_struct *work)
/* usb_clear_halt() needs a thread context */
if (test_bit (EVENT_TX_HALT, &dev->flags)) {
unlink_urbs (dev, &dev->txq);
+ status = usb_autopm_get_interface(dev->intf);
+ if (status < 0)
+ goto fail_pipe;
status = usb_clear_halt (dev->udev, dev->out);
+ usb_autopm_put_interface(dev->intf);
if (status < 0
&& status != -EPIPE
&& status != -ESHUTDOWN) {
if (netif_msg_tx_err (dev))
+fail_pipe:
deverr (dev, "can't clear tx halt, status %d",
status);
} else {
@@ -896,11 +918,16 @@ kevent (struct work_struct *work)
}
if (test_bit (EVENT_RX_HALT, &dev->flags)) {
unlink_urbs (dev, &dev->rxq);
+ status = usb_autopm_get_interface(dev->intf);
+ if (status < 0)
+ goto fail_halt;
status = usb_clear_halt (dev->udev, dev->in);
+ usb_autopm_put_interface(dev->intf);
if (status < 0
&& status != -EPIPE
&& status != -ESHUTDOWN) {
if (netif_msg_rx_err (dev))
+fail_halt:
deverr (dev, "can't clear rx halt, status %d",
status);
} else {
@@ -919,7 +946,12 @@ kevent (struct work_struct *work)
clear_bit (EVENT_RX_MEMORY, &dev->flags);
if (urb != NULL) {
clear_bit (EVENT_RX_MEMORY, &dev->flags);
+ status = usb_autopm_get_interface(dev->intf);
+ if (status < 0)
+ goto fail_lowmem;
rx_submit (dev, urb, GFP_KERNEL);
+ usb_autopm_put_interface(dev->intf);
+fail_lowmem:
tasklet_schedule (&dev->bh);
}
}
@@ -929,11 +961,18 @@ kevent (struct work_struct *work)
int retval = 0;
clear_bit (EVENT_LINK_RESET, &dev->flags);
+ status = usb_autopm_get_interface(dev->intf);
+ if (status < 0)
+ goto skip_reset;
if(info->link_reset && (retval = info->link_reset(dev)) < 0) {
+ usb_autopm_put_interface(dev->intf);
+skip_reset:
devinfo(dev, "link reset failed (%d) usbnet usb-%s-%s, %s",
retval,
dev->udev->bus->bus_name, dev->udev->devpath,
info->description);
+ } else {
+ usb_autopm_put_interface(dev->intf);
}
}
@@ -971,6 +1010,7 @@ static void tx_complete (struct urb *urb)
case -EPROTO:
case -ETIME:
case -EILSEQ:
+ usb_mark_last_busy(dev->udev);
if (!timer_pending (&dev->delay)) {
mod_timer (&dev->delay,
jiffies + THROTTLE_JIFFIES);
@@ -987,6 +1027,7 @@ static void tx_complete (struct urb *urb)
}
}
+ usb_autopm_put_interface_async(dev->intf);
urb->dev = NULL;
entry->state = tx_done;
defer_bh(dev, skb, &dev->txq);
@@ -1057,14 +1098,34 @@ netdev_tx_t usbnet_start_xmit (struct sk_buff *skb,
}
}
- spin_lock_irqsave (&dev->txq.lock, flags);
+ spin_lock_irqsave(&dev->txq.lock, flags);
+ retval = usb_autopm_get_interface_async(dev->intf);
+ if (retval < 0) {
+ spin_unlock_irqrestore(&dev->txq.lock, flags);
+ goto drop;
+ }
+
+#ifdef CONFIG_PM
+ /* if this triggers the device is still a sleep */
+ if (test_bit(EVENT_DEV_ASLEEP, &dev->flags)) {
+ /* transmission will be done in resume */
+ usb_anchor_urb(urb, &dev->deferred);
+ /* no use to process more packets */
+ netif_stop_queue(net);
+ spin_unlock_irqrestore(&dev->txq.lock, flags);
+ devdbg(dev, "Delaying transmission for resumption");
+ goto deferred;
+ }
+#endif
switch ((retval = usb_submit_urb (urb, GFP_ATOMIC))) {
case -EPIPE:
netif_stop_queue (net);
usbnet_defer_kevent (dev, EVENT_TX_HALT);
+ usb_autopm_put_interface_async(dev->intf);
break;
default:
+ usb_autopm_put_interface_async(dev->intf);
if (netif_msg_tx_err (dev))
devdbg (dev, "tx: submit urb err %d", retval);
break;
@@ -1088,6 +1149,7 @@ drop:
devdbg (dev, "> tx, len %d, type 0x%x",
length, skb->protocol);
}
+deferred:
return NETDEV_TX_OK;
}
EXPORT_SYMBOL_GPL(usbnet_start_xmit);
@@ -1263,6 +1325,7 @@ usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
dev->bh.func = usbnet_bh;
dev->bh.data = (unsigned long) dev;
INIT_WORK (&dev->kevent, kevent);
+ init_usb_anchor(&dev->deferred);
dev->delay.function = usbnet_bh;
dev->delay.data = (unsigned long) dev;
init_timer (&dev->delay);
@@ -1380,13 +1443,23 @@ int usbnet_suspend (struct usb_interface *intf, pm_message_t message)
struct usbnet *dev = usb_get_intfdata(intf);
if (!dev->suspend_count++) {
+ spin_lock_irq(&dev->txq.lock);
+ /* don't autosuspend while transmitting */
+ if (dev->txq.qlen && (message.event & PM_EVENT_AUTO)) {
+ spin_unlock_irq(&dev->txq.lock);
+ return -EBUSY;
+ } else {
+ set_bit(EVENT_DEV_ASLEEP, &dev->flags);
+ spin_unlock_irq(&dev->txq.lock);
+ }
/*
* accelerate emptying of the rx and queues, to avoid
* having everything error out.
*/
netif_device_detach (dev->net);
- (void) unlink_urbs (dev, &dev->rxq);
- (void) unlink_urbs (dev, &dev->txq);
+ usbnet_terminate_urbs(dev);
+ usb_kill_urb(dev->interrupt);
+
/*
* reattach so runtime management can use and
* wake the device
@@ -1400,10 +1473,34 @@ EXPORT_SYMBOL_GPL(usbnet_suspend);
int usbnet_resume (struct usb_interface *intf)
{
struct usbnet *dev = usb_get_intfdata(intf);
+ struct sk_buff *skb;
+ struct urb *res;
+ int retval;
+
+ if (!--dev->suspend_count) {
+ spin_lock_irq(&dev->txq.lock);
+ while ((res = usb_get_from_anchor(&dev->deferred))) {
+
+ printk(KERN_INFO"%s has delayed data\n", __func__);
+ skb = (struct sk_buff *)res->context;
+ retval = usb_submit_urb(res, GFP_ATOMIC);
+ if (retval < 0) {
+ dev_kfree_skb_any(skb);
+ usb_free_urb(res);
+ usb_autopm_put_interface_async(dev->intf);
+ } else {
+ dev->net->trans_start = jiffies;
+ __skb_queue_tail(&dev->txq, skb);
+ }
+ }
- if (!--dev->suspend_count)
+ smp_mb();
+ clear_bit(EVENT_DEV_ASLEEP, &dev->flags);
+ spin_unlock_irq(&dev->txq.lock);
+ if (!(dev->txq.qlen >= TX_QLEN(dev)))
+ netif_start_queue(dev->net);
tasklet_schedule (&dev->bh);
-
+ }
return 0;
}
EXPORT_SYMBOL_GPL(usbnet_resume);
diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
index 86c31b7..a7b92d6 100644
--- a/include/linux/usb/usbnet.h
+++ b/include/linux/usb/usbnet.h
@@ -55,6 +55,7 @@ struct usbnet {
struct sk_buff_head done;
struct sk_buff_head rxq_pause;
struct urb *interrupt;
+ struct usb_anchor deferred;
struct tasklet_struct bh;
struct work_struct kevent;
@@ -65,6 +66,8 @@ struct usbnet {
# define EVENT_STS_SPLIT 3
# define EVENT_LINK_RESET 4
# define EVENT_RX_PAUSED 5
+# define EVENT_DEV_WAKING 6
+# define EVENT_DEV_ASLEEP 7
};
static inline struct usb_driver *driver_of(struct usb_interface *intf)
@@ -108,6 +111,9 @@ struct driver_info {
/* see if peer is connected ... can sleep */
int (*check_connect)(struct usbnet *);
+ /* (dis)activate runtime power management */
+ int (*manage_power)(struct usbnet *, int);
+
/* for status polling */
void (*status)(struct usbnet *, struct urb *);
--
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 related
* [PATCH] smsc9420: prevent BUG() if ethtool is called with interface down
From: Steve Glendinning @ 2009-11-25 16:21 UTC (permalink / raw)
To: netdev; +Cc: Steve Glendinning
This patch fixes a null pointer dereference BUG() if ethtool is used on
an smsc9420 interface while it is down, because the phy_dev is only
allocated while the interface is up.
Please also consider for -stable.
Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
---
drivers/net/smsc9420.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/net/smsc9420.c b/drivers/net/smsc9420.c
index 92e2bbe..12f0f5d 100644
--- a/drivers/net/smsc9420.c
+++ b/drivers/net/smsc9420.c
@@ -252,6 +252,9 @@ static int smsc9420_ethtool_get_settings(struct net_device *dev,
{
struct smsc9420_pdata *pd = netdev_priv(dev);
+ if (!pd->phy_dev)
+ return -ENODEV;
+
cmd->maxtxpkt = 1;
cmd->maxrxpkt = 1;
return phy_ethtool_gset(pd->phy_dev, cmd);
@@ -262,6 +265,9 @@ static int smsc9420_ethtool_set_settings(struct net_device *dev,
{
struct smsc9420_pdata *pd = netdev_priv(dev);
+ if (!pd->phy_dev)
+ return -ENODEV;
+
return phy_ethtool_sset(pd->phy_dev, cmd);
}
@@ -290,6 +296,10 @@ static void smsc9420_ethtool_set_msglevel(struct net_device *netdev, u32 data)
static int smsc9420_ethtool_nway_reset(struct net_device *netdev)
{
struct smsc9420_pdata *pd = netdev_priv(netdev);
+
+ if (!pd->phy_dev)
+ return -ENODEV;
+
return phy_start_aneg(pd->phy_dev);
}
@@ -312,6 +322,10 @@ smsc9420_ethtool_getregs(struct net_device *dev, struct ethtool_regs *regs,
for (i = 0; i < 0x100; i += (sizeof(u32)))
data[j++] = smsc9420_reg_read(pd, i);
+ // cannot read phy registers if the net device is down
+ if (!phy_dev)
+ return;
+
for (i = 0; i <= 31; i++)
data[j++] = smsc9420_mii_read(phy_dev->bus, phy_dev->addr, i);
}
--
1.6.2.5
^ permalink raw reply related
* Re: TCP sockets stalling - help! (long)
From: Asdo @ 2009-11-25 16:38 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: e1000-devel, Netdev
In-Reply-To: <4B0D4EFC.4050302@shiftmail.org>
Asdo wrote:
> Asdo wrote:
>> Ilpo Järvinen wrote:
>>
>>> ...I'd next try strace the sftp server to see what it was doing
>>> during the stall.
>>>
>> Thanks for your help Ilpo
>>
>> Isn't the strace equivalent to the stack trace I obtained via cat
>> /proc/pid/stack reported previously? That was at the time of the stall
>>
>> I'm thinking the strace would slow down sftp-server very deeply...
>>
>
> I found out that if I attach the strace I can see at least the last
> function call.
> The SFTP it's hanged right now so I did that:
>
> root@mystorage:/root# strace -p 11475
> Process 11475 attached - interrupt to quit
> select(5, [3], [], NULL, NULL
>
> (stuck here forever... doesn't move)
> (it's strange the first option of select is 5, shouldn't it be 4 from
> man select? A bug of strace maybe?)
>
> root@mystorage:/root# cat /proc/11475/stack
> [<ffffffff8112e644>] poll_schedule_timeout+0x34/0x50
> [<ffffffff8112ef4f>] do_select+0x58f/0x6b0
> [<ffffffff8112f8b5>] core_sys_select+0x185/0x2b0
> [<ffffffff8112fc32>] sys_select+0x42/0x110
> [<ffffffff8101225b>] tracesys+0xd9/0xde
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> And this is from cat /proc/net/tcp 2: 0F12A8C0:0016 2512A8C0:0FBD 01
> 00000000:00000000 02:00009144 00000000 0 0 5326251 2
> ffff88085408ce00 26 4 1 9 4
>
> The select refers to open files so here they are:
>
>
> root@mystorage:/proc/11475/fd# ll
> total 0
> lr-x------ 1 ccosentino wetlab 64 2009-11-25 14:43 0 -> pipe:[5326309]
> l-wx------ 1 ccosentino wetlab 64 2009-11-25 14:43 1 -> pipe:[5326310]
> l-wx------ 1 ccosentino wetlab 64 2009-11-25 14:43 2 -> pipe:[5326311]
> lr-x------ 1 ccosentino wetlab 64 2009-11-25 14:43 3 -> pipe:[5326309]
> l-wx------ 1 ccosentino wetlab 64 2009-11-25 14:43 4 -> pipe:[5326310]
> l-wx------ 1 ccosentino wetlab 64 2009-11-25 14:43 5 ->
> /path/to/file_being_saved.filepart
>
> I tried to send SIGSTOP and then SIGCONT to see if I could make it
> make a loop and then reenter into the select. I'm not sure it really
> did that, what do you think? This is the strace:
> root@mystorage:/root# strace -p 11475 2>&1 | tee sftpstrace.dmp
> Process 11475 attached - interrupt to quit
> select(5, [3], [], NULL, NULL) = ? ERESTARTNOHAND (To be
> restarted)
> --- SIGSTOP (Stopped (signal)) @ 0 (0) ---
> --- SIGSTOP (Stopped (signal)) @ 0 (0) ---
> select(5, [3], [], NULL, NULL) = ? ERESTARTNOHAND (To be
> restarted)
> --- SIGCONT (Continued) @ 0 (0) ---
> select(5, [3], [], NULL, NULL
>
> (hanged again here)
>
>
> Do you think this info is enough or I really have to strace it since
> the beginning?
> If it is a race condition it might not happen if the sftp-server is
> deeply slowed down by the strace.
> If I had a way to make it continue right now we could get the rest of
> the strace... But it's not so easy, I tried starting a Samba transfer
> but it did not unlock the SFTP this time. SIGSTOP + SIGCONT also
> didn't work.
>
> BTW people using the Storage also experienced data loss while pushing
> files in it: appartently data disappeared from the middle of a file
> they were saving to the Storage.
> To me looks like another hint that application-level data which has
> been received via network by TCP stack is trapped there and not being
> pushed to the application.
> Or the data might even be trapped into the anonymous sockets between
> sshd and sftp-server.
>
> Thanks for your help
I thought that it would be more meaningful to try the cat stack, the
strace and the SIGSTOP SIGCONT tricks on the sshd which actually holds
the TCP socket, instead of the sftp-server. Here they are, on the sshd:
root@mystorage:/root# strace -p 11449 2>&1 | tee -a sshd1strace1.dmp
Process 11449 attached - interrupt to quit
read(5, 0x7fff4e956220, 4) = ? ERESTARTSYS (To be restarted)
--- SIGSTOP (Stopped (signal)) @ 0 (0) ---
--- SIGSTOP (Stopped (signal)) @ 0 (0) ---
read(5, 0x7fff4e956220, 4) = ? ERESTARTSYS (To be restarted)
--- SIGCONT (Continued) @ 0 (0) ---
read(5,
(hanged again here after the SIGSTOP + SIGCONT, unfortunately)
root@mystorage:/root# cat /proc/11449/stack
[<ffffffff814b428a>] unix_stream_data_wait+0xaa/0x110
[<ffffffff814b50cd>] unix_stream_recvmsg+0x36d/0x570
[<ffffffff81426399>] sock_aio_read+0x149/0x150
[<ffffffff8111e232>] do_sync_read+0xf2/0x130
[<ffffffff8111e8e1>] vfs_read+0x181/0x1a0
[<ffffffff8111edec>] sys_read+0x4c/0x80
[<ffffffff8101225b>] tracesys+0xd9/0xde
[<ffffffffffffffff>] 0xffffffffffffffff
root@mystorage:/proc/11449/fd# ll
total 0
lrwx------ 1 root root 64 2009-11-25 14:43 0 -> /dev/null
lrwx------ 1 root root 64 2009-11-25 14:43 1 -> /dev/null
lrwx------ 1 root root 64 2009-11-25 14:43 2 -> /dev/null
lrwx------ 1 root root 64 2009-11-25 14:43 3 -> socket:[5326251]
lrwx------ 1 root root 64 2009-11-25 14:43 5 -> socket:[5326303]
I would like to try to attach a program of mine (a python interactive)
to "socket:[5326303]" and try to read data from there to see if
something comes out of the TCP stack, but I don't know where to find the
socket:[5326303] on the filesystem. Is it mapped to a file anywhere in
Linux?
Thank you
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ 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