* Re: [PATCH v2] ipv4: Early TCP socket demux.
From: Ben Hutchings @ 2012-06-20 0:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120619.163911.2094057156011157978.davem@davemloft.net>
On Tue, 2012-06-19 at 16:39 -0700, David Miller wrote:
> Input packet processing for local sockets involves two major demuxes.
> One for the route and one for the socket.
>
> But we can optimize this down to one demux for certain kinds of local
> sockets.
[...]
> --- a/net/ipv4/ip_input.c
> +++ b/net/ipv4/ip_input.c
> @@ -324,19 +324,34 @@ static int ip_rcv_finish(struct sk_buff *skb)
> * how the packet travels inside Linux networking.
> */
> if (skb_dst(skb) == NULL) {
> - int err = ip_route_input_noref(skb, iph->daddr, iph->saddr,
> - iph->tos, skb->dev);
> - if (unlikely(err)) {
> - if (err == -EHOSTUNREACH)
> - IP_INC_STATS_BH(dev_net(skb->dev),
> - IPSTATS_MIB_INADDRERRORS);
> - else if (err == -ENETUNREACH)
> - IP_INC_STATS_BH(dev_net(skb->dev),
> - IPSTATS_MIB_INNOROUTES);
> - else if (err == -EXDEV)
> - NET_INC_STATS_BH(dev_net(skb->dev),
> - LINUX_MIB_IPRPFILTER);
> - goto drop;
> + const struct net_protocol *ipprot;
> + int protocol = iph->protocol;
> + int hash, err;
> +
> + hash = protocol & (MAX_INET_PROTOS - 1);
[...]
This 'hashing' threw me when I read v1, because nowhere do we actually
check that the protocol (as opposed to hash) matches that for the
selected ipprot. (And this also turns out to be true for the current
receive path.)
This works only because MAX_INET_PROTOS is defined as 256, so that hash
== protocol. If we were ever to change MAX_INET_PROTOS then we would
need to add a whole lot of protocol checks, but this isn't particularly
obvious! Perhaps it would be better to remove the 'hashing' altogether?
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH v2] ipv4: Early TCP socket demux.
From: David Miller @ 2012-06-19 23:39 UTC (permalink / raw)
To: netdev
Input packet processing for local sockets involves two major demuxes.
One for the route and one for the socket.
But we can optimize this down to one demux for certain kinds of local
sockets.
Currently we only do this for established TCP sockets, but it could
at least in theory be expanded to other kinds of connections.
If a TCP socket is established then it's identity is fully specified.
This means that whatever input route was used during the three-way
handshake must work equally well for the rest of the connection since
the keys will not change.
Once we move to established state, we cache the receive packet's input
route to use later.
Like the existing cached route in sk->sk_dst_cache used for output
packets, we have to check for route invalidations using dst->obsolete
and dst->ops->check().
Early demux occurs outside of a socket locked section, so when a route
invalidation occurs we defer the fixup of sk->sk_rx_dst until we are
actually inside of established state packet processing and thus have
the socket locked.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
Changes since v1:
1) Remove unlikely() from __inet_lookup_skb()
2) Check for cached route invalidations.
3) Hook up RX dst when outgoing connection moved to established too,
previously it was only handling incoming connections.
diff --git a/include/net/inet_hashtables.h b/include/net/inet_hashtables.h
index 808fc5f..54be028 100644
--- a/include/net/inet_hashtables.h
+++ b/include/net/inet_hashtables.h
@@ -379,10 +379,10 @@ static inline struct sock *__inet_lookup_skb(struct inet_hashinfo *hashinfo,
const __be16 sport,
const __be16 dport)
{
- struct sock *sk;
+ struct sock *sk = skb_steal_sock(skb);
const struct iphdr *iph = ip_hdr(skb);
- if (unlikely(sk = skb_steal_sock(skb)))
+ if (sk)
return sk;
else
return __inet_lookup(dev_net(skb_dst(skb)->dev), hashinfo,
diff --git a/include/net/protocol.h b/include/net/protocol.h
index 875f489..6c47bf8 100644
--- a/include/net/protocol.h
+++ b/include/net/protocol.h
@@ -34,6 +34,7 @@
/* This is used to register protocols. */
struct net_protocol {
+ int (*early_demux)(struct sk_buff *skb);
int (*handler)(struct sk_buff *skb);
void (*err_handler)(struct sk_buff *skb, u32 info);
int (*gso_send_check)(struct sk_buff *skb);
diff --git a/include/net/sock.h b/include/net/sock.h
index 4a45216..87b424a 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -319,6 +319,7 @@ struct sock {
unsigned long sk_flags;
struct dst_entry *sk_dst_cache;
spinlock_t sk_dst_lock;
+ struct dst_entry *sk_rx_dst;
atomic_t sk_wmem_alloc;
atomic_t sk_omem_alloc;
int sk_sndbuf;
@@ -1426,6 +1427,7 @@ extern struct sk_buff *sock_rmalloc(struct sock *sk,
gfp_t priority);
extern void sock_wfree(struct sk_buff *skb);
extern void sock_rfree(struct sk_buff *skb);
+extern void sock_edemux(struct sk_buff *skb);
extern int sock_setsockopt(struct socket *sock, int level,
int op, char __user *optval,
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 9332f34..6660ffc 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -325,6 +325,7 @@ extern void tcp_v4_err(struct sk_buff *skb, u32);
extern void tcp_shutdown (struct sock *sk, int how);
+extern int tcp_v4_early_demux(struct sk_buff *skb);
extern int tcp_v4_rcv(struct sk_buff *skb);
extern struct inet_peer *tcp_v4_get_peer(struct sock *sk);
diff --git a/net/core/sock.c b/net/core/sock.c
index 9e5b71f..929bdcc 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1465,6 +1465,11 @@ void sock_rfree(struct sk_buff *skb)
}
EXPORT_SYMBOL(sock_rfree);
+void sock_edemux(struct sk_buff *skb)
+{
+ sock_put(skb->sk);
+}
+EXPORT_SYMBOL(sock_edemux);
int sock_i_uid(struct sock *sk)
{
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index e4e8e00..a2bd2d2 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -157,6 +157,7 @@ void inet_sock_destruct(struct sock *sk)
kfree(rcu_dereference_protected(inet->inet_opt, 1));
dst_release(rcu_dereference_check(sk->sk_dst_cache, 1));
+ dst_release(sk->sk_rx_dst);
sk_refcnt_debug_dec(sk);
}
EXPORT_SYMBOL(inet_sock_destruct);
@@ -1520,14 +1521,15 @@ static const struct net_protocol igmp_protocol = {
#endif
static const struct net_protocol tcp_protocol = {
- .handler = tcp_v4_rcv,
- .err_handler = tcp_v4_err,
- .gso_send_check = tcp_v4_gso_send_check,
- .gso_segment = tcp_tso_segment,
- .gro_receive = tcp4_gro_receive,
- .gro_complete = tcp4_gro_complete,
- .no_policy = 1,
- .netns_ok = 1,
+ .early_demux = tcp_v4_early_demux,
+ .handler = tcp_v4_rcv,
+ .err_handler = tcp_v4_err,
+ .gso_send_check = tcp_v4_gso_send_check,
+ .gso_segment = tcp_tso_segment,
+ .gro_receive = tcp4_gro_receive,
+ .gro_complete = tcp4_gro_complete,
+ .no_policy = 1,
+ .netns_ok = 1,
};
static const struct net_protocol udp_protocol = {
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 8590144..cb883e1 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -324,19 +324,34 @@ static int ip_rcv_finish(struct sk_buff *skb)
* how the packet travels inside Linux networking.
*/
if (skb_dst(skb) == NULL) {
- int err = ip_route_input_noref(skb, iph->daddr, iph->saddr,
- iph->tos, skb->dev);
- if (unlikely(err)) {
- if (err == -EHOSTUNREACH)
- IP_INC_STATS_BH(dev_net(skb->dev),
- IPSTATS_MIB_INADDRERRORS);
- else if (err == -ENETUNREACH)
- IP_INC_STATS_BH(dev_net(skb->dev),
- IPSTATS_MIB_INNOROUTES);
- else if (err == -EXDEV)
- NET_INC_STATS_BH(dev_net(skb->dev),
- LINUX_MIB_IPRPFILTER);
- goto drop;
+ const struct net_protocol *ipprot;
+ int protocol = iph->protocol;
+ int hash, err;
+
+ hash = protocol & (MAX_INET_PROTOS - 1);
+
+ rcu_read_lock();
+ ipprot = rcu_dereference(inet_protos[hash]);
+ err = -ENOENT;
+ if (ipprot && ipprot->early_demux)
+ err = ipprot->early_demux(skb);
+ rcu_read_unlock();
+
+ if (err) {
+ err = ip_route_input_noref(skb, iph->daddr, iph->saddr,
+ iph->tos, skb->dev);
+ if (unlikely(err)) {
+ if (err == -EHOSTUNREACH)
+ IP_INC_STATS_BH(dev_net(skb->dev),
+ IPSTATS_MIB_INADDRERRORS);
+ else if (err == -ENETUNREACH)
+ IP_INC_STATS_BH(dev_net(skb->dev),
+ IPSTATS_MIB_INNOROUTES);
+ else if (err == -EXDEV)
+ NET_INC_STATS_BH(dev_net(skb->dev),
+ LINUX_MIB_IPRPFILTER);
+ goto drop;
+ }
}
}
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index b224eb8..8416f8a 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5518,6 +5518,18 @@ int tcp_rcv_established(struct sock *sk, struct sk_buff *skb,
struct tcp_sock *tp = tcp_sk(sk);
int res;
+ if (sk->sk_rx_dst) {
+ struct dst_entry *dst = sk->sk_rx_dst;
+ if (unlikely(dst->obsolete)) {
+ if (dst->ops->check(dst, 0) == NULL) {
+ dst_release(dst);
+ sk->sk_rx_dst = NULL;
+ }
+ }
+ }
+ if (unlikely(sk->sk_rx_dst == NULL))
+ sk->sk_rx_dst = dst_clone(skb_dst(skb));
+
/*
* Header prediction.
* The code loosely follows the one in the famous
@@ -5729,8 +5741,10 @@ void tcp_finish_connect(struct sock *sk, struct sk_buff *skb)
tcp_set_state(sk, TCP_ESTABLISHED);
- if (skb != NULL)
+ if (skb != NULL) {
+ sk->sk_rx_dst = dst_clone(skb_dst(skb));
security_inet_conn_established(sk, skb);
+ }
/* Make sure socket is routed, for correct metrics. */
icsk->icsk_af_ops->rebuild_header(sk);
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index fda2ca1..13857df 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1671,6 +1671,52 @@ csum_err:
}
EXPORT_SYMBOL(tcp_v4_do_rcv);
+int tcp_v4_early_demux(struct sk_buff *skb)
+{
+ struct net *net = dev_net(skb->dev);
+ const struct iphdr *iph;
+ const struct tcphdr *th;
+ struct sock *sk;
+ int err;
+
+ err = -ENOENT;
+ if (skb->pkt_type != PACKET_HOST)
+ goto out_err;
+
+ if (!pskb_may_pull(skb, ip_hdrlen(skb) + sizeof(struct tcphdr)))
+ goto out_err;
+
+ iph = ip_hdr(skb);
+ th = (struct tcphdr *) ((char *)iph + ip_hdrlen(skb));
+
+ if (th->doff < sizeof(struct tcphdr) / 4)
+ goto out_err;
+
+ if (!pskb_may_pull(skb, ip_hdrlen(skb) + th->doff * 4))
+ goto out_err;
+
+ sk = __inet_lookup_established(net, &tcp_hashinfo,
+ iph->saddr, th->source,
+ iph->daddr, th->dest,
+ skb->dev->ifindex);
+ if (sk) {
+ skb->sk = sk;
+ skb->destructor = sock_edemux;
+ if (sk->sk_state != TCP_TIME_WAIT) {
+ struct dst_entry *dst = sk->sk_rx_dst;
+ if (dst)
+ dst = dst_check(dst, 0);
+ if (dst) {
+ skb_dst_set_noref(skb, dst);
+ err = 0;
+ }
+ }
+ }
+
+out_err:
+ return err;
+}
+
/*
* From tcp_input.c
*/
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index cb01531..72b7c63 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -445,6 +445,8 @@ struct sock *tcp_create_openreq_child(struct sock *sk, struct request_sock *req,
struct tcp_sock *oldtp = tcp_sk(sk);
struct tcp_cookie_values *oldcvp = oldtp->cookie_values;
+ newsk->sk_rx_dst = dst_clone(skb_dst(skb));
+
/* TCP Cookie Transactions require space for the cookie pair,
* as it differs for each connection. There is no need to
* copy any s_data_payload stored at the original socket.
^ permalink raw reply related
* Re: [PATCH net-next] ixgbe: simplify padding and length checks (v2)
From: Jeff Kirsher @ 2012-06-19 23:30 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Alexander Duyck, Bruce Allan, Carolyn Wyborny, Don Skidmore,
Greg Rose, Peter P Waskiewicz Jr, David S. Miller, e1000-devel,
netdev
In-Reply-To: <20120618163111.4e46493b@nehalam.linuxnetplumber.net>
[-- Attachment #1: Type: text/plain, Size: 548 bytes --]
On Mon, 2012-06-18 at 16:31 -0700, Stephen Hemminger wrote:
> The check for length <= 0 is bogus because length is unsigned, and
> network
> stack never sends zero length packets (unless it is totally broken).
>
> The check for really small packets can be optimized (using unlikely)
> and calling skb_pad directly.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
I just realized I had not responded to this updated patch.
Thanks Stephen, I have dropped your previous 2 patch series and added
this patch to my queue.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: [RFC net-next 11/14] Fix emulex/benet
From: Ajit.Khaparde @ 2012-06-19 22:55 UTC (permalink / raw)
To: yuvalmin, netdev, davem; +Cc: eilong, Sathya.Perla, subbu.seetharaman
In-Reply-To: <1340118848-30978-12-git-send-email-yuvalmin@broadcom.com>
> From: Yuval Mintz [yuvalmin@broadcom.com]
> Sent: Tuesday, June 19, 2012 10:14 AM
> To: netdev@vger.kernel.org; davem@davemloft.net
> Cc: eilong@broadcom.com; Yuval Mintz; Perla, Sathya; Seetharaman, Subramanian; Khaparde, Ajit
> Subject: [RFC net-next 11/14] Fix emulex/benet
> Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
> Cc: Sathya Perla <sathya.perla@emulex.com>
> Cc: Subbu Seetharaman <subbu.seetharaman@emulex.com>
> Cc: Ajit Khaparde <ajit.khaparde@emulex.com>
> ---
> drivers/net/ethernet/emulex/benet/be_main.c | 8 +++++---
> 1 files changed, 5 insertions(+), 3 deletions(-)
We will get back to you on this later in the day.
Thanks
-Ajit
^ permalink raw reply
* Re: [PATCH net-next 0/5] qmi_wwan fixes for 3.6
From: David Miller @ 2012-06-19 22:04 UTC (permalink / raw)
To: oneukum-l3A5Bk7waGM
Cc: bjorn-yOkvZcmFvRU, netdev-u79uwXL29TY76Z2rM5mHXA,
dcbw-H+wXaHxf7aLQT0dZR+AlfA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
ajb-5+cxppFmGx6/3pe1ocb+s/XRex20P6io
In-Reply-To: <201206191253.17413.oneukum-l3A5Bk7waGM@public.gmane.org>
From: Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org>
Date: Tue, 19 Jun 2012 12:53:17 +0200
> Am Dienstag, 19. Juni 2012, 12:41:58 schrieb Bjørn Mork:
>> The two first patches prepare the driver for the new probing
>> model introduced by patch #3, which is the main change in this
>> set. A RFC version of this was posted to linux-usb 29 May 2012
>> for discussion, as it also implicitly affects the cdc-wdm driver,
>> without any comments so far.
>
> Looking good.
All applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch net-next 00/19] team: couple of patches
From: David Miller @ 2012-06-19 22:01 UTC (permalink / raw)
To: jpirko; +Cc: netdev, eric.dumazet, jbrouer
In-Reply-To: <1340121261-2966-1-git-send-email-jpirko@redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Tue, 19 Jun 2012 17:54:02 +0200
> The main impact is this patchset provides an implementation of userspace driven
> TX loadbalancing for team driver.
>
> Also couple of typos are fixed, minor issues fixes.
Looks good, pushed, thanks Jiri.
^ permalink raw reply
* Re: pull-request: can-next 2012-06-19
From: David Miller @ 2012-06-19 22:01 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can
In-Reply-To: <20120619.145907.521642979191972656.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 19 Jun 2012 14:59:07 -0700 (PDT)
> From: David Miller <davem@davemloft.net>
> Date: Tue, 19 Jun 2012 14:48:45 -0700 (PDT)
>
>> From: Marc Kleine-Budde <mkl@pengutronix.de>
>> Date: Tue, 19 Jun 2012 22:01:56 +0200
>>
>>> here is our second pull request for net-next. In this series Federico
>>> Vaga adds a pci driver for c_can/d_can hardware using the existing
>>> generic c_can driver. The remaining 6 patches are by Oliver Hartkopp.
>>> He adds CANFD support to the CAN stack while keeping binary
>>> compatibility for existing applications. CANFD is an extension to the
>>> existing CAN standard, it allows longer CAN frames and/or higher data
>>> rates. There's no real hardware available yet, but this series adds
>>> CANFD support to the vcan driver.
>>
>> Pulled, thanks.
>
> I have to unpull, the new driver results in undefined symbols.
>
> ERROR: "clk_get_rate" [drivers/net/can/c_can/c_can_pci.ko] undefined!
> ERROR: "clk_get" [drivers/net/can/c_can/c_can_pci.ko] undefined!
> ERROR: "clk_put" [drivers/net/can/c_can/c_can_pci.ko] undefined!
Actually I can't un-pull since I already pushed it out to my
tree.
Send me a fix for this bug, fast.
Thanks.
^ permalink raw reply
* Re: pull-request: can-next 2012-06-19
From: David Miller @ 2012-06-19 21:59 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can
In-Reply-To: <20120619.144845.390201286413906004.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 19 Jun 2012 14:48:45 -0700 (PDT)
> From: Marc Kleine-Budde <mkl@pengutronix.de>
> Date: Tue, 19 Jun 2012 22:01:56 +0200
>
>> here is our second pull request for net-next. In this series Federico
>> Vaga adds a pci driver for c_can/d_can hardware using the existing
>> generic c_can driver. The remaining 6 patches are by Oliver Hartkopp.
>> He adds CANFD support to the CAN stack while keeping binary
>> compatibility for existing applications. CANFD is an extension to the
>> existing CAN standard, it allows longer CAN frames and/or higher data
>> rates. There's no real hardware available yet, but this series adds
>> CANFD support to the vcan driver.
>
> Pulled, thanks.
I have to unpull, the new driver results in undefined symbols.
ERROR: "clk_get_rate" [drivers/net/can/c_can/c_can_pci.ko] undefined!
ERROR: "clk_get" [drivers/net/can/c_can/c_can_pci.ko] undefined!
ERROR: "clk_put" [drivers/net/can/c_can/c_can_pci.ko] undefined!
^ permalink raw reply
* Re: [PATCH net] batman-adv: fix skb->data assignment
From: David Miller @ 2012-06-19 21:49 UTC (permalink / raw)
To: ordex; +Cc: netdev, b.a.t.m.a.n, stable
In-Reply-To: <1340133999-26838-1-git-send-email-ordex@autistici.org>
From: Antonio Quartulli <ordex@autistici.org>
Date: Tue, 19 Jun 2012 21:26:39 +0200
> skb_linearize(skb) possibly rearranges the skb internal data and then changes
> the skb->data pointer value. For this reason any other pointer in the code that
> was assigned skb->data before invoking skb_linearise(skb) must be re-assigned.
>
> In the current tt_query message handling code this is not done and therefore, in
> case of skb linearization, the pointer used to handle the packet header ends up
> in pointing to free'd memory.
>
> This bug was introduced by a73105b8d4c765d9ebfb664d0a66802127d8e4c7
> (batman-adv: improved client announcement mechanism)
>
> Signed-off-by: Antonio Quartulli <ordex@autistici.org>
> Cc: <stable@vger.kernel.org>
Applied.
Submit things properly in the future so you don't give me unnecessary
merge hassles like this again.
^ permalink raw reply
* Re: pull-request: can-next 2012-06-19
From: David Miller @ 2012-06-19 21:48 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can
In-Reply-To: <4FE0DAB4.6080400@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Tue, 19 Jun 2012 22:01:56 +0200
> here is our second pull request for net-next. In this series Federico
> Vaga adds a pci driver for c_can/d_can hardware using the existing
> generic c_can driver. The remaining 6 patches are by Oliver Hartkopp.
> He adds CANFD support to the CAN stack while keeping binary
> compatibility for existing applications. CANFD is an extension to the
> existing CAN standard, it allows longer CAN frames and/or higher data
> rates. There's no real hardware available yet, but this series adds
> CANFD support to the vcan driver.
Pulled, thanks.
^ permalink raw reply
* Re: pull request: wireless-next 2012-06-19
From: David Miller @ 2012-06-19 21:38 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20120619195757.GA7466@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 19 Jun 2012 15:57:57 -0400
> This is a sizeable batch of updates intended for 3.6...
>
> The bulk of the changes here are Bluetooth. Gustavo says:
>
> Here goes the first Bluetooth pull request for 3.6, we have
> queued quite a lot of work. Andrei Emeltchenko added the AMP
> Manager code, a lot of work is needed, but the first bit are
> already there. This code is disabled by default. Mat Martineau
> changed the whole L2CAP ERTM state machine code, replacing
> the old one with a new implementation. Besides that we had
> lot of coding style fixes (to follow net rules), more l2cap
> core separation from socket and many clean ups and fixed all
> over the tree.
>
> Along with the above, there is a healthy dose of ath9k, iwlwifi,
> and other driver updates. There is also another pull from the
> wireless tree to resolve some merge issues. I also fixed-up some
> merge discrepencies between net-next and wireless-next.
>
> Please let me know if there are problems!
Pulled, thanks JOhn.
^ permalink raw reply
* Re: [net-next patch 0/11 v2] bnx2x: ethtool and other enhancements
From: David Miller @ 2012-06-19 21:35 UTC (permalink / raw)
To: meravs; +Cc: netdev, eilong
In-Reply-To: <1340104634-14353-1-git-send-email-meravs@broadcom.com>
From: "Merav Sicron" <meravs@broadcom.com>
Date: Tue, 19 Jun 2012 14:17:03 +0300
> This patch series adds few features to bnx2x:
> Add support for external LB in ethtool self-test
> Enable UDP RSS on 4-tupple, controlled by ethtool
> Support up to 63 RSS queues (rather than 16)
> Add support for setting the desired number of RSS queues via ethtool
> Allow to configure dcbx admin params from all drivers on a single physical port
> Add FCoE capabilities advertisement
All applied, thanks.
^ permalink raw reply
* Re: 10GBE performance drop with net.ipv4.tcp_timestamps=0
From: Eric Dumazet @ 2012-06-19 21:31 UTC (permalink / raw)
To: Stefan Priebe; +Cc: Linux Netdev List
In-Reply-To: <4FE0EA33.1000309@profihost.ag>
On Tue, 2012-06-19 at 23:08 +0200, Stefan Priebe wrote:
> Hello List,
>
> i'm testing 10GBE speed with tweo servers. One with 3.5-rc3 nd thoe
> other one whith RHEL 6 (2.6.32 kernel).
>
> I noticed that setting
> net.ipv4.tcp_timestamps=0
>
> descreased the performance from 9,7 Full Duplex to 3-4Gb/s.
>
> Is this bahviour fine? What should / could i tet?
>
Really, you should provide more input than that, if you really want us
to help.
^ permalink raw reply
* Re: [PATCH net] batman-adv: fix skb->data assignment
From: David Miller @ 2012-06-19 21:28 UTC (permalink / raw)
To: ordex; +Cc: netdev, b.a.t.m.a.n, stable
In-Reply-To: <1340133999-26838-1-git-send-email-ordex@autistici.org>
From: Antonio Quartulli <ordex@autistici.org>
Date: Tue, 19 Jun 2012 21:26:39 +0200
> This patch has already been merged in net-next. I am sorry about that, but we
> were missing some knowledge about sending patches for stable.
You really like making my life miserable.
What is so damn complicated about:
1) BUG FIXES go to 'net'
2) NON BUG FIXES go to 'net-next'
This gets stated repeatedly here.
I do see you guys erroneously submit bug fixes into net-next all
the time but I just assumed you simply didn't give a shit about
bug fixes propagating quickly.
You guys definitely need to get your asses in gear.
^ permalink raw reply
* Re: [RFC] TCP: Support configurable delayed-ack parameters.
From: Ben Greear @ 2012-06-19 21:27 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev, dbaluta
In-Reply-To: <20120619.142158.2026176205742396086.davem@davemloft.net>
On 06/19/2012 02:21 PM, David Miller wrote:
> From: Ben Greear<greearb@candelatech.com>
> Date: Tue, 19 Jun 2012 09:11:59 -0700
>
>> Dave..any opinion on this? I'll be happy to get rid of the
>> multiply caching if it's agreed that it should not be there.
>
> I disagree fundamentally with the feature.
>
> I can't believe for one minute that we can't do ACK stretching
> dynamically using reasonable heuristics.
>
> And, as Stephen said, we already have too many damn knobs.
Ok...I'll let someone else take a stab at that.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [RFC net-next 01/14] Add Default
From: David Miller @ 2012-06-19 21:26 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: eilong, yuvalmin, netdev
In-Reply-To: <4FE0CCA2.304@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Tue, 19 Jun 2012 12:01:54 -0700
> There is a huge difference between a kernel parameter an a kconfig
> value. The main idea behind the kconfig value is that you are going to
> have different preferences depending on architectures and such so it
> would make much more sense to have the default as a config option.
I don't think the issue of how many queues to use in a network driver
when you have 1024 cpus is architecture specific.
Please drop this idea, thanks.
^ permalink raw reply
* Re: [RFC net-next 01/14] Add Default
From: David Miller @ 2012-06-19 21:22 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: yuvalmin, netdev, eilong
In-Reply-To: <4FE0AABE.4070100@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Tue, 19 Jun 2012 09:37:18 -0700
> I'm not a big fan of just having this as a fixed define in the code. It
> seems like it would make much more sense to have this in the Kconfig
> somewhere as a range value if you plan on making this changeable in the
> future.
Please not Kconfig :-/
^ permalink raw reply
* Re: [RFC] TCP: Support configurable delayed-ack parameters.
From: David Miller @ 2012-06-19 21:21 UTC (permalink / raw)
To: greearb; +Cc: eric.dumazet, netdev, dbaluta
In-Reply-To: <4FE0A4CF.6000906@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Date: Tue, 19 Jun 2012 09:11:59 -0700
> Dave..any opinion on this? I'll be happy to get rid of the
> multiply caching if it's agreed that it should not be there.
I disagree fundamentally with the feature.
I can't believe for one minute that we can't do ACK stretching
dynamically using reasonable heuristics.
And, as Stephen said, we already have too many damn knobs.
^ permalink raw reply
* Re: [PATCH] ipv6: Prevent access to uninitialized fib_table_hash via /proc/net/ipv6_route
From: David Miller @ 2012-06-19 21:13 UTC (permalink / raw)
To: tgraf; +Cc: nhorman, netdev
In-Reply-To: <20120619113602.GG27921@canuck.infradead.org>
From: Thomas Graf <tgraf@suug.ch>
Date: Tue, 19 Jun 2012 07:36:02 -0400
> On Fri, Jun 15, 2012 at 03:32:40PM -0700, David Miller wrote:
>> Since you're snooping around in here, you might notice that on network
>> namespace shutdown, we leak all user configured ipv6 FIB rules.
>
> I looked into this. fib_rules_unregister() will free all rules
> belonging to the address family in that namespace.
>
> Or were you referring to other rules?
Sorry, the leak I saw was for the fib6 tables, not the rules
themselves.
IPV4 has ip_fib_net_exit() which walks the FIB4 table hash
and releases everything.
I couldn't find the IPV6 counterpart. All I could find was code which
explicitly liberates the ipv6 main and local tables.
There is no ipv6 code I can find which traverses fib_table_hash and
liberates the dynamically generated tables.
^ permalink raw reply
* 10GBE performance drop with net.ipv4.tcp_timestamps=0
From: Stefan Priebe @ 2012-06-19 21:08 UTC (permalink / raw)
To: Linux Netdev List
Hello List,
i'm testing 10GBE speed with tweo servers. One with 3.5-rc3 nd thoe
other one whith RHEL 6 (2.6.32 kernel).
I noticed that setting
net.ipv4.tcp_timestamps=0
descreased the performance from 9,7 Full Duplex to 3-4Gb/s.
Is this bahviour fine? What should / could i tet?
Greets
Stefan
^ permalink raw reply
* pull-request: can-next 2012-06-19
From: Marc Kleine-Budde @ 2012-06-19 20:01 UTC (permalink / raw)
To: davem; +Cc: Linux Netdev List, linux-can@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 2556 bytes --]
Hello David,
here is our second pull request for net-next. In this series Federico
Vaga adds a pci driver for c_can/d_can hardware using the existing
generic c_can driver. The remaining 6 patches are by Oliver Hartkopp.
He adds CANFD support to the CAN stack while keeping binary
compatibility for existing applications. CANFD is an extension to the
existing CAN standard, it allows longer CAN frames and/or higher data
rates. There's no real hardware available yet, but this series adds
CANFD support to the vcan driver.
regards,
Marc
---
The following changes since commit b31525d16b50fe0eb33545afbc0be1a03f2896e3:
net: lpc_eth: Driver cleanup (2012-06-19 00:27:03 -0700)
are available in the git repository at:
git://gitorious.org/linux-can/linux-can-next.git master
for you to fetch changes up to ea53fe0c667ad3cae61d4d71d2be41908ac5c0a4:
canfd: update documentation according to CAN FD extensions (2012-06-19 21:40:26 +0200)
----------------------------------------------------------------
Federico Vaga (1):
c_can_pci: generic module for C_CAN/D_CAN on PCI
Oliver Hartkopp (6):
canfd: add new data structures and constants
canfd: add support for CAN FD in PF_CAN core
canfd: add support for CAN FD in CAN_RAW sockets
candev: add/update helpers for CAN FD
vcan: add CAN FD support
canfd: update documentation according to CAN FD extensions
Documentation/networking/can.txt | 154 ++++++++++++++++++++++++++++--
drivers/net/can/c_can/Kconfig | 7 ++
drivers/net/can/c_can/Makefile | 1 +
drivers/net/can/c_can/c_can_pci.c | 236 ++++++++++++++++++++++++++++++++++++++++++++++
drivers/net/can/dev.c | 35 ++++++-
drivers/net/can/vcan.c | 27 ++++--
include/linux/can.h | 59 +++++++++++-
include/linux/can/core.h | 4 +-
include/linux/can/dev.h | 33 +++++--
include/linux/can/raw.h | 3 +-
include/linux/if_ether.h | 3 +-
net/can/af_can.c | 116 +++++++++++++++++------
net/can/raw.c | 50 +++++++++-
13 files changed, 664 insertions(+), 64 deletions(-)
create mode 100644 drivers/net/can/c_can/c_can_pci.c
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* pull request: wireless-next 2012-06-19
From: John W. Linville @ 2012-06-19 19:57 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 17569 bytes --]
commit b3c911eeb47d08aada986f769b6a060794dfe9d0
Dave,
This is a sizeable batch of updates intended for 3.6...
The bulk of the changes here are Bluetooth. Gustavo says:
Here goes the first Bluetooth pull request for 3.6, we have
queued quite a lot of work. Andrei Emeltchenko added the AMP
Manager code, a lot of work is needed, but the first bit are
already there. This code is disabled by default. Mat Martineau
changed the whole L2CAP ERTM state machine code, replacing
the old one with a new implementation. Besides that we had
lot of coding style fixes (to follow net rules), more l2cap
core separation from socket and many clean ups and fixed all
over the tree.
Along with the above, there is a healthy dose of ath9k, iwlwifi,
and other driver updates. There is also another pull from the
wireless tree to resolve some merge issues. I also fixed-up some
merge discrepencies between net-next and wireless-next.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 43b03f1f6d6832d744918947d185a7aee89d1e0f:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2012-06-12 21:59:18 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git for-davem
Andre Guedes (4):
Bluetooth: Change default MTU for L2CAP ATT channel
Bluetooth: Check MTU value in l2cap_sock_setsockopt_old
Bluetooth: Rename L2CAP_LE_DEFAULT_MTU
Bluetooth: Filter duplicated reports in LE scan
Andrei Emeltchenko (35):
Bluetooth: Silent sparse warnings
Bluetooth: Use defined link key size
Bluetooth: Preserve L2CAP flags values
Bluetooth: trivial: Remove empty line
Bluetooth: Define L2CAP conf continuation flag
Bluetooth: Define and use PSM identifiers
Bluetooth: Use __constant when dealing with constants
Bluetooth: Use __constant modifier in HCI code
Bluetooth: Define HCI AMP cmd struct
Bluetooth: Move clean up code and set of SOCK_ZAPPED to l2cap_sock.c
Bluetooth: Add l2cap_chan->ops->ready()
Bluetooth: trivial: Use defined PSMLEN instead of magic
Bluetooth: A2MP: Create A2MP channel
Bluetooth: A2MP: AMP Manager basic functions
Bluetooth: A2MP: Build and Send msg helpers
Bluetooth: A2MP: Add chan callbacks
Bluetooth: A2MP: Definitions for A2MP commands
Bluetooth: A2MP: Define A2MP status codes
Bluetooth: A2MP: Process A2MP messages
Bluetooth: A2MP: Process A2MP Command Reject
Bluetooth: A2MP: Process A2MP Discover Request
Bluetooth: A2MP: Process A2MP Change Notify
Bluetooth: A2MP: Process A2MP Get Info Request
Bluetooth: A2MP: Process A2MP Get AMP Assoc Request
Bluetooth: A2MP: Process A2MP Create Physlink Request
Bluetooth: A2MP: Process A2MP Disc Physlink Request
Bluetooth: A2MP: Process A2MP Command Responses
Bluetooth: A2MP: Handling fixed channels
Bluetooth: A2MP: Manage incoming connections
Bluetooth: Do not check func ready existence
Bluetooth: A2MP: Do not reference hci_conn
Bluetooth: Make l2cap_data_channel return void
Bluetooth: Make l2cap_conless_channel return void
Bluetooth: Make l2cap_att_channel return void
Bluetooth: Remove magic disconnect reason
Andrzej Kaczmarek (3):
Bluetooth: Allow only one LE connection attempt
Bluetooth: Return proper mgmt state when LE pairing connection failed
Bluetooth: Fix not removing hci_conn for failed LE connection
Arend van Spriel (4):
brcmsmac: remove brcms_set_hint() function
brcmsmac: fix smatch warning found in ampdu.c
brcmfmac: add debugfs helper functions
brcmfmac: expose sdio internal counters in debugfs
Ashok Nagarajan (1):
mac80211: add missing kernel-doc
Avinash Patil (1):
mwifiex: fix incorrect privacy setting in beacon and probe response
Bing Zhao (1):
Bluetooth: btmrvl: add SD8787 Bluetooth AMP device ID
Brandon Misemer (1):
iwlwifi: Fix Makefile build order for built-in driver
Dan Carpenter (2):
iwlwifi: turn on a lockdep assertion
iwlwifi: unlock on error path
David Spinadel (1):
mac80211: stop polling in disassociation
Eliad Peller (2):
cfg80211: fix potential deadlock in regulatory
mac80211: check sdata_running on ieee80211_set_bitrate_mask
Emmanuel Grumbach (10):
iwlwifi: s/iwl_read_targ_mem_words/iwl_read_targ_mem_bytes
iwlwifi: iwl_{read,write}_targ_mem_words takes dwords
iwlwifi: print more info when a queue is stuck
iwlwifi: don't configure a txq that is being disabled
iwlwifi: remove lock around txq_enable
iwlwifi: comment that setting driver_data overrides info->control
iwlwifi: print even more info when a queue is stuck
iwlwifi: don't modify the timer if we don't Tx
iwlwifi: warn if TFD index and WiFi Seq don't match
iwlwifi: WARN only once when we have trouble in reclaim
Gustavo Padovan (29):
Bluetooth: Fix coding style in mgmt.c
Bluetooth: Fix coding style in sco.c
Bluetooth: Fix coding style in hci_sock.c
Bluetooth: Fix coding style in hci_sysfs.c
Bluetooth: Fix coding style in hci_event.c
Bluetooth: Fix coding style in hci_conn.c
Bluetooth: Fix coding style in hci_core.c
Bluetooth: Do not purge queue in Basic Mode
Bluetooth: Remove double check for BT_CONNECTED
Bluetooth: Remove dead int returns
Bluetooth: Fix trailing whitespaces in license text
Bluetooth: Remove most of the inline usage
Bluetooth: Remove 'register' usage from the subsystem
Bluetooth: Fix coding style in include/net/bluetooth
Bluetooth: Fix coding style in the subsystem
Bluetooth: Remove unnecessary headers include
Bluetooth: Remove unneeded EXPORT_SYMBOL
Bluetooth: Use lmp_ssp_capable() macro
Bluetooth: Get a more accurate L2CAP PDU len
Bluetooth: Remove extra l2cap_state_change(BT_CONNECTED)
Bluetooth: Use l2cap_chan_ready() in LE path
Bluetooth: Use chan as parameters for l2cap chan ops
Bluetooth: Use chan->state instead of sk->sk_state
Bluetooth: Move check for backlog size to l2cap_sock.c
Bluetooth: check for already existent channel before create new one
Bluetooth: Create function to return the ERTM header size
Bluetooth: Remove unused err var from l2cap_segment_sdu()
Bluetooth: Create empty l2cap ops function
Bluetooth: Fix style in hidp code
Ilan Peer (2):
iwlwifi: refactor testmode
iwlwifi: decouple testmode and iwl-test
Johan Hedberg (4):
Bluetooth: Fix SMP pairing method selection
Bluetooth: Fix deadlock and crash when SMP pairing times out
Bluetooth: Fix SMP security elevation from medium to high
Bluetooth: Add support for encryption key refresh
Johannes Berg (5):
mac80211: add some missing kernel-doc
iwlwifi: fix dynamic loading
Merge remote-tracking branch 'wireless-next/master' into iwlwifi-next
iwlwifi: fix 6035 device parameters
iwlwifi: use request_module instead of _nowait
John W. Linville (6):
Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth
Merge branch 'master' of git://git.kernel.org/.../linville/wireless
Merge branch 'for-john' of git://git.kernel.org/.../jberg/mac80211
Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth-next
Merge branch 'master' of git://git.kernel.org/.../linville/wireless
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next into for-davem
Jussi Kivilinna (1):
rndis_wlan: fix matching bssid check in rndis_check_bssid_list()
Mat Martineau (28):
Bluetooth: Free allocated ERTM SREJ list if init fails
Bluetooth: Fix early return from l2cap_chan_del
Bluetooth: Change default state of ERTM disable flag
Bluetooth: Add a new L2CAP ERTM transmit state machine.
Bluetooth: Refactor l2cap_streaming_send
Bluetooth: Refactor l2cap_ertm_send
Bluetooth: Refactor l2cap_send_sframe
Bluetooth: Consolidate common receive code for ERTM and streaming mode
Bluetooth: Add streaming mode receive and incoming packet classifier
Bluetooth: Remove receive code that has been superceded
Bluetooth: Refactor l2cap_send_ack
Bluetooth: Use the transmit state machine for busy state changes
Bluetooth: Update l2cap_send_i_or_rr_or_rnr to fit the spec better
Bluetooth: Add the ERTM receive state machine
Bluetooth: Add implementation for retransmitting all unacked frames
Bluetooth: Send SREJ frames when packets go missing
Bluetooth: Reassemble all available data when retransmissions succeed.
Bluetooth: Handle SREJ requests to resend unacked frames
Bluetooth: Handle incoming REJ frames
Bluetooth: Use new header structures in l2cap_send_rr_or_rnr
Bluetooth: Check rules when setting retransmit or monitor timers
Bluetooth: Use the ERTM transmit state machine from timeout handlers
Bluetooth: Simplify the ERTM ack timeout
Bluetooth: Remove unneccesary inline
Bluetooth: Set txwin values for streaming mode
Bluetooth: Remove unused ERTM control field macros
Bluetooth: Enable ERTM by default
Bluetooth: Send a configuration request after security confirmation
Michal Kazior (1):
cfg80211: check iface combinations only when iface is running
Mohammed Shafi Shajakhan (4):
ath9k: Fix a WARNING on suspend/resume with IBSS
ath9k: remove incompatible IBSS interface check in change_iface
ath9k: Fix softlockup in AR9485
ath9k: Fix softlockup in AR9485
Rajkumar Manoharan (19):
ath9k: choose legacy rate as last rate of MRR series
ath9k: restore power state on set channel failure
ath9k_hw: Fix AR9462 power consumption on idle associated
ath9k_hw: check GPM HW write pointer before chip reset
ath9k_hw: fix incorrect LNA register settings
ath9k_hw: program OBS register only when MCI is disabled
ath9k_hw: process MCI interrupts only when btcoex is enabled
ath9k: simplify btcoex profile management
ath9k: keep btcoex period in milliseconds
ath9k: defer btcoex scheme update
ath9k: fix btcoex duty cycle
ath9k_hw: cleanup MCI gpm offset state
ath9k_hw: add utility function to set BT version
ath9k_hw: remove MCI_STATE_SEND_WLAN_CHANNELS
ath9k_hw: remove MCI_STATE_NEED_FLUSH_BT_INFO
ath9k_hw: remove p_data argument from ar9003_mci_state
ath9k_hw: remove MCI_STATE_BT
ath9k_hw: remove MCI_STATE_CONT_* state
ath9k_hw: remove MCI_STATE_SET_BT_SLEEP
Sasha Levin (1):
Bluetooth: Really fix registering hci with duplicate name
Sujith Manoharan (1):
ath9k_hw: Update initvals for AR9462
Szymon Janc (2):
Bluetooth: Rename HCI_QUIRK_NO_RESET to HCI_QUIRK_RESET_ON_CLOSE
Bluetooth: Remove unused HCI timeouts definitions
Vinicius Costa Gomes (1):
Bluetooth: Fix checking the wrong flag when accepting a socket
Vishal Agarwal (1):
Bluetooth: Fix LE pairing completion on connection failure
drivers/bluetooth/bluecard_cs.c | 10 +-
drivers/bluetooth/bpa10x.c | 2 +-
drivers/bluetooth/bt3c_cs.c | 4 +-
drivers/bluetooth/btmrvl_sdio.c | 3 +
drivers/bluetooth/btuart_cs.c | 4 +-
drivers/bluetooth/btusb.c | 14 +-
drivers/bluetooth/dtl1_cs.c | 4 +-
drivers/bluetooth/hci_bcsp.c | 2 +-
drivers/bluetooth/hci_h4.c | 2 +-
drivers/bluetooth/hci_ldisc.c | 2 +-
drivers/bluetooth/hci_ll.c | 6 +-
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 7 +-
drivers/net/wireless/ath/ath9k/ar9003_mci.c | 330 ++--
drivers/net/wireless/ath/ath9k/ar9003_mci.h | 32 +-
.../net/wireless/ath/ath9k/ar9462_2p0_initvals.h | 2 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/gpio.c | 10 +-
drivers/net/wireless/ath/ath9k/hw.c | 11 +-
drivers/net/wireless/ath/ath9k/link.c | 8 +
drivers/net/wireless/ath/ath9k/main.c | 22 +-
drivers/net/wireless/ath/ath9k/mci.c | 162 +-
drivers/net/wireless/ath/ath9k/rc.c | 17 +-
drivers/net/wireless/ath/ath9k/reg.h | 4 +-
drivers/net/wireless/brcm80211/brcmfmac/Makefile | 2 +
drivers/net/wireless/brcm80211/brcmfmac/dhd.h | 3 +
drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.c | 126 ++
drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.h | 59 +
.../net/wireless/brcm80211/brcmfmac/dhd_linux.c | 7 +
drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c | 169 +-
drivers/net/wireless/brcm80211/brcmsmac/ampdu.c | 5 +-
.../net/wireless/brcm80211/brcmsmac/mac80211_if.c | 14 +-
drivers/net/wireless/iwlwifi/Makefile | 10 +-
drivers/net/wireless/iwlwifi/dvm/agn.h | 17 +-
drivers/net/wireless/iwlwifi/dvm/dev.h | 26 +-
drivers/net/wireless/iwlwifi/dvm/lib.c | 2 +-
drivers/net/wireless/iwlwifi/dvm/mac80211.c | 2 +-
drivers/net/wireless/iwlwifi/dvm/main.c | 6 +-
drivers/net/wireless/iwlwifi/dvm/rx.c | 24 +-
drivers/net/wireless/iwlwifi/dvm/testmode.c | 778 +-------
drivers/net/wireless/iwlwifi/dvm/tx.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-drv.c | 38 +-
drivers/net/wireless/iwlwifi/iwl-fh.h | 2 +
drivers/net/wireless/iwlwifi/iwl-io.c | 20 +-
drivers/net/wireless/iwlwifi/iwl-io.h | 14 +-
drivers/net/wireless/iwlwifi/iwl-test.c | 856 ++++++++
drivers/net/wireless/iwlwifi/iwl-test.h | 161 ++
.../iwlwifi/{dvm/testmode.h => iwl-testmode.h} | 0
drivers/net/wireless/iwlwifi/pcie/6000.c | 1 +
drivers/net/wireless/iwlwifi/pcie/internal.h | 9 +-
drivers/net/wireless/iwlwifi/pcie/trans.c | 71 +-
drivers/net/wireless/iwlwifi/pcie/tx.c | 95 +-
drivers/net/wireless/mwifiex/uap_cmd.c | 11 +
drivers/net/wireless/rndis_wlan.c | 2 +-
include/net/bluetooth/a2mp.h | 126 ++
include/net/bluetooth/bluetooth.h | 39 +-
include/net/bluetooth/hci.h | 105 +-
include/net/bluetooth/hci_core.h | 29 +-
include/net/bluetooth/l2cap.h | 205 +--
include/net/mac80211.h | 6 +
net/bluetooth/Makefile | 3 +-
net/bluetooth/a2mp.c | 568 ++++++
net/bluetooth/af_bluetooth.c | 14 +-
net/bluetooth/bnep/core.c | 21 +-
net/bluetooth/bnep/netdev.c | 16 +-
net/bluetooth/bnep/sock.c | 18 +-
net/bluetooth/hci_conn.c | 98 +-
net/bluetooth/hci_core.c | 214 +-
net/bluetooth/hci_event.c | 357 ++--
net/bluetooth/hci_sock.c | 59 +-
net/bluetooth/hci_sysfs.c | 99 +-
net/bluetooth/hidp/core.c | 26 +-
net/bluetooth/hidp/sock.c | 16 +-
net/bluetooth/l2cap_core.c | 2132 ++++++++++++--------
net/bluetooth/l2cap_sock.c | 130 ++-
net/bluetooth/lib.c | 7 +-
net/bluetooth/mgmt.c | 89 +-
net/bluetooth/rfcomm/core.c | 32 +-
net/bluetooth/rfcomm/sock.c | 21 +-
net/bluetooth/rfcomm/tty.c | 9 +-
net/bluetooth/sco.c | 43 +-
net/bluetooth/smp.c | 18 +-
net/mac80211/cfg.c | 3 +
net/mac80211/mlme.c | 4 +-
net/mac80211/sta_info.h | 5 +
net/wireless/reg.c | 2 +-
net/wireless/util.c | 2 +-
86 files changed, 4743 insertions(+), 2966 deletions(-)
create mode 100644 drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.c
create mode 100644 drivers/net/wireless/iwlwifi/iwl-test.c
create mode 100644 drivers/net/wireless/iwlwifi/iwl-test.h
rename drivers/net/wireless/iwlwifi/{dvm/testmode.h => iwl-testmode.h} (100%)
create mode 100644 include/net/bluetooth/a2mp.h
create mode 100644 net/bluetooth/a2mp.c
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC net-next 01/14] Add Default
From: Eilon Greenstein @ 2012-06-19 19:53 UTC (permalink / raw)
To: Alexander Duyck; +Cc: Yuval Mintz, netdev, davem
In-Reply-To: <4FE0CCA2.304@intel.com>
On Tue, 2012-06-19 at 12:01 -0700, Alexander Duyck wrote:
> On 06/19/2012 10:41 AM, Eilon Greenstein wrote:
> > On Tue, 2012-06-19 at 09:37 -0700, Alexander Duyck wrote:
> >> On 06/19/2012 08:13 AM, Yuval Mintz wrote:
> >>> Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
> >>> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
> >>> ---
> >>> include/linux/etherdevice.h | 5 ++++-
> >>> 1 files changed, 4 insertions(+), 1 deletions(-)
> >>>
> >>> diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
> >>> index 3d406e0..bb1ecaf 100644
> >>> --- a/include/linux/etherdevice.h
> >>> +++ b/include/linux/etherdevice.h
> >>> @@ -44,7 +44,10 @@ extern int eth_mac_addr(struct net_device *dev, void *p);
> >>> extern int eth_change_mtu(struct net_device *dev, int new_mtu);
> >>> extern int eth_validate_addr(struct net_device *dev);
> >>>
> >>> -
> >>> +/* The maximal number of RSS queues a driver should have unless configured
> >>> + * so explicitly.
> >>> + */
> >>> +#define DEFAULT_MAX_NUM_RSS_QUEUES (8)
> >>>
> >>> extern struct net_device *alloc_etherdev_mqs(int sizeof_priv, unsigned int txqs,
> >>> unsigned int rxqs);
> >> I'm not a big fan of just having this as a fixed define in the code. It
> >> seems like it would make much more sense to have this in the Kconfig
> >> somewhere as a range value if you plan on making this changeable in the
> >> future.
> > My original suggestion was a kernel command line parameter, but Dave was
> > less than enthusiastic. If you will follow the original thread, you can
> > probably understand why I decided to adopt Dave's constant approach
> > without suggesting Kconfig:
> > http://marc.info/?l=linux-netdev&m=133992386010982&w=2
> There is a huge difference between a kernel parameter an a kconfig
> value. The main idea behind the kconfig value is that you are going to
> have different preferences depending on architectures and such so it
> would make much more sense to have the default as a config option.
Yes, I'm aware of that. Coming from the orientation of number of CPUs
and memory constrains, the kernel parameter came to mind first, after
receiving the reply about using just a good default, I have considered
the kconfig alternative but decided not to make further suggestions and
just go with a good default.
> I'm not sure why you couldn't just limit it to 16. From what I can tell
> that is the largest number that gets used for RSS queues on almost all
> the different hardware out there.
cxgb4 32, myril10ge 32, efx 32, niu 24.
The point is that I was requested by a customer to support more queues,
but simply enabling that much more MSI-X vectors in the FW will cause
the driver to consume too much memory and this is probably not desired
for most users. Having the set_channels API is good solution to have a
default value which is different than the maximal value, and that brings
us to where we are now - finding a default value for all multi-queue
drivers.
> As far as the rest of the patches for the Intel drivers go you might be
> better off if you understood how we allocate queues on the ixgbe/ixgbevf
> drivers. Usually we have the number of queues determined before we set
> the number of vectors so your patches that limited the number of vectors
> aren't going to have the effect you desire. So for example RSS
> configuration is currently handled in either ixgbe_set_rss_queues or
> ixgbe_set_dcb_queues depending on the mode the driver is in. You would
> be much better off looking there for how to limit the RSS queueing on
> the ixgbe adapter.
OK, we will move the logic to those functions.
^ permalink raw reply
* [PATCH net] batman-adv: fix skb->data assignment
From: Antonio Quartulli @ 2012-06-19 19:26 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r,
stable-u79uwXL29TY76Z2rM5mHXA
skb_linearize(skb) possibly rearranges the skb internal data and then changes
the skb->data pointer value. For this reason any other pointer in the code that
was assigned skb->data before invoking skb_linearise(skb) must be re-assigned.
In the current tt_query message handling code this is not done and therefore, in
case of skb linearization, the pointer used to handle the packet header ends up
in pointing to free'd memory.
This bug was introduced by a73105b8d4c765d9ebfb664d0a66802127d8e4c7
(batman-adv: improved client announcement mechanism)
Signed-off-by: Antonio Quartulli <ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
---
This patch has already been merged in net-next. I am sorry about that, but we
were missing some knowledge about sending patches for stable.
Thank you,
Antonio
net/batman-adv/routing.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index 840e2c6..015471d 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -617,6 +617,8 @@ int recv_tt_query(struct sk_buff *skb, struct hard_iface *recv_if)
* changes */
if (skb_linearize(skb) < 0)
goto out;
+ /* skb_linearize() possibly changed skb->data */
+ tt_query = (struct tt_query_packet *)skb->data;
tt_len = tt_query->tt_data * sizeof(struct tt_change);
--
1.7.9.4
^ permalink raw reply related
* Re: [RFC net-next 01/14] Add Default
From: Alexander Duyck @ 2012-06-19 19:01 UTC (permalink / raw)
To: eilong; +Cc: Yuval Mintz, netdev, davem
In-Reply-To: <1340127678.2486.18.camel@lb-tlvb-eilong.il.broadcom.com>
On 06/19/2012 10:41 AM, Eilon Greenstein wrote:
> On Tue, 2012-06-19 at 09:37 -0700, Alexander Duyck wrote:
>> On 06/19/2012 08:13 AM, Yuval Mintz wrote:
>>> Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
>>> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
>>> ---
>>> include/linux/etherdevice.h | 5 ++++-
>>> 1 files changed, 4 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
>>> index 3d406e0..bb1ecaf 100644
>>> --- a/include/linux/etherdevice.h
>>> +++ b/include/linux/etherdevice.h
>>> @@ -44,7 +44,10 @@ extern int eth_mac_addr(struct net_device *dev, void *p);
>>> extern int eth_change_mtu(struct net_device *dev, int new_mtu);
>>> extern int eth_validate_addr(struct net_device *dev);
>>>
>>> -
>>> +/* The maximal number of RSS queues a driver should have unless configured
>>> + * so explicitly.
>>> + */
>>> +#define DEFAULT_MAX_NUM_RSS_QUEUES (8)
>>>
>>> extern struct net_device *alloc_etherdev_mqs(int sizeof_priv, unsigned int txqs,
>>> unsigned int rxqs);
>> I'm not a big fan of just having this as a fixed define in the code. It
>> seems like it would make much more sense to have this in the Kconfig
>> somewhere as a range value if you plan on making this changeable in the
>> future.
> My original suggestion was a kernel command line parameter, but Dave was
> less than enthusiastic. If you will follow the original thread, you can
> probably understand why I decided to adopt Dave's constant approach
> without suggesting Kconfig:
> http://marc.info/?l=linux-netdev&m=133992386010982&w=2
There is a huge difference between a kernel parameter an a kconfig
value. The main idea behind the kconfig value is that you are going to
have different preferences depending on architectures and such so it
would make much more sense to have the default as a config option.
> However, 8 is not a holy number - I'm open for suggestions.
>
> Thanks,
> Eilon
I'm not sure why you couldn't just limit it to 16. From what I can tell
that is the largest number that gets used for RSS queues on almost all
the different hardware out there.
As far as the rest of the patches for the Intel drivers go you might be
better off if you understood how we allocate queues on the ixgbe/ixgbevf
drivers. Usually we have the number of queues determined before we set
the number of vectors so your patches that limited the number of vectors
aren't going to have the effect you desire. So for example RSS
configuration is currently handled in either ixgbe_set_rss_queues or
ixgbe_set_dcb_queues depending on the mode the driver is in. You would
be much better off looking there for how to limit the RSS queueing on
the ixgbe adapter.
Thanks,
Alex
^ 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