* Re: [PATCH net-next] icmp: add a global rate limitation
From: Eric Dumazet @ 2014-09-22 20:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20140922.160904.1566383839759663411.davem@davemloft.net>
On Mon, 2014-09-22 at 16:09 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Fri, 19 Sep 2014 07:38:40 -0700
>
> > Current ICMP rate limiting uses inetpeer cache, which is an RBL tree
> > protected by a lock, meaning that hosts can be stuck hard if all cpus
> > want to check ICMP limits.
>
> However, the replacement uses a single global spinlock for
> synchronization.
>
> ...
> > Note that if we really want to send millions of ICMP messages per
> > second, we might extend idea and infra added in commit 04ca6973f7c1a
> > ("ip: make IP identifiers less predictable") :
> > add a token bucket in the ip_idents hash and no longer rely on inetpeer.
>
> That would be preferred.
>
> I don't really see how this patch makes things better. The code goes
> through a global spinlock unconditionally, and if it passes then it
> looks up the inetpeer anyways.
>
The inetpeer is only hit at most 1000 times per second, which is a
rather low rate.
> I need more information to be convinced that this is an improvement
> and that it actually solves the stated problem. I'm sure you also
> have some performance metrics to share, right? :-)
It does not use the global spinlock in the stress situation.
I tested this patch I can tell you it works ;)
+ /* Check if token bucket is empty and cannot be refilled
+ * without taking the spinlock.
+ */
+ if (!icmp_global.credit) {
+ delta = min_t(u32, now - icmp_global.stamp, HZ);
+ if (delta < HZ / 50)
+ return false;
+ }
+
So if we are under pressure (credit is exhausted), we exit early unless
20ms were elapsed, and in this case we'll refill the token bucket.
Thanks
^ permalink raw reply
* Re: [PATCH net-next] ipv6: mld: answer mldv2 queries with mldv1 reports in mldv1 fallback
From: David Miller @ 2014-09-22 20:23 UTC (permalink / raw)
To: dborkman; +Cc: hannes, netdev
In-Reply-To: <1411214635-14136-1-git-send-email-dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Sat, 20 Sep 2014 14:03:55 +0200
> RFC2710 (MLDv1), section 3.7. says:
,,,
> RFC3810 (MLDv2), section 8.2.1. states for *listeners* regarding
> presence of MLDv1 routers:
...
> While section 8.3.1. specifies *router* behaviour regarding presence
> of MLDv1 routers:
...
> That means that we should not get queries from different versions of
> MLD. When there's a MLDv1 router present, MLDv2 enforces truncation
> and MRC == MRD (both fields are overlapping within the 24 octet range).
>
> Section 8.3.2. specifies behaviour in the presence of MLDv1 multicast
> address *listeners*:
...
> That means, what can happen is the following scenario, that hosts can
> act in MLDv1 compatibility mode when they previously have received an
> MLDv1 query (or, simply operate in MLDv1 mode-only); and at the same
> time, an MLDv2 router could start up and transmits MLDv2 startup query
> messages while being unaware of the current operational mode.
>
> Given RFC2710, section 3.7 we would need to answer to that with an MLDv1
> listener report, so that the router according to RFC3810, section 8.3.2.
> would receive that and internally switch to MLDv1 compatibility as well.
>
> Right now, I believe since the initial implementation of MLDv2, Linux
> hosts would just silently drop such MLDv2 queries instead of replying
> with an MLDv1 listener report, which would prevent a MLDv2 router going
> into fallback mode (until it receives other MLDv1 queries).
>
> Since the mapping of MRC to MRD in exactly such cases can make use of
> the exponential algorithm from 5.1.3, we cannot [strictly speaking] be
> aware in MLDv1 of the encoding in MRC, it seems also not mentioned by
> the RFC. Since encodings are the same up to 32767, assume in such a
> situation this value as a hard upper limit we would clamp. We have asked
> one of the RFC authors on that regard, and he mentioned that there seem
> not to be any implementations that make use of that exponential algorithm
> on startup messages. In any case, this patch fixes this MLD
> interoperability issue.
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> ---
> [ Sending to net-next as it's nothing critical and nobody was screaming
> out loud for so many years, so it can linger a bit in net-next first. ]
Applied, thanks Daniel.
^ permalink raw reply
* Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM
From: Dmitry Torokhov @ 2014-09-22 20:23 UTC (permalink / raw)
To: Pavel Machek
Cc: James Bottomley, Tejun Heo, Luis R. Rodriguez, Lennart Poettering,
Kay Sievers, Greg Kroah-Hartman, Wu Zhangjin, Takashi Iwai,
Arjan van de Ven, linux-kernel@vger.kernel.org, Oleg Nesterov,
hare, Andrew Morton, Tetsuo Handa, Joseph Salisbury,
Benjamin Poirier, Santosh Rastapur, One Thousand Gnomes,
Tim Gardner, Pierre Fersing, Nagalakshmi Nandigama
In-Reply-To: <20140922194906.GB9868@amd>
On Monday, September 22, 2014 09:49:06 PM Pavel Machek wrote:
> On Thu 2014-09-11 13:23:54, Dmitry Torokhov wrote:
> > On Thu, Sep 11, 2014 at 12:59:25PM -0700, James Bottomley wrote:
> > > On Tue, 2014-09-09 at 16:01 -0700, Dmitry Torokhov wrote:
> > > > On Tuesday, September 09, 2014 03:46:23 PM James Bottomley wrote:
> > > > > On Wed, 2014-09-10 at 07:41 +0900, Tejun Heo wrote:
> > > > > > The thing is that we have to have dynamic mechanism to listen for
> > > > > > device attachments no matter what and such mechanism has been in
> > > > > > place
> > > > > > for a long time at this point. The synchronous wait simply
> > > > > > doesn't
> > > > > > serve any purpose anymore and kinda gets in the way in that it
> > > > > > makes
> > > > > > it a possibly extremely slow process to tell whether loading of a
> > > > > > module succeeded or not because the wait for the initial round of
> > > > > > probe is piggybacked.
> > > > >
> > > > > OK, so we just fire and forget in userland ... why bother inventing
> > > > > an
> > > > > elaborate new infrastructure in the kernel to do exactly what
> > > > >
> > > > > modprobe <mod> &
> > > > >
> > > > > would do?
> > > >
> > > > Just so we do not forget: we also want the no-modules case to also be
> > > > able
> > > > to probe asynchronously so that a slow device does not stall kernel
> > > > booting.> >
> > > Yes, but we mostly do this anyway. SCSI for instance does asynchronous
> > > scanning of attached devices (once the cards are probed)
> >
> > What would it do it card was a bit slow to probe?
> >
> > > but has a sync
> > > point for ordering.
> >
> > Quite often we do not really care about ordering of devices. I mean,
> > does it matter if your mouse is discovered before your keyboard or
> > after?
>
> Actually yes, I suspect it does.
>
> I do evtest /dev/input/eventX by hand, occassionaly. It would be
> annoying if they moved between reboots.
I am sorry but you will have to cope with such annoyances. It' snot like we
fail to boot the box here.
The systems are now mostly hot-pluggable and userland is supposed to
handle it, and it does, at least for input devices. If you want stable naming
use udev facilities to rename devices as needed or add needed symlinks (by-id,
etc.).
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH net-next] net: bpf: fix compiler warnings in test_bpf
From: David Miller @ 2014-09-22 20:22 UTC (permalink / raw)
To: ast; +Cc: dborkman, fengguang.wu, netdev
In-Reply-To: <1411160031-3538-1-git-send-email-ast@plumgrid.com>
From: Alexei Starovoitov <ast@plumgrid.com>
Date: Fri, 19 Sep 2014 13:53:51 -0700
> old gcc 4.2 used by avr32 architecture produces warnings:
>
> lib/test_bpf.c:1741: warning: integer constant is too large for 'long' type
> lib/test_bpf.c:1741: warning: integer constant is too large for 'long' type
> lib/test_bpf.c: In function '__run_one':
> lib/test_bpf.c:1897: warning: 'ret' may be used uninitialized in this function
>
> silence these warnings.
>
> Fixes: 02ab695bb37e ("net: filter: add "load 64-bit immediate" eBPF instruction")
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Applied, thank you.
^ permalink raw reply
* [PATCH v3 net-next] tcp: avoid possible arithmetic overflows
From: Eric Dumazet @ 2014-09-22 20:19 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: Joe Perches, David Miller, netdev, Neal Cardwell
In-Reply-To: <1411389739.26859.113.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
icsk_rto is a 32bit field, and icsk_backoff can reach 15 by default,
or more if some sysctl (eg tcp_retries2) are changed.
Better use 64bit to perform icsk_rto << icsk_backoff operations
As Joe Perches suggested, add a helper for this.
Yuchung spotted the tcp_v4_err() case.
From: Eric Dumazet <edumazet@google.com>
---
include/net/inet_connection_sock.h | 9 +++++++++
net/ipv4/tcp_input.c | 5 +++--
net/ipv4/tcp_ipv4.c | 6 +++---
net/ipv4/tcp_output.c | 13 ++++++-------
net/ipv4/tcp_timer.c | 4 ++--
5 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/include/net/inet_connection_sock.h b/include/net/inet_connection_sock.h
index 5fbe6568c3cf..848e85cb5c61 100644
--- a/include/net/inet_connection_sock.h
+++ b/include/net/inet_connection_sock.h
@@ -242,6 +242,15 @@ static inline void inet_csk_reset_xmit_timer(struct sock *sk, const int what,
#endif
}
+static inline unsigned long
+inet_csk_rto_backoff(const struct inet_connection_sock *icsk,
+ unsigned long max_when)
+{
+ u64 when = (u64)icsk->icsk_rto << icsk->icsk_backoff;
+
+ return (unsigned long)min_t(u64, when, max_when);
+}
+
struct sock *inet_csk_accept(struct sock *sk, int flags, int *err);
struct request_sock *inet_csk_search_req(const struct sock *sk,
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 02fb66d4a018..13f3da4762e3 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3208,9 +3208,10 @@ static void tcp_ack_probe(struct sock *sk)
* This function is not for random using!
*/
} else {
+ unsigned long when = inet_csk_rto_backoff(icsk, TCP_RTO_MAX);
+
inet_csk_reset_xmit_timer(sk, ICSK_TIME_PROBE0,
- min(icsk->icsk_rto << icsk->icsk_backoff, TCP_RTO_MAX),
- TCP_RTO_MAX);
+ when, TCP_RTO_MAX);
}
}
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 006b045716d8..3b2e49cb2b61 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -430,9 +430,9 @@ void tcp_v4_err(struct sk_buff *icmp_skb, u32 info)
break;
icsk->icsk_backoff--;
- inet_csk(sk)->icsk_rto = (tp->srtt_us ? __tcp_set_rto(tp) :
- TCP_TIMEOUT_INIT) << icsk->icsk_backoff;
- tcp_bound_rto(sk);
+ icsk->icsk_rto = tp->srtt_us ? __tcp_set_rto(tp) :
+ TCP_TIMEOUT_INIT;
+ icsk->icsk_rto = inet_csk_rto_backoff(icsk, TCP_RTO_MAX);
skb = tcp_write_queue_head(sk);
BUG_ON(!skb);
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 7f1280dcad57..8c61a7c0c889 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -3279,6 +3279,7 @@ void tcp_send_probe0(struct sock *sk)
{
struct inet_connection_sock *icsk = inet_csk(sk);
struct tcp_sock *tp = tcp_sk(sk);
+ unsigned long probe_max;
int err;
err = tcp_write_wakeup(sk);
@@ -3294,9 +3295,7 @@ void tcp_send_probe0(struct sock *sk)
if (icsk->icsk_backoff < sysctl_tcp_retries2)
icsk->icsk_backoff++;
icsk->icsk_probes_out++;
- inet_csk_reset_xmit_timer(sk, ICSK_TIME_PROBE0,
- min(icsk->icsk_rto << icsk->icsk_backoff, TCP_RTO_MAX),
- TCP_RTO_MAX);
+ probe_max = TCP_RTO_MAX;
} else {
/* If packet was not sent due to local congestion,
* do not backoff and do not remember icsk_probes_out.
@@ -3306,11 +3305,11 @@ void tcp_send_probe0(struct sock *sk)
*/
if (!icsk->icsk_probes_out)
icsk->icsk_probes_out = 1;
- inet_csk_reset_xmit_timer(sk, ICSK_TIME_PROBE0,
- min(icsk->icsk_rto << icsk->icsk_backoff,
- TCP_RESOURCE_PROBE_INTERVAL),
- TCP_RTO_MAX);
+ probe_max = TCP_RESOURCE_PROBE_INTERVAL;
}
+ inet_csk_reset_xmit_timer(sk, ICSK_TIME_PROBE0,
+ inet_csk_rto_backoff(icsk, probe_max),
+ TCP_RTO_MAX);
}
int tcp_rtx_synack(struct sock *sk, struct request_sock *req)
diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
index a339e7ba05a4..b24360f6e293 100644
--- a/net/ipv4/tcp_timer.c
+++ b/net/ipv4/tcp_timer.c
@@ -180,7 +180,7 @@ static int tcp_write_timeout(struct sock *sk)
retry_until = sysctl_tcp_retries2;
if (sock_flag(sk, SOCK_DEAD)) {
- const int alive = (icsk->icsk_rto < TCP_RTO_MAX);
+ const int alive = icsk->icsk_rto < TCP_RTO_MAX;
retry_until = tcp_orphan_retries(sk, alive);
do_reset = alive ||
@@ -294,7 +294,7 @@ static void tcp_probe_timer(struct sock *sk)
max_probes = sysctl_tcp_retries2;
if (sock_flag(sk, SOCK_DEAD)) {
- const int alive = ((icsk->icsk_rto << icsk->icsk_backoff) < TCP_RTO_MAX);
+ const int alive = inet_csk_rto_backoff(icsk, TCP_RTO_MAX) < TCP_RTO_MAX;
max_probes = tcp_orphan_retries(sk, alive);
^ permalink raw reply related
* Re: [PATCH net-next] udp: Need to make ip6_udp_tunnel.c have GPL license
From: Tom Herbert @ 2014-09-22 20:17 UTC (permalink / raw)
To: David Miller; +Cc: Andy Zhou, Linux Netdev List
In-Reply-To: <20140922.150832.1458585102153232594.davem@davemloft.net>
Andy, even with the is patch I still can't get VXLAN to work again. I
am assuming this is a problem related to the common UDP tunnel
functions. I haven't had time to look into it in depth, can you verify
if there is an issue.
Thanks,
Tom
On Mon, Sep 22, 2014 at 12:08 PM, David Miller <davem@davemloft.net> wrote:
> From: Tom Herbert <therbert@google.com>
> Date: Mon, 22 Sep 2014 11:39:44 -0700
>
>> Unable to load various tunneling modules without this:
>>
>> [ 80.679049] fou: Unknown symbol udp_sock_create6 (err 0)
>> [ 91.439939] ip6_udp_tunnel: Unknown symbol ip6_local_out (err 0)
>> [ 91.439954] ip6_udp_tunnel: Unknown symbol __put_net (err 0)
>> [ 91.457792] vxlan: Unknown symbol udp_sock_create6 (err 0)
>> [ 91.457831] vxlan: Unknown symbol udp_tunnel6_xmit_skb (err 0)
>>
>> Signed-off-by: Tom Herbert <therbert@google.com>
>
> Applied, thanks Tom.
^ permalink raw reply
* Re: [PATCH net-next v2] fec: Staticize fec_enet_select_queue()
From: David Miller @ 2014-09-22 20:16 UTC (permalink / raw)
To: fabio.estevam; +Cc: Frank.Li, netdev
In-Reply-To: <1411149574-26296-1-git-send-email-fabio.estevam@freescale.com>
From: Fabio Estevam <fabio.estevam@freescale.com>
Date: Fri, 19 Sep 2014 14:59:34 -0300
> fec_enet_select_queue() is only used locally, so mark it as 'static' to fix the
> following sparse warning:
>
> drivers/net/ethernet/freescale/fec_main.c:2707:5: warning: symbol 'fec_enet_select_queue' was not declared. Should it be static?
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> Changes since v1:
> - Make checkpatch happy
Please just delete this function.
It's overriding code which does exactly the same thing.
Actually, more precisely, this code is duplicating code in a way that
bypasses many core facilitites of the networking. For example, this
override means that socket based flow steering, XPS, etc. are all
not happening on these devices.
Without ->ndo_select_queue(), the flow dissector does __netdev_pick_tx
which is exactly what you want to happen.
^ permalink raw reply
* Re: [PATCH v2 net] ipv4: do not use this_cpu_ptr() in preemptible context
From: Eric Dumazet @ 2014-09-22 20:11 UTC (permalink / raw)
To: Joe M; +Cc: Tom Herbert, Stephen Hemminger, David Miller, Linux Netdev List
In-Reply-To: <20140922193451.GA23177@master>
On Mon, 2014-09-22 at 14:34 -0500, Joe M wrote:
> p --ignore-case --exclude-dir=".git" --recursive this_cpu_ptr *.c
> ip_input.c: struct ip_rt_acct *st = this_cpu_ptr(ip_rt_acct);
> ip_vti.c: tstats = this_cpu_ptr(dev->tstats);
> route.c: p = (struct rtable **)__this_cpu_ptr(nh->nh_pcpu_rth_output);
> route.c: prth = __this_cpu_ptr(nh->nh_pcpu_rth_output);
> tcp.c: return __this_cpu_ptr(p);
>
> Is it ok for ip_vti.c and ip_input.c to use this_cpu_ptr?
It is ok.
We run with BH disabled in these contexts.
^ permalink raw reply
* Re: [PATCH net-next v2 2/5] net: tcp: add flag for ca to indicate that ECN is required
From: Hagen Paul Pfeifer @ 2014-09-22 20:11 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Florian Westphal, David Miller, Eggert, Lars, Eric Dumazet,
fontana, Hannes Frederic Sowa, glenn.judd, Daniel Borkmann,
netdev
In-Reply-To: <20140922092606.10977e48@urahara>
On 22 September 2014 18:26, Stephen Hemminger
<stephen@networkplumber.org> wrote:
>> +static inline void
>> +TCP_ECN_create_request(struct request_sock *req, const struct sk_buff *skb,
>> + const struct sock *listen_sk)
>
> Maybe good time to switch to lower case here for function name.
Probably a follow up patch can convert all of TCP_ECN_* to lower case.
HGN
^ permalink raw reply
* Re: [PATCH net-next] icmp: add a global rate limitation
From: David Miller @ 2014-09-22 20:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1411137520.26859.13.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 19 Sep 2014 07:38:40 -0700
> Current ICMP rate limiting uses inetpeer cache, which is an RBL tree
> protected by a lock, meaning that hosts can be stuck hard if all cpus
> want to check ICMP limits.
However, the replacement uses a single global spinlock for
synchronization.
...
> Note that if we really want to send millions of ICMP messages per
> second, we might extend idea and infra added in commit 04ca6973f7c1a
> ("ip: make IP identifiers less predictable") :
> add a token bucket in the ip_idents hash and no longer rely on inetpeer.
That would be preferred.
I don't really see how this patch makes things better. The code goes
through a global spinlock unconditionally, and if it passes then it
looks up the inetpeer anyways.
I need more information to be convinced that this is an improvement
and that it actually solves the stated problem. I'm sure you also
have some performance metrics to share, right? :-)
^ permalink raw reply
* Re: [PATCH net] dm9000: Return an ERR_PTR() in all error conditions of dm9000_parse_dt()
From: David Miller @ 2014-09-22 20:03 UTC (permalink / raw)
To: tklauser; +Cc: netdev
In-Reply-To: <1411136185-28658-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Fri, 19 Sep 2014 16:16:25 +0200
> In one error condition dm9000_parse_dt() returns NULL, however the
> return value is checked using IS_ERR() in dm9000_probe(), leading to the
> error not being properly propagated if CONFIG_OF is not enabled or the
> device tree data is not available. Fix this by also returning an
> ERR_PTR() in this case.
>
> Fixes: 0b8bf1baabe5 (net: dm9000: Allow instantiation using device tree)
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied, thanks.
^ permalink raw reply
* pull request: wireless-next 2014-09-22
From: John W. Linville @ 2014-09-22 19:45 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 31049 bytes --]
Dave,
Please pull this batch of updates intended for the 3.18 stream...
For the mac80211 bits, Johannes says:
"This time, I have some rate minstrel improvements, support for a very
small feature from CCX that Steinar reverse-engineered, dynamic ACK
timeout support, a number of changes for TDLS, early support for radio
resource measurement and many fixes. Also, I'm changing a number of
places to clear key memory when it's freed and Intel claims copyright
for code they developed."
For the bluetooth bits, Johan says:
"Here are some more patches intended for 3.18. Most of them are cleanups
or fixes for SMP. The only exception is a fix for BR/EDR L2CAP fixed
channels which should now work better together with the L2CAP
information request procedure."
For the iwlwifi bits, Emmanuel says:
"I fix here dvm which was broken by my last pull request. Arik
continues to work on TDLS and Luca solved a few issues in CT-Kill. Eyal
keeps digging into rate scaling code, more to come soon. Besides this,
nothing really special here."
Beyond that, there are the usual big batches of updates to ath9k, b43,
mwifiex, and wil6210 as well as a handful of other bits here and there.
Also, rtlwifi gets some btcoexist attention from Larry.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 61a3d4f9d52c00b2016bc27fc66b10a194043f76:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless (2014-09-08 11:14:56 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git tags/master-2014-09-16
for you to fetch changes up to 7a0a260a0f6ff0226c33cf28a5cc26711ab0ae5f:
ath9k: enable ext channel pulse detection (2014-09-16 16:18:42 -0400)
----------------------------------------------------------------
Amitkumar Karwar (4):
mwifiex: fix a bug in Tx multiport aggregation
mwifiex: minor cleanup in multiport aggregation
mwifiex: remove redundant variable report_scan_result
mwifiex: remove low priority scan handling
Andy Shevchenko (1):
hostap: proc: substitute loops by %*phN
Arik Nemtsov (3):
mac80211: set network header in TDLS frames
iwlwifi: mvm: move TDLS code to separate file
iwlwifi: mvm: fix PSM disable during TDLS
Assaf Krauss (3):
nl80211: Allow declaring RRM-related features
nl80211: Add flag attribute for RRM connections
mac80211: Add RRM support to assoc request
Avinash Patil (11):
mwifiex: set fw api info for backword compatibility
mwifiex: fix probable memory corruption while processing TDLS frame
mwifiex: avoid processing RX packets with invalid length
mwifiex: rework internal scan for association
mwifiex: support for event done interrupt
mwifiex: set passive scan type for scan requests with no ssid
mwifiex: bring in scan channel gap feature
mwifiex: remove restriction of single channel scan when connected
mwifiex: process TX even when scan is ongoing
mwifiex: add rx workqueue support
mwifiex: modify TX/RX window sizes for AP interface
Avri Altman (2):
iwlwifi: mvm: remove unused static inline function
iwlwifi: mvm: Fix skip over dtim configuration in d0i3
Behan Webster (1):
Bluetooth: LLVMLinux: Remove VLAIS from bluetooth/amp.c
Champion Chen (1):
Bluetooth: Fix issue with USB suspend in btusb driver
David Spinadel (1):
iwlwifi: mvm: reduce active dwell time
Dedy Lansky (6):
wil6210: fix for memory corruption while insmod
wil6210: fix for memory corruption upon rmmod
wil6210: fix race condition of disconnect while BACK event
wil6210: modify confusing printout
wil6210: fix race condition between BACK event and Rx data
wil6210: introduce separate completion for WMI
Eliad Peller (9):
cfg80211: avoid duplicate entries on regdomain intersection
mac80211: adjust roc duration when combining ROCs
mac80211: combine roc with the "next roc" if possible
iwlwifi: increase DEFAULT_MAX_TX_POWER
cfg80211/mac80211: add wmm info to assoc event
cfg80211: allow requesting SMPS mode on ap start
mac80211: set smps_mode according to ap params
mac80211: replace SMPS hw flags with wiphy feature bits
iwlwifi: mvm: move IWL_MVM_UAPSD_QUEUES to constants.h
Emmanuel Grumbach (8):
iwlwifi: mvm: enable scheduled scan on newest firmware
iwlwifi: mvm: fix endianity issues with Smart Fifo commands
iwlwiwi: mvm: use bss_conf->dtim_period instead of conf.ps_dtim_period
iwlwifi: dvm: disable power save by default
Merge remote-tracking branch 'iwlwifi-fixes/master' into NEXT
iwlwifi: trans: don't configure the set_active in SCD for dvm
iwlwifi: define the non shared antenna per hardware
iwlwifi: mvm: allow to collect debug data when restart is disabled
Eran Harary (1):
iwlwifi: mvm: allow preventing dummy notifications
Eyal Shapira (7):
mac80211: fix broken use of VHT/20Mhz with some APs
iwlwifi: mvm: treat EAPOLs like mgmt frames wrt rate
iwlwifi: mvm: fix an overflow in iwl_mvm_get_signal_strength
iwlwifi: mvm: add LDPC support
iwlwifi: enable LDPC in 8000 chip family
iwlwifi: mvm: rs: remove max_rate_idx
iwlwifi: mvm: rs: don't zero tx stats after idle
Fabian Frederick (2):
brcm80211: use container_of to resolve brcms_phy from brcms_phy_pub
brcm80211: use container_of to resolve dma_info from dma_pub
Hans Wennborg (2):
iwl4965: fix %d confusingly prefixed with 0x in format string
rtlwifi: fix %d confusingly prefixed with 0x in format strings
Hauke Mehrtens (7):
bcma: store more alternative addresses
bcma: add support for chipcommon B core
b43: tell the ucode the mac capabilities
b43: tell ucode the phy type and version
b43: add missing rate
b43: update some transmit header constants
b43: add support for setting the beacon listen interval
Johan Hedberg (41):
Bluetooth: Fix incorrect LE CoC PDU length restriction based on HCI MTU
Bluetooth: Remove unnecessary l2cap_chan_unlock before l2cap_chan_add
Bluetooth: Fix hci_conn reference counting for fixed channels
Bluetooth: Set addr_type only when it's needed
Bluetooth: Optimize connection parameter lookup for LE connections
Bluetooth: Improve *_get() functions to return the object type
Bluetooth: Fix using hci_conn_get() for hci_conn pointers
Bluetooth: Refactor connection parameter freeing into its own function
Bluetooth: Use zero timeout for immediate scheduling
Bluetooth: Fix hci_conn reference counting with hci_chan
Bluetooth: Set disc_timeout to 0 when calling hci_chan_del
Bluetooth: Ignore incoming data after initiating disconnection
Bluetooth: Remove hci_conn_hold/drop from hci_chan
Bluetooth: Set discon_timeout to 0 in l2cap_conn_del
Bluetooth: Use hci_disconnect for immediate disconnection from SMP
Bluetooth: Remove unused l2cap_conn_shutdown API
Bluetooth: Fix SMP error and response to be mutually exclusive
Bluetooth: Update hci_disconnect() to return an error value
Bluetooth: Use hci_disconnect() for mgmt_disconnect_device()
Bluetooth: Move clock offset reading into hci_disconnect()
Bluetooth: Add clarifying comment for LE CoC result value
Bluetooth: Remove unnecessary checks after canceling SMP security timer
Bluetooth: Don't take any action in smp_resume_cb if not encrypted
Bluetooth: Move identity address update behind a workqueue
Bluetooth: Remove unnecessary deferred work for SMP key distribution
Bluetooth: Fix locking of the SMP context
Bluetooth: Add define for key distribution mask
Bluetooth: Fix calling smp_distribute_keys() when still waiting for keys
Bluetooth: Add strict checks for allowed SMP PDUs
Bluetooth: Fix dereferencing conn variable before NULL check
Bluetooth: Fix mgmt pairing failure when authentication fails
Bluetooth: Fix allowing SMP Signing info PDU
Bluetooth: Remove unnecessary early initialization of variable
Bluetooth: Fix ignoring unknown SMP authentication requirement bits
Bluetooth: Centralize disallowing SMP commands to a single place
Bluetooth: Fix SMP security level when we have no IO capabilities
Bluetooth: Add smp_ltk_sec_level() helper function
Bluetooth: Fix L2CAP information request handling for fixed channels
Bluetooth: Avoid hard-coded IO capability values in SMP
Bluetooth: Expire RPA if encryption fails
Bluetooth: Fix re-setting RPA as expired when deferring update
Johannes Berg (19):
mac80211: clean up ieee80211_i.h
mac80211: add Intel Mobile Communications copyright
cfg80211: add Intel Mobile Communications copyright
iwlwifi: mvm: BT Coex - remove shadowing variable
iwlwifi: mvm: correctly handle PM/QoS changes from mac80211
iwlwifi: mvm: BT Coex - always initialize smps_mode
mac80211: annotate MMIC head/tailroom warning
cfg80211: clear connect keys when freeing them
mac80211: clear key material when freeing keys
cfg80211: clear wext keys when freeing and removing them
cfg80211: don't put kek/kck/replay counter on the stack
cfg80211: clear nl80211 messages carrying keys after processing
cfg80211: add WMM traffic stream API
iwlwifi: mvm: disable aggregation queues in station DB in FW
iwlwifi: pcie: clear command data on freeing
iwlwifi: mvm: don't update quota in firmware too often
iwlwifi: mvm: update d0i3 debugfs
iwlwifi: mvm: fix quota update avoidance
iwlwifi: mvm: update QoS parameters when they change
John W. Linville (3):
Merge branch 'for-john' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge tag 'mac80211-next-for-john-2014-09-12' of git://git.kernel.org/.../jberg/mac80211-next
Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth-next
Jukka Rissanen (3):
Bluetooth: 6lowpan: Increase the connection timeout value
Bluetooth: 6lowpan: Set the peer IPv6 address correctly
Bluetooth: 6lowpan: Route packets that are not meant to peer via correct device
Larry Finger (10):
rtlwifi: btcoexist: Modify btcoexist for changes in the V062814 Realtek version
rtlwifi: btcoexist: Modify rtl_btc for changes in latest Realtek code
rtlwifi: btcoexist: Modify driver for V062814 Realtek driver
rtlwifi: btcoexist: Modify driver to support BT coexistence in rtl8723be
rtlwifi: btcoexist: Add BT coexistence routines for driver rtl8821ae
rtlwifi: btcoexist: Add second part of BT coexistence routines for rtl8821ae
rtlwifi: btcoexist: Update remaining old parts of the driver
rtlwifi: btcoexist: Fix "always true" warning from commit ed364abffd6e
rtlwifi: btcoexist: avoid format string in printk
rtlwifi: btcoexist: Change local debugging macros CL_*** into the standard varieties
Liad Kaufman (3):
mac80211: fix description comment of ieee80211_subif_start_xmit
mac80211: add TDLS connection timeout
iwlwifi: make hw rev checking more readable
Lorenzo Bianconi (14):
cfg80211: enable dynack through nl80211
mac80211: extend set_coverage_class signature
ath9k: fix radar parameters initialization
ath9k: export methods related to ACK timeout estimation
ath9k: add duration field to ath_tx_status
ath9k: add dynamic ACK timeout estimation
ath9k: add config for (en|dis)abling ACK timeout estimation
ath9k: do not overwrite ACK timeout estimation
ath9k: add sampling methods for (tx|rx) timestamp
ath9k: enable control frame reception
ath9k: add debugfs support for dynack
ath9k: enable dynack using set_coverage_class codepath
ath9k: initialize ath_node linked list
ath9k: enable ext channel pulse detection
Luciano Coelho (5):
iwlwifi: mvm: set MAC_FILTER_IN_BEACON correctly for STA/P2P client
iwlwifi: mvm: reset ucode_loaded flag when mac80211 stop is called
iwlwifi: mvm: fail temp test enabling if the ucode is not loaded
iwlwifi: mvm: use the firmware to get the temperature during CT kill
iwlwifi: mvm: align CSA GO NOA time event naming with the firmware
Max Stepanov (1):
iwlwifi: mvm: add MVM_FW_MCAST_FILTER_PASS_ALL option
Michal Kazior (1):
mac80211: fix offloaded BA session traffic after hw restart
Oren Givon (2):
iwlwifi: add PCI IDs and add then new 3165 series
iwlwifi: add and edit 8000 series PCI IDs
Rafał Miłecki (12):
bcma: move bus struct setup into early part of host specific code
bcma: use separated function to initialize bus on SoC
bcma: move code for core registration into separate function
bcma: register NAND and QSPI cores early
b43: HT-PHY: Move radio preparation into init function
b43: HT-PHY: Move radio calibration to separated functions
b43: HT-PHY: Define some regs for 0x2059 radio
b43: HT-PHY: Complete radio init (add missing entries)
b43: HT-PHY: Set MAC frequency to correct values
b43: HT-PHY: Implement band switching
b43: HT-PHY: Update values for frequency calibration
b43: Implement PHY PLL reset
Steinar H. Gunderson (2):
mac80211: split 802.11h parsing from transmit power policy
mac80211: support DTPC IE (from Cisco Client eXtensions)
Sujith Manoharan (26):
ath9k: Fix beacon configuration for channel contexts
ath9k: Fix beacons for managed mode
ath9k: Fix panic when adding an AP interface
ath9k: Fix NoA start time calculation
ath9k: Fix offchannel duration calculation
ath9k: Add CTWindow support
ath9k: Fix RX filter calculation
ath9k: Fix ath_startrecv()
ath9k: Fix COMP_BAR filter
ath9k: Fix RX filters in channel contexts
ath9k: Fix interface accounting
ath9k: Use a subroutine to assign HW queues
ath9k: Fix offchannel operation
ath9k: Fix MCC scanning
ath9k: Assign offchannel duration properly
ath9k: Fix Notice of Absence issues
ath9k: Clear offchannel duration properly
ath9k: Fix channel switch time duration
ath9k: Fix beacon miss handling
ath9k: Fix beacon processing in offchannel
ath9k: Remove unnecessary tbtt assignment
ath9k: Check beaconing mode properly
ath9k: Set offchannel state properly
ath9k: Remove useless opmode check
ath9k: Fix primary station configuration
ath9k: Fix build error
Thomas Huehn (2):
mac80211: Unify rate statistic variables between Minstrel & Minstrel_HT
mac80211: improve minstrel_ht rate sorting by throughput & probability
Toralf Förster (1):
iwlwifi/iwl-drv.c: fix typo defualt -> default
Vladimir Kondratiev (17):
wil6210: firmware download
wil6210: debug prints for vring de-allocation
wil6210: print more information when connecting
wil6210: some more debug for the WMI mechanism
wil6210: coding style fixes
wil6210: platform specific module
wil6210: add more debug printouts
wil6210: fix usage of print_hex_dump_debug
wil6210: send connect request IEs to FW also for non-secure connection
wil6210: add change_beacon() driver callback
wil6210: enlarge TX/RX buffer length
wil6210: specify max. IE length
wil6210: fix typo in comment
wil6210: rename [en|dis]able irq to [un]mask
wil6210: fix for oops while stopping interface
wil6210: fix PTR_ERR() usage after initialization to constant
fixup! wil6210: fix usage of print_hex_dump_debug
Xinming Hu (1):
mwifiex: fix 5G association failure after leaving 2.4G IBSS
arch/mips/bcm47xx/setup.c | 4 +
drivers/bcma/Makefile | 1 +
drivers/bcma/bcma_private.h | 4 +
drivers/bcma/driver_chipcommon_b.c | 61 +
drivers/bcma/host_pci.c | 3 +
drivers/bcma/host_soc.c | 14 +-
drivers/bcma/main.c | 100 +-
drivers/bcma/scan.c | 17 +-
drivers/bluetooth/btusb.c | 9 +
drivers/net/wireless/ath/ath.h | 2 +
drivers/net/wireless/ath/ath10k/mac.c | 5 +-
drivers/net/wireless/ath/ath5k/mac80211-ops.c | 2 +-
drivers/net/wireless/ath/ath9k/Kconfig | 9 +
drivers/net/wireless/ath/ath9k/Makefile | 3 +
drivers/net/wireless/ath/ath9k/ar9002_mac.c | 7 +
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 9 +
drivers/net/wireless/ath/ath9k/ath9k.h | 25 +-
drivers/net/wireless/ath/ath9k/beacon.c | 14 +-
drivers/net/wireless/ath/ath9k/channel.c | 192 +-
drivers/net/wireless/ath/ath9k/debug.c | 30 +-
drivers/net/wireless/ath/ath9k/dynack.c | 351 ++
drivers/net/wireless/ath/ath9k/dynack.h | 103 +
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 2 +-
drivers/net/wireless/ath/ath9k/hw.c | 22 +-
drivers/net/wireless/ath/ath9k/hw.h | 7 +
drivers/net/wireless/ath/ath9k/init.c | 7 +-
drivers/net/wireless/ath/ath9k/mac.h | 1 +
drivers/net/wireless/ath/ath9k/main.c | 173 +-
drivers/net/wireless/ath/ath9k/recv.c | 51 +-
drivers/net/wireless/ath/ath9k/tx99.c | 2 +-
drivers/net/wireless/ath/ath9k/wow.c | 2 +-
drivers/net/wireless/ath/ath9k/xmit.c | 5 +
drivers/net/wireless/ath/wil6210/Kconfig | 9 +
drivers/net/wireless/ath/wil6210/Makefile | 3 +
drivers/net/wireless/ath/wil6210/cfg80211.c | 126 +-
drivers/net/wireless/ath/wil6210/debugfs.c | 60 +-
drivers/net/wireless/ath/wil6210/fw.c | 45 +
drivers/net/wireless/ath/wil6210/fw.h | 149 +
drivers/net/wireless/ath/wil6210/fw_inc.c | 495 +++
drivers/net/wireless/ath/wil6210/interrupt.c | 31 +-
drivers/net/wireless/ath/wil6210/main.c | 185 +-
drivers/net/wireless/ath/wil6210/netdev.c | 17 +-
drivers/net/wireless/ath/wil6210/pcie_bus.c | 39 +-
drivers/net/wireless/ath/wil6210/rx_reorder.c | 13 +-
drivers/net/wireless/ath/wil6210/txrx.c | 66 +-
drivers/net/wireless/ath/wil6210/txrx.h | 9 +-
drivers/net/wireless/ath/wil6210/wil6210.h | 50 +-
drivers/net/wireless/ath/wil6210/wil_platform.c | 49 +
drivers/net/wireless/ath/wil6210/wil_platform.h | 34 +
.../net/wireless/ath/wil6210/wil_platform_msm.c | 257 ++
.../net/wireless/ath/wil6210/wil_platform_msm.h | 24 +
drivers/net/wireless/ath/wil6210/wmi.c | 40 +-
drivers/net/wireless/ath/wil6210/wmi.h | 18 +-
drivers/net/wireless/b43/b43.h | 9 +
drivers/net/wireless/b43/main.c | 71 +-
drivers/net/wireless/b43/main.h | 2 +
drivers/net/wireless/b43/phy_ht.c | 205 +-
drivers/net/wireless/b43/phy_ht.h | 7 +-
drivers/net/wireless/b43/phy_n.c | 2 +-
drivers/net/wireless/b43/radio_2059.c | 341 +-
drivers/net/wireless/b43/radio_2059.h | 14 +
drivers/net/wireless/b43/xmit.h | 22 +-
drivers/net/wireless/brcm80211/brcmsmac/dma.c | 38 +-
.../net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c | 122 +-
.../net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c | 6 +-
.../net/wireless/brcm80211/brcmsmac/phy/phy_n.c | 8 +-
drivers/net/wireless/hostap/hostap_proc.c | 6 +-
drivers/net/wireless/iwlegacy/4965-mac.c | 7 +-
drivers/net/wireless/iwlwifi/dvm/mac80211.c | 4 +-
drivers/net/wireless/iwlwifi/dvm/power.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-7000.c | 31 +-
drivers/net/wireless/iwlwifi/iwl-8000.c | 14 +-
drivers/net/wireless/iwlwifi/iwl-config.h | 9 +
drivers/net/wireless/iwlwifi/iwl-csr.h | 10 +
drivers/net/wireless/iwlwifi/iwl-drv.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c | 3 +
drivers/net/wireless/iwlwifi/iwl-fw.h | 2 +
drivers/net/wireless/iwlwifi/iwl-io.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-nvm-parse.c | 7 +-
drivers/net/wireless/iwlwifi/iwl-trans.h | 8 +-
drivers/net/wireless/iwlwifi/mvm/Makefile | 2 +-
drivers/net/wireless/iwlwifi/mvm/coex.c | 13 +-
drivers/net/wireless/iwlwifi/mvm/constants.h | 8 +
drivers/net/wireless/iwlwifi/mvm/debugfs-vif.c | 3 +-
drivers/net/wireless/iwlwifi/mvm/debugfs.c | 15 +
drivers/net/wireless/iwlwifi/mvm/fw-api.h | 40 +-
drivers/net/wireless/iwlwifi/mvm/fw.c | 3 +
drivers/net/wireless/iwlwifi/mvm/mac-ctxt.c | 20 +-
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 183 +-
drivers/net/wireless/iwlwifi/mvm/mvm.h | 30 +-
drivers/net/wireless/iwlwifi/mvm/nvm.c | 3 +-
drivers/net/wireless/iwlwifi/mvm/ops.c | 18 +
drivers/net/wireless/iwlwifi/mvm/power.c | 67 +-
drivers/net/wireless/iwlwifi/mvm/quota.c | 32 +-
drivers/net/wireless/iwlwifi/mvm/rs.c | 68 +-
drivers/net/wireless/iwlwifi/mvm/rs.h | 10 +-
drivers/net/wireless/iwlwifi/mvm/rx.c | 6 +-
drivers/net/wireless/iwlwifi/mvm/scan.c | 4 +-
drivers/net/wireless/iwlwifi/mvm/sf.c | 6 +-
drivers/net/wireless/iwlwifi/mvm/sta.c | 12 +-
drivers/net/wireless/iwlwifi/mvm/tdls.c | 149 +
drivers/net/wireless/iwlwifi/mvm/time-event.c | 10 +-
drivers/net/wireless/iwlwifi/mvm/time-event.h | 8 +-
drivers/net/wireless/iwlwifi/mvm/tt.c | 326 +-
drivers/net/wireless/iwlwifi/mvm/tx.c | 10 +-
drivers/net/wireless/iwlwifi/pcie/drv.c | 8 +
drivers/net/wireless/iwlwifi/pcie/internal.h | 2 +
drivers/net/wireless/iwlwifi/pcie/rx.c | 2 +-
drivers/net/wireless/iwlwifi/pcie/trans.c | 3 +-
drivers/net/wireless/iwlwifi/pcie/tx.c | 12 +-
drivers/net/wireless/mac80211_hwsim.c | 8 +-
drivers/net/wireless/mwifiex/11n_rxreorder.c | 14 +
drivers/net/wireless/mwifiex/cfg80211.c | 15 +-
drivers/net/wireless/mwifiex/cmdevt.c | 4 +
drivers/net/wireless/mwifiex/decl.h | 4 +-
drivers/net/wireless/mwifiex/fw.h | 10 +-
drivers/net/wireless/mwifiex/init.c | 21 +-
drivers/net/wireless/mwifiex/main.c | 191 +-
drivers/net/wireless/mwifiex/main.h | 48 +-
drivers/net/wireless/mwifiex/pcie.c | 37 +-
drivers/net/wireless/mwifiex/pcie.h | 5 +-
drivers/net/wireless/mwifiex/scan.c | 112 +-
drivers/net/wireless/mwifiex/sdio.c | 28 +-
drivers/net/wireless/mwifiex/sta_cmdresp.c | 2 -
drivers/net/wireless/mwifiex/sta_ioctl.c | 9 +-
drivers/net/wireless/mwifiex/tdls.c | 4 +-
drivers/net/wireless/p54/main.c | 3 +-
.../net/wireless/rtlwifi/btcoexist/halbt_precomp.h | 6 +
.../wireless/rtlwifi/btcoexist/halbtc8192e2ant.c | 3849 +++++++++++++++++++
.../wireless/rtlwifi/btcoexist/halbtc8192e2ant.h | 185 +
.../wireless/rtlwifi/btcoexist/halbtc8723b1ant.c | 3170 ++++++++++++++++
.../wireless/rtlwifi/btcoexist/halbtc8723b1ant.h | 184 +
.../wireless/rtlwifi/btcoexist/halbtc8723b2ant.c | 550 +--
.../wireless/rtlwifi/btcoexist/halbtc8723b2ant.h | 31 +-
.../wireless/rtlwifi/btcoexist/halbtc8821a1ant.c | 2970 +++++++++++++++
.../wireless/rtlwifi/btcoexist/halbtc8821a1ant.h | 188 +
.../wireless/rtlwifi/btcoexist/halbtc8821a2ant.c | 3879 ++++++++++++++++++++
.../wireless/rtlwifi/btcoexist/halbtc8821a2ant.h | 205 ++
.../net/wireless/rtlwifi/btcoexist/halbtcoutsrc.c | 52 +-
.../net/wireless/rtlwifi/btcoexist/halbtcoutsrc.h | 122 +-
drivers/net/wireless/rtlwifi/btcoexist/rtl_btc.c | 27 +-
drivers/net/wireless/rtlwifi/btcoexist/rtl_btc.h | 6 +-
drivers/net/wireless/rtlwifi/pci.c | 6 +-
drivers/net/wireless/rtlwifi/rtl8192de/phy.c | 8 +-
drivers/net/wireless/rtlwifi/rtl8723ae/hal_btc.c | 4 +-
drivers/net/wireless/rtlwifi/wifi.h | 15 +-
drivers/usb/host/bcma-hcd.c | 2 +-
include/linux/bcma/bcma.h | 4 +-
include/linux/bcma/bcma_driver_chipcommon.h | 8 +
include/linux/bcma/bcma_soc.h | 1 +
include/linux/ieee80211.h | 8 +-
include/net/bluetooth/hci_core.h | 14 +-
include/net/bluetooth/l2cap.h | 10 +-
include/net/cfg80211.h | 44 +-
include/net/mac80211.h | 20 +-
include/uapi/linux/nl80211.h | 100 +
net/bluetooth/6lowpan.c | 80 +-
net/bluetooth/amp.c | 13 +-
net/bluetooth/hci_conn.c | 49 +-
net/bluetooth/hci_core.c | 30 +-
net/bluetooth/hci_event.c | 33 +-
net/bluetooth/hidp/core.c | 10 +-
net/bluetooth/l2cap_core.c | 120 +-
net/bluetooth/l2cap_sock.c | 8 +
net/bluetooth/mgmt.c | 37 +-
net/bluetooth/smp.c | 272 +-
net/bluetooth/smp.h | 10 +
net/mac80211/agg-rx.c | 5 +-
net/mac80211/cfg.c | 101 +-
net/mac80211/debugfs.c | 6 +-
net/mac80211/debugfs_netdev.c | 4 +-
net/mac80211/debugfs_sta.c | 1 +
net/mac80211/driver-ops.h | 2 +-
net/mac80211/ibss.c | 1 +
net/mac80211/ieee80211_i.h | 8 +-
net/mac80211/iface.c | 15 +-
net/mac80211/key.c | 3 +-
net/mac80211/main.c | 1 +
net/mac80211/mlme.c | 131 +-
net/mac80211/rc80211_minstrel.c | 98 +-
net/mac80211/rc80211_minstrel.h | 43 +-
net/mac80211/rc80211_minstrel_debugfs.c | 19 +-
net/mac80211/rc80211_minstrel_ht.c | 303 +-
net/mac80211/rc80211_minstrel_ht.h | 41 +-
net/mac80211/rc80211_minstrel_ht_debugfs.c | 10 +-
net/mac80211/rx.c | 11 +
net/mac80211/scan.c | 1 +
net/mac80211/sta_info.c | 1 +
net/mac80211/sta_info.h | 7 +
net/mac80211/status.c | 22 +-
net/mac80211/tdls.c | 4 +
net/mac80211/trace.h | 4 +-
net/mac80211/tx.c | 6 +-
net/mac80211/util.c | 26 +
net/mac80211/wme.c | 1 +
net/mac80211/wpa.c | 7 +-
net/wireless/chan.c | 1 +
net/wireless/core.c | 3 +-
net/wireless/ibss.c | 4 +-
net/wireless/mlme.c | 4 +-
net/wireless/nl80211.c | 233 +-
net/wireless/nl80211.h | 3 +-
net/wireless/rdev-ops.h | 31 +
net/wireless/reg.c | 82 +-
net/wireless/scan.c | 1 +
net/wireless/sme.c | 6 +-
net/wireless/trace.h | 45 +
net/wireless/util.c | 3 +-
net/wireless/wext-compat.c | 2 +
net/wireless/wext-sme.c | 2 +-
210 files changed, 20726 insertions(+), 2404 deletions(-)
create mode 100644 drivers/bcma/driver_chipcommon_b.c
create mode 100644 drivers/net/wireless/ath/ath9k/dynack.c
create mode 100644 drivers/net/wireless/ath/ath9k/dynack.h
create mode 100644 drivers/net/wireless/ath/wil6210/fw.c
create mode 100644 drivers/net/wireless/ath/wil6210/fw.h
create mode 100644 drivers/net/wireless/ath/wil6210/fw_inc.c
create mode 100644 drivers/net/wireless/ath/wil6210/wil_platform.c
create mode 100644 drivers/net/wireless/ath/wil6210/wil_platform.h
create mode 100644 drivers/net/wireless/ath/wil6210/wil_platform_msm.c
create mode 100644 drivers/net/wireless/ath/wil6210/wil_platform_msm.h
create mode 100644 drivers/net/wireless/iwlwifi/mvm/tdls.c
create mode 100644 drivers/net/wireless/rtlwifi/btcoexist/halbtc8192e2ant.c
create mode 100644 drivers/net/wireless/rtlwifi/btcoexist/halbtc8192e2ant.h
create mode 100644 drivers/net/wireless/rtlwifi/btcoexist/halbtc8723b1ant.c
create mode 100644 drivers/net/wireless/rtlwifi/btcoexist/halbtc8723b1ant.h
create mode 100644 drivers/net/wireless/rtlwifi/btcoexist/halbtc8821a1ant.c
create mode 100644 drivers/net/wireless/rtlwifi/btcoexist/halbtc8821a1ant.h
create mode 100644 drivers/net/wireless/rtlwifi/btcoexist/halbtc8821a2ant.c
create mode 100644 drivers/net/wireless/rtlwifi/btcoexist/halbtc8821a2ant.h
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [net-next PATCH v2 2/2] net: sched: cls_u32 changes to knode must appear atomic to readers
From: David Miller @ 2014-09-22 20:00 UTC (permalink / raw)
To: john.fastabend; +Cc: xiyou.wangcong, jhs, eric.dumazet, netdev
In-Reply-To: <20140920045031.9869.76112.stgit@nitbit.x32>
From: John Fastabend <john.fastabend@gmail.com>
Date: Fri, 19 Sep 2014 21:50:34 -0700
> Changes to the cls_u32 classifier must appear atomic to the
> readers. Before this patch if a change is requested for both
> the exts and ifindex, first the ifindex is updated then the
> exts with tcf_exts_change(). This opens a small window where
> a reader can have a exts chain with an incorrect ifindex. This
> violates the the RCU semantics.
>
> Here we resolve this by always passing u32_set_parms() a copy
> of the tc_u_knode to work on and then inserting it into the hash
> table after the updates have been successfully applied.
>
> Tested with the following short script:
...
> CC: Eric Dumazet <edumazet@google.com>
> CC: Jamal Hadi Salim <jhs@mojatatu.com>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH v2 1/2] net: cls_u32: fix missed pcpu_success free_percpu
From: David Miller @ 2014-09-22 19:59 UTC (permalink / raw)
To: john.fastabend; +Cc: xiyou.wangcong, jhs, eric.dumazet, netdev
In-Reply-To: <20140920045003.9869.16851.stgit@nitbit.x32>
From: John Fastabend <john.fastabend@gmail.com>
Date: Fri, 19 Sep 2014 21:50:04 -0700
> This fixes a missed free_percpu in the unwind code path and when
> keys are destroyed.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH v14 net-next 00/11] eBPF syscall, verifier, testsuite
From: Daniel Borkmann @ 2014-09-22 19:57 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Ingo Molnar, Linus Torvalds, Andy Lutomirski,
Hannes Frederic Sowa, Chema Gonzalez, Eric Dumazet,
Peter Zijlstra, Pablo Neira Ayuso, H. Peter Anvin, Andrew Morton,
Kees Cook, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1411344411-3824-1-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
On 09/22/2014 02:06 AM, Alexei Starovoitov wrote:
...
> v13 -> v14:
> - small change to 1st patch to ease 'new userspace with old kernel'
> problem (done similar to perf_copy_attr()) (suggested by Daniel)
Thanks for taking care of it.
^ permalink raw reply
* Re: [net-next PATCH v2 00/29] Add support for the Intel FM10000 Ethernet Switch Host Interface
From: Jeff Kirsher @ 2014-09-22 19:46 UTC (permalink / raw)
To: David Miller
Cc: alexander.h.duyck, nhorman, netdev, john.fastabend, matthew.vick,
sassmann
In-Reply-To: <20140922.151750.1374374207690364454.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]
On Mon, 2014-09-22 at 15:17 -0400, David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Mon, 22 Sep 2014 11:36:04 -0700
>
> > On Sat, 2014-09-20 at 19:45 -0400, Alexander Duyck wrote:
> >> This patch series adds support for the FM10000 Ethernet switch host
> >> interface. The Intel FM10000 Ethernet Switch is a 48-port Ethernet switch
> >> supporting both Ethernet ports and PCI Express host interfaces. The fm10k
> >> driver provides support for the host interface portion of the switch, both
> >> PF and VF.
> >>
> >> As the host interfaces are directly connected to the switch this results in
> >> some significant differences versus a standard network driver. For example
> >> there is no PHY or MII on the device. Since packets are delivered directly
> >> from the switch to the host interface these are unnecessary. Otherwise most
> >> of the functionality is very similar to our other network drivers such as
> >> ixgbe or igb. For example we support all the standard network offloads,
> >> jumbo frames, SR-IOV (64 VFS), PTP, and some VXLAN and NVGRE offloads.
> >>
> >> ---
> >
> > Dave, if it makes it easier on you, I can add Alex's series of patches
> > to my net-next tree for you to pull. Just give me an hour or so so that
> > I can update my net-next and push his patches up to my tree.
>
> Yeah, could you please do that?
>
> Thanks.
Working on it now, I will let you know when I have it pushed up to my
tree.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM
From: Pavel Machek @ 2014-09-22 19:49 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: James Bottomley, Tejun Heo, Luis R. Rodriguez, Lennart Poettering,
Kay Sievers, Greg Kroah-Hartman, Wu Zhangjin, Takashi Iwai,
Arjan van de Ven, linux-kernel@vger.kernel.org, Oleg Nesterov,
hare, Andrew Morton, Tetsuo Handa, Joseph Salisbury,
Benjamin Poirier, Santosh Rastapur, One Thousand Gnomes,
Tim Gardner, Pierre Fersing, Nagalakshmi Nandigama
In-Reply-To: <20140911202354.GA2598@core.coreip.homeip.net>
On Thu 2014-09-11 13:23:54, Dmitry Torokhov wrote:
> On Thu, Sep 11, 2014 at 12:59:25PM -0700, James Bottomley wrote:
> >
> > On Tue, 2014-09-09 at 16:01 -0700, Dmitry Torokhov wrote:
> > > On Tuesday, September 09, 2014 03:46:23 PM James Bottomley wrote:
> > > > On Wed, 2014-09-10 at 07:41 +0900, Tejun Heo wrote:
> > > > >
> > > > > The thing is that we have to have dynamic mechanism to listen for
> > > > > device attachments no matter what and such mechanism has been in place
> > > > > for a long time at this point. The synchronous wait simply doesn't
> > > > > serve any purpose anymore and kinda gets in the way in that it makes
> > > > > it a possibly extremely slow process to tell whether loading of a
> > > > > module succeeded or not because the wait for the initial round of
> > > > > probe is piggybacked.
> > > >
> > > > OK, so we just fire and forget in userland ... why bother inventing an
> > > > elaborate new infrastructure in the kernel to do exactly what
> > > >
> > > > modprobe <mod> &
> > > >
> > > > would do?
> > >
> > > Just so we do not forget: we also want the no-modules case to also be able
> > > to probe asynchronously so that a slow device does not stall kernel booting.
> >
> > Yes, but we mostly do this anyway. SCSI for instance does asynchronous
> > scanning of attached devices (once the cards are probed)
>
> What would it do it card was a bit slow to probe?
>
> > but has a sync
> > point for ordering.
>
> Quite often we do not really care about ordering of devices. I mean,
> does it matter if your mouse is discovered before your keyboard or
> after?
Actually yes, I suspect it does.
I do evtest /dev/input/eventX by hand, occassionaly. It would be
annoying if they moved between reboots.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH v2 net] ipv4: do not use this_cpu_ptr() in preemptible context
From: Joe M @ 2014-09-22 19:34 UTC (permalink / raw)
To: Tom Herbert
Cc: Eric Dumazet, Stephen Hemminger, David Miller, Linux Netdev List
In-Reply-To: <20140922190953.GA15929@master>
[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]
Hello Eric,
> > > v2: use latest and shiny raw_cpu_ptr(), as it seems the latest
> > > incantation of ever changing percpu interface.
> > >
> > > net/ipv4/ip_tunnel.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> The below grep shows 3 uses of this_cpu_ptr, whereas the patch only
> replaces 2 instances. Just want to check if that is ok.
>
> grep --ignore-case --exclude-dir=".git" --recursive this_cpu_ptr ip_tunnel.c
> __tunnel_dst_set(this_cpu_ptr(t->dst_cache), dst, saddr);
> idst = this_cpu_ptr(t->dst_cache);
> tstats = this_cpu_ptr(tunnel->dev->tstats);
grep --ignore-case --exclude-dir=".git" --recursive this_cpu_ptr *.c
ip_input.c: struct ip_rt_acct *st = this_cpu_ptr(ip_rt_acct);
ip_vti.c: tstats = this_cpu_ptr(dev->tstats);
route.c: p = (struct rtable **)__this_cpu_ptr(nh->nh_pcpu_rth_output);
route.c: prth = __this_cpu_ptr(nh->nh_pcpu_rth_output);
tcp.c: return __this_cpu_ptr(p);
Is it ok for ip_vti.c and ip_input.c to use this_cpu_ptr?
Thanks
Joe
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 2/2] bonding: remove the unnecessary notes for bond_xmit_broadcast()
From: David Miller @ 2014-09-22 19:21 UTC (permalink / raw)
To: dingtianhong; +Cc: nikolay, andy, fubar, vfalico, netdev
In-Reply-To: <541C29FD.704@huawei.com>
From: Ding Tianhong <dingtianhong@huawei.com>
Date: Fri, 19 Sep 2014 21:05:01 +0800
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/2] bonding: slight optimization for bond_xmit_roundrobin()
From: David Miller @ 2014-09-22 19:21 UTC (permalink / raw)
To: dingtianhong; +Cc: nikolay, andy, fubar, vfalico, netdev
In-Reply-To: <541C29F9.6020001@huawei.com>
From: Ding Tianhong <dingtianhong@huawei.com>
Date: Fri, 19 Sep 2014 21:04:57 +0800
> When the slave is the curr_active_slave, no need to check
> whether the slave is active or not, it is always active.
>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
Applied.
^ permalink raw reply
* Re: [patch -next] r8169: fix an if condition
From: David Miller @ 2014-09-22 19:19 UTC (permalink / raw)
To: dan.carpenter; +Cc: nic_swsd, hayeswang, netdev, kernel-janitors
In-Reply-To: <20140919104025.GA26391@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Fri, 19 Sep 2014 13:40:25 +0300
> There is an extra semi-colon so __rtl8169_set_features() is called every
> time.
>
> Fixes: 929a031dfd62 ('r8169: adjust __rtl8169_set_features')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Dan, this bug exists in 'net' so that is what you should have
targetted this tree at.
Applied, thanks.
^ permalink raw reply
* Re: [net-next PATCH v2 00/29] Add support for the Intel FM10000 Ethernet Switch Host Interface
From: David Miller @ 2014-09-22 19:17 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: alexander.h.duyck, nhorman, netdev, john.fastabend, matthew.vick,
sassmann
In-Reply-To: <1411410964.2513.1.camel@jtkirshe-mobl.jf.intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 22 Sep 2014 11:36:04 -0700
> On Sat, 2014-09-20 at 19:45 -0400, Alexander Duyck wrote:
>> This patch series adds support for the FM10000 Ethernet switch host
>> interface. The Intel FM10000 Ethernet Switch is a 48-port Ethernet switch
>> supporting both Ethernet ports and PCI Express host interfaces. The fm10k
>> driver provides support for the host interface portion of the switch, both
>> PF and VF.
>>
>> As the host interfaces are directly connected to the switch this results in
>> some significant differences versus a standard network driver. For example
>> there is no PHY or MII on the device. Since packets are delivered directly
>> from the switch to the host interface these are unnecessary. Otherwise most
>> of the functionality is very similar to our other network drivers such as
>> ixgbe or igb. For example we support all the standard network offloads,
>> jumbo frames, SR-IOV (64 VFS), PTP, and some VXLAN and NVGRE offloads.
>>
>> ---
>
> Dave, if it makes it easier on you, I can add Alex's series of patches
> to my net-next tree for you to pull. Just give me an hour or so so that
> I can update my net-next and push his patches up to my tree.
Yeah, could you please do that?
Thanks.
^ permalink raw reply
* Re: [PATCH v2 net] ipv4: do not use this_cpu_ptr() in preemptible context
From: Joe M @ 2014-09-22 19:17 UTC (permalink / raw)
To: Tom Herbert
Cc: Eric Dumazet, Stephen Hemminger, David Miller, Linux Netdev List
In-Reply-To: <CA+mtBx9U1EVmRi4amqVT=MMUvMSqo5907yzM0ytkQNvT74Gu2Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 643 bytes --]
Hello Eric, Tom,
> > this_cpu_ptr() in preemptible context is generally bad
> >
> > Sep 22 05:05:55 br kernel: [ 94.608310] BUG: using smp_processor_id()
> > in
> > preemptible [00000000] code: ip/2261
> > Sep 22 05:05:55 br kernel: [ 94.608316] caller is
> > tunnel_dst_set.isra.28+0x20/0x60 [ip_tunnel]
> > Sep 22 05:05:55 br kernel: [ 94.608319] CPU: 3 PID: 2261 Comm: ip Not
> > tainted
> > 3.17.0-rc5 #82
> >
> > We can simply use raw_cpu_ptr(), as preemption is safe in these
> > contexts.
> >
> > Should fix https://bugzilla.kernel.org/show_bug.cgi?id=84991
> >
Thanks, the fix worked. I do not see the BUG message anymore.
Joe
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 net] ipv4: do not use this_cpu_ptr() in preemptible context
From: Joe M @ 2014-09-22 19:09 UTC (permalink / raw)
To: Tom Herbert
Cc: Eric Dumazet, Stephen Hemminger, David Miller, Linux Netdev List
In-Reply-To: <CA+mtBx9U1EVmRi4amqVT=MMUvMSqo5907yzM0ytkQNvT74Gu2Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 632 bytes --]
Hello Eric,
Thanks for the quick fix.
> > v2: use latest and shiny raw_cpu_ptr(), as it seems the latest
> > incantation of ever changing percpu interface.
> >
> > net/ipv4/ip_tunnel.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
The below grep shows 3 uses of this_cpu_ptr, whereas the patch only
replaces 2 instances. Just want to check if that is ok.
grep --ignore-case --exclude-dir=".git" --recursive this_cpu_ptr ip_tunnel.c
__tunnel_dst_set(this_cpu_ptr(t->dst_cache), dst, saddr);
idst = this_cpu_ptr(t->dst_cache);
tstats = this_cpu_ptr(tunnel->dev->tstats);
Thanks
Joe
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] udp: Need to make ip6_udp_tunnel.c have GPL license
From: David Miller @ 2014-09-22 19:08 UTC (permalink / raw)
To: therbert; +Cc: azhou, netdev
In-Reply-To: <1411411184-11993-1-git-send-email-therbert@google.com>
From: Tom Herbert <therbert@google.com>
Date: Mon, 22 Sep 2014 11:39:44 -0700
> Unable to load various tunneling modules without this:
>
> [ 80.679049] fou: Unknown symbol udp_sock_create6 (err 0)
> [ 91.439939] ip6_udp_tunnel: Unknown symbol ip6_local_out (err 0)
> [ 91.439954] ip6_udp_tunnel: Unknown symbol __put_net (err 0)
> [ 91.457792] vxlan: Unknown symbol udp_sock_create6 (err 0)
> [ 91.457831] vxlan: Unknown symbol udp_tunnel6_xmit_skb (err 0)
>
> Signed-off-by: Tom Herbert <therbert@google.com>
Applied, thanks Tom.
^ 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