* Re: [PATCH] tcp: reflect SYN queue_mapping into SYNACK packets
From: Hans Schillstrom @ 2012-06-01 10:45 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Neal Cardwell, Jesper Dangaard Brouer, Tom Herbert
In-Reply-To: <1338544881.2760.1502.camel@edumazet-glaptop>
On Friday 01 June 2012 12:01:21 Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> While testing how linux behaves on SYNFLOOD attack on multiqueue device
> (ixgbe), I found that SYNACK messages were dropped at Qdisc level
> because we send them all on a single queue.
>
> Obvious choice is to reflect incoming SYN packet @queue_mapping to
> SYNACK packet.
>
> Under stress, my machine could only send 25.000 SYNACK per second (for
> 200.000 incoming SYN per second). NIC : ixgbe with 16 rx/tx queues.
>
> After patch, not a single SYNACK is dropped.
>
Great, that was just what I was looking for
Will try to get this on into test to day.
IPv6, do you add that as well ?
--
Regards
Hans Schillstrom
^ permalink raw reply
* Re: [PATCH] tcp: reflect SYN queue_mapping into SYNACK packets
From: Eric Dumazet @ 2012-06-01 10:19 UTC (permalink / raw)
To: Hans Schillstrom
Cc: netdev, Neal Cardwell, Jesper Dangaard Brouer, Tom Herbert
In-Reply-To: <1338544881.2760.1502.camel@edumazet-glaptop>
On Fri, 2012-06-01 at 12:01 +0200, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> ---
> net/ipv4/tcp_ipv4.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
I'll send a v2 with the missing IPv6 part ;)
^ permalink raw reply
* [PATCH] tcp: reflect SYN queue_mapping into SYNACK packets
From: Eric Dumazet @ 2012-06-01 10:01 UTC (permalink / raw)
To: Hans Schillstrom
Cc: netdev, Neal Cardwell, Jesper Dangaard Brouer, Tom Herbert
From: Eric Dumazet <edumazet@google.com>
While testing how linux behaves on SYNFLOOD attack on multiqueue device
(ixgbe), I found that SYNACK messages were dropped at Qdisc level
because we send them all on a single queue.
Obvious choice is to reflect incoming SYN packet @queue_mapping to
SYNACK packet.
Under stress, my machine could only send 25.000 SYNACK per second (for
200.000 incoming SYN per second). NIC : ixgbe with 16 rx/tx queues.
After patch, not a single SYNACK is dropped.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Hans Schillstrom <hans.schillstrom@ericsson.com>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Tom Herbert <therbert@google.com>
---
net/ipv4/tcp_ipv4.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index a43b87d..c8d28c4 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -824,7 +824,8 @@ static void tcp_v4_reqsk_send_ack(struct sock *sk, struct sk_buff *skb,
*/
static int tcp_v4_send_synack(struct sock *sk, struct dst_entry *dst,
struct request_sock *req,
- struct request_values *rvp)
+ struct request_values *rvp,
+ u16 queue_mapping)
{
const struct inet_request_sock *ireq = inet_rsk(req);
struct flowi4 fl4;
@@ -840,6 +841,7 @@ static int tcp_v4_send_synack(struct sock *sk, struct dst_entry *dst,
if (skb) {
__tcp_v4_send_check(skb, ireq->loc_addr, ireq->rmt_addr);
+ skb_set_queue_mapping(skb, queue_mapping);
err = ip_build_and_send_pkt(skb, sk, ireq->loc_addr,
ireq->rmt_addr,
ireq->opt);
@@ -854,7 +856,7 @@ static int tcp_v4_rtx_synack(struct sock *sk, struct request_sock *req,
struct request_values *rvp)
{
TCP_INC_STATS_BH(sock_net(sk), TCP_MIB_RETRANSSEGS);
- return tcp_v4_send_synack(sk, NULL, req, rvp);
+ return tcp_v4_send_synack(sk, NULL, req, rvp, 0);
}
/*
@@ -1422,7 +1424,8 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
tcp_rsk(req)->snt_synack = tcp_time_stamp;
if (tcp_v4_send_synack(sk, dst, req,
- (struct request_values *)&tmp_ext) ||
+ (struct request_values *)&tmp_ext,
+ skb_get_queue_mapping(skb)) ||
want_cookie)
goto drop_and_free;
^ permalink raw reply related
* Re: [PATCH net-next] tcp: avoid tx starvation by SYNACK packets
From: Eric Dumazet @ 2012-06-01 9:34 UTC (permalink / raw)
To: Hans Schillstrom
Cc: netdev, Neal Cardwell, Tom Herbert, Jesper Dangaard Brouer
In-Reply-To: <201206010939.22620.hans.schillstrom@ericsson.com>
On Fri, 2012-06-01 at 09:36 +0200, Hans Schillstrom wrote:
> On Thursday 31 May 2012 23:56:37 Eric Dumazet wrote:
> > From: Eric Dumazet <edumazet@google.com>
> >
> > pfifo_fast being the default Qdisc, its pretty easy to fill it with
> > SYNACK (small) packets while host is under SYNFLOOD attack.
> >
> > Packets of established TCP sessions are dropped and host appears almost
> > dead.
> >
> > Avoid this problem assigning TC_PRIO_FILLER priority to SYNACK
> > generated in SYNCOOKIE mode, so that these packets are enqueued into
> > pfifo_fast band 2.
> >
> > Other packets, queued to band 0 or 1 are dequeued before any SYNACK
> > packets waiting in band 2.
> >
> Thanks Eric,
> the patch is in under test now.
>
Thanks Hans
By the way, I found that we have another problem because __qdisc_run()
( called from net_tx_action()) only pushes 64 frames per invocation, and
in fact less if need_resched() breaks the loop.
Its not fair with the net_rx_action, allowed to receive 64 frames per
NAPI device regardless of need_resched().
So if our cpu is flooded by incoming frames, our output is muted.
Basically we need to make SYNACK frames aware of multiqueue devices,
since they currently all end on one single queue.
Obvious choice is to reflect incoming SYN packet @queue_mapping to
SYNACK packet.
I am testing a patch right now.
^ permalink raw reply
* Re: [PATCH net-next] tcp: avoid tx starvation by SYNACK packets
From: Hans Schillstrom @ 2012-06-01 7:36 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Neal Cardwell, Tom Herbert, Jesper Dangaard Brouer
In-Reply-To: <1338501397.2760.1395.camel@edumazet-glaptop>
On Thursday 31 May 2012 23:56:37 Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> pfifo_fast being the default Qdisc, its pretty easy to fill it with
> SYNACK (small) packets while host is under SYNFLOOD attack.
>
> Packets of established TCP sessions are dropped and host appears almost
> dead.
>
> Avoid this problem assigning TC_PRIO_FILLER priority to SYNACK
> generated in SYNCOOKIE mode, so that these packets are enqueued into
> pfifo_fast band 2.
>
> Other packets, queued to band 0 or 1 are dequeued before any SYNACK
> packets waiting in band 2.
>
Thanks Eric,
the patch is in under test now.
--
Regards
Hans Schillstrom
^ permalink raw reply
* [PATCH] tcp: do not create inetpeer on SYNACK message
From: Eric Dumazet @ 2012-06-01 7:00 UTC (permalink / raw)
To: Hans Schillstrom
Cc: netdev, Jesper Dangaard Brouer, David Miller, Neal Cardwell,
Tom Herbert
In-Reply-To: <1338501397.2760.1395.camel@edumazet-glaptop>
From: Eric Dumazet <edumazet@google.com>
Another problem on SYNFLOOD/DDOS attack is the inetpeer cache getting
larger and larger, using lots of memory and cpu time.
tcp_v4_send_synack()
->inet_csk_route_req()
->ip_route_output_flow()
->rt_set_nexthop()
->rt_init_metrics()
->inet_getpeer( create = true)
This is a side effect of commit a4daad6b09230 (net: Pre-COW metrics for
TCP) added in 2.6.39
Possible solution :
Instruct inet_csk_route_req() to remove FLOWI_FLAG_PRECOW_METRICS
Before patch :
# grep peer /proc/slabinfo
inet_peer_cache 4175430 4175430 192 42 2 : tunables 0 0 0 : slabdata 99415 99415 0
Samples: 41K of event 'cycles', Event count (approx.): 30716565122
+ 20,24% ksoftirqd/0 [kernel.kallsyms] [k] inet_getpeer
+ 8,19% ksoftirqd/0 [kernel.kallsyms] [k] peer_avl_rebalance.isra.1
+ 4,81% ksoftirqd/0 [kernel.kallsyms] [k] sha_transform
+ 3,64% ksoftirqd/0 [kernel.kallsyms] [k] fib_table_lookup
+ 2,36% ksoftirqd/0 [ixgbe] [k] ixgbe_poll
+ 2,16% ksoftirqd/0 [kernel.kallsyms] [k] __ip_route_output_key
+ 2,11% ksoftirqd/0 [kernel.kallsyms] [k] kernel_map_pages
+ 2,11% ksoftirqd/0 [kernel.kallsyms] [k] ip_route_input_common
+ 2,01% ksoftirqd/0 [kernel.kallsyms] [k] __inet_lookup_established
+ 1,83% ksoftirqd/0 [kernel.kallsyms] [k] md5_transform
+ 1,75% ksoftirqd/0 [kernel.kallsyms] [k] check_leaf.isra.9
+ 1,49% ksoftirqd/0 [kernel.kallsyms] [k] ipt_do_table
+ 1,46% ksoftirqd/0 [kernel.kallsyms] [k] hrtimer_interrupt
+ 1,45% ksoftirqd/0 [kernel.kallsyms] [k] kmem_cache_alloc
+ 1,29% ksoftirqd/0 [kernel.kallsyms] [k] inet_csk_search_req
+ 1,29% ksoftirqd/0 [kernel.kallsyms] [k] __netif_receive_skb
+ 1,16% ksoftirqd/0 [kernel.kallsyms] [k] copy_user_generic_string
+ 1,15% ksoftirqd/0 [kernel.kallsyms] [k] kmem_cache_free
+ 1,02% ksoftirqd/0 [kernel.kallsyms] [k] tcp_make_synack
+ 0,93% ksoftirqd/0 [kernel.kallsyms] [k] _raw_spin_lock_bh
+ 0,87% ksoftirqd/0 [kernel.kallsyms] [k] __call_rcu
+ 0,84% ksoftirqd/0 [kernel.kallsyms] [k] rt_garbage_collect
+ 0,84% ksoftirqd/0 [kernel.kallsyms] [k] fib_rules_lookup
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Hans Schillstrom <hans.schillstrom@ericsson.com>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Tom Herbert <therbert@google.com>
---
net/ipv4/inet_connection_sock.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 95e61596..f9ee741 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -377,7 +377,8 @@ struct dst_entry *inet_csk_route_req(struct sock *sk,
flowi4_init_output(fl4, sk->sk_bound_dev_if, sk->sk_mark,
RT_CONN_FLAGS(sk), RT_SCOPE_UNIVERSE,
- sk->sk_protocol, inet_sk_flowi_flags(sk),
+ sk->sk_protocol,
+ inet_sk_flowi_flags(sk) & ~FLOWI_FLAG_PRECOW_METRICS,
(opt && opt->opt.srr) ? opt->opt.faddr : ireq->rmt_addr,
ireq->loc_addr, ireq->rmt_port, inet_sk(sk)->inet_sport);
security_req_classify_flow(req, flowi4_to_flowi(fl4));
^ permalink raw reply related
* Re: [PATCH net-next] tcp: avoid tx starvation by SYNACK packets
From: Eric Dumazet @ 2012-06-01 4:48 UTC (permalink / raw)
To: David Miller; +Cc: hans.schillstrom, netdev, ncardwell, therbert, brouer
In-Reply-To: <20120531.190345.1754322784813248328.davem@davemloft.net>
On Thu, 2012-05-31 at 19:03 -0400, David Miller wrote:
> Is the net-next tree open yet?
David
Hans asked me to send a patch for testing, I sent it, and made clear it
was not a fix for current net tree.
RFC is like 'I throw a patch, I am not even 50% confident of it, please
comment and fix my bugs'. Most busy people just ignore it.
In this case, I know it really fixes a problem, but since its a day-0
one, its not meant for net tree (linux-3.5)
I don't know what's wrong with ignoring patches and consider them later
when net-next is open and various Acked-by or Tested-by signatures were
added, as done by other maintainers.
Just make clear that if a patch is not anymore listed on
http://patchwork.ozlabs.org/project/netdev/list/ , the author is
responsible for resending it with all added signatures ?
We need to exchange ideas (aka patches), even in the merge window, or if
the subtree maintainer is busy doing its own job.
Thanks
^ permalink raw reply
* [PATCH 2/2] 8139cp/8139too: terminate the eeprom access with the right opmode
From: Jason Wang @ 2012-06-01 4:19 UTC (permalink / raw)
To: netdev, davem, linux-kernel; +Cc: mst
In-Reply-To: <20120601041939.4311.55827.stgit@dhcp-8-146.nay.redhat.com>
Currently, we terminate the eeprom access through clearing the CS by:
RTL_W8 (Cfg9346, ~EE_CS); or writeb (~EE_CS, ee_addr);
This would left the eeprom into "Config. Register Write Enable:"
state which is not expcted as the highest two bits were set to
0x11 ( expected is the "Normal" mode (0x00)). Solving this by write
0x0 instead of ~EE_CS when terminating the eeprom access.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/ethernet/realtek/8139cp.c | 2 +-
drivers/net/ethernet/realtek/8139too.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c
index 7f08779..995d0cf 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -1636,7 +1636,7 @@ static void eeprom_cmd(void __iomem *ee_addr, int cmd, int cmd_len)
static void eeprom_cmd_end(void __iomem *ee_addr)
{
- writeb (~EE_CS, ee_addr);
+ writeb(0, ee_addr);
eeprom_delay ();
}
diff --git a/drivers/net/ethernet/realtek/8139too.c b/drivers/net/ethernet/realtek/8139too.c
index 03df076..1d83565 100644
--- a/drivers/net/ethernet/realtek/8139too.c
+++ b/drivers/net/ethernet/realtek/8139too.c
@@ -1173,7 +1173,7 @@ static int __devinit read_eeprom (void __iomem *ioaddr, int location, int addr_l
}
/* Terminate the EEPROM access. */
- RTL_W8 (Cfg9346, ~EE_CS);
+ RTL_W8(Cfg9346, 0);
eeprom_delay ();
return retval;
^ permalink raw reply related
* [PATCH 1/2] 8139cp: set ring address before enabling receiver
From: Jason Wang @ 2012-06-01 4:19 UTC (permalink / raw)
To: netdev, davem, linux-kernel; +Cc: mst
Currently, we enable the receiver before setting the ring address which could
lead the card DMA into unexpected areas. Solving this by set the ring address
before enabling the receiver.
btw. I find and test this in qemu as I didn't have a 8139cp card in hand. please
review it carefully.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/ethernet/realtek/8139cp.c | 22 +++++++++++-----------
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c
index 5eef290..7f08779 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -979,6 +979,17 @@ static void cp_init_hw (struct cp_private *cp)
cpw32_f (MAC0 + 0, le32_to_cpu (*(__le32 *) (dev->dev_addr + 0)));
cpw32_f (MAC0 + 4, le32_to_cpu (*(__le32 *) (dev->dev_addr + 4)));
+ cpw32_f(HiTxRingAddr, 0);
+ cpw32_f(HiTxRingAddr + 4, 0);
+
+ ring_dma = cp->ring_dma;
+ cpw32_f(RxRingAddr, ring_dma & 0xffffffff);
+ cpw32_f(RxRingAddr + 4, (ring_dma >> 16) >> 16);
+
+ ring_dma += sizeof(struct cp_desc) * CP_RX_RING_SIZE;
+ cpw32_f(TxRingAddr, ring_dma & 0xffffffff);
+ cpw32_f(TxRingAddr + 4, (ring_dma >> 16) >> 16);
+
cp_start_hw(cp);
cpw8(TxThresh, 0x06); /* XXX convert magic num to a constant */
@@ -992,17 +1003,6 @@ static void cp_init_hw (struct cp_private *cp)
cpw8(Config5, cpr8(Config5) & PMEStatus);
- cpw32_f(HiTxRingAddr, 0);
- cpw32_f(HiTxRingAddr + 4, 0);
-
- ring_dma = cp->ring_dma;
- cpw32_f(RxRingAddr, ring_dma & 0xffffffff);
- cpw32_f(RxRingAddr + 4, (ring_dma >> 16) >> 16);
-
- ring_dma += sizeof(struct cp_desc) * CP_RX_RING_SIZE;
- cpw32_f(TxRingAddr, ring_dma & 0xffffffff);
- cpw32_f(TxRingAddr + 4, (ring_dma >> 16) >> 16);
-
cpw16(MultiIntr, 0);
cpw8_f(Cfg9346, Cfg9346_Lock);
^ permalink raw reply related
* Re: [V2 PATCH] net: sock: validate data_len before allocating skb in sock_alloc_send_pskb()
From: Jason Wang @ 2012-06-01 3:09 UTC (permalink / raw)
To: David Miller; +Cc: netdev, edumazet, mst, linux-kernel, stable
In-Reply-To: <20120531.182145.119572313886189417.davem@davemloft.net>
On 06/01/2012 06:21 AM, David Miller wrote:
> From: Jason Wang<jasowang@redhat.com>
> Date: Thu, 31 May 2012 15:18:10 +0800
>
>> 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.
>>
>> Signed-off-by: Jason Wang<jasowang@redhat.com>
> Applied and queued up for -stable.
>
> Please do not add explicit stable CC:'s to networking patches, I queue
> appropriate changes up myself, and submit them only when I feel that
> the change has had sufficient exposure and testing in Linus's tree.
Sure, would pay attention next time.
> --
> 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
* Fw: [Bug 43327] New: IP routing: cached route is applied to wrong network interface
From: Stephen Hemminger @ 2012-06-01 0:46 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Fri, 1 Jun 2012 00:18:37 +0000 (UTC)
From: bugzilla-daemon@bugzilla.kernel.org
To: shemminger@linux-foundation.org
Subject: [Bug 43327] New: IP routing: cached route is applied to wrong network interface
https://bugzilla.kernel.org/show_bug.cgi?id=43327
Summary: IP routing: cached route is applied to wrong network
interface
Product: Networking
Version: 2.5
Kernel Version: 3.1.10
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
AssignedTo: shemminger@linux-foundation.org
ReportedBy: dschnabel@appneta.com
Regression: No
IP routing: cached route is applied to wrong network interface
Dynamic route changes like ICMP redirects are cached in the cache routing table
of the kernel. This cache table can be displayed using the command "route -nC"
or "ip route show cache".
Routes in this table are used before checking the Routing Policy Database
(RPDB). In a certain use case a wrong route entry is created in the cache
table.
This is my network setup:
* the Linux machine has 2 network interfaces (eth0 and eth1) with IP adresses
of different subnets
** eth0: 172.16.124.217/24 (Subnet A)
** eth1: 172.16.128.219/24 (Subnet B)
* IP rules to accomplish two default gateways
** root@myBox:~# ip rule show
0: from all lookup local
32764: from 172.16.128.219 lookup E1
32765: from 172.16.124.217 lookup E0
32766: from all lookup main
32767: from all lookup default
** root@myBox:~# ip route show table E0
default via 172.16.124.254 dev eth0
** root@myBox:~# ip route show table E1
default via 172.16.128.254 dev eth1
* Both gateways are connected to Subnet C
This is how it looks like:
************
# ************
* Subnet A *
# * Subnet C *
************ +-------------------+ +-------------------+
# ************
| | | |
#
+-------------------+ GW 172.16.124.254 +------+ GW 172.16.124.18
+------#---------------+
| 172.16.124.217 | | | |
# |
+------+--------+ +-------------------+ +---------+---------+
# |
| eth0 | |
# +--------+----------+
| | |
# | Target |
| Linux Machine | ##################
# | IP 10.20.2.252 |
| | |
# +--------+----------+
| eth1 | |
#
+------+--------+ +-------------------+ |
#
| 172.16.128.219 | | |
#
+-------------------+ GW 172.16.128.254 +----------------+
#
| |
#
************ +-------------------+
#
* Subnet B *
#
************
#
I can ping the target from both interfaces:
ping 10.20.2.252 -I 172.16.124.217
ping 10.20.2.252 -I 172.16.128.219
When pining from eth0 (172.16.124.217) the Gateway 172.16.124.254 will return a
redirect to Gateway 172.16.124.18 since it's in the same network:
root@myBox:~# ping 10.20.2.252 -I 172.16.124.217
PING 10.20.2.252 (10.20.2.252) from 172.16.124.217 : 56(84) bytes of data.
64 bytes from 10.20.2.252: icmp_seq=1 ttl=63 time=81.4 ms
>From 172.16.124.254: icmp_seq=1 Redirect Host(New nexthop: 172.16.124.18)
64 bytes from 10.20.2.252: icmp_seq=2 ttl=63 time=0.277 ms
64 bytes from 10.20.2.252: icmp_seq=3 ttl=63 time=0.238 ms
64 bytes from 10.20.2.252: icmp_seq=4 ttl=63 time=0.236 ms
And this redirect will create a new entry in the cache table:
root@myBox:~# route -nC | grep 172.16.124.18
172.16.124.217 10.20.2.252 172.16.124.18 0 0 2 eth0
So far so good. Here comes the problem.
When I ping the same target now from eth1 (172.16.128.219) then it won't work
anymore:
root@myBox:~# ping 10.20.2.252 -I 172.16.128.219
PING 10.20.2.252 (10.20.2.252) from 172.16.128.219 : 56(84) bytes of data.
>From 172.16.128.219 icmp_seq=2 Destination Host Unreachable
>From 172.16.128.219 icmp_seq=3 Destination Host Unreachable
>From 172.16.128.219 icmp_seq=4 Destination Host Unreachable
^C
--- 10.20.2.252 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2999ms
I check the cache table and notice another entry:
root@portwell19:~# route -nC | grep 172.16.124.18
172.16.124.217 10.20.2.252 172.16.124.18 0 0 2 eth0
172.16.128.219 10.20.2.252 172.16.124.18 0 0 7 eth1
That means eth1 is now trying to reach 10.20.2.252 using the gateway
172.16.124.18. It's obvious that this won't work since eth1 is in a different
subnet.
So the entry in the cache table is wrong. After clearing the cache with "ip
route flush table cache" the ping from eth1 works again.
I did some research:
The cache routing table works on an AVL tree of Internet Peers. Those peers are
stored in a structure called inet_peer (include/net/inetpeer.h). A lookup is
done by the call to inet_getpeer_v4() in net/ipv4/route.c which takes the
destination address (10.20.2.252 in my case) as the first argument. So if the
destination address matches then the peer is returned and saved to the cache
table regardless of the source address.
Two possible fixes I can think of:
* A peer lookup should be done not only by the destination address but also by
the source address (or netmask)
* The inet_peer structure should contain a field for the source address (or
netmask). Then after lookup via inet_getpeer_v4() check the source address (or
netmask) of the returned peer.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: r8169 vpd r/w failed
From: Francois Romieu @ 2012-05-31 23:49 UTC (permalink / raw)
To: Dave Jones; +Cc: netdev, Hayes Wang, Fedora Kernel Team
In-Reply-To: <20120531174126.GA4189@redhat.com>
Dave Jones <davej@redhat.com> :
[...]
> We occasionally see reports from r8169 where it seems to hang
> reading vpd data from the NIC. The printk in drivers/pci/
> suggests it's likely a firmware bug on the device, and recommends the user
> contact the vendor for an update (does Realtek even do firmware updates?)
>
> Is this as the message suggests a firmware bug, or should r8169 be
> avoiding trying to read vpd ?
I have not practiced vpd with the 816x a lot but I have experienced an
unlimited read behavior with the 8168 while trying to access the vpd back
in march. The output exhibited a periodic pattern, so I got rid of
it with something similar to drivers/pci/quirks.c::quirk_brcm_570x_limit_vpd.
I can resurrect it but I'd rather give the pending softirq stuff a try
first and I must test davandra netif_napi_del patch as well. Btw I have
just upgraded my workstation to F17 and it's time for some sleep.
> https://bugzilla.redhat.com/show_bug.cgi?id=827137 is one example.
(990FX)
Adding a RTL_GIGA_MAC_VER_34 case similar to RTL_GIGA_MAC_VER_24 in
rtl_init_rxcfg may temporarily help if netdev watchdog triggers (see
the mess known as https://bugzilla.kernel.org/show_bug.cgi?id=42899).
--
Ueimor
^ permalink raw reply
* Re: [PATCH] cipso: handle CIPSO options correctly when NetLabel is disabled
From: David Miller @ 2012-05-31 23:07 UTC (permalink / raw)
To: pmoore; +Cc: netdev, linux-security-module, stable
In-Reply-To: <20120531200922.6265.81763.stgit@sifl>
From: Paul Moore <pmoore@redhat.com>
Date: Thu, 31 May 2012 16:09:23 -0400
> When NetLabel is not enabled, e.g. CONFIG_NETLABEL=n, and the system
> receives a CIPSO tagged packet it is dropped (cipso_v4_validate()
> returns non-zero). In most cases this is the correct and desired
> behavior, however, in the case where we are simply forwarding the
> traffic, e.g. acting as a network bridge, this becomes a problem.
>
> This patch fixes the forwarding problem by providing the basic CIPSO
> validation code directly in ip_options_compile() without the need for
> the NetLabel or CIPSO code. The new validation code can not perform
> any of the CIPSO option label/value verification that
> cipso_v4_validate() does, but it can verify the basic CIPSO option
> format.
>
> The behavior when NetLabel is enabled is unchanged.
>
> Signed-off-by: Paul Moore <pmoore@redhat.com>
I don't like this at all.
The only conclusion I can come to is that cipso_v4_validate() is doing
the wrong thing when NETLABEL is disabled.
There is never a good reason to crap all over a function with ifdefs.
This is especially true when it's being done to paper over a function
with poor semantics.
The whole idea is to abstract and put all of this kind of logic into
cipso_v4_validate().
^ permalink raw reply
* Re: [PATCH net-next] tcp: avoid tx starvation by SYNACK packets
From: David Miller @ 2012-05-31 23:03 UTC (permalink / raw)
To: eric.dumazet; +Cc: hans.schillstrom, netdev, ncardwell, therbert, brouer
In-Reply-To: <1338501397.2760.1395.camel@edumazet-glaptop>
Is the net-next tree open yet?
^ permalink raw reply
* Winning Notifications!!!!
From: UNC @ 2012-05-31 22:35 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 249 bytes --]
Dear 2012 winner,
Kindly open the attach claims application form and claim your winning fund
by filling the form and send it to our claims department. Please send it
to this email only: uncclaims@yahoo.co.jp
Mrs. Judith Adams.
Online coordinator
[-- Attachment #2: ATTACH COPY.doc --]
[-- Type: application/msword, Size: 251904 bytes --]
^ permalink raw reply
* Re: [V2 PATCH] net: sock: validate data_len before allocating skb in sock_alloc_send_pskb()
From: David Miller @ 2012-05-31 22:21 UTC (permalink / raw)
To: jasowang; +Cc: netdev, edumazet, mst, linux-kernel, stable
In-Reply-To: <20120531071809.6392.26677.stgit@amd-6168-8-1.englab.nay.redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Thu, 31 May 2012 15:18:10 +0800
> 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.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied and queued up for -stable.
Please do not add explicit stable CC:'s to networking patches, I queue
appropriate changes up myself, and submit them only when I feel that
the change has had sufficient exposure and testing in Linus's tree.
^ permalink raw reply
* Re: [PATCH net 3/3] bql: Avoid possible inconsistent calculation.
From: David Miller @ 2012-05-31 22:20 UTC (permalink / raw)
To: shimoda.hiroaki; +Cc: therbert, eric.dumazet, denys, netdev
In-Reply-To: <20120531072537.920f0cb0.shimoda.hiroaki@gmail.com>
From: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Date: Thu, 31 May 2012 07:25:37 +0900
> 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>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net 2/3] bql: Avoid unneeded limit decrement.
From: David Miller @ 2012-05-31 22:20 UTC (permalink / raw)
To: shimoda.hiroaki; +Cc: therbert, eric.dumazet, denys, netdev
In-Reply-To: <20120531072519.16464513.shimoda.hiroaki@gmail.com>
From: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Date: Thu, 31 May 2012 07:25:19 +0900
> 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>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net 1/3] bql: Fix POSDIFF() to integer overflow aware.
From: David Miller @ 2012-05-31 22:19 UTC (permalink / raw)
To: shimoda.hiroaki; +Cc: therbert, eric.dumazet, denys, netdev
In-Reply-To: <20120531072439.6c634a0b.shimoda.hiroaki@gmail.com>
From: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Date: Thu, 31 May 2012 07:24:39 +0900
> POSDIFF() fails to take into account integer overflow case.
>
> Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net 0/6] batch of mlx4 fixes, mostly to SRIOV
From: David Miller @ 2012-05-31 22:19 UTC (permalink / raw)
To: yevgenyp; +Cc: netdev, ogerlitz, yevgenyp, jackm
In-Reply-To: <1338405295-15427-1-git-send-email-yevgenyp@mellanox.com>
From: Yevgeny Petrilin <yevgenyp@mellanox.com>
Date: Wed, 30 May 2012 22:14:49 +0300
> Batch of fixes to the mlx4_core and mlx4_en drivers, prepared
> by Jack Morgenstein, who leads our SRIOV development efforts and
> fix various issues all except for one, relate to the driver
> SRIOV functionality.
All applied, thanks.
^ permalink raw reply
* [PATCH net-next] tcp: avoid tx starvation by SYNACK packets
From: Eric Dumazet @ 2012-05-31 21:56 UTC (permalink / raw)
To: Hans Schillstrom
Cc: netdev, Neal Cardwell, Tom Herbert, Jesper Dangaard Brouer
From: Eric Dumazet <edumazet@google.com>
pfifo_fast being the default Qdisc, its pretty easy to fill it with
SYNACK (small) packets while host is under SYNFLOOD attack.
Packets of established TCP sessions are dropped and host appears almost
dead.
Avoid this problem assigning TC_PRIO_FILLER priority to SYNACK
generated in SYNCOOKIE mode, so that these packets are enqueued into
pfifo_fast band 2.
Other packets, queued to band 0 or 1 are dequeued before any SYNACK
packets waiting in band 2.
Reported-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Tom Herbert <therbert@google.com>
---
net/dccp/ipv4.c | 3 +++
net/ipv4/ip_output.c | 2 +-
net/ipv4/tcp_ipv4.c | 13 +++++++++----
net/ipv6/inet6_connection_sock.c | 1 +
net/ipv6/ip6_output.c | 2 +-
net/ipv6/tcp_ipv6.c | 10 +++++++---
6 files changed, 22 insertions(+), 9 deletions(-)
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index 07f5579..d8a3d87 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -515,6 +515,8 @@ static int dccp_v4_send_response(struct sock *sk, struct request_sock *req,
dh->dccph_checksum = dccp_v4_csum_finish(skb, ireq->loc_addr,
ireq->rmt_addr);
+
+ skb->priority = sk->sk_priority;
err = ip_build_and_send_pkt(skb, sk, ireq->loc_addr,
ireq->rmt_addr,
ireq->opt);
@@ -556,6 +558,7 @@ static void dccp_v4_ctl_send_reset(struct sock *sk, struct sk_buff *rxskb)
skb_dst_set(skb, dst_clone(dst));
bh_lock_sock(ctl_sk);
+ skb->priority = ctl_sk->sk_priority;
err = ip_build_and_send_pkt(skb, ctl_sk,
rxiph->daddr, rxiph->saddr, NULL);
bh_unlock_sock(ctl_sk);
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 451f97c..407e2fc 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -168,7 +168,7 @@ int ip_build_and_send_pkt(struct sk_buff *skb, struct sock *sk,
ip_options_build(skb, &opt->opt, daddr, rt, 0);
}
- skb->priority = sk->sk_priority;
+ /* skb->priority is set by the caller */
skb->mark = sk->sk_mark;
/* Send it out. */
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index a43b87d..613e713 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -81,7 +81,7 @@
#include <linux/stddef.h>
#include <linux/proc_fs.h>
#include <linux/seq_file.h>
-
+#include <linux/pkt_sched.h>
#include <linux/crypto.h>
#include <linux/scatterlist.h>
@@ -824,7 +824,8 @@ static void tcp_v4_reqsk_send_ack(struct sock *sk, struct sk_buff *skb,
*/
static int tcp_v4_send_synack(struct sock *sk, struct dst_entry *dst,
struct request_sock *req,
- struct request_values *rvp)
+ struct request_values *rvp,
+ bool syncookie)
{
const struct inet_request_sock *ireq = inet_rsk(req);
struct flowi4 fl4;
@@ -840,6 +841,9 @@ static int tcp_v4_send_synack(struct sock *sk, struct dst_entry *dst,
if (skb) {
__tcp_v4_send_check(skb, ireq->loc_addr, ireq->rmt_addr);
+ /* SYNACK sent in SYNCOOKIE mode have low priority */
+ skb->priority = syncookie ? TC_PRIO_FILLER : sk->sk_priority;
+
err = ip_build_and_send_pkt(skb, sk, ireq->loc_addr,
ireq->rmt_addr,
ireq->opt);
@@ -854,7 +858,7 @@ static int tcp_v4_rtx_synack(struct sock *sk, struct request_sock *req,
struct request_values *rvp)
{
TCP_INC_STATS_BH(sock_net(sk), TCP_MIB_RETRANSSEGS);
- return tcp_v4_send_synack(sk, NULL, req, rvp);
+ return tcp_v4_send_synack(sk, NULL, req, rvp, false);
}
/*
@@ -1422,7 +1426,8 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
tcp_rsk(req)->snt_synack = tcp_time_stamp;
if (tcp_v4_send_synack(sk, dst, req,
- (struct request_values *)&tmp_ext) ||
+ (struct request_values *)&tmp_ext,
+ want_cookie) ||
want_cookie)
goto drop_and_free;
diff --git a/net/ipv6/inet6_connection_sock.c b/net/ipv6/inet6_connection_sock.c
index e6cee52..5812a74 100644
--- a/net/ipv6/inet6_connection_sock.c
+++ b/net/ipv6/inet6_connection_sock.c
@@ -248,6 +248,7 @@ int inet6_csk_xmit(struct sk_buff *skb, struct flowi *fl_unused)
/* Restore final destination back after routing done */
fl6.daddr = np->daddr;
+ skb->priority = sk->sk_priority;
res = ip6_xmit(sk, skb, &fl6, np->opt, np->tclass);
rcu_read_unlock();
return res;
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 17b8c67..61c0ea8 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -241,7 +241,7 @@ int ip6_xmit(struct sock *sk, struct sk_buff *skb, struct flowi6 *fl6,
hdr->saddr = fl6->saddr;
hdr->daddr = *first_hop;
- skb->priority = sk->sk_priority;
+ /* skb->priority is set by the caller */
skb->mark = sk->sk_mark;
mtu = dst_mtu(dst);
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 554d599..b618413 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -43,6 +43,7 @@
#include <linux/ipv6.h>
#include <linux/icmpv6.h>
#include <linux/random.h>
+#include <linux/pkt_sched.h>
#include <net/tcp.h>
#include <net/ndisc.h>
@@ -476,7 +477,7 @@ out:
static int tcp_v6_send_synack(struct sock *sk, struct request_sock *req,
- struct request_values *rvp)
+ struct request_values *rvp, bool syncookie)
{
struct inet6_request_sock *treq = inet6_rsk(req);
struct ipv6_pinfo *np = inet6_sk(sk);
@@ -512,6 +513,7 @@ static int tcp_v6_send_synack(struct sock *sk, struct request_sock *req,
if (skb) {
__tcp_v6_send_check(skb, &treq->loc_addr, &treq->rmt_addr);
+ skb->priority = syncookie ? TC_PRIO_FILLER : sk->sk_priority;
fl6.daddr = treq->rmt_addr;
err = ip6_xmit(sk, skb, &fl6, opt, np->tclass);
err = net_xmit_eval(err);
@@ -528,7 +530,7 @@ static int tcp_v6_rtx_synack(struct sock *sk, struct request_sock *req,
struct request_values *rvp)
{
TCP_INC_STATS_BH(sock_net(sk), TCP_MIB_RETRANSSEGS);
- return tcp_v6_send_synack(sk, req, rvp);
+ return tcp_v6_send_synack(sk, req, rvp, false);
}
static void tcp_v6_reqsk_destructor(struct request_sock *req)
@@ -906,6 +908,7 @@ static void tcp_v6_send_response(struct sk_buff *skb, u32 seq, u32 ack, u32 win,
dst = ip6_dst_lookup_flow(ctl_sk, &fl6, NULL, false);
if (!IS_ERR(dst)) {
skb_dst_set(buff, dst);
+ skb->priority = ctl_sk->sk_priority;
ip6_xmit(ctl_sk, buff, &fl6, NULL, tclass);
TCP_INC_STATS_BH(net, TCP_MIB_OUTSEGS);
if (rst)
@@ -1213,7 +1216,8 @@ have_isn:
security_inet_conn_request(sk, skb, req);
if (tcp_v6_send_synack(sk, req,
- (struct request_values *)&tmp_ext) ||
+ (struct request_values *)&tmp_ext,
+ want_cookie) ||
want_cookie)
goto drop_and_free;
^ permalink raw reply related
* r8169: IO_PAGE_FAULT & netdev watchdog
From: Vincent Pelletier @ 2012-05-31 21:31 UTC (permalink / raw)
To: netdev
Hi.
First of all, I'm running 3.3.4 as of debian experimental (the rest of
userland is from sid). I am not subscribed to this list, so please keep me
in CC.
I'm getting consistently errors when using btlaunchmanycurses (multi-torrent
downloader) after a few minutes. I usually first notice the network being down
(no trafic) then find this in syslog (see at bottom).
Then, I "ifdown eth0;rmmod r8169;modprobe r8169" (which implicitely ifup's),
but network never comes back - at least no trafic can go through - until
reboot.
www.kerneloops.org being down (aparently for quite some time...) I though I
should report here.
I'm quite sure this problem also occured on 3.2, but I don't know the exact
version I was using at that time. I only have this motherboard since a few
months, and previous one didn't have an IOMMU - which in my understanding is
what causes (well, detects actually) this error.
May 31 22:54:55 x2 kernel: [78579.111904] AMD-Vi: Event logged [IO_PAGE_FAULT device=05:00.0 domain=0x0019 address=0x0000000000003000 flags=0x0050]
May 31 22:55:07 x2 kernel: [78590.832047] ------------[ cut here ]------------
May 31 22:55:07 x2 kernel: [78590.832067] WARNING: at /build/buildd-linux-2.6_3.3.4-1~experimental.1-amd64-_y3OdD/linux-2.6-3.3.4/debian/build/source_amd64_none/net/sched/sch_generic.c:256 dev_watchdog+0xf2/0x151()
May 31 22:55:07 x2 kernel: [78590.832080] Hardware name: GA-990FXA-UD3
May 31 22:55:07 x2 kernel: [78590.832087] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
May 31 22:55:07 x2 kernel: [78590.832093] Modules linked in: pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) snd_hrtimer cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_conservative xt_multiport iptable_filter ip_tables x_tables tun parport_pc ppdev lp parport binfmt_misc ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp libiscsi_tcp
libiscsi scsi_transport_iscsi fuse nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc ext3 mbcache jbd dm_crypt raid1 md_mod powernow_k8 mperf adt7475 it87 hwmon_vid snd_emu10k1_synth snd_emux_synth snd_seq_midi_emul snd_seq_virmidi snd_emu10k1 snd_util_mem snd_ac97_codec snd_hwdep snd_pcm_oss snd_mixer_oss joydev snd_pcm snd_page_alloc nouveau snd_seq_midi
snd_seq_midi_event snd_rawmidi snd_seq video ttm drm_kms_helper drm sp5100_tco i2c_piix4 snd_seq_device k10temp snd_timer i2c_core mxm_wmi snd emu10k1_gp gameport edac_mce_amd edac_core evdev pcspkr wmi processor soundcore ac97_bus button thermal_sys sr_mod cdrom usbhid hid power_supply re
May 31 22:55:07 x2 kernel: iserfs dm_mod nbd usb_storage uas sd_mod crc_t10dif ohci_hcd firewire_ohci firewire_core crc_itu_t ahci libahci ehci_hcd xhci_hcd r8169 mii libata scsi_mod usbcore usb_common [last unloaded: scsi_wait_scan]
May 31 22:55:07 x2 kernel: [78590.832306] Pid: 0, comm: swapper/0 Tainted: G W O 3.3.0-trunk-amd64 #1
May 31 22:55:07 x2 kernel: [78590.832314] Call Trace:
May 31 22:55:07 x2 kernel: [78590.832319] <IRQ> [<ffffffff810387cb>] ? warn_slowpath_common+0x78/0x8c
May 31 22:55:07 x2 kernel: [78590.832339] [<ffffffff81038877>] ? warn_slowpath_fmt+0x45/0x4a
May 31 22:55:07 x2 kernel: [78590.832349] [<ffffffff812aa28d>] ? netif_tx_lock+0x40/0x76
May 31 22:55:07 x2 kernel: [78590.832363] [<ffffffff812aa3ff>] ? dev_watchdog+0xf2/0x151
May 31 22:55:07 x2 kernel: [78590.832374] [<ffffffff81043ef1>] ? run_timer_softirq+0x19a/0x261
May 31 22:55:07 x2 kernel: [78590.832383] [<ffffffff812aa30d>] ? netif_tx_unlock+0x4a/0x4a
May 31 22:55:07 x2 kernel: [78590.832395] [<ffffffff8103de20>] ? __do_softirq+0xb9/0x177
May 31 22:55:07 x2 kernel: [78590.832405] [<ffffffff8106d15b>] ? timekeeping_get_ns+0xd/0x2a
May 31 22:55:07 x2 kernel: [78590.832417] [<ffffffff81358b5c>] ? call_softirq+0x1c/0x30
May 31 22:55:07 x2 kernel: [78590.832428] [<ffffffff8100fa35>] ? do_softirq+0x3c/0x7b
May 31 22:55:07 x2 kernel: [78590.832438] [<ffffffff8103e088>] ? irq_exit+0x3c/0x96
May 31 22:55:07 x2 kernel: [78590.832447] [<ffffffff8100f763>] ? do_IRQ+0x82/0x98
May 31 22:55:07 x2 kernel: [78590.832459] [<ffffffff8135282e>] ? common_interrupt+0x6e/0x6e
May 31 22:55:07 x2 kernel: [78590.832464] <EOI> [<ffffffff8102b0c8>] ? native_safe_halt+0x2/0x3
May 31 22:55:07 x2 kernel: [78590.832481] [<ffffffff81014798>] ? default_idle+0x47/0x7f
May 31 22:55:07 x2 kernel: [78590.832490] [<ffffffff8101488f>] ? amd_e400_idle+0xbf/0xe4
May 31 22:55:07 x2 kernel: [78590.832500] [<ffffffff8100d252>] ? cpu_idle+0xaf/0xf7
May 31 22:55:07 x2 kernel: [78590.832510] [<ffffffff8169ab37>] ? start_kernel+0x3bd/0x3c8
May 31 22:55:07 x2 kernel: [78590.832519] [<ffffffff8169a140>] ? early_idt_handlers+0x140/0x140
May 31 22:55:07 x2 kernel: [78590.832529] [<ffffffff8169a3c3>] ? x86_64_start_kernel+0x104/0x111
May 31 22:55:07 x2 kernel: [78590.832537] ---[ end trace 627ebd8c70d61b1a ]---
May 31 22:55:07 x2 kernel: [78590.848660] r8169 0000:05:00.0: eth0: link up
May 31 22:55:19 x2 kernel: [78602.848659] r8169 0000:05:00.0: eth0: link up
May 31 22:55:31 x2 kernel: [78614.848656] r8169 0000:05:00.0: eth0: link up
May 31 22:55:43 x2 kernel: [78626.848800] r8169 0000:05:00.0: eth0: link up
May 31 22:55:55 x2 ovpn-nexedi[2610]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
May 31 22:56:31 x2 kernel: [78674.848666] r8169 0000:05:00.0: eth0: link up
May 31 22:57:19 x2 kernel: [78722.848598] r8169 0000:05:00.0: eth0: link up
May 31 22:58:07 x2 kernel: [78770.848662] r8169 0000:05:00.0: eth0: link up
May 31 22:58:17 x2 avahi-daemon[2744]: Withdrawing address record for 192.168.0.16 on eth0.
May 31 22:58:17 x2 avahi-daemon[2744]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.0.16.
May 31 22:58:17 x2 avahi-daemon[2744]: Interface eth0.IPv4 no longer relevant for mDNS.
May 31 22:58:17 x2 avahi-daemon[2744]: Interface eth0.IPv6 no longer relevant for mDNS.
May 31 22:58:17 x2 avahi-daemon[2744]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::52e5:49ff:feb4:ed6f.
May 31 22:58:17 x2 avahi-daemon[2744]: Withdrawing address record for fe80::52e5:49ff:feb4:ed6f on eth0.
May 31 22:58:25 x2 avahi-daemon[2744]: Withdrawing workstation service for tun0.
May 31 22:59:29 x2 avahi-daemon[2744]: Withdrawing workstation service for eth0.
May 31 22:59:33 x2 kernel: [78856.929121] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
May 31 22:59:33 x2 kernel: [78856.929312] r8169 0000:05:00.0: irq 41 for MSI/MSI-X
May 31 22:59:33 x2 kernel: [78856.930671] r8169 0000:05:00.0: eth0: RTL8168evl/8111evl at 0xffffc90000c1e000, 50:e5:49:b4:ed:6f, XID 0c900880 IRQ 41
May 31 22:59:33 x2 kernel: [78856.930685] r8169 0000:05:00.0: eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
May 31 22:59:33 x2 avahi-daemon[2744]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.0.16.
May 31 22:59:33 x2 kernel: [78857.169029] r8169 0000:05:00.0: eth0: link down
May 31 22:59:33 x2 kernel: [78857.169043] r8169 0000:05:00.0: eth0: link down
May 31 22:59:33 x2 kernel: [78857.171749] ADDRCONF(NETDEV_UP): eth0: link is not ready
May 31 22:59:33 x2 avahi-daemon[2744]: New relevant interface eth0.IPv4 for mDNS.
May 31 22:59:33 x2 avahi-daemon[2744]: Registering new address record for 192.168.0.16 on eth0.IPv4.
May 31 22:59:36 x2 kernel: [78859.538358] r8169 0000:05:00.0: eth0: link up
May 31 22:59:36 x2 kernel: [78859.539012] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
May 31 22:59:37 x2 avahi-daemon[2744]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::52e5:49ff:feb4:ed6f.
May 31 22:59:37 x2 avahi-daemon[2744]: New relevant interface eth0.IPv6 for mDNS.
May 31 22:59:37 x2 avahi-daemon[2744]: Registering new address record for fe80::52e5:49ff:feb4:ed6f on eth0.*.
May 31 22:59:46 x2 kernel: [78870.104066] eth0: no IPv6 routers present
May 31 23:00:00 x2 kernel: [78883.792620] r8169 0000:05:00.0: eth0: link up
May 31 23:00:37 x2 kerneloops: Submitted 2 kernel oopses to www.kerneloops.org
May 31 23:00:48 x2 kernel: [78931.792643] r8169 0000:05:00.0: eth0: link up
May 31 23:01:21 x2 kernel: [78965.124469] r8169 0000:05:00.0: eth0: link down
May 31 23:01:26 x2 kernel: [78969.278184] r8169 0000:05:00.0: eth0: link up
May 31 23:01:27 x2 kerneloops: Submitted 1 kernel oopses to www.kerneloops.org
May 31 23:01:44 x2 kernel: [78987.792649] r8169 0000:05:00.0: eth0: link up
May 31 23:02:32 x2 kernel: [79035.792636] r8169 0000:05:00.0: eth0: link up
May 31 23:02:54 x2 shutdown[9402]: shutting down for system reboot
Regards,
--
Vincent Pelletier
^ permalink raw reply
* Re: [PATCH 2/4] can: cc770: Fix likely misuse of | for &
From: Marc Kleine-Budde @ 2012-05-31 20:54 UTC (permalink / raw)
To: Joe Perches; +Cc: linux-kernel, Wolfgang Grandegger, linux-can, netdev
In-Reply-To: <6c251b03dc626215cf696e894ac1cdda530f38d9.1338408931.git.joe@perches.com>
[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]
On 05/30/2012 10:25 PM, Joe Perches wrote:
> Using | with a constant is always true.
> Likely this should have be &.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Sounds reasonable. And there are no in tree users of the platform driver
that this fix could break.
commited to linux-can,
Marc
> ---
> drivers/net/can/cc770/cc770_platform.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/can/cc770/cc770_platform.c b/drivers/net/can/cc770/cc770_platform.c
> index 53115ee..688371c 100644
> --- a/drivers/net/can/cc770/cc770_platform.c
> +++ b/drivers/net/can/cc770/cc770_platform.c
> @@ -154,7 +154,7 @@ static int __devinit cc770_get_platform_data(struct platform_device *pdev,
> struct cc770_platform_data *pdata = pdev->dev.platform_data;
>
> priv->can.clock.freq = pdata->osc_freq;
> - if (priv->cpu_interface | CPUIF_DSC)
> + if (priv->cpu_interface & CPUIF_DSC)
> priv->can.clock.freq /= 2;
> priv->clkout = pdata->cor;
> priv->bus_config = pdata->bcr;
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* [PATCH] cipso: handle CIPSO options correctly when NetLabel is disabled
From: Paul Moore @ 2012-05-31 20:09 UTC (permalink / raw)
To: netdev; +Cc: linux-security-module, stable
When NetLabel is not enabled, e.g. CONFIG_NETLABEL=n, and the system
receives a CIPSO tagged packet it is dropped (cipso_v4_validate()
returns non-zero). In most cases this is the correct and desired
behavior, however, in the case where we are simply forwarding the
traffic, e.g. acting as a network bridge, this becomes a problem.
This patch fixes the forwarding problem by providing the basic CIPSO
validation code directly in ip_options_compile() without the need for
the NetLabel or CIPSO code. The new validation code can not perform
any of the CIPSO option label/value verification that
cipso_v4_validate() does, but it can verify the basic CIPSO option
format.
The behavior when NetLabel is enabled is unchanged.
Signed-off-by: Paul Moore <pmoore@redhat.com>
---
net/ipv4/ip_options.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/ip_options.c b/net/ipv4/ip_options.c
index 708b994..ca2c919 100644
--- a/net/ipv4/ip_options.c
+++ b/net/ipv4/ip_options.c
@@ -439,10 +439,30 @@ int ip_options_compile(struct net *net,
goto error;
}
opt->cipso = optptr - iph;
+#ifndef CONFIG_NETLABEL
+ if (optlen < 8) {
+ pp_ptr = optptr + 1;
+ goto error;
+ }
+ if (get_unaligned_be32(&optptr[2]) != 0) {
+ unsigned int iter;
+ for (iter = 6; iter < optlen;) {
+ if (optptr[iter+1] > (optlen - iter)) {
+ pp_ptr = optptr + iter;
+ goto error;
+ }
+ iter += optptr[iter + 1];
+ }
+ } else {
+ pp_ptr = optptr + 2;
+ goto error;
+ }
+#else
if (cipso_v4_validate(skb, &optptr)) {
pp_ptr = optptr;
goto error;
}
+#endif /* CONFIG_NETLABEL */
break;
case IPOPT_SEC:
case IPOPT_SID:
^ permalink raw reply related
* Re: [PATCH 1/3] drivers/net: Convert compare_ether_addr to ether_addr_equal
From: Joe Perches @ 2012-05-31 18:49 UTC (permalink / raw)
To: Jussi Kivilinna
Cc: David Miller, linville-2XuSBdqkA4R54TAoqtyWWQ,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120531150124.119853l3a0cbvj40-tzMWlZeEOor1KXRcyAk9cg@public.gmane.org>
On Thu, 2012-05-31 at 15:01 +0300, Jussi Kivilinna wrote:
> Quoting David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>:
> > From: Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
> > Date: Thu, 10 May 2012 09:11:28 -0700
> >> On Thu, 2012-05-10 at 17:32 +0300, Jussi Kivilinna wrote:
> >>> Quoting Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>:
> >>> > Use the new bool function ether_addr_equal to add
> >>> > some clarity and reduce the likelihood for misuse
> >>> > of compare_ether_addr for sorting.
> >> []
> >>> > diff --git a/drivers/net/wireless/rndis_wlan.c
> >> []
> >>> > @@ -2139,7 +2139,7 @@ resize_buf:
> >>> > while (check_bssid_list_item(bssid, bssid_len, buf, len)) {
> >>> > if (rndis_bss_info_update(usbdev, bssid) && match_bssid &&
> >>> > matched) {
> >>> > - if (compare_ether_addr(bssid->mac, match_bssid))
> >>> > + if (!ether_addr_equal(bssid->mac, match_bssid))
> >>>
> >>> While reviewing this, noticed that above original code is wrong. It
> >>> should be !compare_ether_addr. So do I push patch fixing this through
> >>> wireless-testing althought it will later cause conflict with this patch?
[]
> That line/compare was added as response to hardware bug, where bssid-list does
> not contain BSSID and other information of currently connected AP
> (spec insists
> that device must provide this information in the list when connected). Lack
> bssid-data on current connection then causes WARN_ON somewhere in cfg80211.
> Workaround was to check if bssid-list returns current bssid and if it
> does not,
> manually construct bssid information in other ways. And this
> workaround worked,
> with inverse check. Which must mean that when hardware is experiencing the
> problem, it's actually returning empty bssid-list.
>
> Inverse check causes workaround be activated when bssid-list returns only
> entry, currently connected BSSID. That does not cause problems in itself, just
> slightly more inaccurate information in scan-list.
Thanks.
That information would be useful in the
eventual commit message.
cheers, Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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