* Re: Lower wake up time when phy enter lower mode
From: Frank Li @ 2012-11-08 2:09 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Richard Cochran, netdev
In-Reply-To: <1352315183.2725.17.camel@bwh-desktop.uk.solarflarecom.com>
2012/11/8 Ben Hutchings <bhutchings@solarflare.com>:
> On Wed, 2012-11-07 at 10:52 +0800, Frank Li wrote:
>> Richard:
>>
>> Recently, I found out the path delay will increase about
>> 20us suddenly in something when connect two iMX6 board and Ethernet
>> work on 1G mode.
>> The reason is that the PHY enter lower mode automatically
>> when no package send and receive. It takes some time to recover and
>> send out package by PHY but MAC think package have sent and sample
>> time stamper.
>> Do you meet such case? I can workaround it by two method
>> 1. disable phy lower power feature.
>> 2. add some dummy package before SYNC package.
>
> If this low power mode is related to EEE (Energy Efficient Ethernet)
> then there are ethtool operations defined for configuring it, and you
> could implement those.
Yes, it is phy specific, called smart EEE, which compatible with IEEE 802.3az
and can be used in legacy MAC without EEE.
Do you have example about ethtool operations?
>
> Ben.
>
> --
> Ben Hutchings, Staff Engineer, Solarflare
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
>
^ permalink raw reply
* [PATCH net-next 2/2] ARM: net: bpf_jit_32: add VLAN instructions for BPF JIT
From: Daniel Borkmann @ 2012-11-08 1:31 UTC (permalink / raw)
To: davem; +Cc: Mircea Gherzan, Arnd Bergmann, netdev, linux-arm-kernel
This patch is a follow-up for patch "net: filter: add vlan tag access"
to support the new VLAN_TAG/VLAN_TAG_PRESENT accessors in BPF JIT.
Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
Cc: Mircea Gherzan <mgherzan@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/net/bpf_jit_32.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index 8be702d..9af9a69 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -16,6 +16,7 @@
#include <linux/netdevice.h>
#include <linux/string.h>
#include <linux/slab.h>
+#include <linux/if_vlan.h>
#include <asm/cacheflush.h>
#include <asm/hwcap.h>
@@ -168,6 +169,8 @@ static inline bool is_load_to_a(u16 inst)
case BPF_S_ANC_MARK:
case BPF_S_ANC_PROTOCOL:
case BPF_S_ANC_RXHASH:
+ case BPF_S_ANC_VLAN_TAG:
+ case BPF_S_ANC_VLAN_TAG_PRESENT:
case BPF_S_ANC_QUEUE:
return true;
default:
@@ -815,6 +818,17 @@ b_epilogue:
off = offsetof(struct sk_buff, rxhash);
emit(ARM_LDR_I(r_A, r_skb, off), ctx);
break;
+ case BPF_S_ANC_VLAN_TAG:
+ case BPF_S_ANC_VLAN_TAG_PRESENT:
+ ctx->seen |= SEEN_SKB;
+ BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, vlan_tci) != 2);
+ off = offsetof(struct sk_buff, vlan_tci);
+ emit(ARM_LDRH_I(r_A, r_skb, off), ctx);
+ if (inst->code == BPF_S_ANC_VLAN_TAG)
+ OP_IMM3(ARM_AND, r_A, r_A, VLAN_VID_MASK, ctx);
+ else
+ OP_IMM3(ARM_AND, r_A, r_A, VLAN_TAG_PRESENT, ctx);
+ break;
case BPF_S_ANC_QUEUE:
ctx->seen |= SEEN_SKB;
BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff,
^ permalink raw reply related
* [PATCH net-next 1/2] ARM: net: bpf_jit_32: add XOR instruction for BPF JIT
From: Daniel Borkmann @ 2012-11-08 1:28 UTC (permalink / raw)
To: davem; +Cc: Mircea Gherzan, Arnd Bergmann, netdev, linux-arm-kernel
This patch is a follow-up for patch "filter: add XOR instruction for use
with X/K" that implements BPF ARM JIT parts for the BPF XOR operation.
Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
Cc: Mircea Gherzan <mgherzan@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/net/bpf_jit_32.c | 15 ++++++++++-----
arch/arm/net/bpf_jit_32.h | 2 ++
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index c641fb6..8be702d 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -646,6 +646,16 @@ load_ind:
update_on_xread(ctx);
emit(ARM_ORR_R(r_A, r_A, r_X), ctx);
break;
+ case BPF_S_ALU_XOR_K:
+ /* A ^= K; */
+ OP_IMM3(ARM_EOR, r_A, r_A, k, ctx);
+ break;
+ case BPF_S_ANC_ALU_XOR_X:
+ case BPF_S_ALU_XOR_X:
+ /* A ^= X */
+ update_on_xread(ctx);
+ emit(ARM_EOR_R(r_A, r_A, r_X), ctx);
+ break;
case BPF_S_ALU_AND_K:
/* A &= K */
OP_IMM3(ARM_AND, r_A, r_A, k, ctx);
@@ -762,11 +772,6 @@ b_epilogue:
update_on_xread(ctx);
emit(ARM_MOV_R(r_A, r_X), ctx);
break;
- case BPF_S_ANC_ALU_XOR_X:
- /* A ^= X */
- update_on_xread(ctx);
- emit(ARM_EOR_R(r_A, r_A, r_X), ctx);
- break;
case BPF_S_ANC_PROTOCOL:
/* A = ntohs(skb->protocol) */
ctx->seen |= SEEN_SKB;
diff --git a/arch/arm/net/bpf_jit_32.h b/arch/arm/net/bpf_jit_32.h
index 7fa2f7d..afb8462 100644
--- a/arch/arm/net/bpf_jit_32.h
+++ b/arch/arm/net/bpf_jit_32.h
@@ -69,6 +69,7 @@
#define ARM_INST_CMP_I 0x03500000
#define ARM_INST_EOR_R 0x00200000
+#define ARM_INST_EOR_I 0x02200000
#define ARM_INST_LDRB_I 0x05d00000
#define ARM_INST_LDRB_R 0x07d00000
@@ -135,6 +136,7 @@
#define ARM_CMP_I(rn, imm) _AL3_I(ARM_INST_CMP, 0, rn, imm)
#define ARM_EOR_R(rd, rn, rm) _AL3_R(ARM_INST_EOR, rd, rn, rm)
+#define ARM_EOR_I(rd, rn, imm) _AL3_I(ARM_INST_EOR, rd, rn, imm)
#define ARM_LDR_I(rt, rn, off) (ARM_INST_LDR_I | (rt) << 12 | (rn) << 16 \
| (off))
^ permalink raw reply related
* Re: Optics (SFP) monitoring on ixgbe and igbe
From: Aurélien @ 2012-11-08 0:39 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1352318339.2725.34.camel@bwh-desktop.uk.solarflarecom.com>
On Wed, Nov 7, 2012 at 8:58 PM, Ben Hutchings <bhutchings@solarflare.com> wrote:
> On Wed, 2012-11-07 at 13:27 +0100, Aurélien wrote:
>
> We just added the ETHTOOL_GMODULEINFO and ETHTOOL_GMODULEEEPROM
> interface for this purpose. The diagnostics obviously aren't really an
> EEPROM but I don't think that matters.
>
> These drivers should report a type of ETH_MODULE_SFF_8472 (assuming a
> module is present) and expose an 'EEPROM' with the real EEPROM in the
> first 256 bytes and the diagnostic registers in the next 256 bytes.
>
> Decoding of the diagnostic registers can be done in ethtool itself.
>
Hi Ben,
Thanks for this reply.
I did not see these interfaces in my searches, but from what I gather
from the code, the missing part is the actual decoding of the data in
ethtool.
As soon as I get my card installed in a test server, I'll reboot on a
kernel issued from the davem/net-next master, and will do some tests
to see if ethtool correctly sees an SFF-8472 compliant module, and has
the correct diagnostic data after the eeprom.
Then I will port the decoding part from the kernel-side patches I to
code in ethtool, and will do some basic tests.
Thanks,
Best regards,
--
Aurélien Guillaume
^ permalink raw reply
* [PATCH v2 1/2] usb: gadget: g_ether: fix frame size check for 802.1Q
From: Ian Coolidge @ 2012-11-08 0:39 UTC (permalink / raw)
To: Greg Kroah-Hartman, Felipe Balbi,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Ian Coolidge
In-Reply-To: <1352335159-8049-1-git-send-email-iancoolidge-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Checking skb->len against ETH_FRAME_LEN assumes a 1514
ethernet frame size. With an 802.1Q VLAN header, ethernet
frame length can now be 1518. Validate frame length against that.
Signed-off-by: Ian Coolidge <iancoolidge-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/usb/gadget/u_ether.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/gadget/u_ether.c b/drivers/usb/gadget/u_ether.c
index 6458764..4ec3c0d 100644
--- a/drivers/usb/gadget/u_ether.c
+++ b/drivers/usb/gadget/u_ether.c
@@ -20,6 +20,7 @@
#include <linux/ctype.h>
#include <linux/etherdevice.h>
#include <linux/ethtool.h>
+#include <linux/if_vlan.h>
#include "u_ether.h"
@@ -295,7 +296,7 @@ static void rx_complete(struct usb_ep *ep, struct usb_request *req)
while (skb2) {
if (status < 0
|| ETH_HLEN > skb2->len
- || skb2->len > ETH_FRAME_LEN) {
+ || skb2->len > VLAN_ETH_FRAME_LEN) {
dev->net->stats.rx_errors++;
dev->net->stats.rx_length_errors++;
DBG(dev, "rx length %d\n", skb2->len);
--
1.7.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 related
* [PATCH v2 0/2] Fix CDC_EEM with 802.1Q VLAN and 1500 MTU
From: Ian Coolidge @ 2012-11-08 0:39 UTC (permalink / raw)
To: Greg Kroah-Hartman, Felipe Balbi,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Ian Coolidge
cdc_eem USB host driver and gadget driver both are broken in 1500 MTU
case while using 802.1Q VLANs. In both cases, this is due to the
assumption of standard Ethernet frame length.
v2: rebase against Dave Miller's 'net/master' tree
Ian Coolidge (2):
usb: gadget: g_ether: fix frame size check for 802.1Q
net: usb: cdc_eem: Fix rx skb allocation for 802.1Q VLANs
drivers/net/usb/cdc_eem.c | 3 ++-
drivers/usb/gadget/u_ether.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
--
1.7.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* [PATCH v2 2/2] net: usb: cdc_eem: Fix rx skb allocation for 802.1Q VLANs
From: Ian Coolidge @ 2012-11-08 0:39 UTC (permalink / raw)
To: Greg Kroah-Hartman, Felipe Balbi, linux-usb, netdev; +Cc: Ian Coolidge
In-Reply-To: <1352335159-8049-1-git-send-email-iancoolidge@gmail.com>
cdc_eem frames might need to contain 802.1Q VLAN Ethernet frames.
URB/skb sizing from usbnet will default to the hard_mtu,
so account for the VLAN header by expanding that via hard_header_len
Signed-off-by: Ian Coolidge <iancoolidge@gmail.com>
---
drivers/net/usb/cdc_eem.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/usb/cdc_eem.c b/drivers/net/usb/cdc_eem.c
index c81e278..08d55b6 100644
--- a/drivers/net/usb/cdc_eem.c
+++ b/drivers/net/usb/cdc_eem.c
@@ -31,6 +31,7 @@
#include <linux/usb/cdc.h>
#include <linux/usb/usbnet.h>
#include <linux/gfp.h>
+#include <linux/if_vlan.h>
/*
@@ -92,7 +93,7 @@ static int eem_bind(struct usbnet *dev, struct usb_interface *intf)
/* no jumbogram (16K) support for now */
- dev->net->hard_header_len += EEM_HEAD + ETH_FCS_LEN;
+ dev->net->hard_header_len += EEM_HEAD + ETH_FCS_LEN + VLAN_HLEN;
dev->hard_mtu = dev->net->mtu + dev->net->hard_header_len;
return 0;
--
1.7.6.5
^ permalink raw reply related
* Re: [PATCH net-next] sockopt: Change getsockopt() of SO_BINDTODEVICE to return an interface name
From: Ben Hutchings @ 2012-11-08 0:23 UTC (permalink / raw)
To: Brian Haley
Cc: Pavel Emelyanov, David Miller, Eric Dumazet,
netdev@vger.kernel.org
In-Reply-To: <50988BAE.6020602@hp.com>
On Mon, 2012-11-05 at 21:01 -0700, Brian Haley wrote:
> On 11/02/2012 05:34 PM, Ben Hutchings wrote:
> > On Fri, 2012-11-02 at 11:02 -0400, Brian Haley wrote:
> >> On 11/02/2012 05:36 AM, Pavel Emelyanov wrote:
> >>>> +static int sock_getbindtodevice(struct sock *sk, char __user *optval,
> >>>> + int __user *optlen, int len)
> >>>> +{
> >>>> + int ret = -ENOPROTOOPT;
> >>>> +#ifdef CONFIG_NETDEVICES
> >>>> + struct net *net = sock_net(sk);
> >>>> + struct net_device *dev;
> >>>> + char devname[IFNAMSIZ];
> >>>> +
> >>>> + if (sk->sk_bound_dev_if == 0) {
> >>>> + len = 0;
> >>>> + goto zero;
> >>>> + }
> >>>> +
> >>>> + ret = -EINVAL;
> >>>> + if (len < IFNAMSIZ)
> >>>> + goto out;
> >>>> +
> >>>> + rcu_read_lock();
> >>>> + dev = dev_get_by_index_rcu(net, sk->sk_bound_dev_if);
> >>>> + if (dev)
> >>>> + strcpy(devname, dev->name);
> >>>
> >>> This still races with the device name change, potentially providing
> >>> a name which never existed in the system, doesn't it?
> >>
> >> My only argument here is that SIOCGIFNAME has had this same code forever, and
> >> noone has ever complained about that returning a garbled name. Even
> >> dev_get_by_name() only holds an rcu lock when doing a strncmp().
> >>
> >> We'd need to audit the whole kernel to catch all the places where we potentially
> >> look at dev->name while it could change. Is it really worth it?
> >
> > A net device name can't be changed while the device is up, or while
> > another task holds the RTNL lock. I think that covers almost all uses.
> > I don't know whether it's worth going out to look for exceptions, but we
> > might as well fix the cases we know about.
>
> So do you think we can fix these corner cases later and get the API
> right first?
Well you can avoid the problem here by using rtnl_{,un}lock() and
__dev_get_by_index(). But if that's too heavyweight (it depends on how
often you think this might need to be called) then I suppose it can be
left until we have a general solution for races with renaming.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: pull request: batman-adv 2012-11-07
From: David Miller @ 2012-11-08 0:10 UTC (permalink / raw)
To: ordex-GaUfNO9RBHfsrOwW+9ziJQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <1352315502-20324-1-git-send-email-ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
From: Antonio Quartulli <ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
Date: Wed, 7 Nov 2012 20:11:30 +0100
> Hello David,
>
> first of all thank you for having made us aware of the packet format problem in
> batman-adv! The impact of __packed on performances was not entirely known to me,
> in particular for what concerns the RISC arch.
>
> We have to change a number of packet formats before we can remove __packed
> everywhere which will obviously break compatibility.
>
> However we already scheduled a compatibility break because we want to
> heavily improve our packet formats and to provide a more flexible framework that
> would allow us to add new types and features while reducing the probability of
> breaking compatibility again and again as happened in the past (we are
> implementing TypeLengthValue (TLV) containers among other things).
>
> To avoid breaking compatibility (at least) twice we decided to fix now (in this
> patchset) what is fixable with no consequences to compatibility while we would
> ilike to defer the remaining changes for the scheduled compatibility break.
>
> In this patchset you have the two new features intended for net-next/linux-3.8:
> 1) the new UNICAST_4ADDR packet type
> 2) the Distributed ARP Table (DAT) component
>
> The new packet type has been reviewed to entirely address the alignment issue.
> At the same time we also reviewed the other packet types but as I told you
> before, we will send these changes later.
>
> Other than that you have patch 02/12 that removes the __packed attribute from
> the structures where it was not really needed.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH trivial] ndisc: fix a typo in a comment in ndisc_recv_na()
From: David Miller @ 2012-11-08 0:03 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <1352300738-3851-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Wed, 7 Nov 2012 16:05:38 +0100
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] cxgb4: Fix initialization of SGE_CONTROL register
From: David Miller @ 2012-11-08 0:02 UTC (permalink / raw)
To: vipul; +Cc: netdev, divy, dm, jay
In-Reply-To: <1352295946-32146-1-git-send-email-vipul@chelsio.com>
From: Vipul Pandya <vipul@chelsio.com>
Date: Wed, 7 Nov 2012 19:15:46 +0530
> INGPADBOUNDARY_MASK is already shifted. No need to shift it again. On reloading
> a driver it was resulting in a bad SGE FL MTU sizes [1536, 9088] error. This
> only causes an issue on systems that have L1 cache size of 32B, 128B, 512B,
> 2048B or 4096B.
>
> Signed-off-by: Jay Hernandez <jay@chelsio.com>
> Signed-off-by: Vipul Pandya <vipul@chelsio.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH -next] ksz884x: use module_pci_driver to simplify the code
From: David Miller @ 2012-11-08 0:01 UTC (permalink / raw)
To: weiyj.lk; +Cc: yongjun_wei, netdev
In-Reply-To: <CAPgLHd8mrDXyiJ4rNFLHsYWEreVRiKXwqqr7umtSY36RkzXjUA@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Wed, 7 Nov 2012 20:54:30 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Use the module_pci_driver() macro to make the code simpler
> by eliminating module_init and module_exit calls.
>
> dpatch engine is used to auto generate this patch.
> (https://github.com/weiyj/dpatch)
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/1] isdn: Make CONFIG_ISDN depend on CONFIG_NETDEVICES
From: David Miller @ 2012-11-07 23:59 UTC (permalink / raw)
To: lee.jones; +Cc: linux-kernel, isdn, netdev
In-Reply-To: <1352282103-13665-1-git-send-email-lee.jones@linaro.org>
From: Lee Jones <lee.jones@linaro.org>
Date: Wed, 7 Nov 2012 10:55:03 +0100
> It doesn't make much sense to enable ISDN services if you don't
> intend to connect to a network. Therefore insisting that ISDN
> depends on NETDEVICES seems logical. We can then remove any
> guards mentioning NETDEVICES inside all subordinate drivers.
>
> This also has the nice side-effect of fixing the warning below
> when ISDN_I4L && !CONFIG_NETDEVICES at compile time.
>
> This patch fixes:
> drivers/isdn/i4l/isdn_common.c: In function ‘isdn_ioctl’:
> drivers/isdn/i4l/isdn_common.c:1278:8: warning: unused variable ‘s’ [-Wunused-variable]
>
> Cc: Karsten Keil <isdn@linux-pingi.de>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Applied, thanks.
^ permalink raw reply
* Re: [net-next patch 0/2] bnx2x: Enable cnic at run-time
From: David Miller @ 2012-11-07 23:57 UTC (permalink / raw)
To: meravs; +Cc: netdev, eilong
In-Reply-To: <1352285148-21784-1-git-send-email-meravs@broadcom.com>
From: "Merav Sicron" <meravs@broadcom.com>
Date: Wed, 7 Nov 2012 12:45:46 +0200
> This patch series removes the BCM_CNIC bnx2x define, and eliminates the use of
> the CONFIG_CNIC kconfig option.
> The define removal is mainly important for SR-IOV, as the VF driver will use the
> same code as the PF/hypervisor driver. Since storage is not supported in
> SR-IOV (while is usually enabled in the non SR-IOV driver), we don't want to
> waste resources on it.
> After this change, cnic-related resources are allocated only when the cnic
> module registers with bnx2x (which means that the user asked for storage
> services). Also only at this stage the HW is configured to non-NIC (offload)
> mode.
> The first patch is the driver-FW HSI addition to change the 'update' ramrod for
> offload mode configuration at run-time.
> The second patch is for the removal of the BCM_CNIC define, and for separating
> the load flow to two stages, one for L2 and one for cnic-related stuff.
>
> Please consider applying this patch series to net-next.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v3] packet: tx_ring: allow the user to choose tx data offset
From: David Miller @ 2012-11-07 23:55 UTC (permalink / raw)
To: Paul.Chavent; +Cc: netdev
In-Reply-To: <1352279447-2980-1-git-send-email-paul.chavent@onera.fr>
From: Paul Chavent <Paul.Chavent@onera.fr>
Date: Wed, 7 Nov 2012 10:10:47 +0100
> The tx data offset of packet mmap tx ring used to be :
> (TPACKET2_HDRLEN - sizeof(struct sockaddr_ll))
>
> The problem is that, with SOCK_RAW socket, the payload (14 bytes after
> the beginning of the user data) is misaligned.
>
> This patch allows to let the user gives an offset for it's tx data if
> he desires.
>
> Set sock option PACKET_TX_HAS_OFF to 1, then specify in each frame of
> your tx ring tp_net for SOCK_DGRAM, or tp_mac for SOCK_RAW.
>
> Signed-off-by: Paul Chavent <paul.chavent@onera.fr>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] net: fec: reduce spin lock time in fec_ptp_adjfreq
From: David Miller @ 2012-11-07 23:53 UTC (permalink / raw)
To: Frank.Li
Cc: lznuaa, richardcochran, shawn.guo, linux-arm-kernel, netdev,
bhutchings
In-Reply-To: <1352268889-16836-1-git-send-email-Frank.Li@freescale.com>
From: Frank Li <Frank.Li@freescale.com>
Date: Wed, 7 Nov 2012 14:14:49 +0800
> move below calculate out of spin lock section
> diff = fep->cc.mult;
> diff *= ppb;
> diff = div_u64(diff, 1000000000ULL);
>
> diff is local variable and not neccesary in spin lock
>
> Signed-off-by: Frank Li <Frank.Li@freescale.com>
Also applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] net: fec: default select FEC_PTP at mx6 platform
From: David Miller @ 2012-11-07 23:52 UTC (permalink / raw)
To: Frank.Li
Cc: lznuaa, richardcochran, shawn.guo, linux-arm-kernel, netdev,
bhutchings
In-Reply-To: <1352268883-16800-1-git-send-email-Frank.Li@freescale.com>
From: Frank Li <Frank.Li@freescale.com>
Date: Wed, 7 Nov 2012 14:14:43 +0800
> Remove PPS.
> Limit FEC_PTP option for i.MX chip only.
> FEC_PTP default is on at mx6 platform.
>
> Signed-off-by: Frank Li <Frank.Li@freescale.com>
Applied to net-next.
But please be explicit about which tree your patches are for in the
subject line in the future.
^ permalink raw reply
* Re: [PATCH] tcp: Avoid infinite loop on recvmsg bug
From: Eric Dumazet @ 2012-11-07 23:42 UTC (permalink / raw)
To: Julius Werner
Cc: linux-kernel, netdev, Patrick McHardy, Hideaki YOSHIFUJI,
James Morris, Alexey Kuznetsov, David S. Miller, Dave Jones,
Sameer Nanda, Mandeep Singh Baines
In-Reply-To: <1352331192.2748.10.camel@edumazet-glaptop>
On Wed, 2012-11-07 at 15:33 -0800, Eric Dumazet wrote:
> So you probably are fighting a bug we already fixed in upstream kernel.
>
> (commit c8628155ece363 "tcp: reduce out_of_order memory use" did not
> played well with cloned skbs.)
>
> This issue was already discussed on netdev in the past.
If you use a 3.4 kernel, you want the following patch.
(I guess you could reproduce the crash easily running a tcpdump in //)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 257b617..9f8f68c 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4496,7 +4496,9 @@ static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)
* to avoid future tcp_collapse_ofo_queue(),
* probably the most expensive function in tcp stack.
*/
- if (skb->len <= skb_tailroom(skb1) && !tcp_hdr(skb)->fin) {
+ if (skb->len <= skb_tailroom(skb1) &&
+ !tcp_hdr(skb)->fin &&
+ !skb_cloned(skb1)) {
NET_INC_STATS_BH(sock_net(sk),
LINUX_MIB_TCPRCVCOALESCE);
BUG_ON(skb_copy_bits(skb, 0,
^ permalink raw reply related
* Re: tc filter u32 match
From: Nieścierowicz Adam @ 2012-11-07 23:36 UTC (permalink / raw)
To: Jamal Hadi Salim, Netdev
In-Reply-To: <1337853878.3513.11.camel@mojatatu>
W dniu 24.05.2012 12:04, Jamal Hadi Salim napisał(a):
> On Tue, 2012-05-22 at 15:42 +0200, Nieścierowicz Adam wrote:
>
>> Hello, I'm in the process of building a new shaper, when adding
>> support
>> for 802.1q vlan noticed that u32 can catch network traffic without
>> giving 4 bytes offset. How is this possible?
>
> Because we look at where the network header starts?
> Why do you expect 4 bytes to be counted?
>
>> My environment: eth2 - network card eth2.200 - vlan /sbin/tc filter
>> add
>> dev eth2 parent 1:0 prio 5 handle 35: protocol ip u32 divisor 256
>> /sbin/tc filter add dev eth2 protocol ip parent 1:0 prio 5 u32 ht
>> 800::
>> match ip dst 31.41.208.32/27 hashkey mask 0x000000ff at 16 link 35:
>> /sbin/tc filter add dev eth2 protocol ip parent 1: prio 1 u32 ht
>> 35:24:
>> match ip dst 31.41.208.36 flowid 1:2e5 Here you can see the hits in
>> the
>> rule filter parent 1: protocol ip pref 5 u32 fh 35:24:800 order 2048
>> key ht 35 bkt 24 flowid 1:2e5 (rule hit 44037 success 44037) match
>> 1f29d024/ffffffff at 16 (success 44037 )
>
> I dont see an issue. This looks correct.
>
>>> I found a similar question here
>>
>
http://serverfault.com/questions/370795/tc-u32-how-to-match-l2-protocols-in-recent-kernels
>>
>
> There may have been bugs in the past that someone missed or didnt
> report here (likely around the time there was a lot of changes
> happening with vlan offloading). Try the latest kernel and
> if it behaves badly, send a report and a reproducible test case.
Hello Again,
I changed the kernel to 3.6.0 and ip traffic classification on the
interface and vlan works fine.
Unfortunately I am not able to classify
PPPoE traffic, I checked filters with offset: 16, 20, 24, 28
Is it possible to classify PPPoE traffic on the main interface as it
was in previous kernels?
^ permalink raw reply
* Re: [PATCH] tcp: Avoid infinite loop on recvmsg bug
From: Eric Dumazet @ 2012-11-07 23:33 UTC (permalink / raw)
To: Julius Werner
Cc: linux-kernel, netdev, Patrick McHardy, Hideaki YOSHIFUJI,
James Morris, Alexey Kuznetsov, David S. Miller, Dave Jones,
Sameer Nanda, Mandeep Singh Baines
In-Reply-To: <CAODwPW8mBJspF3k5SCBR-BShNvBLQpD-vyhLRh5Cq-4h=VZDgg@mail.gmail.com>
On Wed, 2012-11-07 at 13:14 -0800, Julius Werner wrote:
> > What I find very sad in all this is that you didnt mention the driver
> > that was triggering this bug.
>
> Sorry, I was just trying to keep this thread focussed on one patch.
> The bug report that led me to this is publicly accessible at
> http://crosbug.com/35827. We have encountered the problem only once,
> on an Acer AC700 Chromebook that ran automated tests. The ethernet
> interface for the offending socket was provided by a USB-to-Ethernet
> dongle using the smsc95xx/usbnet module (v1.0.4).
This driver uses interesting skb_clone() games and skb->truesize lies :
skb->truesize = size + sizeof(struct sk_buff);
So you probably are fighting a bug we already fixed in upstream kernel.
(commit c8628155ece363 "tcp: reduce out_of_order memory use" did not
played well with cloned skbs.)
This issue was already discussed on netdev in the past.
^ permalink raw reply
* Re: [PATCH 0/8] at91_ether share stats/address setting with macb
From: David Miller @ 2012-11-07 22:45 UTC (permalink / raw)
To: manabian; +Cc: nicolas.ferre, plagnioj, netdev
In-Reply-To: <1352312097-31320-1-git-send-email-manabian@gmail.com>
From: Joachim Eastwood <manabian@gmail.com>
Date: Wed, 7 Nov 2012 19:14:49 +0100
> Patch 1-2 add support for some special at91_ether features to macb address setting code. This will allow us to have one address setting function that can be shared.
>
> Patch 4 removes the at91_ether address set/get code and make use of the exported functions for macb.
>
> Patch 5 remove the at91_ether statistics functions and replace them with equivalent function from macb.
>
> Patch 6 removes an unused member from the at91_ether/macb private struct.
>
> Patch 7 is a clean up of the print outs from at91_ether.
>
> Patch 8 is a misc clean up patch which fixes some comment and style issues.
>
>
> Most of the code left in at91_ether now deal with configuration and DMA rx/tx which is hard to share with macb since this is specific for the IP block in AT91RM9200.
>
> Next I'll work on adding PHY GPIO interrupt to the macb driver. at91_ether had this functionality before it began using mdio functions from macb.
All applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/7] be2net: patch set
From: David Miller @ 2012-11-07 22:00 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <4f3dfb12-ef85-48ce-9c67-f5e58ed6f105@CMEXHTCAS2.ad.emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Wed, 7 Nov 2012 09:18:54 +0530
> Pls apply.
>
> Sathya Perla (7):
> be2net: remove LANCER A0 workaround
> be2net: fix wrong usage of adapter->generation
> be2net: do not use sli_family to identify skyhawk-R chip
> be2net: re-factor bar mapping code
> be2net: fix access to SEMAPHORE reg
> be2net: remove roce on lancer
> be2net: remove adapter->eq_next_idx
Looks good, all applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH 0/2] Fix CDC_EEM with 802.1Q VLAN and 1500 MTU
From: David Miller @ 2012-11-07 21:56 UTC (permalink / raw)
To: iancoolidge-Re5JQEeQqe8AvxtiuMwx3w
Cc: oliver-Q6YOFhsQ4GZ7tPAFqOLdPg,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, balbi-l0cyMroinI0,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1352235611-13066-1-git-send-email-iancoolidge-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Patch #2 does not apply cleanl to the net tree.
Please respin and repost this entire series again.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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] tcp: Avoid infinite loop on recvmsg bug
From: Julius Werner @ 2012-11-07 21:14 UTC (permalink / raw)
To: Eric Dumazet
Cc: linux-kernel, netdev, Patrick McHardy, Hideaki YOSHIFUJI,
James Morris, Alexey Kuznetsov, David S. Miller, Dave Jones,
Sameer Nanda, Mandeep Singh Baines
In-Reply-To: <1352317219.5552.6.camel@edumazet-glaptop>
> What I find very sad in all this is that you didnt mention the driver
> that was triggering this bug.
Sorry, I was just trying to keep this thread focussed on one patch.
The bug report that led me to this is publicly accessible at
http://crosbug.com/35827. We have encountered the problem only once,
on an Acer AC700 Chromebook that ran automated tests. The ethernet
interface for the offending socket was provided by a USB-to-Ethernet
dongle using the smsc95xx/usbnet module (v1.0.4).
Don't get me wrong, I do understand the importance of finding the
underlying cause of this... I just don't think I have much of a chance
with one report. I can go through the above-mentioned module and see
if something looks suspicious in the skb handling code if I can find
the time. But on the other hand the fact remains that this condition
is not handled well... not just for this particular case, but for all
future kernel and driver bugs that may trigger it again. I am not
trying to "hide" any issues, I am all for making them as visible as
possible... but as Dave pointed out, kernel panics may not be the best
way to do that either, and I think damage mitigation also has some
value. The current code clearly does the worst of both worlds, so
please let's just improve it one way or the other.
^ permalink raw reply
* Re: [PATCH net] cxgb4: Initialize data structures before using.
From: David Miller @ 2012-11-07 20:43 UTC (permalink / raw)
To: vipul; +Cc: netdev, divy, dm, jay
In-Reply-To: <1352209029-4291-1-git-send-email-vipul@chelsio.com>
From: Vipul Pandya <vipul@chelsio.com>
Date: Tue, 6 Nov 2012 19:07:09 +0530
> We should not assume reserve fields to be don't cares as fields may change.
> Clearing data structures before using.
>
> Signed-off-by: Jay Hernandez <jay@chelsio.com>
> Signed-off-by: Vipul Pandya <vipul@chelsio.com>
Applied, thanks.
^ 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