* Re: [PATCH RFC 0/5] netfilter: implement netfilter SYN proxy
From: Hannes Frederic Sowa @ 2013-08-08 0:04 UTC (permalink / raw)
To: David Miller
Cc: kaber, eric.dumazet, pablo, netfilter-devel, netdev, mph,
jesper.brouer, as
In-Reply-To: <20130807.164056.2110811182336568861.davem@davemloft.net>
On Wed, Aug 07, 2013 at 04:40:56PM -0700, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Date: Wed, 7 Aug 2013 23:05:40 +0200
>
> > It seems, Windows stopped using tcp timestamps at least in windows 8 by
> > default.
>
> Thankfully, Android device outnumber Windows 8 installs
> by... something like 1,000 to 1, right?
Heh, at minimum. :)
> I throw a huge "doesn't matter" to whatever Windows's TCP stack
> decides to do. It absolutely should not dictate whether we decide to
> make use of this or that feature of TCP. It's a bit player at best.
>
> So if Windows 8 is the reason you're saying we shouldn't use
> timestamps for anything, you're wrong.
Actually, I don't care at all, because I don't do anything with windows
and don't get paid by anyone who wants me to care. ;)
But if we switch to a similar scheme as freebsd we can even care
less because even if some other operating systems or a major provider
decides to disable timestamps on their devices, we would still have
window scaling, sack (and ecn?) under syn dos. So, I do think it is an
improvement and don't see any disadvantages.
So, I don't care as long as the change (and siphash or maybe another
hashing scheme) is secure enough...
Greetings,
Hannes
^ permalink raw reply
* Re: linux-next: Tree for Aug 7
From: Eric Dumazet @ 2013-08-08 0:06 UTC (permalink / raw)
To: David Miller
Cc: phil, johannes, sedat.dilek, sfr, linux-next, linux-kernel,
netdev, hannes, linux-wireless, linville
In-Reply-To: <20130807.163621.84433966934449459.davem@davemloft.net>
On Wed, 2013-08-07 at 16:36 -0700, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Wed, 07 Aug 2013 16:27:48 -0700 (PDT)
>
> > Look, I'm going to fix this myself, because I'm pretty tired of
> > waiting for the obvious fix.
>
> Someone please test this:
>
> diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
> index c623861..afc02a6 100644
> --- a/include/linux/etherdevice.h
> +++ b/include/linux/etherdevice.h
> @@ -29,6 +29,7 @@
>
> #ifdef __KERNEL__
> extern __be16 eth_type_trans(struct sk_buff *skb, struct net_device *dev);
> +extern __be16 __eth_type_trans(struct sk_buff *skb, struct net_device *dev);
> extern const struct header_ops eth_header_ops;
>
> extern int eth_header(struct sk_buff *skb, struct net_device *dev,
> diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
> index be1f64d..35dc1be 100644
> --- a/net/ethernet/eth.c
> +++ b/net/ethernet/eth.c
> @@ -146,6 +146,45 @@ int eth_rebuild_header(struct sk_buff *skb)
> EXPORT_SYMBOL(eth_rebuild_header);
>
> /**
> + * __eth_type_trans - only determine the packet's protocol ID.
> + * @skb: packet
> + * @dev: device
> + */
> +__be16 __eth_type_trans(struct sk_buff *skb, struct net_device *dev)
> +{
We probably want an inline here
Or else, we are adding an extra function call in rx fast path.
(At least my compiler did this)
0000000000000470 <eth_type_trans>:
470: e8 00 00 00 00 callq 475 <eth_type_trans+0x5>
471: R_X86_64_PC32 __fentry__-0x4
475: 48 8b 8f d0 00 00 00 mov 0xd0(%rdi),%rcx
47c: 48 8b 87 c8 00 00 00 mov 0xc8(%rdi),%rax
483: 44 8b 47 60 mov 0x60(%rdi),%r8d
487: 55 push %rbp
488: 48 89 77 20 mov %rsi,0x20(%rdi)
48c: 48 89 ca mov %rcx,%rdx
48f: 48 89 e5 mov %rsp,%rbp
492: 48 29 c2 sub %rax,%rdx
495: 41 83 f8 0d cmp $0xd,%r8d
499: 66 89 97 b8 00 00 00 mov %dx,0xb8(%rdi)
4a0: 76 19 jbe 4bb <eth_type_trans+0x4b>
4a2: 41 83 e8 0e sub $0xe,%r8d
4a6: 44 3b 47 64 cmp 0x64(%rdi),%r8d
4aa: 44 89 47 60 mov %r8d,0x60(%rdi)
4ae: 72 36 jb 4e6 <eth_type_trans+0x76>
4b0: 48 83 c1 0e add $0xe,%rcx
4b4: 48 89 8f d0 00 00 00 mov %rcx,0xd0(%rdi)
4bb: 81 e2 ff ff 00 00 and $0xffff,%edx
4c1: 48 01 d0 add %rdx,%rax
4c4: f6 00 01 testb $0x1,(%rax)
4c7: 75 2e jne 4f7 <eth_type_trans+0x87>
4c9: 48 8b 96 88 02 00 00 mov 0x288(%rsi),%rdx
4d0: 48 8b 00 mov (%rax),%rax
4d3: 48 33 02 xor (%rdx),%rax
4d6: 48 c1 e0 10 shl $0x10,%rax
4da: 48 85 c0 test %rax,%rax
4dd: 75 09 jne 4e8 <eth_type_trans+0x78>
4df: e8 00 00 00 00 callq 4e4 <eth_type_trans+0x74>
4e0: R_X86_64_PC32 __eth_type_trans-0x4
4e4: 5d pop %rbp
4e5: c3 retq
4e6: 0f 0b ud2
4e8: 0f b6 47 75 movzbl 0x75(%rdi),%eax
4ec: 83 e0 f8 and $0xfffffff8,%eax
4ef: 83 c8 03 or $0x3,%eax
4f2: 88 47 75 mov %al,0x75(%rdi)
4f5: eb e8 jmp 4df <eth_type_trans+0x6f>
4f7: 48 8b 00 mov (%rax),%rax
4fa: 48 33 86 b8 02 00 00 xor 0x2b8(%rsi),%rax
501: 48 c1 e0 10 shl $0x10,%rax
505: 48 85 c0 test %rax,%rax
508: 0f b6 47 75 movzbl 0x75(%rdi),%eax
50c: 75 0b jne 519 <eth_type_trans+0xa9>
50e: 83 e0 f8 and $0xfffffff8,%eax
511: 83 c8 01 or $0x1,%eax
514: 88 47 75 mov %al,0x75(%rdi)
517: eb c6 jmp 4df <eth_type_trans+0x6f>
519: 83 e0 f8 and $0xfffffff8,%eax
51c: 83 c8 02 or $0x2,%eax
51f: 88 47 75 mov %al,0x75(%rdi)
522: eb bb jmp 4df <eth_type_trans+0x6f>
^ permalink raw reply
* Re: [PATCH] veth: remove hardware checksum feature
From: Ben Greear @ 2013-08-08 0:07 UTC (permalink / raw)
To: Vitaly E. Lavrov; +Cc: netdev, davem, Eric Dumazet
In-Reply-To: <51F15E50.8080208@guap.ru>
On 07/25/2013 10:20 AM, Vitaly E. Lavrov wrote:
> The network device VETH can't support the feature NETIF_F_HW_CSUM.
> All locally generated packets have invalid checksum.
> Wrong commit http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8093315a91340bca52549044975d8c7f673b28a1 ( kernel 3.9.0 )
>
> Workaround "ethtool -K vethX tx off"
>
> Possible patch:
>
> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
> index 177f911..3db97da 100644
> --- a/drivers/net/veth.c
> +++ b/drivers/net/veth.c
> @@ -254,7 +254,7 @@ static const struct net_device_ops veth_netdev_ops = {
> };
>
> #define VETH_FEATURES (NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_ALL_TSO | \
> - NETIF_F_HW_CSUM | NETIF_F_RXCSUM | NETIF_F_HIGHDMA | \
> + NETIF_F_RXCSUM | NETIF_F_HIGHDMA | \
> NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX | \
> NETIF_F_HW_VLAN_STAG_TX | NETIF_F_HW_VLAN_STAG_RX )
I see the same problem.
My test case is a bit complicated, but the gist is that I have a VETH
pair, one with IP (veth1), one connected to a bridge-like-thing (veth2).
The UDP frames sent on veth1 appear on veth2, and when I sniff veth2,
the packets show broken checksum. The work-around mentioned in Vitaly's
email above fixes the problem for me (I did not try the patch yet).
Eric: You responded originally that you needed more info. If
my explanation above is not sufficient, please let me know what
you need...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH V2 0/4] Enable bus master till the FLR completes for Chelsio T4
From: David Miller @ 2013-08-08 0:08 UTC (permalink / raw)
To: vipul
Cc: linux-pci, bhelgaas, leedom, tomreu, divy, dm, nirranjan, eilong,
netdev
In-Reply-To: <1375784319-25760-1-git-send-email-vipul@chelsio.com>
From: Vipul Pandya <vipul@chelsio.com>
Date: Tue, 6 Aug 2013 15:48:35 +0530
> This patch series adds device specific reset method for Chelsio T4 adapters.
>
> The series also adds new routine, pci_wait_for_pending_transaction, to wait for
> pending pci transaction. There are few places where waiting for pending pci
> transaction code was duplicated. This patch series also replaces occurances of
> duplicate code.
>
> This patch series is built against Bjorn Helgaas pci tree next branch. We would
> like to merge this series via the same.
>
> I have Cced respective maintainers of the modified drivers. Kindly review and
> let us know in case of any review comments.
Please push this via the PCI tree, and for the networking bits you can add:
Acked-by: David S. Miller <davem@davemloft.net>
Thanks.
^ permalink raw reply
* Re: linux-next: Tree for Aug 7
From: David Miller @ 2013-08-08 0:09 UTC (permalink / raw)
To: sedat.dilek
Cc: phil, eric.dumazet, johannes, sfr, linux-next, linux-kernel,
netdev, hannes, linux-wireless, linville
In-Reply-To: <CA+icZUUm2nbmVj_WRznPTjXL0y6pcr1GzLjsL7UMhSGQWSm==g@mail.gmail.com>
From: Sedat Dilek <sedat.dilek@gmail.com>
Date: Thu, 8 Aug 2013 02:02:48 +0200
> On Thu, Aug 8, 2013 at 1:36 AM, David Miller <davem@davemloft.net> wrote:
>> From: David Miller <davem@davemloft.net>
>> Date: Wed, 07 Aug 2013 16:27:48 -0700 (PDT)
>>
>>> Look, I'm going to fix this myself, because I'm pretty tired of
>>> waiting for the obvious fix.
>>
>> Someone please test this:
>
> Your patch on top of next-20130807 does not fix the issue in my wifi/network.
> No working Internet connection (ping etc.).
Ok, I'm going to simply revert all of these changes, thanks for testing.
^ permalink raw reply
* Re: More details on why received UDP packets are treated as errors?
From: Ben Greear @ 2013-08-08 0:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1375129292.10515.21.camel@edumazet-glaptop>
On 07/29/2013 01:21 PM, Eric Dumazet wrote:
> On Mon, 2013-07-29 at 11:21 -0700, Ben Greear wrote:
>> We have a test case on 3.9.9+ (local patches applied) where sending from
>> VETH interface, through peer VETH bridged (with our own emulator bridge module)
>> to physical interface, which is then looped to another physical interface (B).
>> The VETH and the wired B interface are sending UDP traffic to each other.
>> Routing rules should be configured such that this all works appropriately.
>>
>> Replacing our bridging module with a user-space bridge has same behaviour.
>>
>> This setup works on the 3.7.y kernel, but we only get one-way traffic
>> (B to VETH) on 3.9.9+.
>>
>> I sniffed the B port, and traffic appears to be sent and received
>> properly (ie, no checksum errors, etc). But, our user-space app
>> shows no received UDP frames on B, and netstat -s gives the
>> output below.
>>
>> Is there any way to get more details about what these 'packet receive errors'
>> are caused by using normal-ish tools?
>
> You could try dropwatch for this kind of obscure drops
>
> https://fedorahosted.org/dropwatch/
I had a chance to crank this up today.
dropwatch is pretty sweet...turns out it's dropping due to bad UDP checksums,
due to the VETH bug/issue where it claims to calculate HW checksum but appearantly does
not actually do so (see previous email in another thread).
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH V2 0/4] Enable bus master till the FLR completes for Chelsio T4
From: Casey Leedom @ 2013-08-08 0:11 UTC (permalink / raw)
To: David Miller
Cc: vipul, linux-pci, bhelgaas, tomreu, divy, dm, nirranjan, eilong,
netdev
In-Reply-To: <20130807.170836.1214269360365516393.davem@davemloft.net>
On 08/07/13 17:08, David Miller wrote:
> From: Vipul Pandya <vipul@chelsio.com>
> Date: Tue, 6 Aug 2013 15:48:35 +0530
>
>> This patch series adds device specific reset method for Chelsio T4 adapters.
>>
>> The series also adds new routine, pci_wait_for_pending_transaction, to wait for
>> pending pci transaction. There are few places where waiting for pending pci
>> transaction code was duplicated. This patch series also replaces occurances of
>> duplicate code.
>>
>> This patch series is built against Bjorn Helgaas pci tree next branch. We would
>> like to merge this series via the same.
>>
>> I have Cced respective maintainers of the modified drivers. Kindly review and
>> let us know in case of any review comments.
> Please push this via the PCI tree, and for the networking bits you can add:
>
> Acked-by: David S. Miller <davem@davemloft.net>
>
> Thanks.
Thanks David. I ~think~ that's covered and we've already gone through
one round of reviews that Bjorn Helgaas graciously provided.
Note that this patch should also obviate the need for the patch which we
attempted to get into the Chelsio T4 network driver cxgb4 several months
ago which monitored the chip for a hang caused by KVM detaching a T4
Virtual Function from a Virtual Machine. You were unhappy with that
patch and requested that we approach the problem differently. Thanks
for your push.
Casey
^ permalink raw reply
* Re: [PATCH] veth: remove hardware checksum feature
From: Eric Dumazet @ 2013-08-08 0:12 UTC (permalink / raw)
To: Ben Greear; +Cc: Vitaly E. Lavrov, netdev, davem
In-Reply-To: <5202E153.4060202@candelatech.com>
On Wed, 2013-08-07 at 17:07 -0700, Ben Greear wrote:
> On 07/25/2013 10:20 AM, Vitaly E. Lavrov wrote:
> > The network device VETH can't support the feature NETIF_F_HW_CSUM.
> > All locally generated packets have invalid checksum.
> > Wrong commit http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8093315a91340bca52549044975d8c7f673b28a1 ( kernel 3.9.0 )
> >
> > Workaround "ethtool -K vethX tx off"
> >
> > Possible patch:
> >
> > diff --git a/drivers/net/veth.c b/drivers/net/veth.c
> > index 177f911..3db97da 100644
> > --- a/drivers/net/veth.c
> > +++ b/drivers/net/veth.c
> > @@ -254,7 +254,7 @@ static const struct net_device_ops veth_netdev_ops = {
> > };
> >
> > #define VETH_FEATURES (NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_ALL_TSO | \
> > - NETIF_F_HW_CSUM | NETIF_F_RXCSUM | NETIF_F_HIGHDMA | \
> > + NETIF_F_RXCSUM | NETIF_F_HIGHDMA | \
> > NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX | \
> > NETIF_F_HW_VLAN_STAG_TX | NETIF_F_HW_VLAN_STAG_RX )
>
> I see the same problem.
>
> My test case is a bit complicated, but the gist is that I have a VETH
> pair, one with IP (veth1), one connected to a bridge-like-thing (veth2).
>
> The UDP frames sent on veth1 appear on veth2, and when I sniff veth2,
> the packets show broken checksum. The work-around mentioned in Vitaly's
> email above fixes the problem for me (I did not try the patch yet).
>
> Eric: You responded originally that you needed more info. If
> my explanation above is not sufficient, please let me know what
> you need...
>
tcpdump is known to display wrong checksums, its not a reason to disable
tx checksums on our interfaces and kill performance.
-K Don't attempt to verify IP, TCP, or UDP checksums. This
is useful for interfaces that perform some or all of those checksum
calculation in hardware; other‐
wise, all outgoing TCP checksums will be flagged as bad.
So we need more information than 'my trcpdump says checksums are wrong'
We could also disable TSO because : It sends packets bigger than MTU,
this can not be good ;)
^ permalink raw reply
* Re: [PATCH net] ipv6: don't stop backtracking in fib6_lookup_1 if subtree does not match
From: David Miller @ 2013-08-08 0:17 UTC (permalink / raw)
To: hannes; +Cc: netdev, teco, yoshfuji, equinox, boutier
In-Reply-To: <20130807003431.GD16410@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Wed, 7 Aug 2013 02:34:31 +0200
> In case a subtree did not match we currently stop backtracking and return
> NULL (root table from fib_lookup). This could yield in invalid routing
> table lookups when using subtrees.
>
> Instead continue to backtrack until a valid subtree or node is found
> and return this match.
>
> Also remove unneeded NULL check.
>
> Reported-by: Teco Boot <teco@inf-net.nl>
> Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> Cc: David Lamparter <equinox@diac24.net>
> Cc: <boutier@pps.univ-paris-diderot.fr>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied and qeued up for -stable, thanks!
^ permalink raw reply
* Re: linux-next: Tree for Aug 7
From: David Miller @ 2013-08-08 0:13 UTC (permalink / raw)
To: sedat.dilek
Cc: phil, eric.dumazet, johannes, sfr, linux-next, linux-kernel,
netdev, hannes, linux-wireless, linville
In-Reply-To: <20130807.170926.319558320779361738.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 07 Aug 2013 17:09:26 -0700 (PDT)
> Ok, I'm going to simply revert all of these changes, thanks for testing.
Here is what I just pushed to net-next:
====================
>From 09effa67a18d893fc4e6f81a3659fc9efef1445e Mon Sep 17 00:00:00 2001
From: "David S. Miller" <davem@davemloft.net>
Date: Wed, 7 Aug 2013 17:11:00 -0700
Subject: [PATCH] packet: Revert recent header parsing changes.
This reverts commits:
0f75b09c798ed00c30d7d5551b896be883bc2aeb
cbd89acb9eb257ed3b2be867142583fdcf7fdc5b
c483e02614551e44ced3fe6eedda8e36d3277ccc
Amongst other things, it's modifies the SKB header
to pull the ethernet headers off via eth_type_trans()
on the output path which is bogus.
It's causing serious regressions for people.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/packet/af_packet.c | 53 ++++++++++++++++++++++--------------------------
1 file changed, 24 insertions(+), 29 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 0c0f6c9..4cb28a7 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -88,7 +88,6 @@
#include <linux/virtio_net.h>
#include <linux/errqueue.h>
#include <linux/net_tstamp.h>
-#include <linux/if_arp.h>
#ifdef CONFIG_INET
#include <net/inet_common.h>
@@ -1924,7 +1923,7 @@ static int tpacket_fill_skb(struct packet_sock *po, struct sk_buff *skb,
__be16 proto, unsigned char *addr, int hlen)
{
union tpacket_uhdr ph;
- int to_write, offset, len, tp_len, nr_frags, len_max, max_frame_len;
+ int to_write, offset, len, tp_len, nr_frags, len_max;
struct socket *sock = po->sk.sk_socket;
struct page *page;
void *data;
@@ -1947,6 +1946,10 @@ static int tpacket_fill_skb(struct packet_sock *po, struct sk_buff *skb,
tp_len = ph.h1->tp_len;
break;
}
+ if (unlikely(tp_len > size_max)) {
+ pr_err("packet size is too long (%d > %d)\n", tp_len, size_max);
+ return -EMSGSIZE;
+ }
skb_reserve(skb, hlen);
skb_reset_network_header(skb);
@@ -2002,25 +2005,10 @@ static int tpacket_fill_skb(struct packet_sock *po, struct sk_buff *skb,
if (unlikely(err))
return err;
- if (dev->type == ARPHRD_ETHER)
- skb->protocol = eth_type_trans(skb, dev);
-
data += dev->hard_header_len;
to_write -= dev->hard_header_len;
}
- max_frame_len = dev->mtu + dev->hard_header_len;
- if (skb->protocol == htons(ETH_P_8021Q))
- max_frame_len += VLAN_HLEN;
-
- if (size_max > max_frame_len)
- size_max = max_frame_len;
-
- if (unlikely(tp_len > size_max)) {
- pr_err("packet size is too long (%d > %d)\n", tp_len, size_max);
- return -EMSGSIZE;
- }
-
offset = offset_in_page(data);
len_max = PAGE_SIZE - offset;
len = ((to_write > len_max) ? len_max : to_write);
@@ -2059,7 +2047,7 @@ static int tpacket_snd(struct packet_sock *po, struct msghdr *msg)
struct net_device *dev;
__be16 proto;
bool need_rls_dev = false;
- int err;
+ int err, reserve = 0;
void *ph;
struct sockaddr_ll *saddr = (struct sockaddr_ll *)msg->msg_name;
int tp_len, size_max;
@@ -2092,6 +2080,8 @@ static int tpacket_snd(struct packet_sock *po, struct msghdr *msg)
if (unlikely(dev == NULL))
goto out;
+ reserve = dev->hard_header_len;
+
err = -ENETDOWN;
if (unlikely(!(dev->flags & IFF_UP)))
goto out_put;
@@ -2099,6 +2089,9 @@ static int tpacket_snd(struct packet_sock *po, struct msghdr *msg)
size_max = po->tx_ring.frame_size
- (po->tp_hdrlen - sizeof(struct sockaddr_ll));
+ if (size_max > dev->mtu + reserve)
+ size_max = dev->mtu + reserve;
+
do {
ph = packet_current_frame(po, &po->tx_ring,
TP_STATUS_SEND_REQUEST);
@@ -2331,20 +2324,22 @@ static int packet_snd(struct socket *sock,
sock_tx_timestamp(sk, &skb_shinfo(skb)->tx_flags);
- if (dev->type == ARPHRD_ETHER) {
- skb->protocol = eth_type_trans(skb, dev);
- if (skb->protocol == htons(ETH_P_8021Q))
- reserve += VLAN_HLEN;
- } else {
- skb->protocol = proto;
- skb->dev = dev;
- }
-
if (!gso_type && (len > dev->mtu + reserve + extra_len)) {
- err = -EMSGSIZE;
- goto out_free;
+ /* Earlier code assumed this would be a VLAN pkt,
+ * double-check this now that we have the actual
+ * packet in hand.
+ */
+ struct ethhdr *ehdr;
+ skb_reset_mac_header(skb);
+ ehdr = eth_hdr(skb);
+ if (ehdr->h_proto != htons(ETH_P_8021Q)) {
+ err = -EMSGSIZE;
+ goto out_free;
+ }
}
+ skb->protocol = proto;
+ skb->dev = dev;
skb->priority = sk->sk_priority;
skb->mark = sk->sk_mark;
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH RFC 0/5] netfilter: implement netfilter SYN proxy
From: Patrick McHardy @ 2013-08-08 0:13 UTC (permalink / raw)
To: David Miller, eric.dumazet, pablo, netfilter-devel, netdev, mph,
jesper.brouer, as
In-Reply-To: <20130808000412.GF32257@order.stressinduktion.org>
On Thu, Aug 08, 2013 at 02:04:12AM +0200, Hannes Frederic Sowa wrote:
> On Wed, Aug 07, 2013 at 04:40:56PM -0700, David Miller wrote:
> > From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> > Date: Wed, 7 Aug 2013 23:05:40 +0200
> >
> > > It seems, Windows stopped using tcp timestamps at least in windows 8 by
> > > default.
> >
> > Thankfully, Android device outnumber Windows 8 installs
> > by... something like 1,000 to 1, right?
>
> Heh, at minimum. :)
>
> > I throw a huge "doesn't matter" to whatever Windows's TCP stack
> > decides to do. It absolutely should not dictate whether we decide to
> > make use of this or that feature of TCP. It's a bit player at best.
> >
> > So if Windows 8 is the reason you're saying we shouldn't use
> > timestamps for anything, you're wrong.
>
> Actually, I don't care at all, because I don't do anything with windows
> and don't get paid by anyone who wants me to care. ;)
>
> But if we switch to a similar scheme as freebsd we can even care
> less because even if some other operating systems or a major provider
> decides to disable timestamps on their devices, we would still have
> window scaling, sack (and ecn?) under syn dos. So, I do think it is an
> improvement and don't see any disadvantages.
>
> So, I don't care as long as the change (and siphash or maybe another
> hashing scheme) is secure enough...
So maybe lets agree to this - we all don't care about Windows 8, but
more importantly, I'd prefer to do one thing at a time and cryptographic
hashing isn't exactly my area of expertise. So lets get these patches
in order and after that I'll look into making SYN cookies perform better
for the poor souls using Windows 8, if that's possible without using
timestamps ;)
^ permalink raw reply
* Re: [PATCH] veth: remove hardware checksum feature
From: Ben Greear @ 2013-08-08 0:23 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Vitaly E. Lavrov, netdev, davem
In-Reply-To: <1375920752.4004.71.camel@edumazet-glaptop>
On 08/07/2013 05:12 PM, Eric Dumazet wrote:
> On Wed, 2013-08-07 at 17:07 -0700, Ben Greear wrote:
>> On 07/25/2013 10:20 AM, Vitaly E. Lavrov wrote:
>>> The network device VETH can't support the feature NETIF_F_HW_CSUM.
>>> All locally generated packets have invalid checksum.
>>> Wrong commit http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8093315a91340bca52549044975d8c7f673b28a1 ( kernel 3.9.0 )
>>>
>>> Workaround "ethtool -K vethX tx off"
>>>
>>> Possible patch:
>>>
>>> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
>>> index 177f911..3db97da 100644
>>> --- a/drivers/net/veth.c
>>> +++ b/drivers/net/veth.c
>>> @@ -254,7 +254,7 @@ static const struct net_device_ops veth_netdev_ops = {
>>> };
>>>
>>> #define VETH_FEATURES (NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_ALL_TSO | \
>>> - NETIF_F_HW_CSUM | NETIF_F_RXCSUM | NETIF_F_HIGHDMA | \
>>> + NETIF_F_RXCSUM | NETIF_F_HIGHDMA | \
>>> NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX | \
>>> NETIF_F_HW_VLAN_STAG_TX | NETIF_F_HW_VLAN_STAG_RX )
>>
>> I see the same problem.
>>
>> My test case is a bit complicated, but the gist is that I have a VETH
>> pair, one with IP (veth1), one connected to a bridge-like-thing (veth2).
>>
>> The UDP frames sent on veth1 appear on veth2, and when I sniff veth2,
>> the packets show broken checksum. The work-around mentioned in Vitaly's
>> email above fixes the problem for me (I did not try the patch yet).
>>
>> Eric: You responded originally that you needed more info. If
>> my explanation above is not sufficient, please let me know what
>> you need...
>>
>
> tcpdump is known to display wrong checksums, its not a reason to disable
> tx checksums on our interfaces and kill performance.
I am receiving the packet into user space by reading veth2
using a packet socket, and then writing that packet out to eth6
(e100e). As far as I can tell, it reads from veth2 with bad checksum
and then goes onto the wire with bad checksum.
> -K Don't attempt to verify IP, TCP, or UDP checksums. This
> is useful for interfaces that perform some or all of those checksum
> calculation in hardware; other‐
> wise, all outgoing TCP checksums will be flagged as bad.
Is it ever valid to *read* a packet with bad checksum though? I thought
the bogus bad hw-checksum issue was only on the tx-side as far as sniffing goes?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2.35 6/6] datapath: Add basic MPLS support to kernel
From: Jesse Gross @ 2013-08-08 0:39 UTC (permalink / raw)
To: Simon Horman
Cc: dev@openvswitch.org, netdev, Ravi K, Isaku Yamahata,
Pravin B Shelar, Jarno Rajahalme, Joe Stringer
In-Reply-To: <1374289623-17056-7-git-send-email-horms@verge.net.au>
On Fri, Jul 19, 2013 at 8:07 PM, Simon Horman <horms@verge.net.au> wrote:
> diff --git a/datapath/actions.c b/datapath/actions.c
> index 0a2def6..99e02cf 100644
> --- a/datapath/actions.c
> +++ b/datapath/actions.c
> +/* The end of the mac header.
> + *
> + * For non-MPLS skbs this will correspond to the network header.
> + * For MPLS skbs it will be berfore the network_header as the MPLS
> + * label stack lies between the end of the mac header and the network
> + * header. That is, for MPLS skbs the end of the mac header
> + * is the top of the MPLS label stack.
> + */
> +static unsigned char *mac_header_end(const struct sk_buff *skb)
> +{
> + return skb_mac_header(skb) + skb->mac_len;
> +}
> +
> +static void set_ethertype(struct sk_buff *skb, __be16 ethertype, bool inner)
> +{
> + struct ethhdr *hdr;
> + if (inner)
> + /* mac_header_end() is used to locate the ethertype
> + * field correctly in the presence of VLAN tags. */
> + hdr = (struct ethhdr *)(mac_header_end(skb) - ETH_HLEN);
> + else
> + hdr = (struct ethhdr *)(skb_mac_header(skb));
> + hdr->h_proto = ethertype;
> +}
> +
> +/* Push MPLS after the ethernet header. We blindly ignore any other tags,
> + * assuming that actions are ordered correctly. */
> +static int push_mpls(struct sk_buff *skb,
> + const struct ovs_action_push_mpls *mpls)
> +{
> + __be32 *new_mpls_lse;
> + int err;
> +
> + if (skb_cow_head(skb, MPLS_HLEN) < 0)
> + return -ENOMEM;
> +
> + err = make_writable(skb, skb->mac_len);
> + if (unlikely(err))
> + return err;
> +
> + skb_push(skb, MPLS_HLEN);
> + memmove(skb_mac_header(skb) - MPLS_HLEN, skb_mac_header(skb),
> + ETH_HLEN);
> + skb_reset_mac_header(skb);
> +
> + new_mpls_lse = (__be32 *)(skb_mac_header(skb) + ETH_HLEN);
> + *new_mpls_lse = mpls->mpls_lse;
> +
> + if (get_ip_summed(skb) == OVS_CSUM_COMPLETE)
> + skb->csum = csum_add(skb->csum, csum_partial(new_mpls_lse,
> + MPLS_HLEN, 0));
> +
> + set_ethertype(skb, mpls->mpls_ethertype, false);
> + if (skb->protocol != htons(ETH_P_8021Q))
> + skb->protocol = mpls->mpls_ethertype;
It seems to me that there is a fair amount of stuff left over from
before the tag ordering conversion. For example, shouldn't we set the
EtherType unconditionally now if we are pushing tags onto the front?
Do we still need to dig into the packet to find the last EtherType if
we are now working on the outer tag? How does this interact with vlan
offloading, etc.?
^ permalink raw reply
* Re: [PATCH] veth: remove hardware checksum feature
From: Eric Dumazet @ 2013-08-08 1:08 UTC (permalink / raw)
To: Ben Greear; +Cc: Vitaly E. Lavrov, netdev, davem
In-Reply-To: <5202E510.9060309@candelatech.com>
On Wed, 2013-08-07 at 17:23 -0700, Ben Greear wrote:
> I am receiving the packet into user space by reading veth2
> using a packet socket, and then writing that packet out to eth6
> (e100e). As far as I can tell, it reads from veth2 with bad checksum
> and then goes onto the wire with bad checksum.
>
Then, when you read the packet socket, you probably have an indication
that checksum is to be computed or ignored.
Your application breaks because of this.
If forwarding was done by the kernel, the checksum would be filled
either by hardware, or core network helpers.
> Is it ever valid to *read* a packet with bad checksum though? I thought
> the bogus bad hw-checksum issue was only on the tx-side as far as sniffing goes?
We have same flags on loopback interface.
So using your application on loopback should break the same ?
I am not saying your application is buggy, maybe we need a helper in
net/packet/af_packet.c. Please check TP_STATUS_CSUMNOTREADY
This was added 6 years ago in commit 8dc4194474159660
("[PACKET]: Add optional checksum computation for recvmsg")
^ permalink raw reply
* Re: [Patch net-next v2 5/8] sunrpc: use generic union inet_addr
From: Cong Wang @ 2013-08-08 1:37 UTC (permalink / raw)
To: Jeff Layton
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller, Trond Myklebust,
J. Bruce Fields, linux-nfs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20130807092123.451e93db-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
On Wed, 2013-08-07 at 09:21 -0400, Jeff Layton wrote:
> Ok, good point. That does look cleaner. I'd still like to see the rpc_*
> wrappers go away, but that can be done later.
>
I will move the wrappers to generic since several people asked.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 00/11] Add namespace support for syslog
From: Gao feng @ 2013-08-08 1:37 UTC (permalink / raw)
To: Eric W. Biederman
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
libo.chen-hv44wF8Li93QT0dZR+AlfA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
guz.fnst-BthXqXjhjHXQFUHtdCDX3A,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
In-Reply-To: <878v0evssv.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
On 08/07/2013 03:55 PM, Eric W. Biederman wrote:
>
> Since this still has not been addressed. I am going to repeat Andrews
> objection again.
>
> Isn't there a better way to get iptables information out than to use
> syslog. I did not have time to follow up on that but it did appear that
> someone did have a better way to get the information out.
>
> Essentially the argument against this goes. The kernel logging facility
> is really not a particularly good tool to be using for anything other
> than kernel debugging information, and there appear to be no substantial
> uses for a separate syslog that should not be done in other ways.
containerizing syslog is not only for iptables, it also isolates the /dev/kmsg,
/proc/kmsg, syslog(2)... user space tools in container may use this interface
to read/generate syslog.
But I don't know how important/urgent this containerizing syslog work is,
Rui Xiang, can you find an important/popular user space tool which uses this
interfaces to generate kernel syslog?
Thanks
Gao
^ permalink raw reply
* Re: [PATCH] veth: remove hardware checksum feature
From: Ben Greear @ 2013-08-08 1:54 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Vitaly E. Lavrov, netdev, davem
In-Reply-To: <1375924125.4004.83.camel@edumazet-glaptop>
On 08/07/2013 06:08 PM, Eric Dumazet wrote:
> On Wed, 2013-08-07 at 17:23 -0700, Ben Greear wrote:
>
>> I am receiving the packet into user space by reading veth2
>> using a packet socket, and then writing that packet out to eth6
>> (e100e). As far as I can tell, it reads from veth2 with bad checksum
>> and then goes onto the wire with bad checksum.
>>
>
> Then, when you read the packet socket, you probably have an indication
> that checksum is to be computed or ignored.
My user-space bridge code doesn't know or care about the checksum, it
is just reading a packet from one interface and writing onto another.
>
> Your application breaks because of this.
>> Is it ever valid to *read* a packet with bad checksum though? I thought
>> the bogus bad hw-checksum issue was only on the tx-side as far as sniffing goes?
>
> We have same flags on loopback interface.
>
> So using your application on loopback should break the same ?
I suppose, I have never tried to bridge loopback, and probably won't
try anytime soon.
> I am not saying your application is buggy, maybe we need a helper in
> net/packet/af_packet.c. Please check TP_STATUS_CSUMNOTREADY
>
> This was added 6 years ago in commit 8dc4194474159660
> ("[PACKET]: Add optional checksum computation for recvmsg")
Hmm, I'm using recmmsg, in case that matters. I'm not sure I really
understand that patch well. It looks like it requires user-space changes?
I'd rather not have to deal with calculating checksums just to bridge
two interfaces...if it comes to that, I'd rather just force a disable
of the HW checksum feature using ethtool when my app is configured in
this manner.
Maybe we should just do the csum calc in the kernel if packet is
about to be sent up to user-space via af_packet? I think that
would keep the expected behaviour, and hopefully not loose any of the performance
benefits for cases where the packet never leaves the kernel?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] veth: remove hardware checksum feature
From: Eric Dumazet @ 2013-08-08 2:52 UTC (permalink / raw)
To: Ben Greear; +Cc: Vitaly E. Lavrov, netdev, davem
In-Reply-To: <5202FA51.4040906@candelatech.com>
On Wed, 2013-08-07 at 18:54 -0700, Ben Greear wrote:
> Maybe we should just do the csum calc in the kernel if packet is
> about to be sent up to user-space via af_packet? I think that
> would keep the expected behaviour, and hopefully not loose any of the performance
> benefits for cases where the packet never leaves the kernel?
I think you are rephrasing what I suggested ;)
I'll send a patch asap, unless someone beats me.
^ permalink raw reply
* Re: skbs delivered to 'wrong' packet_type handler
From: Ying Xue @ 2013-08-08 2:21 UTC (permalink / raw)
To: Erik Hugne; +Cc: Eric Dumazet, netdev, tipc-discussion, jon.maloy
In-Reply-To: <20130807155746.GA16408@eerihug-hybrid.rnd.ki.sw.ericsson.se>
On 08/07/2013 11:57 PM, Erik Hugne wrote:
> On Wed, Aug 07, 2013 at 06:55:43AM -0700, Eric Dumazet wrote:
>> Its not ignored, quite the contrary if you look at the code :
>>
>> vi +3595 net/core/dev.c
>>
>> type = skb->protocol;
>> list_for_each_entry_rcu(ptype,
>> &ptype_base[ntohs(type) & PTYPE_HASH_MASK], list) {
>> if (ptype->type == type &&
>> (ptype->dev == null_or_dev || ptype->dev == skb->dev ||
>> ptype->dev == orig_dev)) {
>> if (pt_prev)
>> ret = deliver_skb(skb, pt_prev, orig_dev);
>> pt_prev = ptype;
>> }
>> }
>>
>>
>> pkt->dev being set is only meaningful for packet sockets.
>>
>> Protocols themselves should not care. If they want to care, they must
>> add their own checks.
>>
>> Socket API has SO_BINDTODEVICE for this purpose.
>> IP layer has RP filtering.
>>
>> A protocol should register a single ptype with NULL dev.
>>
>
> Very well, we'll have to fix the protocol registration and add appropriate
> checks in TIPC then.
Currently the usage of what TIPC registers its protocol handler into
networking device is totally wrong because af_packet_priv in packet_type
should be only owned by AF_PACKET socket as well as ptype->dev is set
with a network device. But I am sure the patch in below link can
definitely fix your met issue although it's not a final version to be
submitted net-next:
http://permalink.gmane.org/gmane.network.tipc.general/4159
Regards,
Ying
> But i fail to understand why a handler registered on the native device needs
> to get the packets destined to a child vlan device (the ptype->dev == orig_dev
> check).
>
> //E
>
>
>
^ permalink raw reply
* Preferred method for configuration
From: Thomas Martitz @ 2013-08-08 5:32 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hello,
I'm developing a NIC driver and currently export some custom
configuration settings and actions (e.g. enabling a loopback mode) via
sysfs. However I read about ioctl() and configfs and am now confused as
to what the preferred/expected method is for new drivers.
Best regards.
^ permalink raw reply
* Re: BUG cxgb3: Check and handle the dma mapping errors
From: Alexey Kardashevskiy @ 2013-08-08 5:38 UTC (permalink / raw)
To: Divy Le ray
Cc: Jay Fenlason, Santosh Rastapur, David S. Miller,
netdev@vger.kernel.org, Linux Kernel Mailing List
In-Reply-To: <52027BEF.5040602@chelsio.com>
[-- Attachment #1: Type: text/plain, Size: 3477 bytes --]
On 08/08/2013 02:55 AM, Divy Le ray wrote:
> On 08/05/2013 11:41 AM, Jay Fenlason wrote:
>> On Mon, Aug 05, 2013 at 12:59:04PM +1000, Alexey Kardashevskiy wrote:
>>> Hi!
>>>
>>> Recently I started getting multiple errors like this:
>>>
>>> cxgb3 0006:01:00.0: iommu_alloc failed, tbl c000000003067980 vaddr
>>> c000001fbdaaa882 npages 1
>>> cxgb3 0006:01:00.0: iommu_alloc failed, tbl c000000003067980 vaddr
>>> c000001fbdaaa882 npages 1
>>> cxgb3 0006:01:00.0: iommu_alloc failed, tbl c000000003067980 vaddr
>>> c000001fbdaaa882 npages 1
>>> cxgb3 0006:01:00.0: iommu_alloc failed, tbl c000000003067980 vaddr
>>> c000001fbdaaa882 npages 1
>>> cxgb3 0006:01:00.0: iommu_alloc failed, tbl c000000003067980 vaddr
>>> c000001fbdaaa882 npages 1
>>> cxgb3 0006:01:00.0: iommu_alloc failed, tbl c000000003067980 vaddr
>>> c000001fbdaaa882 npages 1
>>> cxgb3 0006:01:00.0: iommu_alloc failed, tbl c000000003067980 vaddr
>>> c000001fbdaaa882 npages 1
>>> ... and so on
>>>
>>> This is all happening on a PPC64 "powernv" platform machine. To trigger the
>>> error state, it is enough to _flood_ ping CXGB3 card from another machine
>>> (which has Emulex 10Gb NIC + Cisco switch). Just do "ping -f 172.20.1.2"
>>> and wait 10-15 seconds.
>>>
>>>
>>> The messages are coming from arch/powerpc/kernel/iommu.c and basically
>>> mean that the driver requested more pages than the DMA window has which is
>>> normally 1GB (there could be another possible source of errors -
>>> ppc_md.tce_build callback - but on powernv platform it always succeeds).
>>>
>>>
>>> The patch after which it broke is:
>>> commit f83331bab149e29fa2c49cf102c0cd8c3f1ce9f9
>>> Author: Santosh Rastapur <santosh@chelsio.com>
>>> Date: Tue May 21 04:21:29 2013 +0000
>>> cxgb3: Check and handle the dma mapping errors
>>>
>>> Any quick ideas? Thanks!
>> That patch adds error checking to detect failed dma mapping requests.
>> Before it, the code always assumed that dma mapping requests succeded,
>> whether they actually do or not, so the fact that the older kernel
>> does not log errors only means that the failures are being ignored,
>> and any appearance of working is through pure luck. The machine could
>> have just crashed at that point.
>>
>> What is the observed behavior of the system by the machine initiating
>> the ping flood? Do the older and newer kernels differ in the
>> percentage of pings that do not receive replies? O the newer kernel,
>> when the mapping errors are detected, the packet that it is trying to
>> transmit is dropped, but I'm not at all sure what happens on the older
>> kernel after the dma mapping fails. As I mentioned earlier, I'm
>> surprised it does not crash. Perhaps the folks from Chelsio have a
>> better idea what happens after a dma mapping error is ignored?
>
> Hi,
>
> It should definitely not be ignored. It should not happen this reliably
> either.
> I wonder if we are not hitting a leak of iommu entries.
Yes we do. I did some more tests with socklib from here
http://junkcode.samba.org/ftp/unpacked/junkcode/socklib/
The test is basically sock_source sending packets to sock_sink. If block
size is >=512 bytes, there is no leak, if I set packet size to <=256 bytes,
it starts leaking, smaller block size means faster leak. The type of the
other adapter does not really matter, can be the same Emulex adapter.
I am attaching a small patch which I made in order to detect the leak.
Without the patch, no leak happens, I double checked.
--
Alexey
[-- Attachment #2: cxgb3_debug.patch --]
[-- Type: text/x-patch, Size: 5126 bytes --]
commit 8327d4ca1d63a96454897ef7e5603bf78c9a76c5
Author: Alexey Kardashevskiy <aik@ozlabs.ru>
AuthorDate: Thu Aug 8 15:33:55 2013 +1000
Commit: Alexey Kardashevskiy <aik@ozlabs.ru>
CommitDate: Thu Aug 8 15:33:55 2013 +1000
cxgb3: debug patch
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
diff --git a/drivers/net/ethernet/chelsio/cxgb3/sge.c b/drivers/net/ethernet/chelsio/cxgb3/sge.c
index 687ec4a..4165c0b 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/sge.c
@@ -46,6 +46,15 @@
#include "firmware_exports.h"
#include "cxgb3_offload.h"
+
+unsigned long _cxgb3_maps, _cxgb3_unmaps;
+#define _FLUSH() printk("+%lu -%lu diff=%lu\n", _cxgb3_maps, _cxgb3_unmaps, _cxgb3_maps - _cxgb3_unmaps)
+#define _INC(n) _cxgb3_maps += (n); if (printk_ratelimit()) _FLUSH()
+#define _DEC(n) _cxgb3_unmaps += (n); if (printk_ratelimit()) _FLUSH()
+static int backtraced = 0;
+#define _CXBUG() _FLUSH(); if (!backtraced) { dump_stack(); backtraced = 1; }
+
+
#define USE_GTS 0
#define SGE_RX_SM_BUF_SIZE 1536
@@ -246,6 +255,7 @@ static inline void unmap_skb(struct sk_buff *skb, struct sge_txq *q,
if (frag_idx == 0 && skb_headlen(skb)) {
pci_unmap_single(pdev, be64_to_cpu(sgp->addr[0]),
skb_headlen(skb), PCI_DMA_TODEVICE);
+ _DEC(1);
j = 1;
}
@@ -256,6 +266,7 @@ static inline void unmap_skb(struct sk_buff *skb, struct sge_txq *q,
pci_unmap_page(pdev, be64_to_cpu(sgp->addr[j]),
skb_frag_size(&skb_shinfo(skb)->frags[frag_idx]),
PCI_DMA_TODEVICE);
+ _DEC(1);
j ^= 1;
if (j == 0) {
sgp++;
@@ -355,15 +366,19 @@ static void clear_rx_desc(struct pci_dev *pdev, const struct sge_fl *q,
if (q->use_pages && d->pg_chunk.page) {
(*d->pg_chunk.p_cnt)--;
if (!*d->pg_chunk.p_cnt)
+ {
pci_unmap_page(pdev,
d->pg_chunk.mapping,
q->alloc_size, PCI_DMA_FROMDEVICE);
+ _DEC(1);
+ }
put_page(d->pg_chunk.page);
d->pg_chunk.page = NULL;
} else {
pci_unmap_single(pdev, dma_unmap_addr(d, dma_addr),
q->buf_size, PCI_DMA_FROMDEVICE);
+ _DEC(1);
kfree_skb(d->skb);
d->skb = NULL;
}
@@ -416,7 +431,11 @@ static inline int add_one_rx_buf(void *va, unsigned int len,
mapping = pci_map_single(pdev, va, len, PCI_DMA_FROMDEVICE);
if (unlikely(pci_dma_mapping_error(pdev, mapping)))
+ {
+ _CXBUG();
return -ENOMEM;
+ }
+ _INC(1);
dma_unmap_addr_set(sd, dma_addr, mapping);
@@ -458,8 +477,10 @@ static int alloc_pg_chunk(struct adapter *adapter, struct sge_fl *q,
if (unlikely(pci_dma_mapping_error(adapter->pdev, mapping))) {
__free_pages(q->pg_chunk.page, order);
q->pg_chunk.page = NULL;
+ _CXBUG();
return -EIO;
}
+ _INC(1);
q->pg_chunk.mapping = mapping;
}
sd->pg_chunk = q->pg_chunk;
@@ -816,6 +837,7 @@ recycle:
use_orig_buf:
pci_unmap_single(adap->pdev, dma_unmap_addr(sd, dma_addr),
fl->buf_size, PCI_DMA_FROMDEVICE);
+ _DEC(1);
skb = sd->skb;
skb_put(skb, len);
__refill_fl(adap, fl);
@@ -887,10 +909,13 @@ recycle:
PCI_DMA_FROMDEVICE);
(*sd->pg_chunk.p_cnt)--;
if (!*sd->pg_chunk.p_cnt && sd->pg_chunk.page != fl->pg_chunk.page)
+ {
pci_unmap_page(adap->pdev,
sd->pg_chunk.mapping,
fl->alloc_size,
PCI_DMA_FROMDEVICE);
+ _DEC(1);
+ }
if (!skb) {
__skb_put(newskb, SGE_RX_PULL_LEN);
memcpy(newskb->data, sd->pg_chunk.va, SGE_RX_PULL_LEN);
@@ -972,7 +997,7 @@ static int map_skb(struct pci_dev *pdev, const struct sk_buff *skb,
PCI_DMA_TODEVICE);
if (pci_dma_mapping_error(pdev, *addr))
goto out_err;
-
+ _INC(1);
si = skb_shinfo(skb);
end = &si->frags[si->nr_frags];
@@ -981,16 +1006,23 @@ static int map_skb(struct pci_dev *pdev, const struct sk_buff *skb,
DMA_TO_DEVICE);
if (pci_dma_mapping_error(pdev, *addr))
goto unwind;
+ _INC(1);
}
return 0;
unwind:
+ _CXBUG();
while (fp-- > si->frags)
+ {
dma_unmap_page(&pdev->dev, *--addr, skb_frag_size(fp),
DMA_TO_DEVICE);
+ _DEC(1);
+ }
pci_unmap_single(pdev, addr[-1], skb_headlen(skb), PCI_DMA_TODEVICE);
+ _DEC(1);
out_err:
+ _CXBUG();
return -ENOMEM;
}
@@ -1584,13 +1616,18 @@ static void deferred_unmap_destructor(struct sk_buff *skb)
p = dui->addr;
if (skb_tail_pointer(skb) - skb_transport_header(skb))
+ {
pci_unmap_single(dui->pdev, *p++, skb_tail_pointer(skb) -
skb_transport_header(skb), PCI_DMA_TODEVICE);
-
+ _DEC(1);
+ }
si = skb_shinfo(skb);
for (i = 0; i < si->nr_frags; i++)
+ {
pci_unmap_page(dui->pdev, *p++, skb_frag_size(&si->frags[i]),
PCI_DMA_TODEVICE);
+ _DEC(1);
+ }
}
static void setup_deferred_unmapping(struct sk_buff *skb, struct pci_dev *pdev,
@@ -2143,11 +2180,13 @@ static void lro_add_page(struct adapter *adap, struct sge_qset *qs,
(*sd->pg_chunk.p_cnt)--;
if (!*sd->pg_chunk.p_cnt && sd->pg_chunk.page != fl->pg_chunk.page)
+ {
pci_unmap_page(adap->pdev,
sd->pg_chunk.mapping,
fl->alloc_size,
PCI_DMA_FROMDEVICE);
-
+ _DEC(1);
+ }
if (!skb) {
put_page(sd->pg_chunk.page);
if (complete)
^ permalink raw reply related
* Re: Preferred method for configuration
From: Joe Perches @ 2013-08-08 5:41 UTC (permalink / raw)
To: Thomas Martitz; +Cc: netdev@vger.kernel.org
In-Reply-To: <52032D5E.6070307@hhi.fraunhofer.de>
On Thu, 2013-08-08 at 07:32 +0200, Thomas Martitz wrote:
> Hello,
>
> I'm developing a NIC driver and currently export some custom
> configuration settings and actions (e.g. enabling a loopback mode) via
> sysfs.
Is there some reason you don't want to use ethtool?
^ permalink raw reply
* Re: Preferred method for configuration
From: Thomas Martitz @ 2013-08-08 5:56 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev@vger.kernel.org
In-Reply-To: <1375940480.2424.135.camel@joe-AO722>
Resent with list in CC.
Am 08.08.2013 07:41, schrieb Joe Perches:
> On Thu, 2013-08-08 at 07:32 +0200, Thomas Martitz wrote:
>> Hello,
>>
>> I'm developing a NIC driver and currently export some custom
>> configuration settings and actions (e.g. enabling a loopback mode) via
>> sysfs.
>
> Is there some reason you don't want to use ethtool?
>
>
It doesn't allow for custom settings does it? For standards stuff I'm
sure going to use ethtool.
Best regards.
^ permalink raw reply
* Re: [PATCH net-next] net: sctp: sctp_set_owner_w: fix panic during skb orphaning
From: Neil Horman @ 2013-08-08 5:57 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev, linux-sctp
In-Reply-To: <1375872121-12429-1-git-send-email-dborkman@redhat.com>
On Wed, Aug 07, 2013 at 12:42:01PM +0200, Daniel Borkmann wrote:
> This patch fixes the following triggered bug ...
>
> [ 553.109742] kernel BUG at include/linux/skbuff.h:1813!
> [ 553.109766] invalid opcode: 0000 [#1] SMP
> [ 553.109789] Modules linked in: sctp libcrc32c rfcomm [...]
> [ 553.110259] uinput i915 i2c_algo_bit drm_kms_helper e1000e drm ptp pps_core i2c_core wmi video sunrpc
> [ 553.110320] CPU: 0 PID: 1636 Comm: lt-test_1_to_1_ Not tainted 3.11.0-rc3+ #2
> [ 553.110350] Hardware name: LENOVO 74597D6/74597D6, BIOS 6DET60WW (3.10 ) 09/17/2009
> [ 553.110381] task: ffff88020a01dd40 ti: ffff880204ed0000 task.ti: ffff880204ed0000
> [ 553.110411] RIP: 0010:[<ffffffffa0698017>] [<ffffffffa0698017>] skb_orphan.part.9+0x4/0x6 [sctp]
> [ 553.110459] RSP: 0018:ffff880204ed1bb8 EFLAGS: 00010286
> [ 553.110483] RAX: ffff8802086f5a40 RBX: ffff880204303300 RCX: 0000000000000000
> [ 553.110487] RDX: ffff880204303c28 RSI: ffff8802086f5a40 RDI: ffff880202158000
> [ 553.110487] RBP: ffff880204ed1bb8 R08: 0000000000000000 R09: 0000000000000000
> [ 553.110487] R10: ffff88022f2d9a04 R11: ffff880233001600 R12: 0000000000000000
> [ 553.110487] R13: ffff880204303c00 R14: ffff8802293d0000 R15: ffff880202158000
> [ 553.110487] FS: 00007f31b31fe740(0000) GS:ffff88023bc00000(0000) knlGS:0000000000000000
> [ 553.110487] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 553.110487] CR2: 000000379980e3e0 CR3: 000000020d225000 CR4: 00000000000407f0
> [ 553.110487] Stack:
> [ 553.110487] ffff880204ed1ca8 ffffffffa068d7fc 0000000000000000 0000000000000000
> [ 553.110487] 0000000000000000 ffff8802293d0000 ffff880202158000 ffffffff81cb7900
> [ 553.110487] 0000000000000000 0000400000001c68 ffff8802086f5a40 000000000000000f
> [ 553.110487] Call Trace:
> [ 553.110487] [<ffffffffa068d7fc>] sctp_sendmsg+0x6bc/0xc80 [sctp]
> [ 553.110487] [<ffffffff8128f185>] ? sock_has_perm+0x75/0x90
> [ 553.110487] [<ffffffff815a3593>] inet_sendmsg+0x63/0xb0
> [ 553.110487] [<ffffffff8128f2b3>] ? selinux_socket_sendmsg+0x23/0x30
> [ 553.110487] [<ffffffff8151c5d6>] sock_sendmsg+0xa6/0xd0
> [ 553.110487] [<ffffffff81637b05>] ? _raw_spin_unlock_bh+0x15/0x20
> [ 553.110487] [<ffffffff8151cd38>] SYSC_sendto+0x128/0x180
> [ 553.110487] [<ffffffff8151ce6b>] ? SYSC_connect+0xdb/0x100
> [ 553.110487] [<ffffffffa0690031>] ? sctp_inet_listen+0x71/0x1f0 [sctp]
> [ 553.110487] [<ffffffff8151d35e>] SyS_sendto+0xe/0x10
> [ 553.110487] [<ffffffff81640202>] system_call_fastpath+0x16/0x1b
> [ 553.110487] Code: e0 48 c7 c7 00 22 6a a0 e8 67 a3 f0 e0 48 c7 [...]
> [ 553.110487] RIP [<ffffffffa0698017>] skb_orphan.part.9+0x4/0x6 [sctp]
> [ 553.110487] RSP <ffff880204ed1bb8>
> [ 553.121578] ---[ end trace 46c20c5903ef5be2 ]---
>
> ... that is triggered after commit 376c7311b ("net: add a temporary sanity
> check in skb_orphan()"). What is happening is that we call sctp_set_owner_w()
> for chunks in the SCTP output path from sctp_sendmsg(). Such chunks eventually
> origin from constructors like sctp_make_chunk() where skb->sk = sk is being
> set for socket accounting. Doing a git grep -n "skb->sk" net/sctp/ shows that
> also in other places the socket pointer is being set, before issuing a
> SCTP_CMD_SEND_PKT command and the like. Since SCTP is doing it's own memory
> accounting anyway and has its own skb destructor functions, we should
> customize sctp_set_owner_w() and call skb_orphan() if we set a different
> owner of the skb than the current one in order to properly call their
> destructor function, but not run into a panic due to our non-exisiting one as
> we set sctp_wfree() destructor right after that. Otherwise, we can just skip
> orphaning and reassignment to the very same socket and only set the destructor
> handler.
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> ---
> Only in net-next.
>
> net/sctp/socket.c | 16 +++++++++++-----
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index d5d5882..7459b6c 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -153,13 +153,18 @@ static inline void sctp_set_owner_w(struct sctp_chunk *chunk)
> {
> struct sctp_association *asoc = chunk->asoc;
> struct sock *sk = asoc->base.sk;
> + struct sk_buff *skb = chunk->skb;
>
> /* The sndbuf space is tracked per association. */
> sctp_association_hold(asoc);
>
> - skb_set_owner_w(chunk->skb, sk);
> + if (skb->sk != sk) {
> + skb_orphan(skb);
> + skb->sk = sk;
> + }
> +
> + skb->destructor = sctp_wfree;
>
> - chunk->skb->destructor = sctp_wfree;
> /* Save the chunk pointer in skb for sctp_wfree to use later. */
> *((struct sctp_chunk **)(chunk->skb->cb)) = chunk;
>
> @@ -167,9 +172,10 @@ static inline void sctp_set_owner_w(struct sctp_chunk *chunk)
> sizeof(struct sk_buff) +
> sizeof(struct sctp_chunk);
>
> - atomic_add(sizeof(struct sctp_chunk), &sk->sk_wmem_alloc);
> - sk->sk_wmem_queued += chunk->skb->truesize;
> - sk_mem_charge(sk, chunk->skb->truesize);
> + atomic_add(sizeof(struct sctp_chunk) + skb->truesize,
> + &sk->sk_wmem_alloc);
> + sk->sk_wmem_queued += skb->truesize;
> + sk_mem_charge(sk, skb->truesize);
> }
>
> /* Verify that this is a valid address. */
> --
> 1.7.11.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH 3/5] netfilter: add SYNPROXY core/target
From: Patrick McHardy @ 2013-08-08 6:22 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: pablo, netfilter-devel, netdev, mph, as
In-Reply-To: <20130807205602.GA21463@macbook.localnet>
On Wed, Aug 07, 2013 at 10:56:03PM +0200, Patrick McHardy wrote:
> On Wed, Aug 07, 2013 at 10:26:00PM +0200, Jesper Dangaard Brouer wrote:
> > On Wed, 7 Aug 2013 19:42:49 +0200
> > Patrick McHardy <kaber@trash.net> wrote:
> >
> > Besides when using net->proc_net_stat, then the first entry is usually
> > "entries" which is not percpu, this will likely confusing the tool:
> > lnstat -f synproxy -c 42
>
> I'll look into that.
Ok right, the first field must contains something that is not per-CPU.
Unfortunately I don't have anything to put there and I really don't want
to keep any global state. The two possibilities I see are:
- a dummy field
- the number of proxied connections, but not using a global counter but
gathered by iterating over the entire conntrack hash.
Any opinions?
^ 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