* Re: [PATCH 1/2] rps: core implementation
From: Andi Kleen @ 2009-11-19 10:08 UTC (permalink / raw)
To: Tom Herbert; +Cc: Andi Kleen, David Miller, netdev
In-Reply-To: <65634d660911160902t677a4fb4r71602cb0d10f1cce@mail.gmail.com>
On Mon, Nov 16, 2009 at 09:02:32AM -0800, Tom Herbert wrote:
Sorry for the late answer.
> >> + case __constant_htons(ETH_P_IPV6):
> >> + if (!pskb_may_pull(skb, sizeof(*ip6)))
> >> + return -1;
> >> +
> >> + ip6 = (struct ipv6hdr *) skb->data;
> >> + ip_proto = ip6->nexthdr;
> >> + addr1 = ip6->saddr.s6_addr32[3];
> >> + addr2 = ip6->daddr.s6_addr32[3];
> >
> > Why only [3] ? Is this future proof?
> >
> No. But it's same as inet6_ehashfn :-)
Perhaps it would be good to consolidate all these ipv6 hashes
into one place where they could be at least fixed easily.
>
> >> + for_each_cpu_mask_nr(cpu, __get_cpu_var(rps_remote_softirq_cpus)) {
> >> + struct softnet_data *queue = &per_cpu(softnet_data, cpu);
> >> + __smp_call_function_single(cpu, &queue->csd, 0);
> >
> > How do you get around the standard deadlocks with IPI called from
> > irq disabled section?
> >
>
> What are the standard deadlocks? Looks like __send_remote_softirq
> will call __smp_call_function with irq's disabled...
The traditional deadlock (that was before the queue smp_call_function)
was
A B
grab lock
interrupts off
spin on lock
send IPI
wait for specific CPU
never answers because
interrupts are off
hangs forever
I think with the queued smp_call_function it's better because
the locks are only hold much shorter and that particular scenario
is gone, but I'm not sure the problem has fully gone away.
At least there are still plenty of WARN_ON( ... irqs_disabled()) in
kernel/smp.c
> > It's a standard pet peeve of me, but it's quite unlikely you'll
> > get any useful entropy at this time of kernel startup.
> >
> > Normally it's always the same.
> >
> Would it make sense to just use skb_tx_hashrnd for the receive hash
> key also (renaming it to be more general)?
That has the same problem, although it's at least a bit later,
but I suspect it would be still not very random.
You could just drop it and always use a constant hash rnd?
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* [PATCH-v2 0/3] TI EMAC driver : Make driver re-usable on non-davinci platforms.
From: Sriramakrishnan @ 2009-11-19 10:28 UTC (permalink / raw)
To: davinci-linux-open-source; +Cc: netdev, Sriramakrishnan
The Davinci EMAC peripheral is also available on other TI platforms -
notably TI AM3517 SoC. The following series of patches modify the driver
suitably to make it platform agnostic.
This patch has been generated against the tip of linux-davinci git.
Sriramakrishnan (3):
TI Davinci EMAC : Re-use driver for other platforms.
TI Davinci EMAC : add platform specific interrupt enable/disable
logic.
TI Davinci EMAC : Abstract Buffer address translation logic.
arch/arm/mach-davinci/common.c | 2 +-
arch/arm/mach-davinci/include/mach/da8xx.h | 2 +-
arch/arm/mach-davinci/include/mach/dm365.h | 2 +-
arch/arm/mach-davinci/include/mach/dm644x.h | 2 +-
arch/arm/mach-davinci/include/mach/dm646x.h | 2 +-
arch/arm/mach-davinci/include/mach/emac.h | 36 -----------------
drivers/net/Kconfig | 2 +-
drivers/net/davinci_emac.c | 55 +++++++++++++++++---------
include/linux/davinci_emac.h | 39 +++++++++++++++++++
9 files changed, 81 insertions(+), 61 deletions(-)
delete mode 100644 arch/arm/mach-davinci/include/mach/emac.h
create mode 100644 include/linux/davinci_emac.h
^ permalink raw reply
* [PATCH-v2 2/3] TI Davinci EMAC : add platform specific interrupt enable/disable logic.
From: Sriramakrishnan @ 2009-11-19 10:28 UTC (permalink / raw)
To: davinci-linux-open-source; +Cc: netdev, Sriramakrishnan
In-Reply-To: <1258626507-5570-2-git-send-email-srk@ti.com>
On certain SOCs, the EMAC controller is interfaced with a wrapper logic
for handling interrupts. This patch implements a platform
specific hook to cater to platforms that require custom interrupt
handling logic
Signed-off-by: Sriramakrishnan <srk@ti.com>
Acked-by: Chaithrika U S <chaithrika@ti.com>
Acked-by: David S. Miller <davem@davemloft.net>
---
drivers/net/davinci_emac.c | 11 +++++++++++
include/linux/davinci_emac.h | 2 ++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 6aec8f5..5372582 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -487,6 +487,9 @@ struct emac_priv {
struct mii_bus *mii_bus;
struct phy_device *phydev;
spinlock_t lock;
+ /*platform specific members*/
+ void (*int_enable) (void);
+ void (*int_disable) (void);
};
/* clock frequency for EMAC */
@@ -1001,6 +1004,8 @@ static void emac_int_disable(struct emac_priv *priv)
emac_ctrl_write(EMAC_DM646X_CMRXINTEN, 0x0);
emac_ctrl_write(EMAC_DM646X_CMTXINTEN, 0x0);
/* NOTE: Rx Threshold and Misc interrupts are not disabled */
+ if (priv->int_disable)
+ priv->int_disable();
local_irq_restore(flags);
@@ -1020,6 +1025,9 @@ static void emac_int_disable(struct emac_priv *priv)
static void emac_int_enable(struct emac_priv *priv)
{
if (priv->version == EMAC_VERSION_2) {
+ if (priv->int_enable)
+ priv->int_enable();
+
emac_ctrl_write(EMAC_DM646X_CMRXINTEN, 0xff);
emac_ctrl_write(EMAC_DM646X_CMTXINTEN, 0xff);
@@ -2662,6 +2670,9 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
priv->phy_mask = pdata->phy_mask;
priv->rmii_en = pdata->rmii_en;
priv->version = pdata->version;
+ priv->int_enable = pdata->interrupt_enable;
+ priv->int_disable = pdata->interrupt_disable;
+
emac_dev = &ndev->dev;
/* Get EMAC platform data */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
diff --git a/include/linux/davinci_emac.h b/include/linux/davinci_emac.h
index ff55487..6d894ef 100644
--- a/include/linux/davinci_emac.h
+++ b/include/linux/davinci_emac.h
@@ -25,6 +25,8 @@ struct emac_platform_data {
u32 mdio_max_freq;
u8 rmii_en;
u8 version;
+ void (*interrupt_enable) (void);
+ void (*interrupt_disable) (void);
};
enum {
--
1.6.2.4
^ permalink raw reply related
* [PATCH-v2 1/3] TI Davinci EMAC : Re-use driver for other platforms.
From: Sriramakrishnan @ 2009-11-19 10:28 UTC (permalink / raw)
To: davinci-linux-open-source; +Cc: netdev, Sriramakrishnan
In-Reply-To: <1258626507-5570-1-git-send-email-srk@ti.com>
The davinci EMAC peripheral is also available on other TI
platforms -notably TI AM3517 SoC. This patch modifies the
config option and the platform structure header files so that
the driver can be reused on non-davinci platforms as well.
Signed-off-by: Sriramakrishnan <srk@ti.com>
Acked-by: Chaithrika U S <chaithrika@ti.com>
Acked-by: David S. Miller <davem@davemloft.net>
---
arch/arm/mach-davinci/common.c | 2 +-
arch/arm/mach-davinci/include/mach/da8xx.h | 2 +-
arch/arm/mach-davinci/include/mach/dm365.h | 2 +-
arch/arm/mach-davinci/include/mach/dm644x.h | 2 +-
arch/arm/mach-davinci/include/mach/dm646x.h | 2 +-
arch/arm/mach-davinci/include/mach/emac.h | 36 ---------------------------
drivers/net/Kconfig | 2 +-
drivers/net/davinci_emac.c | 3 +-
include/linux/davinci_emac.h | 36 +++++++++++++++++++++++++++
9 files changed, 43 insertions(+), 44 deletions(-)
delete mode 100644 arch/arm/mach-davinci/include/mach/emac.h
create mode 100644 include/linux/davinci_emac.h
diff --git a/arch/arm/mach-davinci/common.c b/arch/arm/mach-davinci/common.c
index c2de94c..94f27cb 100644
--- a/arch/arm/mach-davinci/common.c
+++ b/arch/arm/mach-davinci/common.c
@@ -11,13 +11,13 @@
#include <linux/module.h>
#include <linux/io.h>
#include <linux/etherdevice.h>
+#include <linux/davinci_emac.h>
#include <asm/tlb.h>
#include <asm/mach/map.h>
#include <mach/common.h>
#include <mach/cputype.h>
-#include <mach/emac.h>
#include "clock.h"
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index 9070491..2af95ff 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -13,10 +13,10 @@
#include <video/da8xx-fb.h>
+#include <linux/davinci_emac.h>
#include <mach/serial.h>
#include <mach/edma.h>
#include <mach/i2c.h>
-#include <mach/emac.h>
#include <mach/asp.h>
#include <mach/mmc.h>
#include <mach/usb.h>
diff --git a/arch/arm/mach-davinci/include/mach/dm365.h b/arch/arm/mach-davinci/include/mach/dm365.h
index f1710a3..3c07a88 100644
--- a/arch/arm/mach-davinci/include/mach/dm365.h
+++ b/arch/arm/mach-davinci/include/mach/dm365.h
@@ -14,8 +14,8 @@
#define __ASM_ARCH_DM665_H
#include <linux/platform_device.h>
+#include <linux/davinci_emac.h>
#include <mach/hardware.h>
-#include <mach/emac.h>
#include <mach/asp.h>
#include <mach/keyscan.h>
diff --git a/arch/arm/mach-davinci/include/mach/dm644x.h b/arch/arm/mach-davinci/include/mach/dm644x.h
index 44e8f0f..1a8b09c 100644
--- a/arch/arm/mach-davinci/include/mach/dm644x.h
+++ b/arch/arm/mach-davinci/include/mach/dm644x.h
@@ -22,8 +22,8 @@
#ifndef __ASM_ARCH_DM644X_H
#define __ASM_ARCH_DM644X_H
+#include <linux/davinci_emac.h>
#include <mach/hardware.h>
-#include <mach/emac.h>
#include <mach/asp.h>
#include <media/davinci/vpfe_capture.h>
diff --git a/arch/arm/mach-davinci/include/mach/dm646x.h b/arch/arm/mach-davinci/include/mach/dm646x.h
index 8cec746..5c92dfb 100644
--- a/arch/arm/mach-davinci/include/mach/dm646x.h
+++ b/arch/arm/mach-davinci/include/mach/dm646x.h
@@ -12,10 +12,10 @@
#define __ASM_ARCH_DM646X_H
#include <mach/hardware.h>
-#include <mach/emac.h>
#include <mach/asp.h>
#include <linux/i2c.h>
#include <linux/videodev2.h>
+#include <linux/davinci_emac.h>
#define DM646X_EMAC_BASE (0x01C80000)
#define DM646X_EMAC_CNTRL_OFFSET (0x0000)
diff --git a/arch/arm/mach-davinci/include/mach/emac.h b/arch/arm/mach-davinci/include/mach/emac.h
deleted file mode 100644
index beff4fb..0000000
--- a/arch/arm/mach-davinci/include/mach/emac.h
+++ /dev/null
@@ -1,36 +0,0 @@
-/*
- * TI DaVinci EMAC platform support
- *
- * Author: Kevin Hilman, Deep Root Systems, LLC
- *
- * 2007 (c) Deep Root Systems, LLC. This file is licensed under
- * the terms of the GNU General Public License version 2. This program
- * is licensed "as is" without any warranty of any kind, whether express
- * or implied.
- */
-#ifndef _MACH_DAVINCI_EMAC_H
-#define _MACH_DAVINCI_EMAC_H
-
-#include <linux/if_ether.h>
-#include <linux/memory.h>
-
-struct emac_platform_data {
- char mac_addr[ETH_ALEN];
- u32 ctrl_reg_offset;
- u32 ctrl_mod_reg_offset;
- u32 ctrl_ram_offset;
- u32 mdio_reg_offset;
- u32 ctrl_ram_size;
- u32 phy_mask;
- u32 mdio_max_freq;
- u8 rmii_en;
- u8 version;
-};
-
-enum {
- EMAC_VERSION_1, /* DM644x */
- EMAC_VERSION_2, /* DM646x */
-};
-
-void davinci_get_mac_addr(struct memory_accessor *mem_acc, void *context);
-#endif
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index e19ca4b..2d3443c 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -920,7 +920,7 @@ config NET_NETX
config TI_DAVINCI_EMAC
tristate "TI DaVinci EMAC Support"
- depends on ARM && ARCH_DAVINCI
+ depends on ARM && ( ARCH_DAVINCI || ARCH_OMAP3 )
select PHYLIB
help
This driver supports TI's DaVinci Ethernet .
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 4cf80ec..6aec8f5 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -62,12 +62,11 @@
#include <linux/bitops.h>
#include <linux/io.h>
#include <linux/uaccess.h>
+#include <linux/davinci_emac.h>
#include <asm/irq.h>
#include <asm/page.h>
-#include <mach/emac.h>
-
static int debug_level;
module_param(debug_level, int, 0);
MODULE_PARM_DESC(debug_level, "DaVinci EMAC debug level (NETIF_MSG bits)");
diff --git a/include/linux/davinci_emac.h b/include/linux/davinci_emac.h
new file mode 100644
index 0000000..ff55487
--- /dev/null
+++ b/include/linux/davinci_emac.h
@@ -0,0 +1,36 @@
+/*
+ * TI DaVinci EMAC platform support
+ *
+ * Author: Kevin Hilman, Deep Root Systems, LLC
+ *
+ * 2007 (c) Deep Root Systems, LLC. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#ifndef _LINUX_DAVINCI_EMAC_H
+#define _LINUX_DAVINCI_EMAC_H
+
+#include <linux/if_ether.h>
+#include <linux/memory.h>
+
+struct emac_platform_data {
+ char mac_addr[ETH_ALEN];
+ u32 ctrl_reg_offset;
+ u32 ctrl_mod_reg_offset;
+ u32 ctrl_ram_offset;
+ u32 mdio_reg_offset;
+ u32 ctrl_ram_size;
+ u32 phy_mask;
+ u32 mdio_max_freq;
+ u8 rmii_en;
+ u8 version;
+};
+
+enum {
+ EMAC_VERSION_1, /* DM644x */
+ EMAC_VERSION_2, /* DM646x */
+};
+
+void davinci_get_mac_addr(struct memory_accessor *mem_acc, void *context);
+#endif
--
1.6.2.4
^ permalink raw reply related
* [PATCH-v2 3/3] TI Davinci EMAC : Abstract Buffer address translation logic.
From: Sriramakrishnan @ 2009-11-19 10:28 UTC (permalink / raw)
To: davinci-linux-open-source; +Cc: netdev, Sriramakrishnan
In-Reply-To: <1258626507-5570-3-git-send-email-srk@ti.com>
When programming the DMA engine, the next pointers must be
programmed with physical address as seen from the DMA master
address space. This address may be different from physical
address of the buffer RAM area. This patch abstracts the
buffer address translation logic.
Signed-off-by: Sriramakrishnan <srk@ti.com>
Acked-by: Chaithrika U S <chaithrika@ti.com>
Acked-by: David S. Miller <davem@davemloft.net>
---
drivers/net/davinci_emac.c | 41 ++++++++++++++++++++++++-----------------
include/linux/davinci_emac.h | 1 +
2 files changed, 25 insertions(+), 17 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 5372582..9fed476 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -464,6 +464,7 @@ struct emac_priv {
void __iomem *ctrl_base;
void __iomem *emac_ctrl_ram;
u32 ctrl_ram_size;
+ u32 hw_ram_addr;
struct emac_txch *txch[EMAC_DEF_MAX_TX_CH];
struct emac_rxch *rxch[EMAC_DEF_MAX_RX_CH];
u32 link; /* 1=link on, 0=link off */
@@ -497,11 +498,9 @@ static struct clk *emac_clk;
static unsigned long emac_bus_frequency;
static unsigned long mdio_max_freq;
-/* EMAC internal utility function */
-static inline u32 emac_virt_to_phys(void __iomem *addr)
-{
- return (u32 __force) io_v2p(addr);
-}
+#define emac_virt_to_phys(addr, priv) \
+ (((u32 __force)(addr) - (u32 __force)(priv->emac_ctrl_ram)) \
+ + priv->hw_ram_addr)
/* Cache macros - Packet buffers would be from skb pool which is cached */
#define EMAC_VIRT_NOCACHE(addr) (addr)
@@ -1309,7 +1308,7 @@ static int emac_tx_bdproc(struct emac_priv *priv, u32 ch, u32 budget)
curr_bd = txch->active_queue_head;
if (NULL == curr_bd) {
emac_write(EMAC_TXCP(ch),
- emac_virt_to_phys(txch->last_hw_bdprocessed));
+ emac_virt_to_phys(txch->last_hw_bdprocessed, priv));
txch->no_active_pkts++;
spin_unlock_irqrestore(&priv->tx_lock, flags);
return 0;
@@ -1319,7 +1318,7 @@ static int emac_tx_bdproc(struct emac_priv *priv, u32 ch, u32 budget)
while ((curr_bd) &&
((frame_status & EMAC_CPPI_OWNERSHIP_BIT) == 0) &&
(pkts_processed < budget)) {
- emac_write(EMAC_TXCP(ch), emac_virt_to_phys(curr_bd));
+ emac_write(EMAC_TXCP(ch), emac_virt_to_phys(curr_bd, priv));
txch->active_queue_head = curr_bd->next;
if (frame_status & EMAC_CPPI_EOQ_BIT) {
if (curr_bd->next) { /* misqueued packet */
@@ -1406,7 +1405,7 @@ static int emac_send(struct emac_priv *priv, struct emac_netpktobj *pkt, u32 ch)
txch->active_queue_tail = curr_bd;
if (1 != txch->queue_active) {
emac_write(EMAC_TXHDP(ch),
- emac_virt_to_phys(curr_bd));
+ emac_virt_to_phys(curr_bd, priv));
txch->queue_active = 1;
}
++txch->queue_reinit;
@@ -1418,10 +1417,11 @@ static int emac_send(struct emac_priv *priv, struct emac_netpktobj *pkt, u32 ch)
tail_bd->next = curr_bd;
txch->active_queue_tail = curr_bd;
tail_bd = EMAC_VIRT_NOCACHE(tail_bd);
- tail_bd->h_next = (int)emac_virt_to_phys(curr_bd);
+ tail_bd->h_next = (int)emac_virt_to_phys(curr_bd, priv);
frame_status = tail_bd->mode;
if (frame_status & EMAC_CPPI_EOQ_BIT) {
- emac_write(EMAC_TXHDP(ch), emac_virt_to_phys(curr_bd));
+ emac_write(EMAC_TXHDP(ch),
+ emac_virt_to_phys(curr_bd, priv));
frame_status &= ~(EMAC_CPPI_EOQ_BIT);
tail_bd->mode = frame_status;
++txch->end_of_queue_add;
@@ -1611,7 +1611,8 @@ static int emac_init_rxch(struct emac_priv *priv, u32 ch, char *param)
}
/* populate the hardware descriptor */
- curr_bd->h_next = emac_virt_to_phys(rxch->active_queue_head);
+ curr_bd->h_next = emac_virt_to_phys(rxch->active_queue_head,
+ priv);
/* FIXME buff_ptr = dma_map_single(... data_ptr ...) */
curr_bd->buff_ptr = virt_to_phys(curr_bd->data_ptr);
curr_bd->off_b_len = rxch->buf_size;
@@ -1886,7 +1887,7 @@ static void emac_addbd_to_rx_queue(struct emac_priv *priv, u32 ch,
rxch->active_queue_tail = curr_bd;
if (0 != rxch->queue_active) {
emac_write(EMAC_RXHDP(ch),
- emac_virt_to_phys(rxch->active_queue_head));
+ emac_virt_to_phys(rxch->active_queue_head, priv));
rxch->queue_active = 1;
}
} else {
@@ -1897,11 +1898,11 @@ static void emac_addbd_to_rx_queue(struct emac_priv *priv, u32 ch,
rxch->active_queue_tail = curr_bd;
tail_bd->next = curr_bd;
tail_bd = EMAC_VIRT_NOCACHE(tail_bd);
- tail_bd->h_next = emac_virt_to_phys(curr_bd);
+ tail_bd->h_next = emac_virt_to_phys(curr_bd, priv);
frame_status = tail_bd->mode;
if (frame_status & EMAC_CPPI_EOQ_BIT) {
emac_write(EMAC_RXHDP(ch),
- emac_virt_to_phys(curr_bd));
+ emac_virt_to_phys(curr_bd, priv));
frame_status &= ~(EMAC_CPPI_EOQ_BIT);
tail_bd->mode = frame_status;
++rxch->end_of_queue_add;
@@ -1994,7 +1995,7 @@ static int emac_rx_bdproc(struct emac_priv *priv, u32 ch, u32 budget)
curr_pkt->num_bufs = 1;
curr_pkt->pkt_length =
(frame_status & EMAC_RX_BD_PKT_LENGTH_MASK);
- emac_write(EMAC_RXCP(ch), emac_virt_to_phys(curr_bd));
+ emac_write(EMAC_RXCP(ch), emac_virt_to_phys(curr_bd, priv));
++rxch->processed_bd;
last_bd = curr_bd;
curr_bd = last_bd->next;
@@ -2005,7 +2006,7 @@ static int emac_rx_bdproc(struct emac_priv *priv, u32 ch, u32 budget)
if (curr_bd) {
++rxch->mis_queued_packets;
emac_write(EMAC_RXHDP(ch),
- emac_virt_to_phys(curr_bd));
+ emac_virt_to_phys(curr_bd, priv));
} else {
++rxch->end_of_queue;
rxch->queue_active = 0;
@@ -2106,7 +2107,7 @@ static int emac_hw_enable(struct emac_priv *priv)
emac_write(EMAC_RXINTMASKSET, BIT(ch));
rxch->queue_active = 1;
emac_write(EMAC_RXHDP(ch),
- emac_virt_to_phys(rxch->active_queue_head));
+ emac_virt_to_phys(rxch->active_queue_head, priv));
}
/* Enable MII */
@@ -2705,6 +2706,12 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
priv->ctrl_ram_size = pdata->ctrl_ram_size;
priv->emac_ctrl_ram = priv->remap_addr + pdata->ctrl_ram_offset;
+ if (pdata->hw_ram_addr)
+ priv->hw_ram_addr = pdata->hw_ram_addr;
+ else
+ priv->hw_ram_addr = (u32 __force)res->start +
+ pdata->ctrl_ram_offset;
+
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res) {
dev_err(emac_dev, "DaVinci EMAC: Error getting irq res\n");
diff --git a/include/linux/davinci_emac.h b/include/linux/davinci_emac.h
index 6d894ef..7c930db 100644
--- a/include/linux/davinci_emac.h
+++ b/include/linux/davinci_emac.h
@@ -19,6 +19,7 @@ struct emac_platform_data {
u32 ctrl_reg_offset;
u32 ctrl_mod_reg_offset;
u32 ctrl_ram_offset;
+ u32 hw_ram_addr;
u32 mdio_reg_offset;
u32 ctrl_ram_size;
u32 phy_mask;
--
1.6.2.4
^ permalink raw reply related
* [PATCH] ieee802154: dont leak skbs in ieee802154_fake_xmit()
From: Eric Dumazet @ 2009-11-19 11:28 UTC (permalink / raw)
To: David S. Miller; +Cc: Dmitry Eremin-Solenikov, Linux Netdev List
ieee802154_fake_xmit() should free skbs since it returns NETDEV_TX_OK
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/drivers/ieee802154/fakehard.c b/drivers/ieee802154/fakehard.c
index 96a2959..7c544f7 100644
--- a/drivers/ieee802154/fakehard.c
+++ b/drivers/ieee802154/fakehard.c
@@ -260,15 +260,12 @@ static int ieee802154_fake_close(struct net_device *dev)
static netdev_tx_t ieee802154_fake_xmit(struct sk_buff *skb,
struct net_device *dev)
{
- skb->iif = dev->ifindex;
- skb->dev = dev;
dev->stats.tx_packets++;
dev->stats.tx_bytes += skb->len;
- dev->trans_start = jiffies;
-
/* FIXME: do hardware work here ... */
+ dev_kfree_skb(skb);
return NETDEV_TX_OK;
}
^ permalink raw reply related
* Re: [PATCH 1/3] macvlan: Reflect macvlan packets meant for other macvlan devices
From: Arnd Bergmann @ 2009-11-19 11:44 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Eric Dumazet, linux-kernel, netdev, David Miller,
Stephen Hemminger, Herbert Xu, Patrick McHardy, Patrick Mullaney,
Edge Virtual Bridging, Anna Fischer, bridge, virtualization,
Jens Osterkamp, Gerhard Stenzel
In-Reply-To: <m1bpiz8k1x.fsf@fess.ebiederm.org>
On Thursday 19 November 2009, Eric W. Biederman wrote:
> > It seems that we should never drop dst then. We either forward the frame to
> > netif_rx or to dev_queue_xmit, and from how I read it now, we want to keep
> > the dst in both cases.
>
> When we loop back on our selves we certainly need to have dst clear because
> we don't know how to cache routes through multiple network namespaces.
Ah, right. So should I add the explicit dst_drop to the new dev_forward_skb()
then? The veth driver doesn't need it, but it also looks like it won't hurt.
Arnd <><
^ permalink raw reply
* Oops in Unix sockets code
From: Blaschka @ 2009-11-19 13:20 UTC (permalink / raw)
To: netdev, linux-s390
Hi,
running disk tests on s390x (kernel 2.6.31) we get following Oops in Unix domain
socket code (hald process). Can somebody help? We do get this Oops from time to
time so we are willing to test a patch or provide additional debug data if
required.
Thanks,
Frank
<1>Unable to handle kernel pointer dereference at virtual kernel address 000000007575e000
<4>Oops: 0011 [#1] PREEMPT SMP DEBUG_PAGEALLOC
<4>Modules linked in: sunrpc qeth_l3 dm_multipath dm_mod qeth ccwgroup chsc_sch
<4>CPU: 0 Not tainted 2.6.31-39.x.20091102-s390xdefault #1
<4>Process hald (pid: 2117, task: 000000007d200c40, ksp: 000000007ab33880)
<4>Krnl PSW : 0704100180000000 00000000003a15f8 (_raw_read_trylock+0x0/0x28)
<4> R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:1 PM:0 EA:3
<4>Krnl GPRS: 16c8a00000000000 000000007d200c40 000000007575ed18 0000000000000003
<4> 00000000005853d2 000000007d201470 0000000000000002 000000007ab33c30
<4> 0000000075746c78 000000007a74da48 000000000051a16a 000000007575ed18
<4> 000000007575ed30 00000000005da190 00000000005853dc 000000007ab338c8
<4>Krnl Code: 00000000003a15e8: c03000185811 larl %r3,6ac60a
<4> 00000000003a15ee: c0e5fffffdd9 brasl %r14,3a11a0
<4> 00000000003a15f4: a7f4ffce brc 15,3a1590
<4> >00000000003a15f8: 58302000 l %r3,0(%r2)
<4> 00000000003a15fc: b9170033 llgtr %r3,%r3
<4> 00000000003a1600: 1853 lr %r5,%r3
<4> 00000000003a1602: 1813 lr %r1,%r3
<4> 00000000003a1604: a75a0001 ahi %r5,1
<4>Call Trace:
<4>([<00000000005853d2>] _read_lock+0x5a/0x98)
<4> [<000000000051a16a>] unix_write_space+0x36/0xb0
<4> [<00000000004788a8>] sock_wfree+0x80/0x84
<4> [<000000000047dc08>] skb_release_head_state+0x88/0x140
<4> [<000000000047d7ec>] __kfree_skb+0x28/0x10c
<4> [<0000000000481d7e>] skb_free_datagram+0x32/0x6c
<4> [<0000000000517a46>] unix_dgram_recvmsg+0x246/0x38c
<4> [<0000000000474036>] sock_recvmsg+0xe2/0x118
<4> [<00000000004754f8>] SyS_recvmsg+0x134/0x310
<4> [<0000000000472f14>] SyS_socketcall+0xfc/0x31c
<4> [<0000000000117f9e>] sysc_noemu+0x10/0x16
<4> [<0000004f131a95ae>] 0x4f131a95ae
<4>INFO: lockdep is turned off.
<4>Last Breaking-Event-Address:
<4> [<00000000005853d6>] _read_lock+0x5e/0x98
<4>
<0>Kernel panic - not syncing: Fatal exception: panic_on_oops
<4>CPU: 0 Tainted: G D 2.6.31-39.x.20091102-s390xdefault #1
<4>Process hald (pid: 2117, task: 000000007d200c40, ksp: 000000007ab33880)
<4>0000000000000000 000000007ab33588 0000000000000002 0000000000000000
<4> 000000007ab33628 000000007ab335a0 000000007ab335a0 00000000005801b8
<4> 0000000000000001 0000000000000000 000000007ab33c30 0000000000000000
<4> 000000000000000d 0000000000000000 000000007ab335f8 000000000000000e
<4> 000000000058fc18 0000000000105700 000000007ab33588 000000007ab335d0
<4>Call Trace:
<4>([<00000000001055fc>] show_trace+0xf0/0x148)
<4> [<0000000000580022>] panic+0xa2/0x1e4
<4> [<0000000000105bf8>] die+0x14c/0x168
<4> [<00000000001012d8>] do_no_context+0xa8/0xe8
<4> [<000000000058597c>] do_dat_exception+0x134/0x338
<4> [<0000000000117fa4>] sysc_return+0x0/0x8
<4> [<00000000003a15f8>] _raw_read_trylock+0x0/0x28
<4>([<00000000005853d2>] _read_lock+0x5a/0x98)
<4> [<000000000051a16a>] unix_write_space+0x36/0xb0
<4> [<00000000004788a8>] sock_wfree+0x80/0x84
<4> [<000000000047dc08>] skb_release_head_state+0x88/0x140
<4> [<000000000047d7ec>] __kfree_skb+0x28/0x10c
<4> [<0000000000481d7e>] skb_free_datagram+0x32/0x6c
<4> [<0000000000517a46>] unix_dgram_recvmsg+0x246/0x38c
<4> [<0000000000474036>] sock_recvmsg+0xe2/0x118
<4> [<00000000004754f8>] SyS_recvmsg+0x134/0x310
<4> [<0000000000472f14>] SyS_socketcall+0xfc/0x31c
<4> [<0000000000117f9e>] sysc_noemu+0x10/0x16
<4> [<0000004f131a95ae>] 0x4f131a95ae
<4>INFO: lockdep is turned off.
^ permalink raw reply
* Re: Oops in Unix sockets code
From: Christian Borntraeger @ 2009-11-19 13:40 UTC (permalink / raw)
To: Blaschka; +Cc: netdev, linux-s390
In-Reply-To: <20091119132028.GA22427@tuxmaker.boeblingen.de.ibm.com>
Am Donnerstag 19 November 2009 14:20:28 schrieb Blaschka:
> <1>Unable to handle kernel pointer dereference at virtual kernel address 000000007575e000
> <4>Oops: 0011 [#1] PREEMPT SMP DEBUG_PAGEALLOC
0011(page translation excepton) and DEBUG_PAGEALLOC might indicate a use after free.
> <4>Modules linked in: sunrpc qeth_l3 dm_multipath dm_mod qeth ccwgroup chsc_sch
> <4>CPU: 0 Not tainted 2.6.31-39.x.20091102-s390xdefault #1
> <4>Process hald (pid: 2117, task: 000000007d200c40, ksp: 000000007ab33880)
> <4>Krnl PSW : 0704100180000000 00000000003a15f8 (_raw_read_trylock+0x0/0x28)
> <4> R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:1 PM:0 EA:3
> <4>Krnl GPRS: 16c8a00000000000 000000007d200c40 000000007575ed18 0000000000000003
> <4> 00000000005853d2 000000007d201470 0000000000000002 000000007ab33c30
> <4> 0000000075746c78 000000007a74da48 000000000051a16a 000000007575ed18
> <4> 000000007575ed30 00000000005da190 00000000005853dc 000000007ab338c8
> <4>Krnl Code: 00000000003a15e8: c03000185811 larl %r3,6ac60a
> <4> 00000000003a15ee: c0e5fffffdd9 brasl %r14,3a11a0
> <4> 00000000003a15f4: a7f4ffce brc 15,3a1590
> <4> >00000000003a15f8: 58302000 l %r3,0(%r2)
> <4> 00000000003a15fc: b9170033 llgtr %r3,%r3
> <4> 00000000003a1600: 1853 lr %r5,%r3
> <4> 00000000003a1602: 1813 lr %r1,%r3
> <4> 00000000003a1604: a75a0001 ahi %r5,1
> <4>Call Trace:
> <4>([<00000000005853d2>] _read_lock+0x5a/0x98)
> <4> [<000000000051a16a>] unix_write_space+0x36/0xb0
[...]
So it looks like that struct sock *sk is already gone in unix_write_space.
Since I have no clue about the socket code, I can only guess that there is a
locking or refcount issue.
Christian
^ permalink raw reply
* Re: Oops in Unix sockets code
From: Eric Dumazet @ 2009-11-19 14:20 UTC (permalink / raw)
To: Christian Borntraeger; +Cc: Blaschka, netdev, linux-s390
In-Reply-To: <200911191440.18949.borntraeger@de.ibm.com>
Christian Borntraeger a écrit :
> Am Donnerstag 19 November 2009 14:20:28 schrieb Blaschka:
>> <1>Unable to handle kernel pointer dereference at virtual kernel address 000000007575e000
>> <4>Oops: 0011 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> 0011(page translation excepton) and DEBUG_PAGEALLOC might indicate a use after free.
>
>> <4>Modules linked in: sunrpc qeth_l3 dm_multipath dm_mod qeth ccwgroup chsc_sch
>> <4>CPU: 0 Not tainted 2.6.31-39.x.20091102-s390xdefault #1
>> <4>Process hald (pid: 2117, task: 000000007d200c40, ksp: 000000007ab33880)
>> <4>Krnl PSW : 0704100180000000 00000000003a15f8 (_raw_read_trylock+0x0/0x28)
>> <4> R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:1 PM:0 EA:3
>> <4>Krnl GPRS: 16c8a00000000000 000000007d200c40 000000007575ed18 0000000000000003
>> <4> 00000000005853d2 000000007d201470 0000000000000002 000000007ab33c30
>> <4> 0000000075746c78 000000007a74da48 000000000051a16a 000000007575ed18
>> <4> 000000007575ed30 00000000005da190 00000000005853dc 000000007ab338c8
>> <4>Krnl Code: 00000000003a15e8: c03000185811 larl %r3,6ac60a
>> <4> 00000000003a15ee: c0e5fffffdd9 brasl %r14,3a11a0
>> <4> 00000000003a15f4: a7f4ffce brc 15,3a1590
>> <4> >00000000003a15f8: 58302000 l %r3,0(%r2)
>> <4> 00000000003a15fc: b9170033 llgtr %r3,%r3
>> <4> 00000000003a1600: 1853 lr %r5,%r3
>> <4> 00000000003a1602: 1813 lr %r1,%r3
>> <4> 00000000003a1604: a75a0001 ahi %r5,1
>> <4>Call Trace:
>> <4>([<00000000005853d2>] _read_lock+0x5a/0x98)
>> <4> [<000000000051a16a>] unix_write_space+0x36/0xb0
> [...]
>
> So it looks like that struct sock *sk is already gone in unix_write_space.
> Since I have no clue about the socket code, I can only guess that there is a
> locking or refcount issue.
2.6.31 has a known bug
2.6.31.4 should correct it
commit 657453424a3c382035983f9a47306fafea730f6d
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu Sep 24 10:49:24 2009 +0000
net: Fix sock_wfree() race
[ Upstream commit d99927f4d93f36553699573b279e0ff98ad7dea6 ]
Commit 2b85a34e911bf483c27cfdd124aeb1605145dc80
(net: No more expensive sock_hold()/sock_put() on each tx)
opens a window in sock_wfree() where another cpu
might free the socket we are working on.
A fix is to call sk->sk_write_space(sk) while still
holding a reference on sk.
Reported-by: Jike Song <albcamus@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Please try 2.6.31.6 ;)
^ permalink raw reply
* NET: Questions about supporting older kernel's with kmods
From: Gregory Haskins @ 2009-11-19 14:21 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]
Hi All,
So I was in the process of packaging up my venet driver so that it could
not only support the in-tree build (in -next), but also build as a KMP
for inclusion in existing distros that already shipped (like SLE, RHEL,
CentOS, etc).
The problem I ran into is that the ethtool and netdev_ops components of
the in-tree version do not necessarily align with the substrate
capabilities of older kernels. What are the best-practices surrounding
this issue?
Q1) Is there any official CONFIG tags (e.g. HAVE_NETDEV_OPS) I can key
off of, or should I simply look at the kernel version? If the latter,
any recommendation on what to use for the aforementioned features? (I
can always try to git-annotate to figure it out, but I wonder if there
are best-practices already in place).
Q2) Is it considered "bad form" to include such compile-time directives
in the version of the code going upstream? E.g. can my driver in -next
have "#ifdef CONFIG_HAVE_NETDEV_OPS" or other version/capability deps,
or do I need to patch these externally into the code destined for the
kmod, and leave the upstream code "pure"?
Thanks in advance,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* Re: netlink: remove subscriptions check on notifier
From: Patrick McHardy @ 2009-11-19 14:22 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev
In-Reply-To: <1258409134.1375.0.camel@johannes.local>
Johannes Berg wrote:
> The netlink URELEASE notifier doesn't notify for
> sockets that have been used to receive multicast
> but it should be called for such sockets as well
> since they might _also_ be used for sending and
> not solely for receiving multicast. We will need
> that for nl80211 (generic netlink sockets) in the
> future.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> Cc: Patrick McHardy <kaber@trash.net>
I've audited all users of this (all within netfilter) and this
change makes sense for them as well.
Acked-by: Patrick McHardy <kaber@trash.net>
^ permalink raw reply
* Re: [PATCH 3/3] macvlan: export macvlan mode through netlink
From: Patrick McHardy @ 2009-11-19 14:38 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Eric Dumazet, linux-kernel, netdev, David Miller,
Stephen Hemminger, Herbert Xu, Patrick Mullaney,
Eric W. Biederman, Edge Virtual Bridging, Anna Fischer, bridge,
virtualization, Jens Osterkamp, Gerhard Stenzel
In-Reply-To: <200911181059.45331.arnd@arndb.de>
Arnd Bergmann wrote:
> On Wednesday 18 November 2009, Eric Dumazet wrote:
>>> --- a/drivers/net/macvlan.c
>>> +++ b/drivers/net/macvlan.c
>>> @@ -33,12 +33,6 @@
>>>
>>> #define MACVLAN_HASH_SIZE (1 << BITS_PER_BYTE)
>>>
>>> -enum macvlan_type {
>>> - MACVLAN_PRIVATE = 1,
>>> - MACVLAN_VEPA = 2,
>>> - MACVLAN_BRIDGE = 4,
>>> -};
>> I realize you defined MACVLAN_PRIVATE in patch 2, but used MACVLAN_MODE_PRIVATE,
>> so patch 2 is not compilable and breaks bisection ?
>>
>
> Hmm, right. I'll fix that up as well.
> +enum ifla_macvlan_mode {
> + MACVLAN_MODE_PRIVATE = 1, /* don't talk to other macvlans */
> + MACVLAN_MODE_VEPA = 2, /* talk to other ports through ext bridge */
> + MACVLAN_MODE_BRIDGE = 4, /* talk to bridge ports directly */
> +};
Please also keep the enum named something without ifla_ since
the mode values themselves are not netlink attributes. Just
macvlan_mode seems fine.
^ permalink raw reply
* Re: [PATCH 3/3] macvlan: export macvlan mode through netlink
From: Arnd Bergmann @ 2009-11-19 14:47 UTC (permalink / raw)
To: Patrick McHardy
Cc: Eric Dumazet, linux-kernel, netdev, David Miller,
Stephen Hemminger, Herbert Xu, Patrick Mullaney,
Eric W. Biederman, Edge Virtual Bridging, Anna Fischer, bridge,
virtualization, Jens Osterkamp, Gerhard Stenzel
In-Reply-To: <4B05586C.5020308@trash.net>
On Thursday 19 November 2009, Patrick McHardy wrote:
> > +enum ifla_macvlan_mode {
> > + MACVLAN_MODE_PRIVATE = 1, /* don't talk to other macvlans */
> > + MACVLAN_MODE_VEPA = 2, /* talk to other ports through ext bridge */
> > + MACVLAN_MODE_BRIDGE = 4, /* talk to bridge ports directly */
> > +};
>
> Please also keep the enum named something without ifla_ since
> the mode values themselves are not netlink attributes. Just
> macvlan_mode seems fine.
Ok, good. I was unsure on the naming and also changed between MACVLAN_*
and MACVLAN_MODE_* a few times.
Thanks for the clarification,
Arnd <><
^ permalink raw reply
* Re: [PATCH 1/3] macvlan: Reflect macvlan packets meant for other macvlan devices
From: Patrick McHardy @ 2009-11-19 14:47 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Eric W. Biederman, Eric Dumazet, linux-kernel, netdev,
David Miller, Stephen Hemminger, Herbert Xu, Patrick Mullaney,
Edge Virtual Bridging, Anna Fischer, bridge, virtualization,
Jens Osterkamp, Gerhard Stenzel
In-Reply-To: <200911191244.43916.arnd@arndb.de>
Arnd Bergmann wrote:
> On Thursday 19 November 2009, Eric W. Biederman wrote:
>>> It seems that we should never drop dst then. We either forward the frame to
>>> netif_rx or to dev_queue_xmit, and from how I read it now, we want to keep
>>> the dst in both cases.
>> When we loop back on our selves we certainly need to have dst clear because
>> we don't know how to cache routes through multiple network namespaces.
>
> Ah, right. So should I add the explicit dst_drop to the new dev_forward_skb()
> then? The veth driver doesn't need it, but it also looks like it won't hurt.
Yes, I think that should be fine.
^ permalink raw reply
* Re: NET: Questions about supporting older kernel's with kmods
From: Ben Hutchings @ 2009-11-19 14:53 UTC (permalink / raw)
To: Gregory Haskins; +Cc: netdev, linux-kernel
In-Reply-To: <4B055479.8070101@gmail.com>
On Thu, 2009-11-19 at 09:21 -0500, Gregory Haskins wrote:
> Hi All,
>
> So I was in the process of packaging up my venet driver so that it could
> not only support the in-tree build (in -next), but also build as a KMP
> for inclusion in existing distros that already shipped (like SLE, RHEL,
> CentOS, etc).
>
> The problem I ran into is that the ethtool and netdev_ops components of
> the in-tree version do not necessarily align with the substrate
> capabilities of older kernels. What are the best-practices surrounding
> this issue?
>
> Q1) Is there any official CONFIG tags (e.g. HAVE_NETDEV_OPS) I can key
> off of,
These feature test macros are not consistently provided.
> or should I simply look at the kernel version?
That works up to a point, but the 'enterprise' distros backport a lot to
earlier kernel versions which can make version tests invalid.
Some out-of-tree/backported drivers use autoconf-style tests, but there
is no standard way of doing this.
[...]
> Q2) Is it considered "bad form" to include such compile-time directives
> in the version of the code going upstream?
[...]
Yes. Don't do that.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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: [RFC PATCH 1/4] net: Add support to netdev ops for changing hardware queue MAC and VLAN filters
From: Ben Hutchings @ 2009-11-19 14:54 UTC (permalink / raw)
To: Williams, Mitch A
Cc: Kirsher, Jeffrey T, davem@davemloft.net, shemminger@vyatta.com,
netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A1365FA69A337F@rrsmsx501.amr.corp.intel.com>
On Wed, 2009-11-18 at 16:33 -0700, Williams, Mitch A wrote:
[...]
> In the case of SR-IOV on our hardware, these filters are perfect - no
> hash tables are required. (We do use hash tables when we have a bunch
> of multicast addresses, but that's not what this is about.)
>
> MAC filters deny packets by default, so you won't get anything without
> a valid MAC filter on the queue.
>
> A queue with no VLAN filters will receive packets from all VLANs,
> albeit with the tags passed up intact. So in that sense, the VLAN
> filters are default-allow.
>
> However, once you enable any VLAN filter, the hardware starts
> stripping tags and begins to deny packets by default.
>
> Based on these semantics, the filtering operation that I've described
> above makes perfect sense.
[...]
But they are not the semantics we would want in supposedly generic
netdev operations.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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
* netfilter 00/02: Netfilter fixes
From: Patrick McHardy @ 2009-11-19 14:59 UTC (permalink / raw)
To: davem; +Cc: netdev, Patrick McHardy, netfilter-devel
Hi Dave,
following are two patches for netfilter, fixing
- a positive errno return value in the osf match
- a sleeping function called under RCU lock in the nf_log seq_show function
Please apply or pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git master
Thanks!
net/netfilter/nf_log.c | 18 +++++-------------
net/netfilter/xt_osf.c | 2 +-
2 files changed, 6 insertions(+), 14 deletions(-)
Roel Kluin (1):
netfilter: xt_osf: fix xt_osf_remove_callback() return value
Wu Fengguang (1):
netfilter: nf_log: fix sleeping function called from invalid context in seq_show()
^ permalink raw reply
* netfilter 01/02: xt_osf: fix xt_osf_remove_callback() return value
From: Patrick McHardy @ 2009-11-19 14:59 UTC (permalink / raw)
To: davem; +Cc: netdev, Patrick McHardy, netfilter-devel
In-Reply-To: <20091119145902.18633.28666.sendpatchset@x2.localnet>
commit 1c622ae67bfc729891f5cd80795b15b87e6ac471
Author: Roel Kluin <roel.kluin@gmail.com>
Date: Fri Nov 13 09:31:35 2009 +0100
netfilter: xt_osf: fix xt_osf_remove_callback() return value
Return a negative error value.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/net/netfilter/xt_osf.c b/net/netfilter/xt_osf.c
index 63e1905..4d1a41b 100644
--- a/net/netfilter/xt_osf.c
+++ b/net/netfilter/xt_osf.c
@@ -118,7 +118,7 @@ static int xt_osf_remove_callback(struct sock *ctnl, struct sk_buff *skb,
{
struct xt_osf_user_finger *f;
struct xt_osf_finger *sf;
- int err = ENOENT;
+ int err = -ENOENT;
if (!osf_attrs[OSF_ATTR_FINGER])
return -EINVAL;
^ permalink raw reply related
* netfilter 02/02: nf_log: fix sleeping function called from invalid context in seq_show()
From: Patrick McHardy @ 2009-11-19 14:59 UTC (permalink / raw)
To: davem; +Cc: netdev, Patrick McHardy, netfilter-devel
In-Reply-To: <20091119145902.18633.28666.sendpatchset@x2.localnet>
commit 7378396cd172cc058fa62220c6486419046c4e0c
Author: Wu Fengguang <fengguang.wu@intel.com>
Date: Fri Nov 13 09:34:44 2009 +0100
netfilter: nf_log: fix sleeping function called from invalid context in seq_show()
[ 171.925285] BUG: sleeping function called from invalid context at kernel/mutex.c:280
[ 171.925296] in_atomic(): 1, irqs_disabled(): 0, pid: 671, name: grep
[ 171.925306] 2 locks held by grep/671:
[ 171.925312] #0: (&p->lock){+.+.+.}, at: [<c10b8acd>] seq_read+0x25/0x36c
[ 171.925340] #1: (rcu_read_lock){.+.+..}, at: [<c1391dac>] seq_start+0x0/0x44
[ 171.925372] Pid: 671, comm: grep Not tainted 2.6.31.6-4-netbook #3
[ 171.925380] Call Trace:
[ 171.925398] [<c105104e>] ? __debug_show_held_locks+0x1e/0x20
[ 171.925414] [<c10264ac>] __might_sleep+0xfb/0x102
[ 171.925430] [<c1461521>] mutex_lock_nested+0x1c/0x2ad
[ 171.925444] [<c1391c9e>] seq_show+0x74/0x127
[ 171.925456] [<c10b8c5c>] seq_read+0x1b4/0x36c
[ 171.925469] [<c10b8aa8>] ? seq_read+0x0/0x36c
[ 171.925483] [<c10d5c8e>] proc_reg_read+0x60/0x74
[ 171.925496] [<c10d5c2e>] ? proc_reg_read+0x0/0x74
[ 171.925510] [<c10a4468>] vfs_read+0x87/0x110
[ 171.925523] [<c10a458a>] sys_read+0x3b/0x60
[ 171.925538] [<c1002a49>] syscall_call+0x7/0xb
Fix it by replacing RCU with nf_log_mutex.
Reported-by: "Yin, Kangkai" <kangkai.yin@intel.com>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/net/netfilter/nf_log.c b/net/netfilter/nf_log.c
index c93494f..d65d348 100644
--- a/net/netfilter/nf_log.c
+++ b/net/netfilter/nf_log.c
@@ -128,9 +128,8 @@ EXPORT_SYMBOL(nf_log_packet);
#ifdef CONFIG_PROC_FS
static void *seq_start(struct seq_file *seq, loff_t *pos)
- __acquires(RCU)
{
- rcu_read_lock();
+ mutex_lock(&nf_log_mutex);
if (*pos >= ARRAY_SIZE(nf_loggers))
return NULL;
@@ -149,9 +148,8 @@ static void *seq_next(struct seq_file *s, void *v, loff_t *pos)
}
static void seq_stop(struct seq_file *s, void *v)
- __releases(RCU)
{
- rcu_read_unlock();
+ mutex_unlock(&nf_log_mutex);
}
static int seq_show(struct seq_file *s, void *v)
@@ -161,7 +159,7 @@ static int seq_show(struct seq_file *s, void *v)
struct nf_logger *t;
int ret;
- logger = rcu_dereference(nf_loggers[*pos]);
+ logger = nf_loggers[*pos];
if (!logger)
ret = seq_printf(s, "%2lld NONE (", *pos);
@@ -171,22 +169,16 @@ static int seq_show(struct seq_file *s, void *v)
if (ret < 0)
return ret;
- mutex_lock(&nf_log_mutex);
list_for_each_entry(t, &nf_loggers_l[*pos], list[*pos]) {
ret = seq_printf(s, "%s", t->name);
- if (ret < 0) {
- mutex_unlock(&nf_log_mutex);
+ if (ret < 0)
return ret;
- }
if (&t->list[*pos] != nf_loggers_l[*pos].prev) {
ret = seq_printf(s, ",");
- if (ret < 0) {
- mutex_unlock(&nf_log_mutex);
+ if (ret < 0)
return ret;
- }
}
}
- mutex_unlock(&nf_log_mutex);
return seq_printf(s, ")\n");
}
^ permalink raw reply related
* Re: NET: Questions about supporting older kernel's with kmods
From: Gregory Haskins @ 2009-11-19 14:59 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, linux-kernel
In-Reply-To: <1258642393.2837.5.camel@achroite.uk.solarflarecom.com>
[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]
Ben Hutchings wrote:
> On Thu, 2009-11-19 at 09:21 -0500, Gregory Haskins wrote:
[...]
>
>> or should I simply look at the kernel version?
>
> That works up to a point, but the 'enterprise' distros backport a lot to
> earlier kernel versions which can make version tests invalid.
Good point
>
> Some out-of-tree/backported drivers use autoconf-style tests, but there
> is no standard way of doing this.
>
Yeah, this might be the only sane way. It turns out that my ETHTOOL
issue was trivial. I was missing "#include <linux/ethtool.h>" which
worked in upstream, but not in older kernels. So that issue is resolved.
Now I just need to figure out netdev_ops. Perhaps I will just patch the
netdev_ops out when building a kmod, since its just
a different way to describe the same thing, and the resulting driver
will perform the same.
> [...]
>> Q2) Is it considered "bad form" to include such compile-time directives
>> in the version of the code going upstream?
> [...]
>
> Yes. Don't do that.
Ok.
Thanks Ben,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* tg3: link is permanently down after ifdown and ifup
From: Felix Radensky @ 2009-11-19 15:16 UTC (permalink / raw)
To: netdev@vger.kernel.org, linuxppc-dev@ozlabs.org
Hi,
I have a problem with tg3 driver on a custom MPC8536 based board
running linux-2.6.31, with tg3 and Broadcom phy drivers taken from
linux-2.6.32-rc7. Broadcom NIC is BCM57760, phy is BCM57780.
The problem I'm seeing is that the downing and interface leads to
permanent link loss, even after interface is upped again. E.g, to
reproduce the problem it is sufficient to run:
modprobe tg3
ifconfig eth2 up
ifconfig eth2 down
ifconfig eth2 up
After ifdown PHY LEDs also go down and do not come back
after ifup. Ethtool reports that no link is detected. After reloading
the driver the link comes back.
Am I the only one seeing this problem ?
Any help on fixing this is appreciated.
Thanks a lot.
Felix.
^ permalink raw reply
* Re: Problem with VLANs and via-velocity driver
From: Patrick McHardy @ 2009-11-19 15:17 UTC (permalink / raw)
To: Séguier Régis; +Cc: Kevin Shanahan, netdev
In-Reply-To: <4AFD4595.1070904@e-teleport.net>
Séguier Régis wrote:
> Patrick McHardy a écrit :
>>
>>>> There's some special-casing for VID 0 in velocity_init_cam_filter().
>>>> Does "ip link add link eth0 type vlan id 0" make any difference?
>>>> If not, does "ip link set eth0 promisc on"?
>>>>
>>> When we patch the driver to support multiple vlan, we decide to use the
>>> vlan 0 to desactivate the vlan filtering.
>>>
>>
>> Why? The usual behaviour is to receive both tagged and untagged
>> frames.
>>
> We decide this with françois as an alternative to desactivate the NIC
> vlan filtering instead of creating a modul parameter.
> The vlan id 0 need to be created but not necessary activate.
That doesn't seem like a good idea since it behaves differently than
any other driver supporting VLAN.
> In september 2008, we had a discution about exactly the same problem.
> You speak about the possibility of an ALLVLAN device flag.
That was meant for the case where hardware filtering for specific VLANs
is active and you want to see traffic of VLANs not configured locally
without switching to promiscous mode.
> I think i proposed a patch to desactivate NIC vlan filtering when we are
> in promisc mode but not used.
Yes, in promiscous mode VLAN filtering should be disabled.
^ permalink raw reply
* Re: Problem with VLANs and via-velocity driver
From: Patrick McHardy @ 2009-11-19 15:18 UTC (permalink / raw)
To: Kevin Shanahan; +Cc: netdev
In-Reply-To: <20091116005750.GR838@cubit>
Kevin Shanahan wrote:
> On Fri, Nov 13, 2009 at 07:40:39AM +0100, Patrick McHardy wrote:
>> Kevin Shanahan wrote:
>>> Hi,
>>>
>>> I've had some problems with getting a fairly simple (I thought) VLAN
>>> configuration working with the on board Via NICs on my Via M700
>>> board. Looks like as soon as a tagged VLAN interface is added, the
>>> underlying "raw" (untagged) interface stops responding.
>>>
>>> ...
>>>
>>> A bit of searching found a few references to similar problems going
>>> back a few years (2005, 2007). Sounded like there were some driver
>>> issues, but it wasn't clear from the messages I found whether they
>>> were believed to be fixed or not. I tried the same test using a
>>> differnt NIC with the tg3 driver and there were no problems, so it
>>> looks to me like it's still a via-velocity issue. Unfortunately I
>>> don't have room to add NICs to this machine and need to use the on
>>> board Via hardware.
>> There's some special-casing for VID 0 in velocity_init_cam_filter().
>> Does "ip link add link eth0 type vlan id 0" make any difference?
>
> Thanks Patrick, this command got the untagged interface working again
> (eth1 in my case). I can use this as a work around.
>
> I didn't really understand if there was a good reason for the
> special-casing in this driver, but from at least from my user
> perspective I think it would be better if the drivers were consistent
> in how they handle this.
I agree.
^ permalink raw reply
* Re: Oops in Unix sockets code
From: Sebastian Ott @ 2009-11-19 15:46 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Christian Borntraeger, Blaschka, netdev, linux-s390
In-Reply-To: <4B05542D.7060401@gmail.com>
On Thu, 19 Nov 2009, Eric Dumazet wrote:
...
> 2.6.31 has a known bug
>
> 2.6.31.4 should correct it
>
> commit 657453424a3c382035983f9a47306fafea730f6d
> Author: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu Sep 24 10:49:24 2009 +0000
indeed, problem didn't show up with d99927f applied. thanks for
pointing that out.
sebastian
^ 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