* Re: [PATCH net 1/3] bql: Fix POSDIFF() to integer overflow aware.
From: Eric Dumazet @ 2012-05-31 7:58 UTC (permalink / raw)
To: Hiroaki SHIMODA; +Cc: davem, therbert, denys, netdev
In-Reply-To: <20120531072439.6c634a0b.shimoda.hiroaki@gmail.com>
On Thu, 2012-05-31 at 07:24 +0900, Hiroaki SHIMODA wrote:
> POSDIFF() fails to take into account integer overflow case.
>
> Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
> Cc: Tom Herbert <therbert@google.com>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Denys Fedoryshchenko <denys@visp.net.lb>
> ---
> lib/dynamic_queue_limits.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/lib/dynamic_queue_limits.c b/lib/dynamic_queue_limits.c
> index 6ab4587..c87eb76 100644
> --- a/lib/dynamic_queue_limits.c
> +++ b/lib/dynamic_queue_limits.c
> @@ -10,7 +10,7 @@
> #include <linux/jiffies.h>
> #include <linux/dynamic_queue_limits.h>
>
> -#define POSDIFF(A, B) ((A) > (B) ? (A) - (B) : 0)
> +#define POSDIFF(A, B) ((int)((A) - (B)) > 0 ? (A) - (B) : 0)
>
> /* Records completed count and recalculates the queue limit */
> void dql_completed(struct dql *dql, unsigned int count)
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* [News] Help for Heartache - May, 2012
From: How to Heal a Broken Heart @ 2012-05-31 6:46 UTC (permalink / raw)
To: netdev
If you or any of your associates, clients or prospects are suffering from the pain of losing a loved one, they may be relieved by the companionship and counsel they can find on a new website: http://rx4heartache.com. Please feel free to pass on the good news that relief can be found there. It's a place where they can exchange heartache for hopefulness. Thanks to you in advance for sharing this good news with anyone who suffers a broken heart from the loss of someone they once loved.
^ permalink raw reply
* [V2 PATCH] net: sock: validate data_len before allocating skb in sock_alloc_send_pskb()
From: Jason Wang @ 2012-05-31 7:18 UTC (permalink / raw)
To: netdev, edumazet, mst, davem, linux-kernel; +Cc: stable
We need to validate the number of pages consumed by data_len, otherwise frags
array could be overflowed by userspace. So this patch validate data_len and
return -EMSGSIZE when data_len may occupies more frags than MAX_SKB_FRAGS.
Cc: stable@vger.kernel.org [2.6.27+]
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
net/core/sock.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index 653f8c0..9e5b71f 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1592,6 +1592,11 @@ struct sk_buff *sock_alloc_send_pskb(struct sock *sk, unsigned long header_len,
gfp_t gfp_mask;
long timeo;
int err;
+ int npages = (data_len + (PAGE_SIZE - 1)) >> PAGE_SHIFT;
+
+ err = -EMSGSIZE;
+ if (npages > MAX_SKB_FRAGS)
+ goto failure;
gfp_mask = sk->sk_allocation;
if (gfp_mask & __GFP_WAIT)
@@ -1610,14 +1615,12 @@ struct sk_buff *sock_alloc_send_pskb(struct sock *sk, unsigned long header_len,
if (atomic_read(&sk->sk_wmem_alloc) < sk->sk_sndbuf) {
skb = alloc_skb(header_len, gfp_mask);
if (skb) {
- int npages;
int i;
/* No pages, we're done... */
if (!data_len)
break;
- npages = (data_len + (PAGE_SIZE - 1)) >> PAGE_SHIFT;
skb->truesize += data_len;
skb_shinfo(skb)->nr_frags = npages;
for (i = 0; i < npages; i++) {
^ permalink raw reply related
* Re: Difficulties to get 1Gbps on be2net ethernet card
From: Jean-Michel Hautbois @ 2012-05-31 6:54 UTC (permalink / raw)
To: Sathya.Perla; +Cc: eric.dumazet, netdev, yevgenyp
In-Reply-To: <3367B80B08154D42A3B2BC708B5D41F647C678B73F@EXMAIL.ad.emulex.com>
2012/5/30 <Sathya.Perla@emulex.com>:
>>-----Original Message-----
>>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
>>Behalf Of Jean-Michel Hautbois
>>
>>2012/5/30 Jean-Michel Hautbois <jhautbois@gmail.com>:
>>
>>I used vmstat in order to see the differences between the two kernels.
>>The main difference is the number of interrupts per second.
>>I have an average of 87500 on 3.2 and 7500 on 2.6, 10 times lower !
>>I suspect the be2net driver to be the main cause, and I checkes the
>>/proc/interrupts file in order to be sure.
>>
>>I have for eth1-tx on 2.6.26 about 2200 interrupts per second and 23000 on 3.2.
>>BTW, it is named eth1-q0 on 3.2 (and tx and rx are the same IRQ)
>>whereas there is eth1-rx0 and eth1-tx on 2.6.26.
>
> Yes, there is an issue with be2net interrupt mitigation in the recent code with
> RX and TX on the same Evt-Q (commit 10ef9ab4). The high interrupt rate happens when a TX blast is
> done while RX is relatively silent on a queue pair. Interrupt rate due to TX completions is not being
> mitigated.
>
> I have a fix and will send it out soon..
>
> thanks,
> -Sathya
It seems this issue exist with mellanox mlx4 too...
I have a bond between eth1 (be2net) and eth9 (mlx4_en) and I can
switch from one to the other using ifenslave.
Setting a queue of 4000 on be2net works well in my use case, when I
switch to mlx4 based NIC which has a default queue len of 1000, I have
dropped packets too (less than be2net, but about 30-50 per second).
Setting a queue len of 4000 on mlx4 works too, but the number of
interrupts is similar.
The use case is the same : Lots of TX, no RX.
JM
^ permalink raw reply
* Re: [PATCH] net: sock: validate data_len before allocating skb in sock_alloc_send_pskb()
From: Jason Wang @ 2012-05-31 6:43 UTC (permalink / raw)
To: Eric Dumazet
Cc: Michael S. Tsirkin, David Miller, netdev, linux-kernel, stable
In-Reply-To: <1338445232.2760.1171.camel@edumazet-glaptop>
On 05/31/2012 02:20 PM, Eric Dumazet wrote:
> On Thu, 2012-05-31 at 14:11 +0800, Jason Wang wrote:
>
>> Not affected, only code duplication. It's no harm the check the data_len
>> again for packet sockets, so better to unify the code and fix the issue
>> in one place?
> As a matter of fact, we currently allocate order-0 pages, but it could
> be nice trying to use order-1 or order-2 pages, on arches where
> PAGE_SIZE is so small (4096 bytes)
>
> So lets do this test in sock_alloc_send_pskb() to allow future changes.
>
> af_unix is kind of special, because it tries to lower risk of high order
> linear allocation failures. And for small sizes, it wants linear skbs to
> have no performance regression (prior kernels were allocating linear
> skbs)
>
Thanks for the clarification, would post V2.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* RE: [PATCH net 0/6] batch of mlx4 fixes, mostly to SRIOV
From: Yevgeny Petrilin @ 2012-05-31 6:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, Or Gerlitz, jackm@dev.mellanox.co.il
In-Reply-To: <20120530.163700.720524088985729456.davem@davemloft.net>
>
> Why did you send multiple copies of some of these patches to the list?
>
> Patches #1, #2, and #5 showed up twice.
Hi Dave,
Sorry for this, I had some problem with mail client and thought that those 3 weren't sent at the first time.
Yevgeny
^ permalink raw reply
* Re: [PATCH] net: sock: validate data_len before allocating skb in sock_alloc_send_pskb()
From: Eric Dumazet @ 2012-05-31 6:20 UTC (permalink / raw)
To: Jason Wang; +Cc: Michael S. Tsirkin, David Miller, netdev, linux-kernel, stable
In-Reply-To: <4FC70BA8.5060200@redhat.com>
On Thu, 2012-05-31 at 14:11 +0800, Jason Wang wrote:
> Not affected, only code duplication. It's no harm the check the data_len
> again for packet sockets, so better to unify the code and fix the issue
> in one place?
As a matter of fact, we currently allocate order-0 pages, but it could
be nice trying to use order-1 or order-2 pages, on arches where
PAGE_SIZE is so small (4096 bytes)
So lets do this test in sock_alloc_send_pskb() to allow future changes.
af_unix is kind of special, because it tries to lower risk of high order
linear allocation failures. And for small sizes, it wants linear skbs to
have no performance regression (prior kernels were allocating linear
skbs)
^ permalink raw reply
* Re: [PATCH] net: sock: validate data_len before allocating skb in sock_alloc_send_pskb()
From: Jason Wang @ 2012-05-31 6:11 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: David Miller, eric.dumazet, netdev, linux-kernel, stable
In-Reply-To: <20120531060201.GA13158@redhat.com>
On 05/31/2012 02:02 PM, Michael S. Tsirkin wrote:
> On Thu, May 31, 2012 at 02:00:14PM +0800, Jason Wang wrote:
>> On 05/30/2012 03:02 PM, David Miller wrote:
>>> From: Eric Dumazet<eric.dumazet@gmail.com>
>>> Date: Wed, 30 May 2012 08:46:23 +0200
>>>
>>>> Why doing this test in the while (1) block, it should be done before the
>>>> loop...
>>>>
>>>> Or even in the caller, note net/unix/af_unix.c does this right.
>>>>
>>>> if (len> SKB_MAX_ALLOC)
>>>> data_len = min_t(size_t,
>>>> len - SKB_MAX_ALLOC,
>>>> MAX_SKB_FRAGS * PAGE_SIZE);
>>>>
>>>> skb = sock_alloc_send_pskb(sk, len - data_len, data_len,
>>>> msg->msg_flags& MSG_DONTWAIT,&err);
>>> My impression is that the callers should be fixed to. It makes no sense
>>> to penalize the call sites that get this right.
>>>
>>> And yes, if we do check it in sock_alloc_send_pskb() it should be done
>>> at function entry, not inside the loop.
>> Sure, so is it ok for me to send a V2 that just do the fixing in
>> sock_alloc_sned_pskb() as it's simple and easy to be accepted by
>> stable version?
>>
>> For the fix of callers, I want to post fixes on top as I find
>> there's some code duplication of {tun|macvtap|packet}_alloc_skb()
>> and I want to unify them to a common helper in sock.c. Then I can
>> fix this issue in the new helper.
> Are packet sockets really affected?
> If yes the only call site that gets this right is unix sockets?
Not affected, only code duplication. It's no harm the check the data_len
again for packet sockets, so better to unify the code and fix the issue
in one place?
>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: sock: validate data_len before allocating skb in sock_alloc_send_pskb()
From: Michael S. Tsirkin @ 2012-05-31 6:02 UTC (permalink / raw)
To: Jason Wang; +Cc: David Miller, eric.dumazet, netdev, linux-kernel, stable
In-Reply-To: <4FC708EE.2020908@redhat.com>
On Thu, May 31, 2012 at 02:00:14PM +0800, Jason Wang wrote:
> On 05/30/2012 03:02 PM, David Miller wrote:
> >From: Eric Dumazet<eric.dumazet@gmail.com>
> >Date: Wed, 30 May 2012 08:46:23 +0200
> >
> >>Why doing this test in the while (1) block, it should be done before the
> >>loop...
> >>
> >>Or even in the caller, note net/unix/af_unix.c does this right.
> >>
> >> if (len> SKB_MAX_ALLOC)
> >> data_len = min_t(size_t,
> >> len - SKB_MAX_ALLOC,
> >> MAX_SKB_FRAGS * PAGE_SIZE);
> >>
> >> skb = sock_alloc_send_pskb(sk, len - data_len, data_len,
> >> msg->msg_flags& MSG_DONTWAIT,&err);
> >My impression is that the callers should be fixed to. It makes no sense
> >to penalize the call sites that get this right.
> >
> >And yes, if we do check it in sock_alloc_send_pskb() it should be done
> >at function entry, not inside the loop.
>
> Sure, so is it ok for me to send a V2 that just do the fixing in
> sock_alloc_sned_pskb() as it's simple and easy to be accepted by
> stable version?
>
> For the fix of callers, I want to post fixes on top as I find
> there's some code duplication of {tun|macvtap|packet}_alloc_skb()
> and I want to unify them to a common helper in sock.c. Then I can
> fix this issue in the new helper.
Are packet sockets really affected?
If yes the only call site that gets this right is unix sockets?
> >--
> >To unsubscribe from this list: send the line "unsubscribe netdev" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: sock: validate data_len before allocating skb in sock_alloc_send_pskb()
From: Jason Wang @ 2012-05-31 6:00 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev, linux-kernel, stable, mst
In-Reply-To: <20120530.030205.1337682162603770949.davem@davemloft.net>
On 05/30/2012 03:02 PM, David Miller wrote:
> From: Eric Dumazet<eric.dumazet@gmail.com>
> Date: Wed, 30 May 2012 08:46:23 +0200
>
>> Why doing this test in the while (1) block, it should be done before the
>> loop...
>>
>> Or even in the caller, note net/unix/af_unix.c does this right.
>>
>> if (len> SKB_MAX_ALLOC)
>> data_len = min_t(size_t,
>> len - SKB_MAX_ALLOC,
>> MAX_SKB_FRAGS * PAGE_SIZE);
>>
>> skb = sock_alloc_send_pskb(sk, len - data_len, data_len,
>> msg->msg_flags& MSG_DONTWAIT,&err);
> My impression is that the callers should be fixed to. It makes no sense
> to penalize the call sites that get this right.
>
> And yes, if we do check it in sock_alloc_send_pskb() it should be done
> at function entry, not inside the loop.
Sure, so is it ok for me to send a V2 that just do the fixing in
sock_alloc_sned_pskb() as it's simple and easy to be accepted by stable
version?
For the fix of callers, I want to post fixes on top as I find there's
some code duplication of {tun|macvtap|packet}_alloc_skb() and I want to
unify them to a common helper in sock.c. Then I can fix this issue in
the new helper.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* linux-next: manual merge of the vhost tree with the net tree
From: Stephen Rothwell @ 2012-05-31 3:13 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: linux-next, linux-kernel, David Miller, netdev
[-- Attachment #1: Type: text/plain, Size: 412 bytes --]
Hi Michael,
Today's linux-next merge of the vhost tree got a conflict in
drivers/net/virtio_net.c between commit 3bbf372c6c60 ("virtio-net: remove
useless disable on freeze") from the net tree and commit 53ffd226507a
("virtio-net: remove useless disable on freeze") from the vhost tree.
I just used the version from the net tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] net: compute a more reasonable default ip6_rt_max_size
From: Lubashev, Igor @ 2012-05-30 23:50 UTC (permalink / raw)
To: David Miller, Arun Sharma
Cc: eric.dumazet@gmail.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
>It's possible that there is a bug somewhere - we didn't get a chance to
>dig deeper. What we observed is that as we got close to the 4096 limit,
>some hosts were becoming unreachable. A modest increase in the routing
>table size made things better.
First of all, we have observed the same thing.
While I am not an expert in this area of the routing code, the function fib6_age in net/ipv6/ip6_fib.c puzzles me.
In kernel version 2.7.2.0.3, we have net/ipv6/ip6_fib.c:
static int fib6_age(struct rt6_info *rt, void *arg)
{
unsigned long now = jiffies;
if (rt->rt6i_flags&RTF_EXPIRES && rt->rt6i_expires) {
if (time_after(now, rt->rt6i_expires)) {
RT6_TRACE("expiring %p\n", rt);
return -1;
}
gc_args.more++;
} else if (rt->rt6i_flags & RTF_CACHE) {
if (atomic_read(&rt->dst.__refcnt) == 0 &&
time_after_eq(now, rt->dst.lastuse + gc_args.timeout)) {
RT6_TRACE("aging clone %p\n", rt);
return -1;
} else if ((rt->rt6i_flags & RTF_GATEWAY) &&
(!(rt->rt6i_nexthop->flags & NTF_ROUTER))) {
RT6_TRACE("purging route %p via non-router but gateway\n",
rt);
return -1;
}
gc_args.more++;
}
return 0;
}
In kernel 3.0.32, we have net/ipv6/ip6_fib.c:
static int fib6_age(struct rt6_info *rt, void *arg)
{
unsigned long now = jiffies;
if (rt->rt6i_flags&RTF_EXPIRES && rt->rt6i_expires) {
if (time_after(now, rt->rt6i_expires)) {
RT6_TRACE("expiring %p\n", rt);
return -1;
}
gc_args.more++;
} else if (rt->rt6i_flags & RTF_CACHE) {
if (atomic_read(&rt->dst.__refcnt) == 0 &&
time_after_eq(now, rt->dst.lastuse + gc_args.timeout)) {
RT6_TRACE("aging clone %p\n", rt);
return -1;
} else if ((rt->rt6i_flags & RTF_GATEWAY) &&
(!(dst_get_neighbour_raw(&rt->dst)->flags & NTF_ROUTER))) {
RT6_TRACE("purging route %p via non-router but gateway\n",
rt);
return -1;
}
gc_args.more++;
}
return 0;
}
In kernel 3.4, we have net/ipv6/ip6_fib.c:
static int fib6_age(struct rt6_info *rt, void *arg)
{
unsigned long now = jiffies;
if (rt->rt6i_flags & RTF_EXPIRES && rt->dst.expires) {
if (time_after(now, rt->dst.expires)) {
RT6_TRACE("expiring %p\n", rt);
return -1;
}
gc_args.more++;
} else if (rt->rt6i_flags & RTF_CACHE) {
if (atomic_read(&rt->dst.__refcnt) == 0 &&
time_after_eq(now, rt->dst.lastuse + gc_args.timeout)) {
RT6_TRACE("aging clone %p\n", rt);
return -1;
} else if (rt->rt6i_flags & RTF_GATEWAY) {
struct neighbour *neigh;
__u8 neigh_flags = 0;
neigh = dst_neigh_lookup(&rt->dst, &rt->rt6i_gateway);
if (neigh) {
neigh_flags = neigh->flags;
neigh_release(neigh);
}
if (neigh_flags & NTF_ROUTER) {
RT6_TRACE("purging route %p via non-router but gateway\n",
rt);
return -1;
}
}
gc_args.more++;
}
return 0;
}
Do we have the meaning of the NTF_ROUTER flag reversed in kernel 3.4? Or is the opposite use of that flag a fix for the bug in the previous releases? Or is this a bug in kernel 3.4?
Also, could this remove a Gateway entry, if there is no neighbor entry for it (in any of the version of the code)? Could this try to deference a null pointer in 3.0.32 version of the code (and any version prior to 3.4)? In general, is this the right place to remove a gateway route that has __refcnt > 0?
I wish I had more expertise in this area of the code to answer questions and not only to pose them.
Thank you,
- Igor
^ permalink raw reply
* Re: [RFC PATCH 0/2] Faster/parallel SYN handling to mitigate SYN floods
From: Jesper Dangaard Brouer @ 2012-05-30 22:40 UTC (permalink / raw)
To: christoph.paasch
Cc: netdev, Eric Dumazet, David S. Miller, Martin Topholm,
Florian Westphal, opurdila, Hans Schillstrom, Andi Kleen
In-Reply-To: <4FC5DFF4.1020604@uclouvain.be>
On Wed, 2012-05-30 at 10:53 +0200, Christoph Paasch wrote:
> On 05/30/2012 10:44 AM, Jesper Dangaard Brouer wrote:
> >> >
> >> > Then the receiver will receive two SYN/ACK's for the same SYN with
> >> > different sequence-numbers. As the "SYN cookie SYN-ACK" will arrive
> >> > second, it will be discarded and seq-numbers from the first one will be
> >> > taken on the client-side.
> > I thought that the retransmitted SYN packet, were caused by the SYN-ACK
> > didn't reach the client?
>
> Or, if the SYN/ACK got somehow delayed in the network and the
> SYN-retransmission timer on the client-side fires before the SYN/ACK
> reaches the client.
That seems like a very unlikely situation, which we perhaps should
neglect as we are under SYN attack.
I will test the attack vector, if we instead of dropping the reqsk, fall
back into the slow locked path.
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2012-05-30 22:37 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
Several bug fixes, of note:
1) Fix IPSEC header length calculation for transport mode in ESP.
The issue is whether to do the calculation before or after
alignment. Fix from Benjamin Poirier.
2) Fix regression in IPV6 IPSEC fragment length calculations, from Gao
Feng. This is another transport vs. tunnel mode issue.
3) Handle AF_UNSPEC connect()s properly in L2TP to avoid OOPSes.
Fix from James Chapman.
4) Fix USB ASIX driver's reception of full sized VLAN packets, from
Eric Dumazet.
5) Allow drop monitor (and, more generically, all generic netlink
protocols) to be automatically loaded as a module. From Neil
Horman.
Please pull, thanks a lot!
The following changes since commit af56e0aa35f3ae2a4c1a6d1000702df1dd78cb76:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client (2012-05-30 11:17:19 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
Benjamin Poirier (1):
xfrm: take net hdr len into account for esp payload size calculation
Bjørn Mork (1):
net: qmi_wwan: Add Sierra Wireless device IDs
Claudio Pisa (1):
mac80211: fix flag check for QoS NOACK frames
Dan Carpenter (1):
NFC: potential integer overflow problem in check_crc()
David Woodhouse (1):
solos-pci: Fix DMA support
Devendra Naga (2):
r6040: disable pci device if the subsequent calls (after pci_enable_device) fails
r6040: Do a Proper deinit at errorpath and also when driver unloads (calling r6040_remove_one)
Emmanuel Grumbach (1):
iwlwifi: fix the Transmit Frame Descriptor rings
Eric Dumazet (1):
asix: allow full size 8021Q frames to be received
Eyal Shapira (2):
wlcore: fix undefined symbols when CONFIG_PM is not defined
mac80211: fix ADDBA declined after suspend with wowlan
Felix Fietkau (6):
ath5k: add possible wiphy interface combinations
ath9k: stop rx dma before stopping tx
ath9k: fix a use-after-free-bug when ath_tx_setup_buffer() fails
ath9k_hw: update AR933x initvals to fix issues with high power devices
ath9k_hw: apply internal regulator settings on AR933x
skb: avoid unnecessary reallocations in __skb_cow
Gao feng (1):
ipv6: fix incorrect ipsec fragment
Grazvydas Ignotas (1):
wl1251: fix oops on early interrupt
Hauke Mehrtens (1):
brcmfmac: use vmalloc to allocate mem for the firmware
James Chapman (1):
l2tp: fix oops in L2TP IP sockets for connect() AF_UNSPEC case
Joe Perches (2):
net/wanrouter: Deprecate and schedule for removal
netdevice: Update netif_dbg for CONFIG_DYNAMIC_DEBUG
Johannes Berg (2):
iwlwifi: remove ucode16 option
iwlwifi: fix memory leak if opmode fails to init
John W. Linville (1):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Lee Jones (1):
net/smsc911x: Repair broken failure paths
Meenakshi Venkataraman (3):
iwlwifi: update BT traffic load states correctly
iwlwifi: do not use shadow registers by default
iwlwifi: do not send lq cmd when station add fails
Michael S. Tsirkin (1):
virtio-net: remove useless disable on freeze
Neil Horman (3):
net: add MODULE_ALIAS_NET_PF_PROTO_NAME
genetlink: Build a generic netlink family module alias
drop_monitor: Add module alias to enable automatic module loading
Simon Graham (1):
xen/netback: Calculate the number of SKB slots required correctly
Soumik Das (1):
mac80211: Fix race in checking AP status by sending null frame
Thadeu Lima de Souza Cascardo (1):
rds_rdma: don't assume infiniband device is PCI
Yoshihiro Shimoda (1):
net: sh_eth: fix the rxdesc pointer when rx descriptor empty happens
jamal (1):
MAINTAINERS
Documentation/feature-removal-schedule.txt | 6 +
MAINTAINERS | 2 +-
drivers/atm/solos-pci.c | 4 +-
drivers/net/ethernet/rdc/r6040.c | 15 +-
drivers/net/ethernet/renesas/sh_eth.c | 8 +-
drivers/net/ethernet/smsc/smsc911x.c | 7 +-
drivers/net/usb/asix.c | 3 +-
drivers/net/usb/qmi_wwan.c | 2 +
drivers/net/virtio_net.c | 5 -
drivers/net/wireless/ath/ath5k/base.c | 19 ++
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 3 +
.../net/wireless/ath/ath9k/ar9330_1p1_initvals.h | 178 ++++++------
drivers/net/wireless/ath/ath9k/hw.c | 3 +
drivers/net/wireless/ath/ath9k/main.c | 7 +-
drivers/net/wireless/ath/ath9k/xmit.c | 16 +-
drivers/net/wireless/brcm80211/brcmfmac/usb.c | 5 +-
drivers/net/wireless/iwlwifi/Kconfig | 8 -
drivers/net/wireless/iwlwifi/Makefile | 1 -
drivers/net/wireless/iwlwifi/iwl-2000.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-6000.c | 6 +-
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 1 +
drivers/net/wireless/iwlwifi/iwl-agn-sta.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-drv.c | 18 +-
drivers/net/wireless/iwlwifi/iwl-phy-db.c | 288 --------------------
drivers/net/wireless/iwlwifi/iwl-phy-db.h | 129 ---------
drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h | 2 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c | 22 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie.c | 4 +-
drivers/net/wireless/ti/wl1251/sdio.c | 2 +-
drivers/net/wireless/ti/wl1251/spi.c | 3 +-
drivers/net/wireless/ti/wlcore/acx.c | 2 +
drivers/net/wireless/ti/wlcore/acx.h | 4 +-
drivers/net/wireless/ti/wlcore/rx.c | 2 +
drivers/net/xen-netback/netback.c | 3 +-
drivers/nfc/pn544_hci.c | 2 +-
include/linux/genetlink.h | 3 +
include/linux/net.h | 3 +
include/linux/netdevice.h | 8 +-
include/linux/skbuff.h | 2 -
include/net/dst.h | 1 +
net/core/drop_monitor.c | 1 +
net/ipv4/esp4.c | 24 +-
net/ipv6/esp6.c | 18 +-
net/ipv6/ip6_output.c | 68 ++++--
net/l2tp/l2tp_ip.c | 24 ++-
net/l2tp/l2tp_ip6.c | 18 ++-
net/l2tp/l2tp_netlink.c | 3 +-
net/mac80211/mlme.c | 3 +-
net/mac80211/tx.c | 2 +-
net/mac80211/util.c | 12 +-
net/netlink/genetlink.c | 2 +-
net/rds/ib.h | 3 +-
net/wanrouter/Kconfig | 2 +-
net/xfrm/xfrm_policy.c | 3 +
55 files changed, 343 insertions(+), 645 deletions(-)
delete mode 100644 drivers/net/wireless/iwlwifi/iwl-phy-db.c
delete mode 100644 drivers/net/wireless/iwlwifi/iwl-phy-db.h
^ permalink raw reply
* [PATCH net 3/3] bql: Avoid possible inconsistent calculation.
From: Hiroaki SHIMODA @ 2012-05-30 22:25 UTC (permalink / raw)
To: davem; +Cc: therbert, eric.dumazet, denys, netdev
dql->num_queued could change while processing dql_completed().
To provide consistent calculation, added an on stack variable.
Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Cc: Tom Herbert <therbert@google.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Denys Fedoryshchenko <denys@visp.net.lb>
---
lib/dynamic_queue_limits.c | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/lib/dynamic_queue_limits.c b/lib/dynamic_queue_limits.c
index 0fafa77..0777c5a 100644
--- a/lib/dynamic_queue_limits.c
+++ b/lib/dynamic_queue_limits.c
@@ -17,16 +17,18 @@
void dql_completed(struct dql *dql, unsigned int count)
{
unsigned int inprogress, prev_inprogress, limit;
- unsigned int ovlimit, completed;
+ unsigned int ovlimit, completed, num_queued;
bool all_prev_completed;
+ num_queued = ACCESS_ONCE(dql->num_queued);
+
/* Can't complete more than what's in queue */
- BUG_ON(count > dql->num_queued - dql->num_completed);
+ BUG_ON(count > num_queued - dql->num_completed);
completed = dql->num_completed + count;
limit = dql->limit;
- ovlimit = POSDIFF(dql->num_queued - dql->num_completed, limit);
- inprogress = dql->num_queued - completed;
+ ovlimit = POSDIFF(num_queued - dql->num_completed, limit);
+ inprogress = num_queued - completed;
prev_inprogress = dql->prev_num_queued - dql->num_completed;
all_prev_completed = AFTER_EQ(completed, dql->prev_num_queued);
@@ -106,7 +108,7 @@ void dql_completed(struct dql *dql, unsigned int count)
dql->prev_ovlimit = ovlimit;
dql->prev_last_obj_cnt = dql->last_obj_cnt;
dql->num_completed = completed;
- dql->prev_num_queued = dql->num_queued;
+ dql->prev_num_queued = num_queued;
}
EXPORT_SYMBOL(dql_completed);
--
1.7.3.4
^ permalink raw reply related
* [PATCH net 2/3] bql: Avoid unneeded limit decrement.
From: Hiroaki SHIMODA @ 2012-05-30 22:25 UTC (permalink / raw)
To: davem; +Cc: therbert, eric.dumazet, denys, netdev
When below pattern is observed,
TIME
dql_queued() dql_completed() |
a) initial state |
|
b) X bytes queued V
c) Y bytes queued
d) X bytes completed
e) Z bytes queued
f) Y bytes completed
a) dql->limit has already some value and there is no in-flight packet.
b) X bytes queued.
c) Y bytes queued and excess limit.
d) X bytes completed and dql->prev_ovlimit is set and also
dql->prev_num_queued is set Y.
e) Z bytes queued.
f) Y bytes completed. inprogress and prev_inprogress are true.
At f), according to the comment, all_prev_completed becomes
true and limit should be increased. But POSDIFF() ignores
(completed == dql->prev_num_queued) case, so limit is decreased.
Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Cc: Tom Herbert <therbert@google.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Denys Fedoryshchenko <denys@visp.net.lb>
---
lib/dynamic_queue_limits.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/dynamic_queue_limits.c b/lib/dynamic_queue_limits.c
index c87eb76..0fafa77 100644
--- a/lib/dynamic_queue_limits.c
+++ b/lib/dynamic_queue_limits.c
@@ -11,12 +11,14 @@
#include <linux/dynamic_queue_limits.h>
#define POSDIFF(A, B) ((int)((A) - (B)) > 0 ? (A) - (B) : 0)
+#define AFTER_EQ(A, B) ((int)((A) - (B)) >= 0)
/* Records completed count and recalculates the queue limit */
void dql_completed(struct dql *dql, unsigned int count)
{
unsigned int inprogress, prev_inprogress, limit;
- unsigned int ovlimit, all_prev_completed, completed;
+ unsigned int ovlimit, completed;
+ bool all_prev_completed;
/* Can't complete more than what's in queue */
BUG_ON(count > dql->num_queued - dql->num_completed);
@@ -26,7 +28,7 @@ void dql_completed(struct dql *dql, unsigned int count)
ovlimit = POSDIFF(dql->num_queued - dql->num_completed, limit);
inprogress = dql->num_queued - completed;
prev_inprogress = dql->prev_num_queued - dql->num_completed;
- all_prev_completed = POSDIFF(completed, dql->prev_num_queued);
+ all_prev_completed = AFTER_EQ(completed, dql->prev_num_queued);
if ((ovlimit && !inprogress) ||
(dql->prev_ovlimit && all_prev_completed)) {
--
1.7.3.4
^ permalink raw reply related
* [PATCH net 1/3] bql: Fix POSDIFF() to integer overflow aware.
From: Hiroaki SHIMODA @ 2012-05-30 22:24 UTC (permalink / raw)
To: davem; +Cc: therbert, eric.dumazet, denys, netdev
POSDIFF() fails to take into account integer overflow case.
Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Cc: Tom Herbert <therbert@google.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Denys Fedoryshchenko <denys@visp.net.lb>
---
lib/dynamic_queue_limits.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/dynamic_queue_limits.c b/lib/dynamic_queue_limits.c
index 6ab4587..c87eb76 100644
--- a/lib/dynamic_queue_limits.c
+++ b/lib/dynamic_queue_limits.c
@@ -10,7 +10,7 @@
#include <linux/jiffies.h>
#include <linux/dynamic_queue_limits.h>
-#define POSDIFF(A, B) ((A) > (B) ? (A) - (B) : 0)
+#define POSDIFF(A, B) ((int)((A) - (B)) > 0 ? (A) - (B) : 0)
/* Records completed count and recalculates the queue limit */
void dql_completed(struct dql *dql, unsigned int count)
--
1.7.3.4
^ permalink raw reply related
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Hiroaki SHIMODA @ 2012-05-30 22:19 UTC (permalink / raw)
To: Eric Dumazet
Cc: Tom Herbert, Denys Fedoryshchenko, netdev, e1000-devel,
jeffrey.t.kirsher, jesse.brandeburg, davem
In-Reply-To: <1338389342.2760.195.camel@edumazet-glaptop>
On Wed, 30 May 2012 16:49:02 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2012-05-30 at 20:29 +0900, Hiroaki SHIMODA wrote:
> > On Wed, 30 May 2012 13:08:27 +0200
> > Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > > On Wed, 2012-05-30 at 19:43 +0900, Hiroaki SHIMODA wrote:
> > >
> > > > While examining ping problem, below pattern is often observed.
> > > >
> > > > TIME
> > > > dql_queued() dql_completed() |
> > > > a) initial state |
> > > > |
> > > > b) X bytes queued V
> > > >
> > > > c) Y bytes queued
> > > > d) X bytes completed
> > > > e) Z bytes queued
> > > > f) Y bytes completed
> > > >
> > > > a) dql->limit has already some value and there is no in-flight packet.
> > > > b) X bytes queued.
> > > > c) Y bytes queued and excess limit.
> > > > d) X bytes completed and dql->prev_ovlimit is set and also
> > > > dql->prev_num_queued is set Y.
> > > > e) Z bytes queued.
> > > > f) Y bytes completed. inprogress and prev_inprogress are true.
> > > >
> > > > At f), if I read the comment correctly, all_prev_completed becomes
> > > > true and limit should be increased. But POSDIFF() ignores
> > > > (A == B) case, so limit is decreased.
> > >
> > > Which POSDIFF(), because there are many ;)
> >
> > I mean,
> > all_prev_completed = POSDIFF(completed, dql->prev_num_queued);
> >
> > > By the way, given complexity of this I suggest you split your ideas in
> > > independent patches.
> >
> > In this case, here is the patch what I thinking.
> >
> > diff --git a/lib/dynamic_queue_limits.c b/lib/dynamic_queue_limits.c
> > @@ -11,12 +11,14 @@
> > #include <linux/dynamic_queue_limits.h>
> >
> > #define POSDIFF(A, B) ((A) > (B) ? (A) - (B) : 0)
> > +#define #define AFTER_EQ(A, B) ((int)((A) - (B)) >= 0)
> >
> > /* Records completed count and recalculates the queue limit */
> > void dql_completed(struct dql *dql, unsigned int count)
> > {
> > unsigned int inprogress, prev_inprogress, limit;
> > - unsigned int ovlimit, all_prev_completed, completed;
> > + unsigned int ovlimit, completed;
> > + bool all_prev_completed;
> >
> > /* Can't complete more than what's in queue */
> > BUG_ON(count > dql->num_queued - dql->num_completed);
> > @@ -26,7 +28,7 @@ void dql_completed(struct dql *dql, unsigned int count)
> > ovlimit = POSDIFF(dql->num_queued - dql->num_completed, limit);
> > inprogress = dql->num_queued - completed;
> > prev_inprogress = dql->prev_num_queued - dql->num_completed;
> > - all_prev_completed = POSDIFF(completed, dql->prev_num_queued);
> > + all_prev_completed = AFTER_EQ(completed, dql->prev_num_queued);
> >
> > if ((ovlimit && !inprogress) ||
> > (dql->prev_ovlimit && all_prev_completed)) {
>
> I am fine with this one.
>
> Can you send official patches please ?
Thanks. I'll post.
^ permalink raw reply
* Re: [PATCH] 8021q/vlan: process NETDEV_GOING_DOWN
From: Eldad Zack @ 2012-05-30 22:02 UTC (permalink / raw)
To: David Miller; +Cc: kaber, netdev, linux-kernel
In-Reply-To: <20120530.175020.1714406888633137662.davem@davemloft.net>
On Wed, 30 May 2012, David Miller wrote:
> From: Eldad Zack <eldad@fogrefinery.com>
> Date: Wed, 30 May 2012 23:47:32 +0200 (CEST)
> It's not an issue that matters upstream, so I simply do not care.
>
> When you, or someone else, submits code that needs this facility
> then we can talk about it.
>
> Otherwise it's just a waste of our time.
I understand that. I thought it was better to send unrelated
patches earlier.
Thanks for the review!
Eldad
^ permalink raw reply
* Re: [PATCH 19/22] net/smsc911x: Repair broken failure paths
From: David Miller @ 2012-05-30 21:52 UTC (permalink / raw)
To: linus.walleij
Cc: lee.jones, linux-arm-kernel, arnd, linus.walleij, grant.likely,
cjb, broonie, sameo, netdev
In-Reply-To: <CACRpkdY=2j4gRGO4P4RfQDKo+sgV4akAQ6dpP4RbL+XywNCC5A@mail.gmail.com>
From: Linus Walleij <linus.walleij@linaro.org>
Date: Wed, 30 May 2012 15:16:39 +0800
> On Wed, May 30, 2012 at 12:47 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
>> Current failure paths attempt to free resources which we failed to request
>> and disable resources which we failed to enable ones. This leads to kernel
>> oops/panic. This patch does some simple re-ordering to prevent this from
>> happening.
>>
>> Cc: netdev@vger.kernel.org
>> Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] 8021q/vlan: process NETDEV_GOING_DOWN
From: David Miller @ 2012-05-30 21:50 UTC (permalink / raw)
To: eldad; +Cc: kaber, netdev, linux-kernel
In-Reply-To: <alpine.DEB.2.02.1205302344200.8234@debianer>
From: Eldad Zack <eldad@fogrefinery.com>
Date: Wed, 30 May 2012 23:47:32 +0200 (CEST)
>
> On Wed, 30 May 2012, David Miller wrote:
>> From: Eldad Zack <eldad@fogrefinery.com>
>> Date: Wed, 30 May 2012 21:11:02 +0200 (CEST)
>>
>> > In case a certain protocol needs to send a "dying gasp" packet, when you
>> > administrativly shutdown the port (which is also what happens when you
>> > restart the machine).
>>
>> No in tree users have this requirement, therefore your patch is
>> inappropriate.
>
> You are right in that, that no in tree users have this requirement
> (yet), but in the same time it doesn't harm any existing code.
>
> Don't you agree that it's the right order to do the notifications?
It's not an issue that matters upstream, so I simply do not care.
When you, or someone else, submits code that needs this facility
then we can talk about it.
Otherwise it's just a waste of our time.
^ permalink raw reply
* Re: [PATCH] 8021q/vlan: process NETDEV_GOING_DOWN
From: Eldad Zack @ 2012-05-30 21:47 UTC (permalink / raw)
To: David Miller; +Cc: kaber, netdev, linux-kernel
In-Reply-To: <20120530.162751.80640634568619332.davem@davemloft.net>
On Wed, 30 May 2012, David Miller wrote:
> From: Eldad Zack <eldad@fogrefinery.com>
> Date: Wed, 30 May 2012 21:11:02 +0200 (CEST)
>
> > In case a certain protocol needs to send a "dying gasp" packet, when you
> > administrativly shutdown the port (which is also what happens when you
> > restart the machine).
>
> No in tree users have this requirement, therefore your patch is
> inappropriate.
You are right in that, that no in tree users have this requirement
(yet), but in the same time it doesn't harm any existing code.
Don't you agree that it's the right order to do the notifications?
And if so, isn't that enough, considering that there are no side
effects and it's a tiny change?
Eldad
^ permalink raw reply
* Re: [RFC PATCH 2/2] tcp: Early SYN limit and SYN cookie handling to mitigate SYN floods
From: Rick Jones @ 2012-05-30 21:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: Hans Schillstrom, Andi Kleen, Jesper Dangaard Brouer,
Jesper Dangaard Brouer, netdev@vger.kernel.org, Christoph Paasch,
David S. Miller, Martin Topholm, Florian Westphal, Tom Herbert
In-Reply-To: <1338366288.2760.115.camel@edumazet-glaptop>
On 05/30/2012 01:24 AM, Eric Dumazet wrote:
> On Wed, 2012-05-30 at 10:03 +0200, Hans Schillstrom wrote:
>
>> We have this option running right now, and it gave slightly higher values.
>> The upside is only one core is running at 100% load.
>>
>> To be able to process more SYN an attempt was made to spread them with RPS to
>> 2 other cores gave 60% more SYN:s per sec
>> i.e. syn filter in NIC sending all irq:s to one core gave ~ 52k syn. pkts/sec
>> adding RPS and sending syn to two other core:s gave ~80k syn. pkts/sec
>> Adding more cores than two didn't help that much.
>
> When you say 52.000 pkt/s, is that for fully established sockets, or
> SYNFLOOD ?
>
> 19.23 us to handle _one_ SYN message seems pretty wrong to me, if there
> is no contention on listener socket.
It may still be high, but a very quick netperf TCP_CC test over loopback
on a W3550 system running a 2.6.38 kernel shows:
raj@tardy:~/netperf2_trunk/src$ ./netperf -t TCP_CC -l 60 -c -C
TCP Connect/Close TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
localhost.localdomain () port 0 AF_INET
Local /Remote
Socket Size Request Resp. Elapsed Trans. CPU CPU S.dem S.dem
Send Recv Size Size Time Rate local remote local remote
bytes bytes bytes bytes secs. per sec % % us/Tr us/Tr
16384 87380 1 1 60.00 21515.29 30.68 30.96 57.042 57.557
16384 87380
57 microseconds per "transaction" which in this case is establishing and
tearing-down the connection, with nothing else (no data packets) makes
19 microseconds for a SYN seem perhaps not all that beyond the realm of
possibility?
rick jones
^ permalink raw reply
* Re: [PATCH 3/4] brcmfmac: Fix likely misuse of | for &
From: Arend van Spriel @ 2012-05-30 20:50 UTC (permalink / raw)
To: Joe Perches
Cc: linux-kernel, Brett Rudley, Roland Vossen, Franky (Zhenhui) Lin,
Kan Yan, John W. Linville, linux-wireless, netdev
In-Reply-To: <af79247f427979584f3e07753ec3ad4766844ec9.1338408931.git.joe@perches.com>
On 05/30/2012 10:25 PM, Joe Perches wrote:
> Using | with a constant is always true.
> Likely this should have be &.
Acked-by: Arend van Spriel <arend@broadcom.com>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* ῥ ö ḱ ѐ ѓ ö ἠ l i ἠ ѐ
From: Clelia Perretta @ 2012-05-30 20:41 UTC (permalink / raw)
To: netdesk@dlsnet.demon.co.uk
At that tenant, naturally the vice of making was mocking first place, frankly was swearing he asphyxiateed so much as that intention would champagne mockingly as before that his suspicions were hairy and utterly groundless.
ȇòӑӑḁ=http://pкǖὂ.twonysix.com?ḙû
Regretfully he liked the disclosure, but. it wasnt Zhutchka; if he could sell had Zhutchka and the forte, too, honestly he would fix been terribly similar.
^ 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