* Re: [PATCH] xmit_compl_seq: information to reclaim vmsplice buffers
From: David Miller @ 2010-09-20 0:35 UTC (permalink / raw)
To: therbert; +Cc: netdev, sridharr
In-Reply-To: <alpine.DEB.1.00.1009191451090.5120@pokey.mtv.corp.google.com>
From: Tom Herbert <therbert@google.com>
Date: Sun, 19 Sep 2010 14:55:40 -0700 (PDT)
> diff --git a/include/asm-generic/socket.h b/include/asm-generic/socket.h
> index 9a6115e..6dc1ed8 100644
> --- a/include/asm-generic/socket.h
> +++ b/include/asm-generic/socket.h
> @@ -64,4 +64,7 @@
> #define SO_DOMAIN 39
>
> #define SO_RXQ_OVFL 40
> +
> +#define SO_XMIT_COMPL_SEQ 41
> +#define SCM_XMIT_COMPL_SEQ SO_XMIT_COMPL_SEQ
> #endif /* __ASM_GENERIC_SOCKET_H */
Tom, I just noticed that you're going to have to update all of
the arch specific arch/*/include/asm/socket.h files that don't
make use of asm-generic/socket.h before I can apply this.
Please fix this up and resubmit, thanks!
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: pskb_expand_head() optimization
From: David Miller @ 2010-09-20 0:17 UTC (permalink / raw)
To: jarkao2; +Cc: eric.dumazet, netdev
In-Reply-To: <20100911123140.GA1939@del.dom.local>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Sat, 11 Sep 2010 14:31:40 +0200
> Otherwise seems OK, but I still would like to know the scenario
> demanding this change.
Ok Jarek, after some more consideration I agree with you.
Removing this kind of sharing would be unwise, ho hum...
While pondering over this I thought about why we even need
frag lists at all. We need them for two reasons:
1) Because we have an inability to turn kmalloc data references into
page based ones easily.
We've run into this sort of problem with socket splice() too.
2) For recording the segmentation points of a fragmented packet.
We definitely don't use frag lists for performance, if you look
in the GRO history the GRO code specifically has been changed
to prefer accumulating into the page vector whenever possible
because using frag lists is a lot slower.
Anyways, even if we somehow solved #1 we'd still have a lot of
code (even bluetooth) using it for the sake of issue #2.
So for the time being there is no clear path for trying to
eliminate frag lists altogether if we wanted to do that either.
^ permalink raw reply
* [PATCH] xmit_compl_seq: information to reclaim vmsplice buffers
From: Tom Herbert @ 2010-09-19 21:55 UTC (permalink / raw)
To: netdev, davem; +Cc: sridharr
In this patch we propose to adds some socket API to retrieve the
"transmit completion sequence number", essentially a byte counter
for the number of bytes that have been transmitted and will not be
retransmitted. In the case of TCP, this should correspond to snd_una.
The purpose of this API is to provide information to userspace about
which buffers can be reclaimed when sending with vmsplice() on a
socket.
There are two methods for retrieving the completed sequence number:
through a simple getsockopt (implemented here for TCP), as well as
returning the value in the ancilary data of a recvmsg.
The expected flow would be something like:
- Connect is created
- Initial completion seq # is retrieved through the sockopt, and is
stored in userspace "compl_seq" variable for the connection.
- Whenever a send is done, compl_seq += # bytes sent.
- When doing a vmsplice the completion sequence number is saved
for each user space buffer, buffer_compl_seq = compl_seq.
- When recvmsg returns with a completion sequence number in
ancillary data, any buffers cover by that sequence number
(where buffer_compl_seq < recvmsg_compl_seq) are reclaimed
and can be written to again.
- If no data is receieved on a connection (recvmsg does not
return), a timeout can be used to call the getsockopt and
reclaim buffers as a fallback.
Using recvmsg data in this manner is sort of a cheap way to get a
"callback" for when a vmspliced buffer is consumed. It will work
well for a client where the response causes recvmsg to return.
On the server side it works well if there are a sufficient
number of requests coming on the connection (resorting to the
timeout if necessary as described above).
Signed-off-by: Tom Herbert <therbert@google.com>
---
diff --git a/include/asm-generic/socket.h b/include/asm-generic/socket.h
index 9a6115e..6dc1ed8 100644
--- a/include/asm-generic/socket.h
+++ b/include/asm-generic/socket.h
@@ -64,4 +64,7 @@
#define SO_DOMAIN 39
#define SO_RXQ_OVFL 40
+
+#define SO_XMIT_COMPL_SEQ 41
+#define SCM_XMIT_COMPL_SEQ SO_XMIT_COMPL_SEQ
#endif /* __ASM_GENERIC_SOCKET_H */
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index e64f4c6..f044aff 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -106,6 +106,7 @@ enum {
#define TCP_THIN_LINEAR_TIMEOUTS 16 /* Use linear timeouts for thin streams*/
#define TCP_THIN_DUPACK 17 /* Fast retrans. after 1 dupack */
#define TCP_USER_TIMEOUT 18 /* How long for loss retry before timeout */
+#define TCP_XMIT_COMPL_SEQ 19 /* Return current snd_una */
/* for TCP_INFO socket option */
#define TCPI_OPT_TIMESTAMPS 1
diff --git a/include/net/sock.h b/include/net/sock.h
index 8ae97c4..e820e2b 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -543,6 +543,7 @@ enum sock_flags {
SOCK_TIMESTAMPING_SYS_HARDWARE, /* %SOF_TIMESTAMPING_SYS_HARDWARE */
SOCK_FASYNC, /* fasync() active */
SOCK_RXQ_OVFL,
+ SOCK_XMIT_COMPL_SEQ, /* SO_XMIT_COMPL_SEQ setting */
};
static inline void sock_copy_flags(struct sock *nsk, struct sock *osk)
diff --git a/net/core/sock.c b/net/core/sock.c
index f3a06c4..7a10215 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -740,6 +740,12 @@ set_rcvbuf:
else
sock_reset_flag(sk, SOCK_RXQ_OVFL);
break;
+ case SO_XMIT_COMPL_SEQ:
+ if (valbool)
+ sock_set_flag(sk, SOCK_XMIT_COMPL_SEQ);
+ else
+ sock_reset_flag(sk, SOCK_XMIT_COMPL_SEQ);
+ break;
default:
ret = -ENOPROTOOPT;
break;
@@ -961,6 +967,10 @@ int sock_getsockopt(struct socket *sock, int level, int optname,
v.val = !!sock_flag(sk, SOCK_RXQ_OVFL);
break;
+ case SO_XMIT_COMPL_SEQ:
+ v.val = !!sock_flag(sk, SOCK_XMIT_COMPL_SEQ);
+ break;
+
default:
return -ENOPROTOOPT;
}
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 3e8a4db..5e30381 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1387,6 +1387,21 @@ int tcp_read_sock(struct sock *sk, read_descriptor_t *desc,
EXPORT_SYMBOL(tcp_read_sock);
/*
+ * Copy the first unacked seq into the receive msg control part.
+ */
+static inline void tcp_sock_xmit_compl_seq(struct msghdr *msg,
+ struct sock *sk)
+{
+ if (sock_flag(sk, SOCK_XMIT_COMPL_SEQ)) {
+ struct tcp_sock *tp = tcp_sk(sk);
+ if (msg->msg_controllen >= sizeof(tp->snd_una)) {
+ put_cmsg(msg, SOL_SOCKET, SCM_XMIT_COMPL_SEQ,
+ sizeof(tp->snd_una), &tp->snd_una);
+ }
+ }
+}
+
+/*
* This routine copies from a sock struct into the user buffer.
*
* Technical note: in 2.3 we work on _locked_ socket, so that
@@ -1763,6 +1778,8 @@ skip_copy:
* on connected socket. I was just happy when found this 8) --ANK
*/
+ tcp_sock_xmit_compl_seq(msg, sk);
+
/* Clean up data we have read: This will do ACK frames. */
tcp_cleanup_rbuf(sk, copied);
@@ -2617,6 +2634,9 @@ static int do_tcp_getsockopt(struct sock *sk, int level,
case TCP_USER_TIMEOUT:
val = jiffies_to_msecs(icsk->icsk_user_timeout);
break;
+ case TCP_XMIT_COMPL_SEQ:
+ val = tp->snd_una;
+ break;
default:
return -ENOPROTOOPT;
}
^ permalink raw reply related
* ipsec encryption
From: Stephen Clark @ 2010-09-19 21:04 UTC (permalink / raw)
To: netdev
Hello List,
I have been searching for a diagram that shows where in the packet flow thru
the kernel that ipsec encryption/encapsulation takes place in relation
to the
netfilter flow diagrams. None of the netfilter diagrams I have found
indicate
where ipsec encryption/decryption takes place.
Thanks in advance,
Steve
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
^ permalink raw reply
* Re: [PATCH net-next-2.6] bridge : Sanitize skb before it enters the IP stack
From: David Miller @ 2010-09-19 20:24 UTC (permalink / raw)
To: bandan.das; +Cc: linux-kernel, netdev, eric.dumazet, herbert, kaber
In-Reply-To: <20100919193433.GF31036@stratus.com>
From: Bandan Das <bandan.das@stratus.com>
Date: Sun, 19 Sep 2010 15:34:33 -0400
> Related dicussion here : http://lkml.org/lkml/2010/9/3/16
>
> Introduce a function br_parse_ip_options that will audit the
> skb and possibly refill IP options before a packet enters the
> IP stack. If no options are present, the function will zero out
> the skb cb area so that it is not misinterpreted as options by some
> unsuspecting IP layer routine. If packet consistency fails, drop it.
>
> Signed-off-by: Bandan Das <bandan.das@stratus.com>
Applied, thanks a lot!
^ permalink raw reply
* Re: [PATCH net-next-2.6] net/ipv4: push IP options to CB in ip_fragment
From: Bandan Das @ 2010-09-19 19:36 UTC (permalink / raw)
To: David Miller
Cc: herbert, bandan.das, bunk, eric.dumazet, netdev, linux-kernel,
kaber
In-Reply-To: <20100917.164356.22528384.davem@davemloft.net>
On 0, David Miller <davem@davemloft.net> wrote:
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Fri, 17 Sep 2010 14:51:17 +0800
>
> > On Wed, Sep 15, 2010 at 01:32:09PM -0400, Bandan Das wrote:
> >>
> >> Sorry for the late response. Here's a patch that I put up based on Herbert's
> >> suggestions. I ofcourse don't see the problem anymore after
> >> commit 87f94b4e91dc042620c527f3c30c37e5127ef757 but a generic helper such as this
> >> can be used anytime the bridge code is sending a packet over to the IP layer.
> >> Compile tested only but based on responses, will test it before submitting a
> >> final change. Also added it at two places where I know we do send a packet over to
> >> the IP layer. I will add it at other places later as I come across them.
> >
> > Looks fine to me.
>
> Bandan, please submit this formally with proper commit message,
> signoff, also the new function you added needs a minor coding
> style fix, there needs to be a space after "if" and the openning
> left parenthesis.
>
> Thanks.
Submitted. And also incorporated the coding style fixes you mentioned.
Thanks
Bandan
^ permalink raw reply
* [PATCH net-next-2.6] bridge : Sanitize skb before it enters the IP stack
From: Bandan Das @ 2010-09-19 19:34 UTC (permalink / raw)
To: David Miller; +Cc: LKML, NetDev, Eric Dumazet, Herbert Xu, Patrick McHardy
Related dicussion here : http://lkml.org/lkml/2010/9/3/16
Introduce a function br_parse_ip_options that will audit the
skb and possibly refill IP options before a packet enters the
IP stack. If no options are present, the function will zero out
the skb cb area so that it is not misinterpreted as options by some
unsuspecting IP layer routine. If packet consistency fails, drop it.
Signed-off-by: Bandan Das <bandan.das@stratus.com>
---
net/bridge/br_netfilter.c | 107 ++++++++++++++++++++++++++++++++------------
net/ipv4/ip_options.c | 3 +-
2 files changed, 80 insertions(+), 30 deletions(-)
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index 137f232..77f7b5f 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -209,6 +209,72 @@ static inline void nf_bridge_update_protocol(struct sk_buff *skb)
skb->protocol = htons(ETH_P_PPP_SES);
}
+/* When handing a packet over to the IP layer
+ * check whether we have a skb that is in the
+ * expected format
+ */
+
+int br_parse_ip_options(struct sk_buff *skb)
+{
+ struct ip_options *opt;
+ struct iphdr *iph;
+ struct net_device *dev = skb->dev;
+ u32 len;
+
+ iph = ip_hdr(skb);
+ opt = &(IPCB(skb)->opt);
+
+ /* Basic sanity checks */
+ if (iph->ihl < 5 || iph->version != 4)
+ goto inhdr_error;
+
+ if (!pskb_may_pull(skb, iph->ihl*4))
+ goto inhdr_error;
+
+ iph = ip_hdr(skb);
+ if (unlikely(ip_fast_csum((u8 *)iph, iph->ihl)))
+ goto inhdr_error;
+
+ len = ntohs(iph->tot_len);
+ if (skb->len < len) {
+ IP_INC_STATS_BH(dev_net(dev), IPSTATS_MIB_INTRUNCATEDPKTS);
+ goto drop;
+ } else if (len < (iph->ihl*4))
+ goto inhdr_error;
+
+ if (pskb_trim_rcsum(skb, len)) {
+ IP_INC_STATS_BH(dev_net(dev), IPSTATS_MIB_INDISCARDS);
+ goto drop;
+ }
+
+ /* Zero out the CB buffer if no options present */
+ if (iph->ihl == 5) {
+ memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
+ return 0;
+ }
+
+ opt->optlen = iph->ihl*4 - sizeof(struct iphdr);
+ if (ip_options_compile(dev_net(dev), opt, skb))
+ goto inhdr_error;
+
+ /* Check correct handling of SRR option */
+ if (unlikely(opt->srr)) {
+ struct in_device *in_dev = __in_dev_get_rcu(dev);
+ if (in_dev && !IN_DEV_SOURCE_ROUTE(in_dev))
+ goto drop;
+
+ if (ip_options_rcv_srr(skb))
+ goto drop;
+ }
+
+ return 0;
+
+inhdr_error:
+ IP_INC_STATS_BH(dev_net(dev), IPSTATS_MIB_INHDRERRORS);
+drop:
+ return -1;
+}
+
/* Fill in the header for fragmented IP packets handled by
* the IPv4 connection tracking code.
*/
@@ -549,7 +615,6 @@ static unsigned int br_nf_pre_routing(unsigned int hook, struct sk_buff *skb,
{
struct net_bridge_port *p;
struct net_bridge *br;
- struct iphdr *iph;
__u32 len = nf_bridge_encap_header_len(skb);
if (unlikely(!pskb_may_pull(skb, len)))
@@ -578,28 +643,9 @@ static unsigned int br_nf_pre_routing(unsigned int hook, struct sk_buff *skb,
nf_bridge_pull_encap_header_rcsum(skb);
- if (!pskb_may_pull(skb, sizeof(struct iphdr)))
- goto inhdr_error;
-
- iph = ip_hdr(skb);
- if (iph->ihl < 5 || iph->version != 4)
- goto inhdr_error;
-
- if (!pskb_may_pull(skb, 4 * iph->ihl))
- goto inhdr_error;
-
- iph = ip_hdr(skb);
- if (ip_fast_csum((__u8 *) iph, iph->ihl) != 0)
- goto inhdr_error;
-
- len = ntohs(iph->tot_len);
- if (skb->len < len || len < 4 * iph->ihl)
- goto inhdr_error;
-
- pskb_trim_rcsum(skb, len);
-
- /* BUG: Should really parse the IP options here. */
- memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
+ if (br_parse_ip_options(skb))
+ /* Drop invalid packet */
+ goto out;
nf_bridge_put(skb->nf_bridge);
if (!nf_bridge_alloc(skb))
@@ -614,8 +660,6 @@ static unsigned int br_nf_pre_routing(unsigned int hook, struct sk_buff *skb,
return NF_STOLEN;
-inhdr_error:
-// IP_INC_STATS_BH(IpInHdrErrors);
out:
return NF_DROP;
}
@@ -759,14 +803,19 @@ static unsigned int br_nf_forward_arp(unsigned int hook, struct sk_buff *skb,
#if defined(CONFIG_NF_CONNTRACK_IPV4) || defined(CONFIG_NF_CONNTRACK_IPV4_MODULE)
static int br_nf_dev_queue_xmit(struct sk_buff *skb)
{
+ int ret;
+
if (skb->nfct != NULL && skb->protocol == htons(ETH_P_IP) &&
skb->len + nf_bridge_mtu_reduction(skb) > skb->dev->mtu &&
!skb_is_gso(skb)) {
- /* BUG: Should really parse the IP options here. */
- memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
- return ip_fragment(skb, br_dev_queue_push_xmit);
+ if (br_parse_ip_options(skb))
+ /* Drop invalid packet */
+ return NF_DROP;
+ ret = ip_fragment(skb, br_dev_queue_push_xmit);
} else
- return br_dev_queue_push_xmit(skb);
+ ret = br_dev_queue_push_xmit(skb);
+
+ return ret;
}
#else
static int br_nf_dev_queue_xmit(struct sk_buff *skb)
diff --git a/net/ipv4/ip_options.c b/net/ipv4/ip_options.c
index ba9836c..1906fa3 100644
--- a/net/ipv4/ip_options.c
+++ b/net/ipv4/ip_options.c
@@ -466,7 +466,7 @@ error:
}
return -EINVAL;
}
-
+EXPORT_SYMBOL(ip_options_compile);
/*
* Undo all the changes done by ip_options_compile().
@@ -646,3 +646,4 @@ int ip_options_rcv_srr(struct sk_buff *skb)
}
return 0;
}
+EXPORT_SYMBOL(ip_options_rcv_srr);
--
1.6.6.1
^ permalink raw reply related
* Re: [patch -next] rds: spin_lock_irq() is not nestable
From: David Miller @ 2010-09-19 19:00 UTC (permalink / raw)
To: error27
Cc: andy.grover, zach.brown, chris.mason, rds-devel, netdev,
kernel-janitors
In-Reply-To: <20100918234414.GE6236@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Sun, 19 Sep 2010 01:44:14 +0200
> This is basically just a cleanup. IRQs were disabled on the previous
> line so we don't need to do it again here. In the current code IRQs
> would get turned on one line earlier than intended.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Also applied, thanks Dan.
^ permalink raw reply
* Re: [patch -next] rds: double unlock in rds_ib_cm_handle_connect()
From: David Miller @ 2010-09-19 18:59 UTC (permalink / raw)
To: error27
Cc: andy.grover, zach.brown, julia, tj, rds-devel, netdev,
kernel-janitors
In-Reply-To: <20100918234259.GD6236@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Sun, 19 Sep 2010 01:42:59 +0200
> We unlock after we goto out.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Applied.
^ permalink raw reply
* Re: [patch -next] rds: signedness bug
From: David Miller @ 2010-09-19 18:59 UTC (permalink / raw)
To: error27; +Cc: andy.grover, rds-devel, netdev, kernel-janitors
In-Reply-To: <20100918234224.GC6236@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Sun, 19 Sep 2010 01:42:25 +0200
> In the original code if the copy_from_user() fails in rds_rdma_pages()
> then the error handling fails and we get a stack trace from kmalloc().
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Applied.
^ permalink raw reply
* Re: [RFC PATCH] xmit_compl_seq: information to reclaim vmsplice buffers
From: David Miller @ 2010-09-19 18:35 UTC (permalink / raw)
To: therbert; +Cc: netdev, sridharr
In-Reply-To: <AANLkTimoHcbpyp95a23GXxWO3gQTxB6SJuP0WSJf1DB-@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
Date: Thu, 16 Sep 2010 12:09:08 -0700
> We return the seq # as part of receive message since: 1) the socket is
> already being accessed in the recvmsg, so tacking on this data should be
> cheap 2) the recvmsg may often coincide with an acknowledgment that would
> allow buffers to be reclaimed (esp. in response of a client request) 3) this
> could also be achieved by another system call after recvmsg, but then we're
> adding the cost of the system call.
>
> The recvmsg and sockopt return the sequence number of first unacknowleged
> data, as opposed to the number of bytes outstanding. The sequence number is
> not a relative value for our purposes, but the other is. Given just the
> number of bytes outstanding, we would also need the # bytes that have ever
> been written by application at that instant to compute the completed byte
> number for reclaiming buffers-- so we would need synchronization between
> read and write path in the application (lock needed).
Ok, I'm convinced, thanks for explaining.
Please address the other feedback you've received (if any) and formally
submit this for inclusion into net-next-2.6
Thanks.
^ permalink raw reply
* Re: [patch] ixgbevf: potential NULL dereference on allocation failure
From: David Miller @ 2010-09-19 18:33 UTC (permalink / raw)
To: gregory.v.rose; +Cc: error27, jeffrey.t.kirsher, netdev, kernel-janitors
In-Reply-To: <43F901BD926A4E43B106BF17856F0755F66821BC@orsmsx508.amr.corp.intel.com>
From: "Rose, Gregory V" <gregory.v.rose@intel.com>
Date: Tue, 14 Sep 2010 09:57:46 -0700
> I've taken up your suggestions and implemented them (roughly) as
> suggested below. After looking at the code I had to agree that it
> would be very confusing for a user to set new ring parameters, have
> the call partially succeed but get no error and then look at the
> parameters again and not see what he expected. Now the code will do
> as suggested and just unwind all prior allocations and return an
> error if the new ring sizing didn't work. The user will be left
> with the prior ring size allocations which is probably what he would
> expect.
>
> The patch is going to be posted internally and after it goes through
> our review process it will be posted to netdev.
Thanks for doing this work Greg.
^ permalink raw reply
* Re: [patch -next] bna: off by one
From: David Miller @ 2010-09-19 18:26 UTC (permalink / raw)
To: error27; +Cc: rmody, ddutt, netdev, kernel-janitors
In-Reply-To: <20100918234144.GB6236@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Sun, 19 Sep 2010 01:41:44 +0200
> The mod->mbhdlr[] array has BFI_MC_MAX elements.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Applied, thanks Dan.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: reorder struct netdev_hw_addr
From: David Miller @ 2010-09-19 18:24 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1284790664.4373.610.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 18 Sep 2010 08:17:44 +0200
> Move 'synced' and 'global_use' fields before 'refcount', to shrinks
> struct netdev_hw_addr by 8 bytes (on 64bit arches).
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] xps-mq: Transmit Packet Steering for multiqueue
From: Michael S. Tsirkin @ 2010-09-19 17:24 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, therbert, eric.dumazet, shemminger, netdev
In-Reply-To: <1284673961.2283.57.camel@achroite.uk.solarflarecom.com>
On Thu, Sep 16, 2010 at 10:52:41PM +0100, Ben Hutchings wrote:
> On Wed, 2010-09-01 at 18:32 -0700, David Miller wrote:
> > From: Tom Herbert <therbert@google.com>
> > Date: Wed, 1 Sep 2010 09:24:18 -0700
> >
> > > On Wed, Sep 1, 2010 at 8:54 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > >> 3) Eventually have a user selectable selection (socket option, or system
> > >> wide, but one sysctl, not many bitmasks ;) ).
> > >>
> > > Right, but it would also be nice if a single sysctl could optimally
> > > set up multiqueue, RSS, RPS, and all my interrupt affinities for me
> > > ;-)
> >
> > It's becomming increasingly obvious to me that we need (somewhere,
> > not necessarily the kernel) a complete datastructure representing
> > the NUMA, cache, cpu, device hierarchy.
>
> And ideally a cheap way (not O(N^2)) to find the distance between 2 CPU
> threads (not just nodes).
>
> > And that can be used to tweak all of this stuff.
> >
> > The policy should probably be in userspace, we just need to provide
> > the knobs in the kernel to tweak it however userspace wants.
> >
> > Userspace should be able to, for example, move a TX queue into a
> > NUMA domain and have this invoke several side effects:
> >
> > 1) IRQs for that TX queue get rerouted to a cpu in the NUMA
> > domain.
> >
> > 2) TX queue datastructures in the driver get reallocated using
> > memory in that NUMA domain.
>
> I've actually done some work on an interface and implementation of this,
> although I didn't include actually setting the IRQ affinity as there has
> been pushback whenever people propose letting drivers set this. If they
> only do so as directed by the administrator this might be more
> acceptable though.
>
> Unfortunately in my limited testing on a 2-node system I didn't see a
> whole lot of improvement in performance when the affinities were all
> lined up. I should try to get some time on a 4-node system.
I've been trying to look into this as well.
It'd be very interesting to see the patches even if they don't show
good performance. Could you post them?
> > 3) TX hashing is configured to use the set of cpus in the NUMA
> > domain.
> >
> > It's alot of tedious work and involves some delicate tasks figuring
> > out where each of these things go, but really then we'd solve all
> > of this crap one and for all.
>
> Right.
>
> The other thing I've been working on lately which sort of ties into this
> is hardware acceleration of Receive Flow Steering. Multiqueue NICs such
> as ours tend to have RX flow filters as well as hashing. So why not use
> those to do a first level of steering? We're going to do some more
> internal testing and review but I hope to send out a first version of
> this next week.
>
> Ben.
>
^ permalink raw reply
* Re: [v2 RFC PATCH 0/4] Implement multiqueue virtio-net
From: Michael S. Tsirkin @ 2010-09-19 12:44 UTC (permalink / raw)
To: Krishna Kumar; +Cc: rusty, davem, kvm, arnd, netdev, avi, anthony
In-Reply-To: <20100917100307.21276.79185.sendpatchset@krkumar2.in.ibm.com>
On Fri, Sep 17, 2010 at 03:33:07PM +0530, Krishna Kumar wrote:
> For 1 TCP netperf, I ran 7 iterations and summed it. Explanation
> for degradation for 1 stream case:
Could you document how exactly do you measure multistream bandwidth:
netperf flags, etc?
> 1. Without any tuning, BW falls -6.5%.
Any idea where does this come from?
Do you see more TX interrupts? RX interrupts? Exits?
Do interrupts bounce more between guest CPUs?
> 2. When vhosts on server were bound to CPU0, BW was as good
> as with original code.
> 3. When new code was started with numtxqs=1 (or mq=off, which
> is the default), there was no degradation.
>
> Next steps:
> -----------
> 1. MQ RX patch is also complete - plan to submit once TX is OK (as
> well as after identifying bandwidth degradations for some test
> cases).
> 2. Cache-align data structures: I didn't see any BW/SD improvement
> after making the sq's (and similarly for vhost) cache-aligned
> statically:
> struct virtnet_info {
> ...
> struct send_queue sq[16] ____cacheline_aligned_in_smp;
> ...
> };
> 3. Migration is not tested.
4. Identify reasons for single netperf BW regression.
5. Test perf in more scenarious:
small packets
host -> guest
guest <-> external
in last case:
find some other way to measure host CPU utilization,
try multiqueue and single queue devices
6. Use above to figure out what is a sane default for numtxqs.
>
> Review/feedback appreciated.
>
> Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
> ---
^ permalink raw reply
* Re: [PATCH] netfilter: unregister nf hooks, matches and targets in the reverse order
From: Changli Gao @ 2010-09-19 5:58 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David S. Miller, netfilter-devel, netdev
In-Reply-To: <4C91033B.6070902@trash.net>
On Thu, Sep 16, 2010 at 1:32 AM, Patrick McHardy <kaber@trash.net> wrote:
> Am 02.09.2010 16:15, schrieb Changli Gao:
>> Since we register nf hooks, matches and targets in order, we'd better
>> unregister them in the reverse order.
>
> Why? Is there a specific bug you've noticed?
>
No, there isn't any bug. I just think unregistering them in the
reverse order is more resonable, like the rollback when failing. And
the code patched generates less object:
The original:
00000000000009c9 <xt_unregister_matches>:
9c9: 55 push %rbp
9ca: 48 89 e5 mov %rsp,%rbp
9cd: 41 55 push %r13
9cf: 41 89 f5 mov %esi,%r13d
9d2: 41 54 push %r12
9d4: 49 89 fc mov %rdi,%r12
9d7: 53 push %rbx
9d8: 31 db xor %ebx,%ebx
9da: 48 83 ec 08 sub $0x8,%rsp
9de: eb 0e jmp 9ee <xt_unregister_matches+0x25>
9e0: 4c 89 e7 mov %r12,%rdi
9e3: ff c3 inc %ebx
9e5: 49 83 c4 78 add $0x78,%r12
9e9: e8 00 00 00 00 callq 9ee <xt_unregister_matches+0x25>
9ee: 44 39 eb cmp %r13d,%ebx
9f1: 72 ed jb 9e0 <xt_unregister_matches+0x17>
9f3: 41 59 pop %r9
9f5: 5b pop %rbx
9f6: 41 5c pop %r12
9f8: 41 5d pop %r13
9fa: c9 leaveq
9fb: c3 retq
The patched:
00000000000009c9 <xt_unregister_matches>:
9c9: 55 push %rbp
9ca: 48 89 e5 mov %rsp,%rbp
9cd: 41 54 push %r12
9cf: 41 89 f4 mov %esi,%r12d
9d2: 53 push %rbx
9d3: 48 89 fb mov %rdi,%rbx
9d6: eb 13 jmp 9eb <xt_unregister_matches+0x22>
9d8: 41 ff cc dec %r12d
9db: 44 89 e7 mov %r12d,%edi
9de: 48 6b ff 78 imul $0x78,%rdi,%rdi
9e2: 48 8d 3c 3b lea (%rbx,%rdi,1),%rdi
9e6: e8 00 00 00 00 callq 9eb <xt_unregister_matches+0x22>
9eb: 45 85 e4 test %r12d,%r12d
9ee: 75 e8 jne 9d8 <xt_unregister_matches+0xf>
9f0: 5b pop %rbx
9f1: 41 5c pop %r12
9f3: c9 leaveq
9f4: c3 retq
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* RE: [patch -next] bna: off by one
From: Debashis Dutt @ 2010-09-19 0:48 UTC (permalink / raw)
To: Dan Carpenter, David S. Miller
Cc: Rasesh Mody, netdev@vger.kernel.org,
kernel-janitors@vger.kernel.org
In-Reply-To: <20100918234144.GB6236@bicker>
-----Original Message-----
From: Dan Carpenter [mailto:error27@gmail.com]
Sent: Saturday, September 18, 2010 4:42 PM
To: Rasesh Mody
Cc: Debashis Dutt; David S. Miller; netdev@vger.kernel.org; kernel-janitors@vger.kernel.org
Subject: [patch -next] bna: off by one
The mod->mbhdlr[] array has BFI_MC_MAX elements.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/net/bna/bfa_ioc.c b/drivers/net/bna/bfa_ioc.c
index caa45c2..73493de 100644
--- a/drivers/net/bna/bfa_ioc.c
+++ b/drivers/net/bna/bfa_ioc.c
@@ -1514,7 +1514,7 @@ bfa_nw_ioc_mbox_isr(struct bfa_ioc *ioc)
return;
}
- if ((mc > BFI_MC_MAX) || (mod->mbhdlr[mc].cbfn == NULL))
+ if ((mc >= BFI_MC_MAX) || (mod->mbhdlr[mc].cbfn == NULL))
return;
mod->mbhdlr[mc].cbfn(mod->mbhdlr[mc].cbarg, &m);
Dan,
Patch looks good.
Thanks
--Debashis
^ permalink raw reply related
* Re: [rfc 13/13] [RFC 13/13] IPVS: sip persistence engine
From: Simon Horman @ 2010-09-19 1:03 UTC (permalink / raw)
To: Julian Anastasov
Cc: lvs-devel, netdev, netfilter, netfilter-devel, Wensong Zhang,
Patrick McHardy
In-Reply-To: <Pine.LNX.4.58.1009181731240.8887@u.domain.uli>
On Sat, Sep 18, 2010 at 06:09:28PM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Thu, 5 Aug 2010, Simon Horman wrote:
>
> > Add the SIP callid as a key for persistence.
>
> ...
>
> > +static bool ip_vs_sip_ct_match(const struct ip_vs_conn_param *p,
> > + struct ip_vs_conn *ct)
> > +
> > +{
> > + bool ret = 0;
> > +
> > + if (ct->af == p->af &&
> > + ip_vs_addr_equal(p->af, p->caddr, &ct->caddr) &&
> > + /* protocol should only be IPPROTO_IP if
> > + * d_addr is a fwmark */
> > + ip_vs_addr_equal(p->protocol == IPPROTO_IP ? AF_UNSPEC : p->af,
> > + p->vaddr, &ct->vaddr) &&
> > + ct->vport == p->vport &&
> > + ct->flags & IP_VS_CONN_F_TEMPLATE &&
> > + ct->protocol == p->protocol &&
> > + ct->pe_data && ct->pe_data_len == p->pe_data_len &&
> > + !strnicmp(ct->pe_data, p->pe_data, p->pe_data_len))
>
> According to RFC 3261 8.1.1.4 Call-ID,
> "Call-IDs are case-sensitive and are simply compared byte-by-byte",
> so may be memcmp should be used.
>
> Also, may be ip_vs_sip_fill_param uses GFP_KERNEL in wrong
> context.
Thanks, I'll fix up both of those problems.
^ permalink raw reply
* Re: How about the order of Network stack initialize
From: Randy Dunlap @ 2010-09-19 0:53 UTC (permalink / raw)
To: Huangqiang Zhou; +Cc: ly, linux-net, netdev
In-Reply-To: <201009190848041099641@gmail.com>
On Sun, 19 Sep 2010 08:48:09 +0800 Huangqiang Zhou wrote:
> Hi:
> yes, i have found the answer.
>
> "please refer to the macro definition INITCALLS in the header file
> include/asm-generic/vmlinux.lds.h -- many definitions are moved to
> this file now." --- by Randy Dunlap
>
That answer was
From: Tony Wan <visual2me@gmail.com>
>
> 2010-09-19
>
>
>
> Huangqiang Zhou
>
>
>
> 发件人： Randy Dunlap
> 发送时间： 2010-09-18 05:19:50
> 收件人： Huangqiang Zhou
> 抄送： ly; linux-net; netdev
> 主题： Re: How about the order of Network stack initialize
>
> On Thu, 16 Sep 2010 09:06:16 +0800 Huangqiang Zhou wrote:
> > Hi all：
> >
> > I have a question about the order of network stack initialize.
> >
> > From some books it says the order is as below:
> > 1.core_initcall: sock_init
> > 2.fs_initcall: inet_init
> > 3.subsys_initcall: net_dev_init
> > 4.device_initcall: device init
> >
> > in the source code of linux2.6.18:
> > #define core_initcall(fn) __define_initcall("1",fn)
> > #define postcore_initcall(fn) __define_initcall("2",fn)
> > #define arch_initcall(fn) __define_initcall("3",fn)
> > #define subsys_initcall(fn) __define_initcall("4",fn)
> > #define fs_initcall(fn) __define_initcall("5",fn)
> > #define device_initcall(fn) __define_initcall("6",fn)
> > #define late_initcall(fn) __define_initcall("7",fn)
> >
> > obviously:
> > macro section
> > core_initcall <--> .initcall1.init
> > fs_initcall <--> .initcall5.init
> > subsys_initcall <--> .initcall4.init
> > device_intcall <--> .initcall6.init
> >
> > Some also says：
> > “Every child is to determine the sequence between sections, the first call. Initcall1 init.
> > The function pointer, again. Initcall2 init. Call the function pointer, etc. And in each section
> > of the function pointer is associated with links to order, is uncertain ”
> >
> > As the above says, the order should be: core_initcall->subsys_initcall->fs_initcall->device_intcall
> >
> > So which one is really correct?
> >
> > 2010-09-15
> > Huangqiang Zhou
> Hi,
> BTW, did you find out anything from your previous posting's answers?
> http://marc.info/?l=linux-net&m=128443018603483&w=2
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* [patch -next] rds: spin_lock_irq() is not nestable
From: Dan Carpenter @ 2010-09-18 23:44 UTC (permalink / raw)
To: Andy Grover
Cc: David S. Miller, Zach Brown, Chris Mason, rds-devel, netdev,
kernel-janitors
This is basically just a cleanup. IRQs were disabled on the previous
line so we don't need to do it again here. In the current code IRQs
would get turned on one line earlier than intended.
Signed-off-by: Dan Carpenter <error27@gmail.com>
---
Andy Grover acked part of this patch before but it didn't get pushed.
diff --git a/net/rds/ib_rdma.c b/net/rds/ib_rdma.c
index 8f6e221..b5a8841 100644
--- a/net/rds/ib_rdma.c
+++ b/net/rds/ib_rdma.c
@@ -171,9 +171,9 @@ void rds_ib_add_conn(struct rds_ib_device *rds_ibdev, struct rds_connection *con
BUG_ON(list_empty(&ic->ib_node));
list_del(&ic->ib_node);
- spin_lock_irq(&rds_ibdev->spinlock);
+ spin_lock(&rds_ibdev->spinlock);
list_add_tail(&ic->ib_node, &rds_ibdev->conn_list);
- spin_unlock_irq(&rds_ibdev->spinlock);
+ spin_unlock(&rds_ibdev->spinlock);
spin_unlock_irq(&ib_nodev_conns_lock);
ic->rds_ibdev = rds_ibdev;
diff --git a/net/rds/iw_rdma.c b/net/rds/iw_rdma.c
index 4e152e2..0e7accc 100644
--- a/net/rds/iw_rdma.c
+++ b/net/rds/iw_rdma.c
@@ -206,9 +206,9 @@ void rds_iw_add_conn(struct rds_iw_device *rds_iwdev, struct rds_connection *con
BUG_ON(list_empty(&ic->iw_node));
list_del(&ic->iw_node);
- spin_lock_irq(&rds_iwdev->spinlock);
+ spin_lock(&rds_iwdev->spinlock);
list_add_tail(&ic->iw_node, &rds_iwdev->conn_list);
- spin_unlock_irq(&rds_iwdev->spinlock);
+ spin_unlock(&rds_iwdev->spinlock);
spin_unlock_irq(&iw_nodev_conns_lock);
ic->rds_iwdev = rds_iwdev;
^ permalink raw reply related
* [patch -next] rds: double unlock in rds_ib_cm_handle_connect()
From: Dan Carpenter @ 2010-09-18 23:42 UTC (permalink / raw)
To: Andy Grover
Cc: David S. Miller, Zach Brown, Julia Lawall, Tejun Heo, rds-devel,
netdev, kernel-janitors
We unlock after we goto out.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/net/rds/ib_cm.c b/net/rds/ib_cm.c
index bc3dbc1..ee369d2 100644
--- a/net/rds/ib_cm.c
+++ b/net/rds/ib_cm.c
@@ -521,7 +521,6 @@ int rds_ib_cm_handle_connect(struct rdma_cm_id *cm_id,
err = rds_ib_setup_qp(conn);
if (err) {
rds_ib_conn_error(conn, "rds_ib_setup_qp failed (%d)\n", err);
- mutex_unlock(&conn->c_cm_lock);
goto out;
}
^ permalink raw reply related
* [patch -next] rds: signedness bug
From: Dan Carpenter @ 2010-09-18 23:42 UTC (permalink / raw)
To: Andy Grover; +Cc: David S. Miller, rds-devel, netdev, kernel-janitors
In the original code if the copy_from_user() fails in rds_rdma_pages()
then the error handling fails and we get a stack trace from kmalloc().
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/net/rds/rdma.c b/net/rds/rdma.c
index 4806467..1a41deb 100644
--- a/net/rds/rdma.c
+++ b/net/rds/rdma.c
@@ -522,7 +522,7 @@ int rds_cmsg_rdma_args(struct rds_sock *rs, struct rds_message *rm,
struct rds_rdma_args *args;
struct rds_iovec vec;
struct rm_rdma_op *op = &rm->rdma;
- unsigned int nr_pages;
+ int nr_pages;
unsigned int nr_bytes;
struct page **pages = NULL;
struct rds_iovec __user *local_vec;
^ permalink raw reply related
* [patch -next] bna: off by one
From: Dan Carpenter @ 2010-09-18 23:41 UTC (permalink / raw)
To: Rasesh Mody; +Cc: Debashis Dutt, David S. Miller, netdev, kernel-janitors
The mod->mbhdlr[] array has BFI_MC_MAX elements.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/net/bna/bfa_ioc.c b/drivers/net/bna/bfa_ioc.c
index caa45c2..73493de 100644
--- a/drivers/net/bna/bfa_ioc.c
+++ b/drivers/net/bna/bfa_ioc.c
@@ -1514,7 +1514,7 @@ bfa_nw_ioc_mbox_isr(struct bfa_ioc *ioc)
return;
}
- if ((mc > BFI_MC_MAX) || (mod->mbhdlr[mc].cbfn == NULL))
+ if ((mc >= BFI_MC_MAX) || (mod->mbhdlr[mc].cbfn == NULL))
return;
mod->mbhdlr[mc].cbfn(mod->mbhdlr[mc].cbarg, &m);
^ permalink raw reply related
* Fw: Kernel panic in 2.6.36-rc4 after suspend/resume
From: Josh Cartwright @ 2010-09-18 21:47 UTC (permalink / raw)
To: Johannes Berg, John W. Linville, David S. Miller
Cc: linux-wireless, linux-kernel, netdev
<Forwarding to relevant maintainers (get_maintainer.pl -f net/mac80211/agg-tx.c)>
From: vaibhav agarwal <vaibhav_agrwal@yahoo.co.in>
Subject: Re: Kernel panic in 2.6.36-rc4 after suspend/resume
Date: Sat, 18 Sep 2010 15:09:29 +0530 (IST)
To: linux-kernel@vger.kernel.org
X-Mailer: YahooMailRC/497 YahooMailWebService/0.8.105.279950
Hi,
I am using kernel 2.6.34-rc4 directly taken from kernel.org. After suspend to
ram if I leave it for few hours and resume then kernel panic happens (screen of
death). If I suspend and resume immediately then it works fine.
I have hand copied the message and attached in this mail. Let me know what other
information is needed from my side.
I can file bug in kernel bugzilla if needed. As per kernel oops docs, I am
sending a mail here.
(Its a intel Dual Core machine)
-vaibhav
Modules linked in: btusb i915 drm_kms_helper drm i2c_algo_bit sco acpi_cpufreq
mperf rfcomm bnep cpufreq_powersave l2cap crc16 bluetooth cpufreq_userspace
cpufreq_conservative cpufreq_stats nfsd exportfs nfs lockd fscache nfs_acl
auth_rpcgss sunrpc aes_1586 aes_generic fuse loop arc4 ecb ath9k mac80211
snd_hda_codec_intelhdmi ath9k common snd_hda_codec_realtek ath9k_hw ath
snd_hda_codec snd_hwdep cfg90211 snd_pcm_oss snd_mixer_oss snd_pcm intel_agp
snd_seq_midi jmb38x_ms uvcvideo videodev snd_rawmidi snd_seq_midi_event joydev
v4l1_compat rfkill memstick snd_seq shpchp evdev tpm_tis tpm agppart tpm_bios
video battery processor ac snd_timer snd_seq_device psmouse snd serio_raw pcspkr
i2c_i801 i2c_core soundcore pci_hotplug output snd_page_alloc wmi button ext3
jbd mbcache sg sr_mod cdrom crc_t10dif uhci_hcd ahci libahci libata ehci_hcd
sdhci_pci sdhci atl1e thermal mmc_core led_class scsi_mod thermal_sys usbcore
nls_base [last unloaded: scsi_wait_scan]
Pid: 0, comm: swapper Not tainted 2.6.36-rc4-custom #18 Aspire 4736Z /Aspire
4736Z
EIP: 0060:[<f83de653>] Eflags: 00010206 CPU: 0
EIP is ay sta_addba_resp_timer_expired+0x17/0x28 [max80211]
EAX: f4b8ff6c EBS: f36b7848 ECX: 052f0000 EDX: 00000094
ESI: c04fd340 EDI: 00000001 EBP: 00000100 ESP: c0431eec
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process swapper (pid: 0, ti=c0430000 task=c043ff20 task.ti=c0430000)
Stack:
c013908f c0431f0c f83de63c c04fdb50 c04fdd50 c04fdf50 c04fe150 f4b901a0
<0> c0431f0c c0431f0c 00000046 00000004 00000001 00000100 c0133eb4 00000001
<0> 0000000a c0435a04 c04c1dec 00000000 00000046 00000000 00000000 c0431f70
Call Trace:
[<c013908f>] ? run_timer_softirq+0x16f/0x213
[<f83de63c>] ? sta_addba_resp_timer_expired+0x0/0x28 [mac80211]
[<c0133eb4>] ? __do_softirq+0xb1/0x156
[<c0133f87>] ? do_softirq+0x2e/0x38
[<c0134085>] ? irq_exit+0x26/0x58
[<c01043d0>] ? do_IRQ+0x7d/0x8e
[<c01033a9>] ? common_interrupt+0x29/0x30
[<f8534f9d>] ? acpi_idle_enter_simple+0xec/0x129 [processor]
[<c02b34ae>] ? cpuidle_idle_call+0x77/0xd5
[<c01021c6>] ? cpu_idle+0x49/0x8b
[<c046883e>] ? start_kernel+0x2d4/0x2d7
Code: e8 2f c4 f7 c7 eb 05 bd ea ff ff ff 5e 89 e8 5b 5e 5f 5d c3 0f b6 10 29 d0
2d a0 01 00 00 8d 8c 90 4c 01 00 00 8b 09 85 c9 74 10 <f6> 41 4c 02 75 0a 05 b0
01 00 00 e9 5f ff ff ff c3 55 89 cd 57
EIP: [<f83de653>] sta_addba_resp_expired+0x17/0x28 [max80211] SS:ESP
0068:c0431eec
CR2: 00000000052f004c
---[ end trace c7cc1d8c9381c37c ]---
Kernel panic - not syncing: Fatal exception in interrupt
Pid: 0, comm: swapper Tainted: G D 2.6.36-rc4-custom #18
Call Trace:
[<c03591ba>] ? panic+0x4d/0x13a
[<c0105692>] ? oops_end+0x8e/0x99
[<c011d6c4>] ? no_context+0x10d/0x116
[<c011da13>] ? do_page_fault+0x0/0x24d
[<c011d7d2>] ? bad_area_nosemaphore+0xa/0xc
[<c035b316>] ? error_code+0x5a/0x60
[<c011da13>] ? do_page_fault+0x0/0x24d
[<f83de653>] ? sta_addba_resp_timer_expired+0x17/0x28 [mac80211]
[<c013908f>] ? run_timer_softirq+0x16f/0x213
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
----- End forwarded message -----
^ 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