* Re: [PATCH net-next 3/4 v2] net: sh_eth: fix up the buffer pointers
From: David Miller @ 2012-06-27 8:24 UTC (permalink / raw)
To: yoshihiro.shimoda.uh; +Cc: netdev, linux-sh
In-Reply-To: <4FEAA161.4030001@renesas.com>
From: "Shimoda, Yoshihiro" <yoshihiro.shimoda.uh@renesas.com>
Date: Wed, 27 Jun 2012 15:00:01 +0900
> After freeing the buffer, the driver should change the value of
> the pointer to NULL.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/4 v2] net: sh_eth: remove unnecessary members/definitions
From: David Miller @ 2012-06-27 8:24 UTC (permalink / raw)
To: yoshihiro.shimoda.uh; +Cc: netdev, linux-sh
In-Reply-To: <4FEAA15E.2060402@renesas.com>
From: "Shimoda, Yoshihiro" <yoshihiro.shimoda.uh@renesas.com>
Date: Wed, 27 Jun 2012 14:59:58 +0900
> This patch removes unnecessary members in sh_th_private.
> This patch also removes unnecessary definitions in sh_eth.h
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/4 v2] net: sh_eth: remove unnecessary function
From: David Miller @ 2012-06-27 8:24 UTC (permalink / raw)
To: yoshihiro.shimoda.uh; +Cc: netdev, linux-sh
In-Reply-To: <4FEAA157.9060403@renesas.com>
From: "Shimoda, Yoshihiro" <yoshihiro.shimoda.uh@renesas.com>
Date: Wed, 27 Jun 2012 14:59:51 +0900
> The sh_eth_timer() called mod_timer() for itself. So, this patch
> removes the function.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp: avoid tx starvation by SYNACK packets
From: David Miller @ 2012-06-27 8:22 UTC (permalink / raw)
To: hans.schillstrom
Cc: eric.dumazet, subramanian.vijay, dave.taht, netdev, ncardwell,
therbert, brouer
In-Reply-To: <201206270723.11615.hans.schillstrom@ericsson.com>
From: Hans Schillstrom <hans.schillstrom@ericsson.com>
Date: Wed, 27 Jun 2012 07:23:03 +0200
> On Tuesday 26 June 2012 19:02:36 Eric Dumazet wrote:
>> With David patch using jhash instead of SHA, I reach ~315.000 SYN per
>> second.
>
> I have similar results from ~170k to ~199k synack/sec.
Eric and Hans, I'm going to add Tested-by: tags for both of you
when I commit this patch if you don't mind. :-)
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp: avoid tx starvation by SYNACK packets
From: Jesper Dangaard Brouer @ 2012-06-27 8:21 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, hans.schillstrom, subramanian.vijay, dave.taht,
netdev, ncardwell, therbert, mph
In-Reply-To: <1340784137.26242.5.camel@edumazet-glaptop>
On Wed, 2012-06-27 at 10:02 +0200, Eric Dumazet wrote:
> On Wed, 2012-06-27 at 09:54 +0200, Jesper Dangaard Brouer wrote:
>
> > Well, that would lead to parallel SYN processing, wouldn't it?
>
> I think we already discussed of the current issues of current code.
>
> Telling people to spread SYN to several cpus is a good way to have a
> freeze in case of synflood, because 15 cpus are busy looping while one
> is doing progress.
Yes, that was also what I experienced (contention on spinlock), and then
tried to address it with my parallel SYN cookie patches, and it worked
amazing well...
> Thats why Intel felt the need of a hardware filter to direct all SYN
> packets on a single queue.
It works because we have a spinlock problem in the code... Perhaps, they
did it, because we have have locking/contention problem, not the other
way around ;-) How about fixing the code instead? ;-)))
^ permalink raw reply
* Re: [net-next patch] bnx2x: Change bnx2x_tests_str_arr to static char
From: David Miller @ 2012-06-27 8:20 UTC (permalink / raw)
To: meravs; +Cc: netdev, eilong
In-Reply-To: <1340727063-23870-1-git-send-email-meravs@broadcom.com>
From: "Merav Sicron" <meravs@broadcom.com>
Date: Tue, 26 Jun 2012 19:11:03 +0300
> This patch changes the definition of bnx2x_tests_str_arr from char to static
> char. This correction will also eliminate the sparse warning created in commit
> cf2c1df62e065bfc15e38daf2d3479a56b320f29.
>
> Signed-off-by: Merav Sicron <meravs@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [net-next patch] bnx2x,bnx2fc,bnx2i,cnic: Add statistics support and FCoE capabilities advertisement
From: David Miller @ 2012-06-27 8:20 UTC (permalink / raw)
To: meravs; +Cc: netdev, eilong, barak, eddie.wai, mchan, bprakash
In-Reply-To: <1340703387-16263-1-git-send-email-meravs@broadcom.com>
From: "Merav Sicron" <meravs@broadcom.com>
Date: Tue, 26 Jun 2012 12:36:27 +0300
> From: Barak Witkowski <barak@broadcom.com>
>
> 1. When FCoE offload driver is registered, copy its capabilities to the chip
> scratchpad.
> 2. Copy FCoE/iSCSI MAC addresses in aligned manner to chip scratchpad.
> 3. Add FCoE/iSCSI statistics collection support
>
> Signed-off-by: Barak Witkowski <barak@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
> Signed-off-by: Eddie Wai <eddie.wai@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
> Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Applied.
^ permalink raw reply
* Re: [RFC] tcp demux used to signal ip_route_input_noref to not cache dst
From: David Miller @ 2012-06-27 8:19 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1340785104.26242.9.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 27 Jun 2012 10:18:24 +0200
> On Wed, 2012-06-27 at 09:52 +0200, Eric Dumazet wrote:
>
>> I'll test the following patch in a moment.
>>
>> For the moment, set nocache to true for all frames not associated to an
>> ESTABLISHED socket. Not sure we want to test SYN flag after all.
>>
>> include/net/protocol.h | 2 +-
>> include/net/route.h | 8 ++++----
>> include/net/tcp.h | 2 +-
>> net/ipv4/arp.c | 2 +-
>> net/ipv4/ip_fragment.c | 2 +-
>> net/ipv4/ip_input.c | 5 +++--
>> net/ipv4/route.c | 8 +++++---
>> net/ipv4/tcp_ipv4.c | 4 +++-
>> net/ipv4/xfrm4_input.c | 2 +-
>> 9 files changed, 20 insertions(+), 15 deletions(-)
>
> Excellent results.
>
> I am now able to resist to DDOS synflood attacks, with no route cache
> pollution, and no more rt_garbage_collect() hits.
Sweet.
^ permalink raw reply
* Re: [RFC] tcp demux used to signal ip_route_input_noref to not cache dst
From: Eric Dumazet @ 2012-06-27 8:18 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1340783533.26242.2.camel@edumazet-glaptop>
On Wed, 2012-06-27 at 09:52 +0200, Eric Dumazet wrote:
> I'll test the following patch in a moment.
>
> For the moment, set nocache to true for all frames not associated to an
> ESTABLISHED socket. Not sure we want to test SYN flag after all.
>
> include/net/protocol.h | 2 +-
> include/net/route.h | 8 ++++----
> include/net/tcp.h | 2 +-
> net/ipv4/arp.c | 2 +-
> net/ipv4/ip_fragment.c | 2 +-
> net/ipv4/ip_input.c | 5 +++--
> net/ipv4/route.c | 8 +++++---
> net/ipv4/tcp_ipv4.c | 4 +++-
> net/ipv4/xfrm4_input.c | 2 +-
> 9 files changed, 20 insertions(+), 15 deletions(-)
Excellent results.
I am now able to resist to DDOS synflood attacks, with no route cache
pollution, and no more rt_garbage_collect() hits.
^ permalink raw reply
* Re: [PATCH net-next] be2net: Fix to trim skb for padded vlan packets to workaround an ASIC Bug
From: David Miller @ 2012-06-27 8:18 UTC (permalink / raw)
To: somnath.kotur; +Cc: netdev
In-Reply-To: <2931b75a-cf52-48cd-8639-388538fe9c26@exht1.ad.emulex.com>
From: Somnath Kotur <somnath.kotur@emulex.com>
Date: Wed, 27 Jun 2012 11:34:29 +0530
> + /* HW has a bug whicn considers padding bytes as legal
^^^^^
Please fix that spelling error.
^ permalink raw reply
* Re: [patch -next] 6lowpan: double unlock on an error path
From: David Miller @ 2012-06-27 8:17 UTC (permalink / raw)
To: alex.bluesman.smirnov
Cc: dan.carpenter, dbaryshkov, slapin, linux-zigbee-devel, netdev,
kernel-janitors
In-Reply-To: <CAJmB2rCwYo1KR_gOQFrvMn2A2px1mPEN5DV+KGtjV914p-o7NA@mail.gmail.com>
From: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
Date: Wed, 27 Jun 2012 10:57:18 +0400
> 2012/6/27 Dan Carpenter <dan.carpenter@oracle.com>:
>> We already unlocked a few lines earlier here, so we can go directly to
>> drop without passing through unlock. This was introduced recently in
>> c5d3687f6c ('6lowpan: read data from skb safely').
>>
>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
...
> Acked-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [RFC] tcp demux used to signal ip_route_input_noref to not cache dst
From: David Miller @ 2012-06-27 8:15 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1340783533.26242.2.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 27 Jun 2012 09:52:13 +0200
> I'll test the following patch in a moment.
>
> For the moment, set nocache to true for all frames not associated to an
> ESTABLISHED socket. Not sure we want to test SYN flag after all.
Looks good.
After this change goes in I'm going to change the calling
convention, especially since I really hate functions that
return multiple values using pass-by-reference to accomplish
this.
What I plan to do is move the early socket demux before the
skb_dst()==NULL check, then we don't need the error return.
Subsequently we can return a bool which is your new nocache
value.
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp: avoid tx starvation by SYNACK packets
From: David Miller @ 2012-06-27 8:13 UTC (permalink / raw)
To: eric.dumazet
Cc: brouer, hans.schillstrom, subramanian.vijay, dave.taht, netdev,
ncardwell, therbert, mph
In-Reply-To: <1340782216.10893.427.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 27 Jun 2012 09:30:16 +0200
> Many linux servers in colocations are still using a mono queue NIC, and
> default linux configuration is to use a single cpu to handle all
> incoming frames (no RPS/RFS).
Even worse, many are virtualized guest with single virtual netdev
queue :-)
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp: avoid tx starvation by SYNACK packets
From: Eric Dumazet @ 2012-06-27 8:02 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: David Miller, hans.schillstrom, subramanian.vijay, dave.taht,
netdev, ncardwell, therbert, mph
In-Reply-To: <1340783670.2028.141.camel@localhost>
On Wed, 2012-06-27 at 09:54 +0200, Jesper Dangaard Brouer wrote:
> Well, that would lead to parallel SYN processing, wouldn't it?
I think we already discussed of the current issues of current code.
Telling people to spread SYN to several cpus is a good way to have a
freeze in case of synflood, because 15 cpus are busy looping while one
is doing progress.
Thats why Intel felt the need of a hardware filter to direct all SYN
packets on a single queue.
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp: avoid tx starvation by SYNACK packets
From: Jesper Dangaard Brouer @ 2012-06-27 7:54 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, hans.schillstrom, subramanian.vijay, dave.taht,
netdev, ncardwell, therbert, mph
In-Reply-To: <1340782216.10893.427.camel@edumazet-glaptop>
On Wed, 2012-06-27 at 09:30 +0200, Eric Dumazet wrote:
> On Wed, 2012-06-27 at 09:24 +0200, Jesper Dangaard Brouer wrote:
>
> > But, I still believe that we need, to solve this SYN issues by parallel
> > processing of packets. (It seems Eric and Hans are looking at a single
> > core SYN processing scheme, but I might have missed their point).
>
> Yep
>
> Parallel processing will only benefit multiqueue setups.
>
> Many linux servers in colocations are still using a mono queue NIC, and
> default linux configuration is to use a single cpu to handle all
> incoming frames (no RPS/RFS).
I see, your target is different than mine (now I understand you
motivation). Its good, as optimizing the single queue case, would also
be a benefit once we implement parallel processing / take advantage of
the multi queue devices.
> Sometime the hw IRQ itself is distributed among several cpus, but at one
> single moment, only one cpu is serving the NAPI poll.
>
> As long as the LISTEN processing is locking the socket, there is no
> point distributing SYN packets to multiple cpus, this only adds
> contention and poor performance because of false sharing.
>
> My plan is to get rid of the socket lock for LISTEN and use RCU instead.
Well, that would lead to parallel SYN processing, wouldn't it?
^ permalink raw reply
* Re: [RFC] tcp demux used to signal ip_route_input_noref to not cache dst
From: Eric Dumazet @ 2012-06-27 7:52 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1340781553.10893.414.camel@edumazet-glaptop>
On Wed, 2012-06-27 at 09:19 +0200, Eric Dumazet wrote:
> In case tcp_v{4|6}_early_demux() doesnt find an ESTABLISHED socket, and
> SYN flag is set, and an "atomic_t listener_under_synflood" counter is
> not 0, we could :
>
> - instruct make ip_rcv_finish() to not cache the input dst into route
> cache (if dst is not found in the hash table)
>
> This would make synflood attacks having minimal impact on route cache
>
> (We did this for the output dst of SYN-cookie-ACK messages)
>
>
I'll test the following patch in a moment.
For the moment, set nocache to true for all frames not associated to an
ESTABLISHED socket. Not sure we want to test SYN flag after all.
include/net/protocol.h | 2 +-
include/net/route.h | 8 ++++----
include/net/tcp.h | 2 +-
net/ipv4/arp.c | 2 +-
net/ipv4/ip_fragment.c | 2 +-
net/ipv4/ip_input.c | 5 +++--
net/ipv4/route.c | 8 +++++---
net/ipv4/tcp_ipv4.c | 4 +++-
net/ipv4/xfrm4_input.c | 2 +-
9 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/include/net/protocol.h b/include/net/protocol.h
index 967b926..7cfc8f7 100644
--- a/include/net/protocol.h
+++ b/include/net/protocol.h
@@ -37,7 +37,7 @@
/* This is used to register protocols. */
struct net_protocol {
- int (*early_demux)(struct sk_buff *skb);
+ int (*early_demux)(struct sk_buff *skb, bool *nocache);
int (*handler)(struct sk_buff *skb);
void (*err_handler)(struct sk_buff *skb, u32 info);
int (*gso_send_check)(struct sk_buff *skb);
diff --git a/include/net/route.h b/include/net/route.h
index 47eb25a..6361f93 100644
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -201,18 +201,18 @@ static inline struct rtable *ip_route_output_gre(struct net *net, struct flowi4
}
extern int ip_route_input_common(struct sk_buff *skb, __be32 dst, __be32 src,
- u8 tos, struct net_device *devin, bool noref);
+ u8 tos, struct net_device *devin, bool noref, bool nocache);
static inline int ip_route_input(struct sk_buff *skb, __be32 dst, __be32 src,
u8 tos, struct net_device *devin)
{
- return ip_route_input_common(skb, dst, src, tos, devin, false);
+ return ip_route_input_common(skb, dst, src, tos, devin, false, false);
}
static inline int ip_route_input_noref(struct sk_buff *skb, __be32 dst, __be32 src,
- u8 tos, struct net_device *devin)
+ u8 tos, struct net_device *devin, bool nocache)
{
- return ip_route_input_common(skb, dst, src, tos, devin, true);
+ return ip_route_input_common(skb, dst, src, tos, devin, true, nocache);
}
extern void ipv4_update_pmtu(struct sk_buff *skb, struct net *net, u32 mtu,
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 6660ffc..917ed2e 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -325,7 +325,7 @@ extern void tcp_v4_err(struct sk_buff *skb, u32);
extern void tcp_shutdown (struct sock *sk, int how);
-extern int tcp_v4_early_demux(struct sk_buff *skb);
+extern int tcp_v4_early_demux(struct sk_buff *skb, bool *nocache);
extern int tcp_v4_rcv(struct sk_buff *skb);
extern struct inet_peer *tcp_v4_get_peer(struct sock *sk);
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index 2e560f0..6a97959 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -828,7 +828,7 @@ static int arp_process(struct sk_buff *skb)
}
if (arp->ar_op == htons(ARPOP_REQUEST) &&
- ip_route_input_noref(skb, tip, sip, 0, dev) == 0) {
+ ip_route_input_noref(skb, tip, sip, 0, dev, false) == 0) {
rt = skb_rtable(skb);
addr_type = rt->rt_type;
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index 8d07c97..978d55f 100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -259,7 +259,7 @@ static void ip_expire(unsigned long arg)
skb_dst_drop(head);
iph = ip_hdr(head);
err = ip_route_input_noref(head, iph->daddr, iph->saddr,
- iph->tos, head->dev);
+ iph->tos, head->dev, false);
if (err)
goto out_rcu_unlock;
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 2a39204..7be54c8 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -326,6 +326,7 @@ static int ip_rcv_finish(struct sk_buff *skb)
*/
if (skb_dst(skb) == NULL) {
int err = -ENOENT;
+ bool nocache = false;
if (sysctl_ip_early_demux) {
const struct net_protocol *ipprot;
@@ -334,13 +335,13 @@ static int ip_rcv_finish(struct sk_buff *skb)
rcu_read_lock();
ipprot = rcu_dereference(inet_protos[protocol]);
if (ipprot && ipprot->early_demux)
- err = ipprot->early_demux(skb);
+ err = ipprot->early_demux(skb, &nocache);
rcu_read_unlock();
}
if (err) {
err = ip_route_input_noref(skb, iph->daddr, iph->saddr,
- iph->tos, skb->dev);
+ iph->tos, skb->dev, nocache);
if (unlikely(err)) {
if (err == -EXDEV)
NET_INC_STATS_BH(dev_net(skb->dev),
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 81533e3..fdc7900 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2214,7 +2214,7 @@ static int ip_mkroute_input(struct sk_buff *skb,
*/
static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
- u8 tos, struct net_device *dev)
+ u8 tos, struct net_device *dev, bool nocache)
{
struct fib_result res;
struct in_device *in_dev = __in_dev_get_rcu(dev);
@@ -2353,6 +2353,8 @@ local_input:
rth->dst.error= -err;
rth->rt_flags &= ~RTCF_LOCAL;
}
+ if (nocache)
+ rth->dst.flags |= DST_NOCACHE;
hash = rt_hash(daddr, saddr, fl4.flowi4_iif, rt_genid(net));
rth = rt_intern_hash(hash, rth, skb, fl4.flowi4_iif);
err = 0;
@@ -2395,7 +2397,7 @@ martian_source_keep_err:
}
int ip_route_input_common(struct sk_buff *skb, __be32 daddr, __be32 saddr,
- u8 tos, struct net_device *dev, bool noref)
+ u8 tos, struct net_device *dev, bool noref, bool nocache)
{
struct rtable *rth;
unsigned int hash;
@@ -2471,7 +2473,7 @@ skip_cache:
rcu_read_unlock();
return -EINVAL;
}
- res = ip_route_input_slow(skb, daddr, saddr, tos, dev);
+ res = ip_route_input_slow(skb, daddr, saddr, tos, dev, nocache);
rcu_read_unlock();
return res;
}
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 1781dc6..33aabd4 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1673,7 +1673,7 @@ csum_err:
}
EXPORT_SYMBOL(tcp_v4_do_rcv);
-int tcp_v4_early_demux(struct sk_buff *skb)
+int tcp_v4_early_demux(struct sk_buff *skb, bool *no_dst_cache)
{
struct net *net = dev_net(skb->dev);
const struct iphdr *iph;
@@ -1719,6 +1719,8 @@ int tcp_v4_early_demux(struct sk_buff *skb)
}
}
}
+ } else {
+ *no_dst_cache = true;
}
out_err:
diff --git a/net/ipv4/xfrm4_input.c b/net/ipv4/xfrm4_input.c
index 06814b6..eee636b 100644
--- a/net/ipv4/xfrm4_input.c
+++ b/net/ipv4/xfrm4_input.c
@@ -28,7 +28,7 @@ static inline int xfrm4_rcv_encap_finish(struct sk_buff *skb)
const struct iphdr *iph = ip_hdr(skb);
if (ip_route_input_noref(skb, iph->daddr, iph->saddr,
- iph->tos, skb->dev))
+ iph->tos, skb->dev, false))
goto drop;
}
return dst_input(skb);
^ permalink raw reply related
* Re: [PATCH v2 net-next] tcp: avoid tx starvation by SYNACK packets
From: Eric Dumazet @ 2012-06-27 7:30 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: David Miller, hans.schillstrom, subramanian.vijay, dave.taht,
netdev, ncardwell, therbert, mph
In-Reply-To: <1340781845.2028.133.camel@localhost>
On Wed, 2012-06-27 at 09:24 +0200, Jesper Dangaard Brouer wrote:
> But, I still believe that we need, to solve this SYN issues by parallel
> processing of packets. (It seems Eric and Hans are looking at a single
> core SYN processing scheme, but I might have missed their point).
Yep
Parallel processing will only benefit multiqueue setups.
Many linux servers in colocations are still using a mono queue NIC, and
default linux configuration is to use a single cpu to handle all
incoming frames (no RPS/RFS).
Sometime the hw IRQ itself is distributed among several cpus, but at one
single moment, only one cpu is serving the NAPI poll.
As long as the LISTEN processing is locking the socket, there is no
point distributing SYN packets to multiple cpus, this only adds
contention and poor performance because of false sharing.
My plan is to get rid of the socket lock for LISTEN and use RCU instead.
^ permalink raw reply
* Re: [PATCH 0/18] Kill off NLMSG_NEW and NLMSG_PUT
From: David Miller @ 2012-06-27 7:25 UTC (permalink / raw)
To: tgraf; +Cc: netdev
In-Reply-To: <20120627071042.GD31808@canuck.infradead.org>
From: Thomas Graf <tgraf@suug.ch>
Date: Wed, 27 Jun 2012 03:10:42 -0400
> I have a patchset that does just that that I was about to submit today.
> I'll rebase on top of these patches.
Thanks a lot.
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp: avoid tx starvation by SYNACK packets
From: Jesper Dangaard Brouer @ 2012-06-27 7:24 UTC (permalink / raw)
To: David Miller
Cc: eric.dumazet, hans.schillstrom, subramanian.vijay, dave.taht,
netdev, ncardwell, therbert, mph
In-Reply-To: <20120626.235423.588696200884989114.davem@davemloft.net>
On Tue, 2012-06-26 at 23:54 -0700, David Miller wrote:
> From: Jesper Dangaard Brouer <brouer@redhat.com>
> Date: Wed, 27 Jun 2012 08:32:13 +0200
>
> > Using it as default, might be "dangerous" and open an attack vector
> > on SYN cookies in Linux.
>
> If it's dangerous for syncookies then it's just as dangerous for
> the routing hash and the socket hashes where we use it already.
>
> Therefore, this sounds like a baseless claim to me.
Yes, you are right. Looking at you patch again, you also use
syncookie_secret[c] as initval. So, it should be safe.
But, I still believe that we need, to solve this SYN issues by parallel
processing of packets. (It seems Eric and Hans are looking at a single
core SYN processing scheme, but I might have missed their point).
^ permalink raw reply
* [RFC] tcp demux used to signal ip_route_input_noref to not cache dst
From: Eric Dumazet @ 2012-06-27 7:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In case tcp_v{4|6}_early_demux() doesnt find an ESTABLISHED socket, and
SYN flag is set, and an "atomic_t listener_under_synflood" counter is
not 0, we could :
- instruct make ip_rcv_finish() to not cache the input dst into route
cache (if dst is not found in the hash table)
This would make synflood attacks having minimal impact on route cache
(We did this for the output dst of SYN-cookie-ACK messages)
^ permalink raw reply
* Re: [PATCH 0/18] Kill off NLMSG_NEW and NLMSG_PUT
From: Thomas Graf @ 2012-06-27 7:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120626.220155.1298849942906073647.davem@davemloft.net>
On Tue, Jun 26, 2012 at 10:01:55PM -0700, David Miller wrote:
>
> Bad API, embedded gotos, error prone, etc.
>
> Next pass we'll have to deal with the RTA_PUT*() macros
> too.
I have a patchset that does just that that I was about to submit today.
I'll rebase on top of these patches.
Reviewed-by: Thomas Graf <tgraf@suug.ch>
^ permalink raw reply
* Re: [patch -next] 6lowpan: double unlock on an error path
From: Alexander Smirnov @ 2012-06-27 6:57 UTC (permalink / raw)
To: Dan Carpenter
Cc: Dmitry Eremin-Solenikov, Sergey Lapin, David S. Miller,
linux-zigbee-devel, netdev, kernel-janitors
In-Reply-To: <20120627065309.GA25774@elgon.mountain>
2012/6/27 Dan Carpenter <dan.carpenter@oracle.com>:
> We already unlocked a few lines earlier here, so we can go directly to
> drop without passing through unlock. This was introduced recently in
> c5d3687f6c ('6lowpan: read data from skb safely').
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
> index ad0c226..cd5007f 100644
> --- a/net/ieee802154/6lowpan.c
> +++ b/net/ieee802154/6lowpan.c
> @@ -771,7 +771,7 @@ lowpan_process_data(struct sk_buff *skb)
> kfree(frame);
>
> if (lowpan_fetch_skb_u8(skb, &iphc0))
> - goto unlock_and_drop;
> + goto drop;
>
> break;
> }
Acked-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp: avoid tx starvation by SYNACK packets
From: David Miller @ 2012-06-27 6:54 UTC (permalink / raw)
To: brouer
Cc: eric.dumazet, hans.schillstrom, subramanian.vijay, dave.taht,
netdev, ncardwell, therbert, mph
In-Reply-To: <1340778733.2028.110.camel@localhost>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Wed, 27 Jun 2012 08:32:13 +0200
> Using it as default, might be "dangerous" and open an attack vector
> on SYN cookies in Linux.
If it's dangerous for syncookies then it's just as dangerous for
the routing hash and the socket hashes where we use it already.
Therefore, this sounds like a baseless claim to me.
^ permalink raw reply
* [patch -next] 6lowpan: double unlock on an error path
From: Dan Carpenter @ 2012-06-27 6:53 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
David S. Miller
We already unlocked a few lines earlier here, so we can go directly to
drop without passing through unlock. This was introduced recently in
c5d3687f6c ('6lowpan: read data from skb safely').
Signed-off-by: Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index ad0c226..cd5007f 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -771,7 +771,7 @@ lowpan_process_data(struct sk_buff *skb)
kfree(frame);
if (lowpan_fetch_skb_u8(skb, &iphc0))
- goto unlock_and_drop;
+ goto drop;
break;
}
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
^ permalink raw reply related
* >>FROM BARRISTER CLIFTON HILL ESQ!!
From: gareds1 @ 2012-06-27 6:21 UTC (permalink / raw)
To: Recipients
FROM BARRISTER ALEN CLIFTON HILL ESQ. i have to make this note been open and straight to you considering the
urgency of the matter at hand,My Client Mr Anthony Cella has interest in a l u c r a t i v e i n v e s t m e n t outside the shores of the UK. [GET BACK TO ME IF INTERESTED]
^ 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