* [net-2.6 PATCH 2/3] ixgbe: disable tx engine before disabling tx laser
From: Jeff Kirsher @ 2010-06-30 4:28 UTC (permalink / raw)
To: davem
Cc: netdev, gospo, bphilips, John Fastabend, Peter P Waskiewicz Jr,
Jeff Kirsher
In-Reply-To: <20100630042739.8925.24962.stgit@localhost.localdomain>
From: John Fastabend <john.r.fastabend@intel.com>
Disabling the tx laser while receiving DMA requests
can hang the device. After this occurs the device
is in a bad state. The GPIO bit never clears when
PCI master access is disabled and a reboot is required
to get the device in a good state again.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_main.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index e237748..7ddd60e 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -3684,10 +3684,6 @@ void ixgbe_down(struct ixgbe_adapter *adapter)
/* signal that we are down to the interrupt handler */
set_bit(__IXGBE_DOWN, &adapter->state);
- /* power down the optics */
- if (hw->phy.multispeed_fiber)
- hw->mac.ops.disable_tx_laser(hw);
-
/* disable receive for all VFs and wait one second */
if (adapter->num_vfs) {
/* ping all the active vfs to let them know we are going down */
@@ -3742,6 +3738,10 @@ void ixgbe_down(struct ixgbe_adapter *adapter)
(IXGBE_READ_REG(hw, IXGBE_DMATXCTL) &
~IXGBE_DMATXCTL_TE));
+ /* power down the optics */
+ if (hw->phy.multispeed_fiber)
+ hw->mac.ops.disable_tx_laser(hw);
+
/* clear n-tuple filters that are cached */
ethtool_ntuple_flush(netdev);
^ permalink raw reply related
* [net-2.6 PATCH 3/3] ixgbe: skip non IPv4 packets in ATR filter
From: Jeff Kirsher @ 2010-06-30 4:29 UTC (permalink / raw)
To: davem
Cc: netdev, gospo, bphilips, Guillaume Gaudonville,
Peter P Waskiewicz Jr, Don Skidmore, Jeff Kirsher
In-Reply-To: <20100630042739.8925.24962.stgit@localhost.localdomain>
From: Guillaume Gaudonville <guillaume.gaudonville@6wind.com>
In driver ixgbe, ixgbe_atr may cause crashes for non-ipv4 packets. Just
add a test to check skb->protocol. It may crash on short packets due
to ip_hdr() access.
Signed-off-by: Guillaume Gaudonville <guillaume.gaudonville@6wind.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_main.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 7ddd60e..a0b3316 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -6024,7 +6024,6 @@ static void ixgbe_tx_queue(struct ixgbe_adapter *adapter,
static void ixgbe_atr(struct ixgbe_adapter *adapter, struct sk_buff *skb,
int queue, u32 tx_flags)
{
- /* Right now, we support IPv4 only */
struct ixgbe_atr_input atr_input;
struct tcphdr *th;
struct iphdr *iph = ip_hdr(skb);
@@ -6033,6 +6032,9 @@ static void ixgbe_atr(struct ixgbe_adapter *adapter, struct sk_buff *skb,
u32 src_ipv4_addr, dst_ipv4_addr;
u8 l4type = 0;
+ /* Right now, we support IPv4 only */
+ if (skb->protocol != htons(ETH_P_IP))
+ return;
/* check if we're UDP or TCP */
if (iph->protocol == IPPROTO_TCP) {
th = tcp_hdr(skb);
^ permalink raw reply related
* [net-next-2.6 PATCH] ixgbe: add 1g PHY support for 82599
From: Jeff Kirsher @ 2010-06-30 4:30 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, bphilips, Don Skidmore, Jeff Kirsher
From: Don Skidmore <donald.c.skidmore@intel.com>
Add support for 1G SFP+ PHY's to 82599.
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_82599.c | 13 +++++++++++++
drivers/net/ixgbe/ixgbe_ethtool.c | 7 +++++++
drivers/net/ixgbe/ixgbe_phy.c | 33 +++++++++++++++++++++++++++++----
drivers/net/ixgbe/ixgbe_phy.h | 1 +
drivers/net/ixgbe/ixgbe_type.h | 2 ++
5 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_82599.c b/drivers/net/ixgbe/ixgbe_82599.c
index 976fd9e..0ee175a 100644
--- a/drivers/net/ixgbe/ixgbe_82599.c
+++ b/drivers/net/ixgbe/ixgbe_82599.c
@@ -206,6 +206,14 @@ static s32 ixgbe_get_link_capabilities_82599(struct ixgbe_hw *hw,
s32 status = 0;
u32 autoc = 0;
+ /* Determine 1G link capabilities off of SFP+ type */
+ if (hw->phy.sfp_type == ixgbe_sfp_type_1g_cu_core0 ||
+ hw->phy.sfp_type == ixgbe_sfp_type_1g_cu_core1) {
+ *speed = IXGBE_LINK_SPEED_1GB_FULL;
+ *negotiation = true;
+ goto out;
+ }
+
/*
* Determine link capabilities based on the stored value of AUTOC,
* which represents EEPROM defaults. If AUTOC value has not been
@@ -2087,6 +2095,7 @@ static u32 ixgbe_get_supported_physical_layer_82599(struct ixgbe_hw *hw)
u32 pma_pmd_1g = autoc & IXGBE_AUTOC_1G_PMA_PMD_MASK;
u16 ext_ability = 0;
u8 comp_codes_10g = 0;
+ u8 comp_codes_1g = 0;
hw->phy.ops.identify(hw);
@@ -2167,11 +2176,15 @@ sfp_check:
case ixgbe_phy_sfp_intel:
case ixgbe_phy_sfp_unknown:
hw->phy.ops.read_i2c_eeprom(hw,
+ IXGBE_SFF_1GBE_COMP_CODES, &comp_codes_1g);
+ hw->phy.ops.read_i2c_eeprom(hw,
IXGBE_SFF_10GBE_COMP_CODES, &comp_codes_10g);
if (comp_codes_10g & IXGBE_SFF_10GBASESR_CAPABLE)
physical_layer = IXGBE_PHYSICAL_LAYER_10GBASE_SR;
else if (comp_codes_10g & IXGBE_SFF_10GBASELR_CAPABLE)
physical_layer = IXGBE_PHYSICAL_LAYER_10GBASE_LR;
+ else if (comp_codes_1g & IXGBE_SFF_1GBASET_CAPABLE)
+ physical_layer = IXGBE_PHYSICAL_LAYER_1000BASE_T;
break;
default:
break;
diff --git a/drivers/net/ixgbe/ixgbe_ethtool.c b/drivers/net/ixgbe/ixgbe_ethtool.c
index 873b45e..2e88fc6 100644
--- a/drivers/net/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ixgbe/ixgbe_ethtool.c
@@ -234,6 +234,13 @@ static int ixgbe_get_settings(struct net_device *netdev,
case ixgbe_sfp_type_not_present:
ecmd->port = PORT_NONE;
break;
+ case ixgbe_sfp_type_1g_cu_core0:
+ case ixgbe_sfp_type_1g_cu_core1:
+ ecmd->port = PORT_TP;
+ ecmd->supported = SUPPORTED_TP;
+ ecmd->advertising = (ADVERTISED_1000baseT_Full |
+ ADVERTISED_TP);
+ break;
case ixgbe_sfp_type_unknown:
default:
ecmd->port = PORT_OTHER;
diff --git a/drivers/net/ixgbe/ixgbe_phy.c b/drivers/net/ixgbe/ixgbe_phy.c
index 48325a5..6c0d42e 100644
--- a/drivers/net/ixgbe/ixgbe_phy.c
+++ b/drivers/net/ixgbe/ixgbe_phy.c
@@ -577,6 +577,8 @@ s32 ixgbe_identify_sfp_module_generic(struct ixgbe_hw *hw)
* 6 SFP_SR/LR_CORE1 - 82599-specific
* 7 SFP_act_lmt_DA_CORE0 - 82599-specific
* 8 SFP_act_lmt_DA_CORE1 - 82599-specific
+ * 9 SFP_1g_cu_CORE0 - 82599-specific
+ * 10 SFP_1g_cu_CORE1 - 82599-specific
*/
if (hw->mac.type == ixgbe_mac_82598EB) {
if (cable_tech & IXGBE_SFF_DA_PASSIVE_CABLE)
@@ -625,6 +627,13 @@ s32 ixgbe_identify_sfp_module_generic(struct ixgbe_hw *hw)
else
hw->phy.sfp_type =
ixgbe_sfp_type_srlr_core1;
+ else if (comp_codes_1g & IXGBE_SFF_1GBASET_CAPABLE)
+ if (hw->bus.lan_id == 0)
+ hw->phy.sfp_type =
+ ixgbe_sfp_type_1g_cu_core0;
+ else
+ hw->phy.sfp_type =
+ ixgbe_sfp_type_1g_cu_core1;
else
hw->phy.sfp_type = ixgbe_sfp_type_unknown;
}
@@ -696,8 +705,10 @@ s32 ixgbe_identify_sfp_module_generic(struct ixgbe_hw *hw)
goto out;
}
- /* 1G SFP modules are not supported */
- if (comp_codes_10g == 0) {
+ /* Verify supported 1G SFP modules */
+ if (comp_codes_10g == 0 &&
+ !(hw->phy.sfp_type == ixgbe_sfp_type_1g_cu_core1 ||
+ hw->phy.sfp_type == ixgbe_sfp_type_1g_cu_core0)) {
hw->phy.type = ixgbe_phy_sfp_unsupported;
status = IXGBE_ERR_SFP_NOT_SUPPORTED;
goto out;
@@ -711,7 +722,9 @@ s32 ixgbe_identify_sfp_module_generic(struct ixgbe_hw *hw)
/* This is guaranteed to be 82599, no need to check for NULL */
hw->mac.ops.get_device_caps(hw, &enforce_sfp);
- if (!(enforce_sfp & IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP)) {
+ if (!(enforce_sfp & IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP) &&
+ !((hw->phy.sfp_type == ixgbe_sfp_type_1g_cu_core0) ||
+ (hw->phy.sfp_type == ixgbe_sfp_type_1g_cu_core1))) {
/* Make sure we're a supported PHY type */
if (hw->phy.type == ixgbe_phy_sfp_intel) {
status = 0;
@@ -742,6 +755,7 @@ s32 ixgbe_get_sfp_init_sequence_offsets(struct ixgbe_hw *hw,
u16 *data_offset)
{
u16 sfp_id;
+ u16 sfp_type = hw->phy.sfp_type;
if (hw->phy.sfp_type == ixgbe_sfp_type_unknown)
return IXGBE_ERR_SFP_NOT_SUPPORTED;
@@ -753,6 +767,17 @@ s32 ixgbe_get_sfp_init_sequence_offsets(struct ixgbe_hw *hw,
(hw->phy.sfp_type == ixgbe_sfp_type_da_cu))
return IXGBE_ERR_SFP_NOT_SUPPORTED;
+ /*
+ * Limiting active cables and 1G Phys must be initialized as
+ * SR modules
+ */
+ if (sfp_type == ixgbe_sfp_type_da_act_lmt_core0 ||
+ sfp_type == ixgbe_sfp_type_1g_cu_core0)
+ sfp_type = ixgbe_sfp_type_srlr_core0;
+ else if (sfp_type == ixgbe_sfp_type_da_act_lmt_core1 ||
+ sfp_type == ixgbe_sfp_type_1g_cu_core1)
+ sfp_type = ixgbe_sfp_type_srlr_core1;
+
/* Read offset to PHY init contents */
hw->eeprom.ops.read(hw, IXGBE_PHY_INIT_OFFSET_NL, list_offset);
@@ -769,7 +794,7 @@ s32 ixgbe_get_sfp_init_sequence_offsets(struct ixgbe_hw *hw,
hw->eeprom.ops.read(hw, *list_offset, &sfp_id);
while (sfp_id != IXGBE_PHY_INIT_END_NL) {
- if (sfp_id == hw->phy.sfp_type) {
+ if (sfp_id == sfp_type) {
(*list_offset)++;
hw->eeprom.ops.read(hw, *list_offset, data_offset);
if ((!*data_offset) || (*data_offset == 0xFFFF)) {
diff --git a/drivers/net/ixgbe/ixgbe_phy.h b/drivers/net/ixgbe/ixgbe_phy.h
index ef4ba83..fb3898f 100644
--- a/drivers/net/ixgbe/ixgbe_phy.h
+++ b/drivers/net/ixgbe/ixgbe_phy.h
@@ -48,6 +48,7 @@
#define IXGBE_SFF_DA_SPEC_ACTIVE_LIMITING 0x4
#define IXGBE_SFF_1GBASESX_CAPABLE 0x1
#define IXGBE_SFF_1GBASELX_CAPABLE 0x2
+#define IXGBE_SFF_1GBASET_CAPABLE 0x8
#define IXGBE_SFF_10GBASESR_CAPABLE 0x10
#define IXGBE_SFF_10GBASELR_CAPABLE 0x20
#define IXGBE_I2C_EEPROM_READ_MASK 0x100
diff --git a/drivers/net/ixgbe/ixgbe_type.h b/drivers/net/ixgbe/ixgbe_type.h
index cdd1998..9587d97 100644
--- a/drivers/net/ixgbe/ixgbe_type.h
+++ b/drivers/net/ixgbe/ixgbe_type.h
@@ -2214,6 +2214,8 @@ enum ixgbe_sfp_type {
ixgbe_sfp_type_srlr_core1 = 6,
ixgbe_sfp_type_da_act_lmt_core0 = 7,
ixgbe_sfp_type_da_act_lmt_core1 = 8,
+ ixgbe_sfp_type_1g_cu_core0 = 9,
+ ixgbe_sfp_type_1g_cu_core1 = 10,
ixgbe_sfp_type_not_present = 0xFFFE,
ixgbe_sfp_type_unknown = 0xFFFF
};
^ permalink raw reply related
* [net-next-2.6 PATCH v2] x86: Align skb w/ start of cacheline on newer core 2/Xeon Arch
From: Jeff Kirsher @ 2010-06-30 4:38 UTC (permalink / raw)
To: davem
Cc: netdev, gospo, bphilips, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86, Alexander Duyck, Jeff Kirsher
From: Alexander Duyck <alexander.h.duyck@intel.com>
x86 architectures can handle unaligned accesses in hardware, and it has
been shown that unaligned DMA accesses can be expensive on Nehalem
architectures. As such we should overwrite NET_IP_ALIGN to resolve
this issue.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
arch/x86/include/asm/system.h | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/system.h b/arch/x86/include/asm/system.h
index b8fe48e..b4293fc 100644
--- a/arch/x86/include/asm/system.h
+++ b/arch/x86/include/asm/system.h
@@ -457,4 +457,13 @@ static inline void rdtsc_barrier(void)
alternative(ASM_NOP3, "lfence", X86_FEATURE_LFENCE_RDTSC);
}
+#ifdef CONFIG_MCORE2
+/*
+ * We handle most unaligned accesses in hardware. On the other hand
+ * unaligned DMA can be quite expensive on some Nehalem processors.
+ *
+ * Based on this we disable the IP header alignment in network drivers.
+ */
+#define NET_IP_ALIGN 0
+#endif
#endif /* _ASM_X86_SYSTEM_H */
^ permalink raw reply related
* Re: static inline int xfrm_mark_get() broken
From: Simon Horman @ 2010-06-30 4:46 UTC (permalink / raw)
To: Andreas Steffen; +Cc: netdev
In-Reply-To: <4C28EE19.2090502@hsr.ch>
On Mon, Jun 28, 2010 at 08:46:49PM +0200, Andreas Steffen wrote:
> Hi,
>
> experimenting with the new XFRM_MARK feature of the 2.6.34 kernel
> I found out that the extraction of the mark mask might accidentally
> work on 64 bit platforms but on 32 bit platforms the function is
> awfully broken. The rather trivial patch attached to this mail fixes
> the problem. Otherwise the XFRM_MARK feature seems quite promising!
>
> Best regards
>
> Andreas
>
> ======================================================================
> Andreas Steffen e-mail: andreas.steffen@hsr.ch
> Institute for Internet Technologies and Applications
> Hochschule fuer Technik Rapperswil phone: +41 55 222 42 68
> CH-8640 Rapperswil (Switzerland) mobile: +41 76 340 25 56
> ===========================================================[ITA-HSR]==
> --- linux/include/net/xfrm.h.ori 2010-06-28 18:53:28.229489876 +0200
> +++ linux/include/net/xfrm.h 2010-06-28 18:53:50.745487383 +0200
> @@ -1587,7 +1587,7 @@
> static inline int xfrm_mark_get(struct nlattr **attrs, struct xfrm_mark *m)
> {
> if (attrs[XFRMA_MARK])
> - memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(m));
> + memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(struct xfrm_mark));
This fix looks correct to me, but
I believe that sizeof(*m) is the preferred style.
> else
> m->v = m->m = 0;
>
^ permalink raw reply
* Re: nonlocal_bind & IPv6
From: Simon Horman @ 2010-06-30 4:48 UTC (permalink / raw)
To: Michal Humpula; +Cc: netdev
In-Reply-To: <201006262242.16346.michal.humpula@hudrydum.cz>
On Sat, Jun 26, 2010 at 10:42:16PM +0200, Michal Humpula wrote:
> On Saturday 26 of June 2010 15:25:40 Simon Horman wrote:
> > On Fri, Jun 25, 2010 at 09:10:08PM +0200, Michal Humpula wrote:
> > > Ok, more detail example.
> > >
> > > Let on each node be an apache (just for an example), and you configure
> > > VirtualHost for specific IP. So when node A fails, keepalived move IP to
> > > the node B and everything is still running. No need for restart of apache
> > > or anything else. There is a probably a better solution, but I can't find
> > > anything more simple than the posted patch:)
> >
> > Not an answer to your original question, but that sounds like a problem
> > that can be resolved using IP_TRANSPARENT. Although I have only tested
> > that feature in conjunction with IPv4, it seems to support IPv6 too.
> >
> > See Documentation/networking/tproxy.txt
>
> Thanks for redirection. I don't think that IP_TRANSPARENT is suited well
> for my problem, but I did find the IP_FREEBIND in the process.
> Unfortunately it seems that both are enabled only for IPv4 and IPv6
> mapped addresses.
>
> So, is there any reason why IP_FREEBIND or nonlocal_bind sysctl is not in
> current IPv6 kernel implementation?
My suspicion is that its just an oversight. A good way to either get it
fixed or have the idea buried would be to send some patches.
^ permalink raw reply
* Re: [RFC] [PATCH] ethtool: Change ethtool_op_set_flags to validate flags
From: Jeff Garzik @ 2010-06-30 5:26 UTC (permalink / raw)
To: Ben Hutchings
Cc: Stanislaw Gruszka, Amit Salecha, netdev@vger.kernel.org,
Amerigo Wang, Anirban Chakraborty
In-Reply-To: <1277827261.2112.48.camel@achroite.uk.solarflarecom.com>
On 06/29/2010 12:01 PM, Ben Hutchings wrote:
> This is the sort of change I'd like to see.
>
> Ben.
>
> ---
> ethtool_op_set_flags() does not check for unsupported flags, and has
> no way of doing so. This means it is not suitable for use as a
> default implementation of ethtool_ops::set_flags.
>
> Add a 'supported' parameter specifying the flags that the driver and
> hardware support, validate the requested flags against this, and
> change all current callers to pass this parameter.
>
> Change some other trivial implementations of ethtool_ops::set_flags to
> call ethtool_op_set_flags().
> ---
> drivers/net/cxgb4/cxgb4_main.c | 9 +--------
> drivers/net/enic/enic_main.c | 1 -
> drivers/net/ixgbe/ixgbe_ethtool.c | 5 ++++-
> drivers/net/mv643xx_eth.c | 7 ++++++-
> drivers/net/myri10ge/myri10ge.c | 10 +++++++---
> drivers/net/niu.c | 9 +--------
> drivers/net/sfc/ethtool.c | 5 +----
> drivers/net/sky2.c | 16 ++++++----------
> include/linux/ethtool.h | 2 +-
> net/core/ethtool.c | 28 +++++-----------------------
> 10 files changed, 32 insertions(+), 60 deletions(-)
Acked-by: Jeff Garzik <jgarzik@redhat.com>
I think that's a better way to do it...
^ permalink raw reply
* Re: [PATCH 0/4] Extend Time Stamping
From: Richard Cochran @ 2010-06-30 6:28 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100629.153134.25136559.davem@davemloft.net>
On Tue, Jun 29, 2010 at 03:31:34PM -0700, David Miller wrote:
> --------------------
> By this I mean you should provide these inline helpers by default
> then we can begin to put them into the drivers.
> --------------------
>
> This means no config option.
Okay, but what about the PHY time stamping hooks?
I anticipate that people will complain about the "performance penalty"
of these extra checks in a critical path.
Richard
static inline void phy_tx_timestamp(struct phy_device *phy, struct sk_buff *skb)
{
union skb_shared_tx *shtx = skb_tx(skb);
if (shtx->hardware && phy && phy->drv->txtstamp)
phy->drv->txtstamp(phy, skb);
}
static inline void phy_rx_timestamp(struct phy_device *phy, struct sk_buff *skb)
{
if (phy && phy->drv->rxtstamp)
phy->drv->rxtstamp(phy, skb);
}
^ permalink raw reply
* Re: [PATCH 0/4] Extend Time Stamping
From: David Miller @ 2010-06-30 5:37 UTC (permalink / raw)
To: richardcochran; +Cc: netdev
In-Reply-To: <20100630062806.GA3646@riccoc20.at.omicron.at>
From: Richard Cochran <richardcochran@gmail.com>
Date: Wed, 30 Jun 2010 08:28:06 +0200
> On Tue, Jun 29, 2010 at 03:31:34PM -0700, David Miller wrote:
>> --------------------
>> By this I mean you should provide these inline helpers by default
>> then we can begin to put them into the drivers.
>> --------------------
>>
>> This means no config option.
>
> Okay, but what about the PHY time stamping hooks?
>
> I anticipate that people will complain about the "performance penalty"
> of these extra checks in a critical path.
If you want to conditionalize the PHY hooks, fine.
But at a minimum, the software timestamping bits should be there by
default.
^ permalink raw reply
* Re: static inline int xfrm_mark_get() broken
From: Andreas Steffen @ 2010-06-30 5:03 UTC (permalink / raw)
To: Simon Horman
Cc: Steffen Andreas (asteffen@hsr.ch), netdev@vger.kernel.org, jamal
In-Reply-To: <20100630044637.GV2138@verge.net.au>
Hello Simon,
actually I don't care how this bug is going to be fixed, but with
sizeof(struct xfrm_mark) I'm dead certain that both the mark
value and mask are being copied. Actually in the next inline
function right below sizeof(struct xfrm_mark) is used, too:
static inline int xfrm_mark_put(struct sk_buff *skb, struct xfrm_mark *m)
{
if (m->m | m->v)
NLA_PUT(skb, XFRMA_MARK, sizeof(struct xfrm_mark), m);
return 0;
Regards
Andreas
On 06/30/2010 06:46 AM, Simon Horman wrote:
> On Mon, Jun 28, 2010 at 08:46:49PM +0200, Andreas Steffen wrote:
>> Hi,
>>
>> experimenting with the new XFRM_MARK feature of the 2.6.34 kernel
>> I found out that the extraction of the mark mask might accidentally
>> work on 64 bit platforms but on 32 bit platforms the function is
>> awfully broken. The rather trivial patch attached to this mail fixes
>> the problem. Otherwise the XFRM_MARK feature seems quite promising!
>>
>> Best regards
>>
>> Andreas
>>
>> ======================================================================
>> Andreas Steffen e-mail: andreas.steffen@hsr.ch
>> Institute for Internet Technologies and Applications
>> Hochschule fuer Technik Rapperswil phone: +41 55 222 42 68
>> CH-8640 Rapperswil (Switzerland) mobile: +41 76 340 25 56
>> ===========================================================[ITA-HSR]==
>
>> --- linux/include/net/xfrm.h.ori 2010-06-28 18:53:28.229489876 +0200
>> +++ linux/include/net/xfrm.h 2010-06-28 18:53:50.745487383 +0200
>> @@ -1587,7 +1587,7 @@
>> static inline int xfrm_mark_get(struct nlattr **attrs, struct xfrm_mark *m)
>> {
>> if (attrs[XFRMA_MARK])
>> - memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(m));
>> + memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(struct xfrm_mark));
>
> This fix looks correct to me, but
> I believe that sizeof(*m) is the preferred style.
>
>> else
>> m->v = m->m = 0;
======================================================================
Andreas Steffen e-mail: andreas.steffen@hsr.ch
Institute for Internet Technologies and Applications
Hochschule fuer Technik Rapperswil phone: +41 55 222 42 68
CH-8640 Rapperswil (Switzerland) mobile: +41 76 340 25 56
===========================================================[ITA-HSR]==
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/4] e1000e: don't inadvertently re-set INTX_DISABLE
From: David Miller @ 2010-06-30 6:14 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, dnelson, stable
In-Reply-To: <20100630040959.8652.31147.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Jun 2010 21:12:05 -0700
> From: Dean Nelson <dnelson@redhat.com>
>
> Should e1000_test_msi() fail to see an msi interrupt, it attempts to
> fallback to legacy INTx interrupts. But an error in the code may prevent
> this from happening correctly.
...
> The solution is to have e1000_test_msi() re-read the PCI_COMMAND bits as
> part of its attempt to re-enable SERR.
>
> During debugging/testing of this issue I found that not all the systems
> I ran on had the SERR bit set to begin with. And on some of the systems
> the same could be said for the INTX_DISABLE bit. Needless to say these
> latter systems didn't have a problem falling back to legacy INTx
> interrupts with the code as is.
>
> Signed-off-by: Dean Nelson <dnelson@redhat.com>
> CC: stable@kernel.org
> Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/4] e1000e: suppress compile warnings on certain archs
From: David Miller @ 2010-06-30 6:14 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bruce.w.allan
In-Reply-To: <20100630041228.8652.61761.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Jun 2010 21:12:30 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> Commit 84f4ee902ad3ee964b7b3a13d5b7cf9c086e9916 causes compile warnings on
> architectures that have unsigned long long's that are not 64-bit, e.g.
> ia64.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 3/4] e1000e: remove EEE module parameter
From: David Miller @ 2010-06-30 6:14 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bruce.w.allan
In-Reply-To: <20100630041249.8652.67388.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Jun 2010 21:12:52 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> As requested by Dave Miller. A follow-on set of patches will allow for
> ethtool to enable/disable the feature instead.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 4/4] e1000e: disable EEE support by default
From: David Miller @ 2010-06-30 6:15 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bhutchings, bruce.w.allan
In-Reply-To: <20100630041311.8652.42432.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Jun 2010 21:13:13 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> Based on community feedback, EEE should be disabled by default until the
> IEEE802.3az specification has been finalized.
>
> Cc: bhutchings@solarflare.com
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 1/3] ixgbe: fix panic when shutting down system with WoL enabled
From: David Miller @ 2010-06-30 6:15 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, andy, jesse.brandeburg
In-Reply-To: <20100630042739.8925.24962.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Jun 2010 21:28:12 -0700
> From: Andy Gospodarek <andy@greyhouse.net>
>
> This patch added to 2.6.34:
>
> commit 5f6c01819979afbfec7e0b15fe52371b8eed87e8
> Author: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Date: Wed Apr 14 16:04:23 2010 -0700
>
> ixgbe: fix bug with vlan strip in promsic mode
>
> among other things added a function called ixgbe_vlan_filter_enable.
> This new function wants to access and set some rx_ring parameters, but
> adapter->rx_ring has already been freed. This simply moves the free
> until after the access and makes __ixgbe_shutdown look more like
> ixgbe_remove.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 2/3] ixgbe: disable tx engine before disabling tx laser
From: David Miller @ 2010-06-30 6:15 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: netdev, gospo, bphilips, john.r.fastabend, peter.p.waskiewicz.jr
In-Reply-To: <20100630042836.8925.82492.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Jun 2010 21:28:36 -0700
> From: John Fastabend <john.r.fastabend@intel.com>
>
> Disabling the tx laser while receiving DMA requests
> can hang the device. After this occurs the device
> is in a bad state. The GPIO bit never clears when
> PCI master access is disabled and a reboot is required
> to get the device in a good state again.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 3/3] ixgbe: skip non IPv4 packets in ATR filter
From: David Miller @ 2010-06-30 6:15 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: netdev, gospo, bphilips, guillaume.gaudonville,
peter.p.waskiewicz.jr, donald.c.skidmore
In-Reply-To: <20100630042859.8925.23844.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Jun 2010 21:29:00 -0700
> From: Guillaume Gaudonville <guillaume.gaudonville@6wind.com>
>
> In driver ixgbe, ixgbe_atr may cause crashes for non-ipv4 packets. Just
> add a test to check skb->protocol. It may crash on short packets due
> to ip_hdr() access.
>
> Signed-off-by: Guillaume Gaudonville <guillaume.gaudonville@6wind.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCHv2 net-next-2.6] 3c59x: Use fine-grained locks for MII and windowed register access
From: David Miller @ 2010-06-30 6:15 UTC (permalink / raw)
To: ben; +Cc: steffen.klassert, netdev, chase.douglas, nordmark
In-Reply-To: <1277861216.28819.36.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Wed, 30 Jun 2010 02:26:56 +0100
> This avoids scheduling in atomic context and also means that IRQs
> will only be deferred for relatively short periods of time.
>
> Previously discussed in:
> http://article.gmane.org/gmane.linux.network/155024
>
> Reported-by: Arne Nordmark <nordmark@mech.kth.se>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Applied.
^ permalink raw reply
* Re: RFC: Allow 'ip' to run in daemon mode?
From: Stephen Hemminger @ 2010-06-30 7:00 UTC (permalink / raw)
To: Ben Greear, NetDev; +Cc: Stephen Hemminger
write a new service rather than bloating the existing code or just use netlink or libnl
Ben Greear <greearb@candelatech.com> wrote:
>I'm considering modifying 'ip' to be able to run in daemon
>mode so that I can do lots of IP commands without having to
>pay the startup cost of iproute.
>
>The -batch option almost works, but it's hard to programatically
>figure out failure codes.
>
>I'm thinking about making these changes:
>
>1) Move all of the error printing code into common methods (basically,
> wrap printf). In daemon mode this text can be sent back to the
> calling process, and in normal mode, it will be printed to stdout/stderr
> as it is currently.
>
>2) Remove all or most calls to 'exit' and instead return error codes
> to the calling logic.
>
>3) Add ability to listen on a unix socket for commands, basically treat
> them just like batch commands, one command per packet.
>
>4) Return well formatted error code and text response to calling process
> over the unix socket, maybe something like:
>
>RV: [errno or equiv, zero for success]\n
>CMD: [ command string this relates to ]\n
>[ Optional free form text ]
>
>
>Does something like this have any chance of upstream inclusion?
>
>Thanks,
>Ben
>
>--
>Ben Greear <greearb@candelatech.com>
>Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: static inline int xfrm_mark_get() broken
From: Simon Horman @ 2010-06-30 7:01 UTC (permalink / raw)
To: Andreas Steffen
Cc: Steffen Andreas (asteffen@hsr.ch), netdev@vger.kernel.org, jamal
In-Reply-To: <4C2AD009.40306@hsr.ch>
On Wed, Jun 30, 2010 at 07:03:05AM +0200, Andreas Steffen wrote:
> Hello Simon,
>
> actually I don't care how this bug is going to be fixed, but with
> sizeof(struct xfrm_mark) I'm dead certain that both the mark
> value and mask are being copied. Actually in the next inline
> function right below sizeof(struct xfrm_mark) is used, too:
>
> static inline int xfrm_mark_put(struct sk_buff *skb, struct xfrm_mark *m)
> {
> if (m->m | m->v)
> NLA_PUT(skb, XFRMA_MARK, sizeof(struct xfrm_mark), m);
> return 0;
In that case I withdraw my suggestion.
^ permalink raw reply
* ip6 route output() and ip_route_output_key() by drivers
From: Parav Pandit @ 2010-06-30 7:24 UTC (permalink / raw)
To: netdev
Hi,
Our device driver uses ip6 route output() and typecast the return value of dst_entry to rt6_info (similar to (net/ip6/icmp.c)
Driver uses (a) rt6i_dst.addr, (b) rt6i_dst.plen and (c) rt6i_gateway to get the route entry (ip/mask, gw, netdev).
Can anyone please confirm that drivers and/or netfilter kernel modules are allowed to use them? netdev drivers like : cnic.c, cxgb3, nes are using the ipv4 API (but not IPv6 API).
Also ip_route_output_key() rtable and dst_entry doesn't seem to provide route entry's subnet mask/prefix value. how drivers/netfilter kernel module can get a ip/mask gateway value while given a destination IP address as input?
I really appreciate your inputs. I hope I am asking it on the relevant mailing list.
Regards,
Parav Pandit
^ permalink raw reply
* Re: [Bridge] Bridge blocking network traffic
From: ratheesh k @ 2010-06-30 7:50 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Netfilter mailing list, netdev, bridge
In-Reply-To: <20100422130919.70206765@nehalam>
>>On Fri, Apr 23, 2010 at 1:39 AM, Stephen Hemminger <shemminger@linux-foundation.org> wrote:
>>You are supposed to assign IP address to bridge not the member of the bridge
Why is it so ?
I have a linux machine with interfaces eth0 (192.168.1.100 ) and
eth1 ( 192.168.2.100 ) . . I can connect both eth0 an eth1 to a
hardware HUB . How could i do this in linux machine itself using
brctl ?
Thanks,
Ratheesh
> On Thu, 22 Apr 2010 10:48:09 +1000
> benno joy <bennojoy@gmail.com> wrote:
>
>> Dear Team,
>>
>> I have a strange problem...... This is my problem i have a linux box running
>> Xen kernel (2.2). and i have the a bonding interface called bond0.497(eth0
>> and eth1 and also des Vlan tagging).
>> the bond0.497 is part of the bridge "xenbrv497", the issue is as soon as i
>> make the bond a part of the bridge my network traffic stops to work.
>> I did some prelimanary tests and found the following:
>> 1) if i assighn an ip to the bond and do a ping to the gateway it works
>> (provided it is not part of bridge xenbrv497)
>> 2) if i add the bondig interface to the brodge xenbrv497 (brclt addif
>> xenbrv497 bond0.497) the ping tests fails.
>> 3) i did a tcpdump and found that arp requests are going out of the
>> interface and we are getting response also. but soemhow
>> the arp entries are not gettign registered. i did some googling and found it
>> may be because of filtering so i disabled it by
>> echo 0 > in /proc/sys/net/bridge/bridge-nf-*.
>> But even this did not help still the arp entries are not getting registered
>> due to which my network traffic is gettign dropped.
>> This problem can be resolved by a reboot. but i would like to troubleshoot
>> it.
>> Could you please let me know how i can get more debugging message from the
>> bridge calls so i can figure out what exactly is happening.
>>
>> # uname -a
>> Linux vmclkxstgh04.espdev.aurdev.national.com.au 2.6.18-128.2.1.4.13.el5xen
>> #1 SMP Mon Dec 7 14:34:40 EST 2009 i686 i686 i386 GNU/Linux
>>
>> [root@vmclkxstgh04 ~]# brctl show
>> bridge name bridge id STP enabled interfaces
>> vlan441 8000.0017a4770470 no bond0.441
>> xenbrv205 8000.0017a477046c no bond1.205
>> xenbrv208 8000.0017a477046c no bond1.208
>> xenbrv220 8000.000000000000 no
>> xenbrv221 8000.000000000000 no
>> xenbrv226 8000.0017a477046c no vif40.1
>> vif39.1
>> vif37.1
>> vif26.1
>> vif25.1
>> vif24.1
>> vif13.1
>> bond1.226
>> xenbrv227 8000.0017a4770470 no vif40.0
>> vif39.0
>> vif37.0
>> vif26.0
>> vif25.0
>> vif24.0
>> vif13.0
>> bond0.227
>> xenbrv420 8000.0017a4770470 no bond0.420
>> xenbrv422 8000.0017a4770470 no vif35.0
>> vif7.0
>> vif6.0
>> vif4.0
>> vif3.0
>> vif2.0
>> tap2.0
>> bond0.422
>> xenbrv425 8000.0017a4770470 no bond0.425
>> xenbrv450 8000.0017a4770470 no bond0.450
>> xenbrv492 8000.0017a4770470 no bond0.492
>> xenbrv493 8000.0017a4770470 no bond0.493
>> xenbrv494 8000.0017a4770470 no bond0.494
>> xenbrv495 8000.0017a4770470 no bond0.495
>> xenbrv496 8000.0017a4770470 no bond0.496
>> xenbrv497 8000.0017a4770470 no bond0.497
>> xenbrv701 8000.0017a477046c no vif44.1
>> bond1.701
>>
>> bond0.497 Link encap:Ethernet HWaddr 00:17:A4:77:04:70
>> inet addr:10.12.166.231 Bcast:10.12.166.255 Mask:255.255.255.224
>> UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
>> RX packets:3807595 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:3304 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:0
>> RX bytes:188847200 (180.0 MiB) TX bytes:138768 (135.5 KiB)
>
> You are supposed to assign IP address to bridge not the member of the bridge.
>
>
> --
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge
>
^ permalink raw reply
* [PATCH] igbvf: avoid name clash between PF and VF
From: Stefan Assmann @ 2010-06-30 8:53 UTC (permalink / raw)
To: netdev; +Cc: e1000-devel, Andy Gospodarek, jeffrey.t.kirsher, gregory.v.rose
From: Stefan Assmann <sassmann@redhat.com>
It looks like the VFs get initialized before all the PFs are. Therefore
the udev mapping MAC <-> ethX (for PFs) gets screwed because the VFs
may grab the ethX interface names (reserved by udev) for the PFs.
Example:
igb max_vfs=0
eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E
eth1 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F
eth2 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0
eth3 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1
igb max_vfs=1
eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E
eth1 Link encap:Ethernet HWaddr 0A:CF:41:69:F7:A9
eth2 Link encap:Ethernet HWaddr 3A:FE:20:4C:2A:3B
eth3 Link encap:Ethernet HWaddr C6:C3:B1:56:C9:A4
eth3_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F
eth4 Link encap:Ethernet HWaddr 6E:8A:8A:A3:5F:69
eth4_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0
eth5_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1
In the example above VF 0A:CF:41:69:F7:A9 grabs eth1 but udev
has a rule that says eth1 should be assigned PF 00:13:20:F7:A5:9F
(eth3_rename) and waits for the VF to disappear to rename eth3_rename
to eth1. Unfortunately eth1 is not going to disappear.
This is not a udev bug since udev doesn't create persistent rules for
VFs as their MAC address changes every reboot.
To avoid this problem we could change the kernel name for the VFs and
thus avoid confusion between VFs and PFs.
I've already discussed this with Alexander Duyck and Greg Rose, so far
they have no objection. However this problem appears for all drivers that
support PFs and VFs and thus the changes should be applied consistently
to all of these drivers.
Signed-off-by: Stefan Assmann <sassmann@redhat.com>
---
drivers/net/igbvf/netdev.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/igbvf/netdev.c b/drivers/net/igbvf/netdev.c
index 5e2b2a8..2fb665b 100644
--- a/drivers/net/igbvf/netdev.c
+++ b/drivers/net/igbvf/netdev.c
@@ -2787,7 +2787,7 @@ static int __devinit igbvf_probe(struct pci_dev *pdev,
netif_carrier_off(netdev);
netif_stop_queue(netdev);
- strcpy(netdev->name, "eth%d");
+ strcpy(netdev->name, "veth%d");
err = register_netdev(netdev);
if (err)
goto err_hw_init;
--
1.6.5.2
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply related
* [PATCH] act_mirred: combine duplicate code
From: Changli Gao @ 2010-06-30 8:54 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: David S. Miller, netdev, linux-kernel, Changli Gao
act_mirred: combine duplicate code
tcf_bstats is updated in any way, so we can do it earlier to reduce the size of
the code.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
net/sched/act_mirred.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
index 2e9a7b9..a16b017 100644
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -160,6 +160,8 @@ static int tcf_mirred(struct sk_buff *skb, struct tc_action *a,
spin_lock(&m->tcf_lock);
m->tcf_tm.lastuse = jiffies;
+ m->tcf_bstats.bytes += qdisc_pkt_len(skb);
+ m->tcf_bstats.packets++;
dev = m->tcfm_dev;
if (!(dev->flags & IFF_UP)) {
@@ -174,8 +176,6 @@ static int tcf_mirred(struct sk_buff *skb, struct tc_action *a,
if (skb2 == NULL)
goto out;
- m->tcf_bstats.bytes += qdisc_pkt_len(skb2);
- m->tcf_bstats.packets++;
if (!(at & AT_EGRESS)) {
if (m->tcfm_ok_push)
skb_push(skb2, skb2->dev->hard_header_len);
@@ -193,8 +193,6 @@ static int tcf_mirred(struct sk_buff *skb, struct tc_action *a,
out:
if (err) {
m->tcf_qstats.overlimits++;
- m->tcf_bstats.bytes += qdisc_pkt_len(skb);
- m->tcf_bstats.packets++;
/* should we be asking for packet to be dropped?
* may make sense for redirect case only
*/
^ permalink raw reply related
* [PATCH v2] net/core: use ntohs for skb->protocol
From: Sebastian Andrzej Siewior @ 2010-06-30 9:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100629.151740.135534374.davem@davemloft.net>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
This is only noticed by people that are not doing everything correct in
the first place.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
net/core/dev.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index eb4be99..8e61dc5 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1537,7 +1537,8 @@ static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
if (net_ratelimit())
printk(KERN_CRIT "protocol %04x is "
"buggy, dev %s\n",
- skb2->protocol, dev->name);
+ ntohs(skb2->protocol),
+ dev->name);
skb_reset_network_header(skb2);
}
--
1.6.6.1
^ permalink raw reply related
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