* Re: [PATCH 3/3, v2] fs_enet: Add PHY interface selection for MPC5121 fs_enet.
From: vooon341 @ 2011-03-22 14:10 UTC (permalink / raw)
To: linuxppc-dev; +Cc: netdev, linux-kernel, Vitaly Bordug
Add PHY interface selection for MPC5121 fs_enet.
Adds phy-connection-type optional property for ethernet node.
It should be rmii or mii.
Signed-off-by: Vladimir Ermakov <vooon341@gmail.com>
---
v2:
- replace Kconfig to device tree
- add phy-connection-type for mpc5121-fec nodes
---
drivers/net/fs_enet/fec.h | 6 ++++--
drivers/net/fs_enet/fs_enet-main.c | 14 ++++++++++++--
drivers/net/fs_enet/mac-fec.c | 9 ++++++---
3 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/net/fs_enet/fec.h b/drivers/net/fs_enet/fec.h
index e980527..9fd1ff5 100644
--- a/drivers/net/fs_enet/fec.h
+++ b/drivers/net/fs_enet/fec.h
@@ -23,6 +23,10 @@
#define FEC_ECNTRL_ETHER_EN 0x00000002
#define FEC_ECNTRL_RESET 0x00000001
+/* RMII mode enabled only when MII_MODE bit is set too. */
+#define FEC_RCNTRL_RMII_MODE (0x00000100 | \
+ FEC_RCNTRL_MII_MODE | FEC_RCNTRL_FCE)
+#define FEC_RCNTRL_FCE 0x00000020
#define FEC_RCNTRL_BC_REJ 0x00000010
#define FEC_RCNTRL_PROM 0x00000008
#define FEC_RCNTRL_MII_MODE 0x00000004
@@ -33,8 +37,6 @@
#define FEC_TCNTRL_HBC 0x00000002
#define FEC_TCNTRL_GTS 0x00000001
-
-
/*
* Delay to wait for FEC reset command to complete (in us)
*/
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index 24cb953..c424159 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -788,16 +788,20 @@ static int fs_init_phy(struct net_device *dev)
{
struct fs_enet_private *fep = netdev_priv(dev);
struct phy_device *phydev;
+ phy_interface_t iface;
fep->oldlink = 0;
fep->oldspeed = 0;
fep->oldduplex = -1;
+ iface = (fep->fpi->use_rmii) ?
+ PHY_INTERFACE_MODE_RMII : PHY_INTERFACE_MODE_MII;
+
phydev = of_phy_connect(dev, fep->fpi->phy_node, &fs_adjust_link, 0,
- PHY_INTERFACE_MODE_MII);
+ iface);
if (!phydev) {
phydev = of_phy_connect_fixed_link(dev, &fs_adjust_link,
- PHY_INTERFACE_MODE_MII);
+ iface);
}
if (!phydev) {
dev_err(&dev->dev, "Could not attach to PHY\n");
@@ -1005,6 +1009,7 @@ static int __devinit fs_enet_probe(struct
platform_device *ofdev)
struct fs_platform_info *fpi;
const u32 *data;
const u8 *mac_addr;
+ char *phy_connection_type;
int privsize, len, ret = -ENODEV;
if (!ofdev->dev.of_match)
@@ -1032,6 +1037,11 @@ static int __devinit fs_enet_probe(struct
platform_device *ofdev)
NULL)))
goto out_free_fpi;
+ phy_connection_type = of_get_property(ofdev->dev.of_node,
+ "phy-connection-type", NULL);
+ if (phy_connection_type && strcmp("rmii", phy_connection_type) == 0)
+ fpi->use_rmii = 1;
+
privsize = sizeof(*fep) +
sizeof(struct sk_buff **) *
(fpi->rx_ring + fpi->tx_ring);
diff --git a/drivers/net/fs_enet/mac-fec.c b/drivers/net/fs_enet/mac-fec.c
index 61035fc..7ba36c1 100644
--- a/drivers/net/fs_enet/mac-fec.c
+++ b/drivers/net/fs_enet/mac-fec.c
@@ -322,10 +322,11 @@ static void restart(struct net_device *dev)
FW(fecp, r_cntrl, FEC_RCNTRL_MII_MODE); /* MII enable */
#else
/*
- * Only set MII mode - do not touch maximum frame length
+ * Only set MII/RMII mode - do not touch maximum frame length
* configured before.
*/
- FS(fecp, r_cntrl, FEC_RCNTRL_MII_MODE);
+ FS(fecp, r_cntrl, (fpi->use_rmii) ?
+ FEC_RCNTRL_RMII_MODE : FEC_RCNTRL_MII_MODE);
#endif
/*
* adjust to duplex mode
@@ -381,7 +382,9 @@ static void stop(struct net_device *dev)
/* shut down FEC1? that's where the mii bus is */
if (fpi->has_phy) {
- FS(fecp, r_cntrl, FEC_RCNTRL_MII_MODE); /* MII enable */
+ FS(fecp, r_cntrl, (fpi->use_rmii) ?
+ FEC_RCNTRL_RMII_MODE :
+ FEC_RCNTRL_MII_MODE); /* MII/RMII enable */
FS(fecp, ecntrl, FEC_ECNTRL_PINMUX | FEC_ECNTRL_ETHER_EN);
FW(fecp, ievent, FEC_ENET_MII);
FW(fecp, mii_speed, feci->mii_speed);
--
1.7.1
^ permalink raw reply related
* Re: xfrm: Fix initialize repl field of struct xfrm_state
From: Steffen Klassert @ 2011-03-22 13:14 UTC (permalink / raw)
To: Wei Yongjun; +Cc: David Miller, netdev
In-Reply-To: <4D87F5A6.90704@cn.fujitsu.com>
On Tue, Mar 22, 2011 at 09:04:38AM +0800, Wei Yongjun wrote:
>
> BTW, looking into more about this, another path, XFRM_MSG_NEWAE,
> can overwrite the x->replay_esn with the nla_data length, which
> may larger then the size we malloc.
>
Yes, I've noticed that yesterday too. I'll fix it up.
Thanks!
^ permalink raw reply
* [patch net-2.6] bonding: fix rx_handler locking
From: Jiri Pirko @ 2011-03-22 12:38 UTC (permalink / raw)
To: netdev; +Cc: davem, nicolas.2p.debian, andy, fubar
This prevents possible race between bond_enslave and bond_handle_frame
as reported by Nicolas by moving rx_handler register/unregister.
slave->bond is added to hold pointer to master bonding sructure. That
way dev->master is no longer used in bond_handler_frame.
Also, this removes "BUG: scheduling while atomic" message
Reported-by: Nicolas de Pesloüan <nicolas.2p.debian@gmail.com>
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
drivers/net/bonding/bond_main.c | 56 +++++++++++++++++++++-----------------
drivers/net/bonding/bonding.h | 1 +
2 files changed, 32 insertions(+), 25 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 338bea1..16d6fe9 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1482,21 +1482,16 @@ static rx_handler_result_t bond_handle_frame(struct sk_buff **pskb)
{
struct sk_buff *skb = *pskb;
struct slave *slave;
- struct net_device *bond_dev;
struct bonding *bond;
- slave = bond_slave_get_rcu(skb->dev);
- bond_dev = ACCESS_ONCE(slave->dev->master);
- if (unlikely(!bond_dev))
- return RX_HANDLER_PASS;
-
skb = skb_share_check(skb, GFP_ATOMIC);
if (unlikely(!skb))
return RX_HANDLER_CONSUMED;
*pskb = skb;
- bond = netdev_priv(bond_dev);
+ slave = bond_slave_get_rcu(skb->dev);
+ bond = slave->bond;
if (bond->params.arp_interval)
slave->dev->last_rx = jiffies;
@@ -1505,10 +1500,10 @@ static rx_handler_result_t bond_handle_frame(struct sk_buff **pskb)
return RX_HANDLER_EXACT;
}
- skb->dev = bond_dev;
+ skb->dev = bond->dev;
if (bond->params.mode == BOND_MODE_ALB &&
- bond_dev->priv_flags & IFF_BRIDGE_PORT &&
+ bond->dev->priv_flags & IFF_BRIDGE_PORT &&
skb->pkt_type == PACKET_HOST) {
if (unlikely(skb_cow_head(skb,
@@ -1516,7 +1511,7 @@ static rx_handler_result_t bond_handle_frame(struct sk_buff **pskb)
kfree_skb(skb);
return RX_HANDLER_CONSUMED;
}
- memcpy(eth_hdr(skb)->h_dest, bond_dev->dev_addr, ETH_ALEN);
+ memcpy(eth_hdr(skb)->h_dest, bond->dev->dev_addr, ETH_ALEN);
}
return RX_HANDLER_ANOTHER;
@@ -1698,20 +1693,15 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
pr_debug("Error %d calling netdev_set_bond_master\n", res);
goto err_restore_mac;
}
- res = netdev_rx_handler_register(slave_dev, bond_handle_frame,
- new_slave);
- if (res) {
- pr_debug("Error %d calling netdev_rx_handler_register\n", res);
- goto err_unset_master;
- }
/* open the slave since the application closed it */
res = dev_open(slave_dev);
if (res) {
pr_debug("Opening slave %s failed\n", slave_dev->name);
- goto err_unreg_rxhandler;
+ goto err_unset_master;
}
+ new_slave->bond = bond;
new_slave->dev = slave_dev;
slave_dev->priv_flags |= IFF_BONDING;
@@ -1907,6 +1897,13 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
if (res)
goto err_close;
+ res = netdev_rx_handler_register(slave_dev, bond_handle_frame,
+ new_slave);
+ if (res) {
+ pr_debug("Error %d calling netdev_rx_handler_register\n", res);
+ goto err_dest_symlinks;
+ }
+
pr_info("%s: enslaving %s as a%s interface with a%s link.\n",
bond_dev->name, slave_dev->name,
bond_is_active_slave(new_slave) ? "n active" : " backup",
@@ -1916,13 +1913,12 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
return 0;
/* Undo stages on error */
+err_dest_symlinks:
+ bond_destroy_slave_symlinks(bond_dev, slave_dev);
+
err_close:
dev_close(slave_dev);
-err_unreg_rxhandler:
- netdev_rx_handler_unregister(slave_dev);
- synchronize_net();
-
err_unset_master:
netdev_set_bond_master(slave_dev, NULL);
@@ -1988,6 +1984,14 @@ int bond_release(struct net_device *bond_dev, struct net_device *slave_dev)
return -EINVAL;
}
+ /* unregister rx_handler early so bond_handle_frame wouldn't be called
+ * for this slave anymore.
+ */
+ netdev_rx_handler_unregister(slave_dev);
+ write_unlock_bh(&bond->lock);
+ synchronize_net();
+ write_lock_bh(&bond->lock);
+
if (!bond->params.fail_over_mac) {
if (!compare_ether_addr(bond_dev->dev_addr, slave->perm_hwaddr) &&
bond->slave_cnt > 1)
@@ -2104,8 +2108,6 @@ int bond_release(struct net_device *bond_dev, struct net_device *slave_dev)
netif_addr_unlock_bh(bond_dev);
}
- netdev_rx_handler_unregister(slave_dev);
- synchronize_net();
netdev_set_bond_master(slave_dev, NULL);
slave_disable_netpoll(slave);
@@ -2186,6 +2188,12 @@ static int bond_release_all(struct net_device *bond_dev)
*/
write_unlock_bh(&bond->lock);
+ /* unregister rx_handler early so bond_handle_frame wouldn't
+ * be called for this slave anymore.
+ */
+ netdev_rx_handler_unregister(slave_dev);
+ synchronize_net();
+
if (bond_is_lb(bond)) {
/* must be called only after the slave
* has been detached from the list
@@ -2217,8 +2225,6 @@ static int bond_release_all(struct net_device *bond_dev)
netif_addr_unlock_bh(bond_dev);
}
- netdev_rx_handler_unregister(slave_dev);
- synchronize_net();
netdev_set_bond_master(slave_dev, NULL);
slave_disable_netpoll(slave);
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 6b26962..90736cb 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -187,6 +187,7 @@ struct slave {
struct net_device *dev; /* first - useful for panic debug */
struct slave *next;
struct slave *prev;
+ struct bonding *bond; /* our master */
int delay;
unsigned long jiffies;
unsigned long last_arp_rx;
--
1.7.4
^ permalink raw reply related
* Re: [PATCH 4/4] drivers/net/fec: Don't mess with configured MAC addresses.
From: Shawn Guo @ 2011-03-22 12:33 UTC (permalink / raw)
To: Lothar Waßmann; +Cc: netdev, u.kleine-koenig
In-Reply-To: <e7cec31bec3eb7dad56688c4390a59f99625ea83.1300724245.git.LW@KARO-electronics.de>
On Tue, Mar 22, 2011 at 11:00:02AM +0100, Lothar Waßmann wrote:
> The FEC driver currently uses the MAC address assigned to the first
> interface incremented by one for the second interface.
>
> Change this to be able to configure distinct MAC addresses via
> platform_data.
>
> Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Acked-by: <shawn.guo@freescale.com>
--
Regards,
Shawn
> ---
> drivers/net/fec.c | 9 ++-------
> 1 files changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> index 3666524..9d89e99 100644
> --- a/drivers/net/fec.c
> +++ b/drivers/net/fec.c
> @@ -736,7 +736,7 @@ static void __inline__ fec_get_mac(struct net_device *ndev)
> {
> struct fec_enet_private *fep = netdev_priv(ndev);
> struct fec_platform_data *pdata = fep->pdev->dev.platform_data;
> - unsigned char *iap, tmpaddr[ETH_ALEN];
> + unsigned char iap[ETH_ALEN], tmpaddr[ETH_ALEN];
>
> /*
> * try to get mac address in following order:
> @@ -744,7 +744,10 @@ static void __inline__ fec_get_mac(struct net_device *ndev)
> * 1) module parameter via kernel command line in form
> * fec.macaddr=0x00,0x04,0x9f,0x01,0x30,0xe0
> */
> - iap = macaddr;
> + if (fep->pdev->id == 0)
> + memcpy(iap, macaddr, ETH_ALEN);
> + else
> + memset(iap, 0, ETH_ALEN);
>
> /*
> * 2) from flash or fuse (via platform data)
> @@ -767,14 +770,10 @@ static void __inline__ fec_get_mac(struct net_device *ndev)
> be32_to_cpu(readl(fep->hwp + FEC_ADDR_LOW));
> *((unsigned short *) &tmpaddr[4]) =
> be16_to_cpu(readl(fep->hwp + FEC_ADDR_HIGH) >> 16);
> - iap = &tmpaddr[0];
> + memcpy(iap, tmpaddr, ETH_ALEN);
> }
>
> memcpy(ndev->dev_addr, iap, ETH_ALEN);
> -
> - /* Adjust MAC if using macaddr */
> - if (iap == macaddr)
> - ndev->dev_addr[ETH_ALEN-1] = macaddr[ETH_ALEN-1] + fep->pdev->id;
> }
>
> /* ------------------------------------------------------------------------- */
> --
> 1.5.6.5
>
^ permalink raw reply
* [PATCHv2] net: davinci_emac:Fix translation logic for buffer descriptor
From: Sriramakrishnan A G @ 2011-03-22 12:31 UTC (permalink / raw)
To: netdev; +Cc: davinci-linux-open-source, davem, srk, sshtylyov
With recent changes to the driver(switch to new cpdma layer),
the support for buffer descriptor address translation logic
is broken. This affects platforms where the physical address of
the descriptors as seen by the DMA engine is different from the
physical address.
Original Patch adding translation logic support:
Commit: ad021ae8862209864dc8ebd3b7d3a55ce84b9ea2
Signed-off-by: Sriramakrishnan A G <srk@ti.com>
---
Addresses review comments from Sergei. Generated against tip of Linus tree.
drivers/net/davinci_cpdma.c | 11 ++++++++---
drivers/net/davinci_cpdma.h | 1 +
drivers/net/davinci_emac.c | 5 ++++-
include/linux/davinci_emac.h | 1 +
4 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/net/davinci_cpdma.c b/drivers/net/davinci_cpdma.c
index e92b2b6..ae47f23 100644
--- a/drivers/net/davinci_cpdma.c
+++ b/drivers/net/davinci_cpdma.c
@@ -76,6 +76,7 @@ struct cpdma_desc {
struct cpdma_desc_pool {
u32 phys;
+ u32 hw_addr;
void __iomem *iomap; /* ioremap map */
void *cpumap; /* dma_alloc map */
int desc_size, mem_size;
@@ -137,7 +138,8 @@ struct cpdma_chan {
* abstract out these details
*/
static struct cpdma_desc_pool *
-cpdma_desc_pool_create(struct device *dev, u32 phys, int size, int align)
+cpdma_desc_pool_create(struct device *dev, u32 phys, u32 hw_addr,
+ int size, int align)
{
int bitmap_size;
struct cpdma_desc_pool *pool;
@@ -161,10 +163,12 @@ cpdma_desc_pool_create(struct device *dev, u32 phys, int size, int align)
if (phys) {
pool->phys = phys;
pool->iomap = ioremap(phys, size);
+ pool->hw_addr = hw_addr;
} else {
pool->cpumap = dma_alloc_coherent(dev, size, &pool->phys,
GFP_KERNEL);
pool->iomap = (void __force __iomem *)pool->cpumap;
+ pool->hw_addr = pool->phys;
}
if (pool->iomap)
@@ -201,14 +205,14 @@ static inline dma_addr_t desc_phys(struct cpdma_desc_pool *pool,
{
if (!desc)
return 0;
- return pool->phys + (__force dma_addr_t)desc -
+ return pool->hw_addr + (__force dma_addr_t)desc -
(__force dma_addr_t)pool->iomap;
}
static inline struct cpdma_desc __iomem *
desc_from_phys(struct cpdma_desc_pool *pool, dma_addr_t dma)
{
- return dma ? pool->iomap + dma - pool->phys : NULL;
+ return dma ? pool->iomap + dma - pool->hw_addr : NULL;
}
static struct cpdma_desc __iomem *
@@ -260,6 +264,7 @@ struct cpdma_ctlr *cpdma_ctlr_create(struct cpdma_params *params)
ctlr->pool = cpdma_desc_pool_create(ctlr->dev,
ctlr->params.desc_mem_phys,
+ ctlr->params.desc_hw_addr,
ctlr->params.desc_mem_size,
ctlr->params.desc_align);
if (!ctlr->pool) {
diff --git a/drivers/net/davinci_cpdma.h b/drivers/net/davinci_cpdma.h
index 868e50e..afa19a0 100644
--- a/drivers/net/davinci_cpdma.h
+++ b/drivers/net/davinci_cpdma.h
@@ -33,6 +33,7 @@ struct cpdma_params {
bool has_soft_reset;
int min_packet_size;
u32 desc_mem_phys;
+ u32 desc_hw_addr;
int desc_mem_size;
int desc_align;
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 082d6ea..baca6bf 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -1854,10 +1854,13 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
dma_params.rxcp = priv->emac_base + 0x660;
dma_params.num_chan = EMAC_MAX_TXRX_CHANNELS;
dma_params.min_packet_size = EMAC_DEF_MIN_ETHPKTSIZE;
- dma_params.desc_mem_phys = hw_ram_addr;
+ dma_params.desc_hw_addr = hw_ram_addr;
dma_params.desc_mem_size = pdata->ctrl_ram_size;
dma_params.desc_align = 16;
+ dma_params.desc_mem_phys = pdata->no_bd_ram ? 0 :
+ (u32 __force)res->start + pdata->ctrl_ram_offset;
+
priv->dma = cpdma_ctlr_create(&dma_params);
if (!priv->dma) {
dev_err(emac_dev, "DaVinci EMAC: Error initializing DMA\n");
diff --git a/include/linux/davinci_emac.h b/include/linux/davinci_emac.h
index 5dd4285..5428885 100644
--- a/include/linux/davinci_emac.h
+++ b/include/linux/davinci_emac.h
@@ -36,6 +36,7 @@ struct emac_platform_data {
u8 rmii_en;
u8 version;
+ bool no_bd_ram;
void (*interrupt_enable) (void);
void (*interrupt_disable) (void);
};
--
1.6.2.4
^ permalink raw reply related
* Re: [PATCH 0/7] TCP CUBIC Hystart fixes
From: David Miller @ 2011-03-22 12:05 UTC (permalink / raw)
To: lucas.nussbaum; +Cc: shemminger, netdev
In-Reply-To: <20110322113542.GB21254@xanadu.blop.info>
From: Lucas Nussbaum <lucas.nussbaum@loria.fr>
Date: Tue, 22 Mar 2011 12:35:42 +0100
> On 14/03/11 at 10:52 -0700, Stephen Hemminger wrote:
>> This is the merge of my patches and recent update Sangtae.
>> It addresses the problems reported by Lucas Nussbaum that Hystart causes
>> poor startup performance over links with lots of buffering.
>
> What do you plan to do regarding stable kernels? We should probably
> either push that patch serie, or disable hystart if HZ < 1000.
I think once the patch series gets some soaking time in Linus's tree
we can send it over to -stable.
^ permalink raw reply
* [Patch] net: remove useless comments in net/core/dev.c
From: Amerigo Wang @ 2011-03-22 11:59 UTC (permalink / raw)
To: linux-kernel
Cc: WANG Cong, David S. Miller, Eric Dumazet, Changli Gao,
Tom Herbert, Jesse Gross, netdev
The code itself can explain what it is doing, no need these comments.
Signed-off-by: WANG Cong <amwang@redhat.com>
---
net/core/dev.c | 54 ------------------------------------------------------
1 files changed, 0 insertions(+), 54 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 0b88eba..2c2f243 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1140,9 +1140,6 @@ static int __dev_open(struct net_device *dev)
ASSERT_RTNL();
- /*
- * Is it even present?
- */
if (!netif_device_present(dev))
return -ENODEV;
@@ -1151,9 +1148,6 @@ static int __dev_open(struct net_device *dev)
if (ret)
return ret;
- /*
- * Call device private open method
- */
set_bit(__LINK_STATE_START, &dev->state);
if (ops->ndo_validate_addr)
@@ -1162,31 +1156,12 @@ static int __dev_open(struct net_device *dev)
if (!ret && ops->ndo_open)
ret = ops->ndo_open(dev);
- /*
- * If it went open OK then:
- */
-
if (ret)
clear_bit(__LINK_STATE_START, &dev->state);
else {
- /*
- * Set the flags.
- */
dev->flags |= IFF_UP;
-
- /*
- * Enable NET_DMA
- */
net_dmaengine_get();
-
- /*
- * Initialize multicasting status
- */
dev_set_rx_mode(dev);
-
- /*
- * Wakeup transmit queue engine
- */
dev_activate(dev);
}
@@ -1209,22 +1184,13 @@ int dev_open(struct net_device *dev)
{
int ret;
- /*
- * Is it already up?
- */
if (dev->flags & IFF_UP)
return 0;
- /*
- * Open device
- */
ret = __dev_open(dev);
if (ret < 0)
return ret;
- /*
- * ... and announce new interface.
- */
rtmsg_ifinfo(RTM_NEWLINK, dev, IFF_UP|IFF_RUNNING);
call_netdevice_notifiers(NETDEV_UP, dev);
@@ -1240,10 +1206,6 @@ static int __dev_close_many(struct list_head *head)
might_sleep();
list_for_each_entry(dev, head, unreg_list) {
- /*
- * Tell people we are going down, so that they can
- * prepare to death, when device is still operating.
- */
call_netdevice_notifiers(NETDEV_GOING_DOWN, dev);
clear_bit(__LINK_STATE_START, &dev->state);
@@ -1272,15 +1234,7 @@ static int __dev_close_many(struct list_head *head)
if (ops->ndo_stop)
ops->ndo_stop(dev);
- /*
- * Device is now down.
- */
-
dev->flags &= ~IFF_UP;
-
- /*
- * Shutdown NET_DMA
- */
net_dmaengine_put();
}
@@ -1309,9 +1263,6 @@ static int dev_close_many(struct list_head *head)
__dev_close_many(head);
- /*
- * Tell people we are down
- */
list_for_each_entry(dev, head, unreg_list) {
rtmsg_ifinfo(RTM_NEWLINK, dev, IFF_UP|IFF_RUNNING);
call_netdevice_notifiers(NETDEV_DOWN, dev);
@@ -1368,11 +1319,6 @@ EXPORT_SYMBOL(dev_disable_lro);
static int dev_boot_phase = 1;
-/*
- * Device change register/unregister. These are not inline or static
- * as we export them to the world.
- */
-
/**
* register_netdevice_notifier - register a network notifier block
* @nb: notifier
^ permalink raw reply related
* [PATCH] netfilter: h323: bug in parsing of ASN1 SEQOF field
From: David Sterba @ 2011-03-22 11:55 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, David Sterba, David Miller, stable
Static analyzer of clang found a dead store which appears to be a bug in
reading count of items in SEQOF field, only the lower byte of word is
stored. This may lead to corrupted read and communication shutdown.
The bug has been in the module since it's first inclusion into linux
kernel.
Signed-off-by: David Sterba <dsterba@suse.cz>
CC: David Miller <davem@davemloft.net>
CC: netdev@vger.kernel.org
CC: stable@kernel.org
---
net/netfilter/nf_conntrack_h323_asn1.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/netfilter/nf_conntrack_h323_asn1.c b/net/netfilter/nf_conntrack_h323_asn1.c
index 8678823..bcd5ed6 100644
--- a/net/netfilter/nf_conntrack_h323_asn1.c
+++ b/net/netfilter/nf_conntrack_h323_asn1.c
@@ -631,7 +631,7 @@ static int decode_seqof(bitstr_t *bs, const struct field_t *f,
CHECK_BOUND(bs, 2);
count = *bs->cur++;
count <<= 8;
- count = *bs->cur++;
+ count += *bs->cur++;
break;
case SEMI:
BYTE_ALIGN(bs);
--
1.7.4.1.176.g501cc
^ permalink raw reply related
* Re: [PATCH 2/2] virtio_net: remove send completion interrupts and avoid TX queue overrun through packet drop
From: Michael S. Tsirkin @ 2011-03-22 11:36 UTC (permalink / raw)
To: Shirley Ma; +Cc: Herbert Xu, rusty, davem, kvm, netdev
In-Reply-To: <1300730587.3441.24.camel@localhost.localdomain>
On Mon, Mar 21, 2011 at 11:03:07AM -0700, Shirley Ma wrote:
> On Fri, 2011-03-18 at 18:41 -0700, Shirley Ma wrote:
> > > > + /* Drop packet instead of stop queue for better
> > performance
> > > */
> > >
> > > I would like to see some justification as to why this is the right
> > > way to go and not just papering over the real problem.
> >
> > Fair. KVM guest virtio_net TX queue stop/restart is pretty expensive,
> > which involves:
> >
> > 1. Guest enable callback: one memory barrier, interrupt flag set
>
> Missed this cost: for history reason, it also involves a guest exit from
> I/O write (PCI_QUEUE_NOTIFY).
OK, after some research, it looks like the reason was the tx timer that
qemu used to use. So the hack of avoiding the add_buf call will
avoid this kick and so break these hosts.
I guess we can add a feature bit to detect a new host
and so avoid the kick. We are running low on feature bits
unfortunately, but just fo testing, could you quantify the difference
that this makes using the following patch:
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index cc2f73e..6106017 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -185,11 +185,6 @@ int virtqueue_add_buf_gfp(struct virtqueue *_vq,
if (vq->num_free < out + in) {
pr_debug("Can't add buf len %i - avail = %i\n",
out + in, vq->num_free);
- /* FIXME: for historical reasons, we force a notify here if
- * there are outgoing parts to the buffer. Presumably the
- * host should service the ring ASAP. */
- if (out)
- vq->notify(&vq->vq);
END_USE(vq);
return -ENOSPC;
}
--
MST
^ permalink raw reply related
* Re: [PATCH 0/7] TCP CUBIC Hystart fixes
From: Lucas Nussbaum @ 2011-03-22 11:35 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David S. Miller, netdev
In-Reply-To: <20110314175211.788224699@vyatta.com>
On 14/03/11 at 10:52 -0700, Stephen Hemminger wrote:
> This is the merge of my patches and recent update Sangtae.
> It addresses the problems reported by Lucas Nussbaum that Hystart causes
> poor startup performance over links with lots of buffering.
What do you plan to do regarding stable kernels? We should probably
either push that patch serie, or disable hystart if HZ < 1000.
--
| Lucas Nussbaum MCF Université Nancy 2 |
| lucas.nussbaum@loria.fr LORIA / AlGorille |
| http://www.loria.fr/~lnussbau/ +33 3 54 95 86 19 |
^ permalink raw reply
* Re: [PATCH 0/7] TCP CUBIC Hystart fixes
From: Lucas Nussbaum @ 2011-03-22 11:34 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David S. Miller, netdev
In-Reply-To: <20110314175211.788224699@vyatta.com>
On 14/03/11 at 10:52 -0700, Stephen Hemminger wrote:
> This is the merge of my patches and recent update Sangtae.
> It addresses the problems reported by Lucas Nussbaum that Hystart causes
> poor startup performance over links with lots of buffering.
Hi,
I've tested the patches, and they work fine.
Here are some results (gigabit link, RTT=11ms).
Without the patches, hystart disabled:
Segments (cwnd, ssthresh)
2500 ++-----------+-------------+------------+-------------+-----------++
+ + + + snd_cwnd ****** +
| snd_ssthresh ###### |
2000 ++ ************************************************* ++
| ** |
| * |
| * |
1500 ++ * ++
| * |
| * |
1000 ++ * ++
| ** |
| * |
| * |
500 ++ * ++
| ** |
+ ** + + + + +
0 ++-***####################################################--------++
0 0.5 1 1.5 2 2.5
time (seconds)
Without the patches, hystart enabled:
Segments (cwnd, ssthresh)
300 ++------------+------------+-------------+------------+------------++
+ + + + snd_cwnd ****** +
| ***snd_ssthresh ###### |
250 ++ *********************** ++
| ******************################################### |
| * |
200 ++ * ++
| * |
150 ++ * ++
| * |
| * |
100 ++ ** ++
| *# |
| *# |
50 ++ *# ++
| **# |
+ ** # + + + + +
0 ++-*###-------+------------+-------------+------------+------------++
0 0.5 1 1.5 2 2.5
time (seconds)
Note how slow start ends very early (~ 230 segments), resulting in poor performance.
With the patches, hystart enabled, run 1:
Segments (cwnd, ssthresh)
2500 ++-----+-------+------+-------+------+-------+------+-------+-----++
+ + + + + + + snd_cwnd ****** +
| snd_ssthresh ###### |
2000 ++ ********************************************************* ++
| * |
| * |
| * |
1500 ++ * ++
| * |
| ** |
1000 ++ * ++
| * |
| * |
| * |
500 ++ * ++
| ** |
+ * + + + + + + + + +
0 ++**##########################################################----++
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5
time (seconds)
There's no perceived delay increase, but also no losses. The NIC sends data at
line rate without congestion. we don't exit slow start, but that's fine:
With the patch, hystart enabled, run 2: (that's the most frequent situation)
Segments (cwnd, ssthresh)
2500 ++-----+-------+------+-------+------+-------+------+-------+-----++
+ + + + + + + snd_cwnd ****** +
| snd_ssthresh ###### |
2000 ++ ******************************************************** ++
| *# |
| *# |
| *# |
1500 ++ *# ++
| *# |
| *# |
1000 ++ **# ++
| * # |
| * # |
| * # |
500 ++ ** # ++
| * # |
+ ** # + + + + + + + +
0 ++**####-------+------+-------+------+-------+------+-------+-----++
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5
time (seconds)
Hystart detects a delay increase, so we exit slow start, but at a reasonable point.
Hystart works fine in that case. (no impact on performance).
With the patch, hystart enabled, run 3:
Segments (cwnd, ssthresh)
2500 ++-----+-------+------+-------+------+-------+------+-------+-----++
+ + + + + + + snd_cwnd ****** +
| snd_ssthresh ###### |
2000 ++ ******************************************************* ++
| * |
| ** |
| * |
1500 ++ **####################################################### ++
| *# |
| *# |
1000 ++ *# ++
| *# |
| **# |
| * # |
500 ++ * # ++
| * # |
+ ** #+ + + + + + + + +
0 ++**###+-------+------+-------+------+-------+------+-------+-----++
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5
time (seconds)
Hystart causes slow start to end a bit too early, but late enough not to affect
performance significantly. Hystart behaves fine in that case too.
Tested-By: Lucas Nussbaum <lucas.nussbaum@loria.fr>
--
| Lucas Nussbaum MCF Université Nancy 2 |
| lucas.nussbaum@loria.fr LORIA / AlGorille |
| http://www.loria.fr/~lnussbau/ +33 3 54 95 86 19 |
^ permalink raw reply
* Re: [Security] [SECURITY] DECnet: need to validate user data and access data?
From: Dan Rosenberg @ 2011-03-22 11:01 UTC (permalink / raw)
To: Steven Whitehouse; +Cc: Eugene Teo, davem, netdev, security, linux-decnet-user
In-Reply-To: <1300785230.2558.6.camel@dolmen>
On Tue, 2011-03-22 at 09:13 +0000, Steven Whitehouse wrote:
> Hi,
>
> On Tue, 2011-03-22 at 15:42 +0800, Eugene Teo wrote:
> > Cc'ed the decnet list. Looks like it's still active even though the
> > status is orphan.
> >
> Well, kind of active :-) I don't think there is a lot of development
> going on despite davem's recent changes to the routing code.
>
> These functions are used in relation to conninit messages which, on the
> incoming side are checked in dn_nsp_in.c:dn_find_listener() via the
> calls to dn_check_idf() so that we should never queue an incorrectly
> formatted message to the socket. The intent was that all messages should
> be checked as early as possible on entry to the code so that we can then
> rely on their content later on without needing to check again.
>
> I hope that answers your question, but let me know if you need anything
> else,
Thanks very much, that does clear it up. I must have missed it because
I was expecting it to use the array size macro (DN_MAXACCL) rather than
a hard-coded value. Glad it's a non-issue.
-Dan
> Steve.
>
> > On Tue, Mar 22, 2011 at 7:41 AM, Dan Rosenberg <drosenberg@vsecurity.com> wrote:
> > > In net/decnet/af_decnet.c, in the dn_access_copy() and dn_user_copy()
> > > functions, which are called from dn_connect(), length values are
> > > retrieved from incoming skb data and used as size values to copy
> > > functions:
> > >
> > > static void dn_access_copy(struct sk_buff *skb, struct accessdata_dn *acc)
> > > {
> > > unsigned char *ptr = skb->data;
> > >
> > > acc->acc_userl = *ptr++;
> > > memcpy(&acc->acc_user, ptr, acc->acc_userl);
> > > ptr += acc->acc_userl;
> > >
> > > acc->acc_passl = *ptr++;
> > > memcpy(&acc->acc_pass, ptr, acc->acc_passl);
> > > ptr += acc->acc_passl;
> > >
> > > acc->acc_accl = *ptr++;
> > > memcpy(&acc->acc_acc, ptr, acc->acc_accl);
> > >
> > > skb_pull(skb, acc->acc_accl + acc->acc_passl + acc->acc_userl + 3);
> > >
> > > }
> > >
> > > static void dn_user_copy(struct sk_buff *skb, struct optdata_dn *opt)
> > > {
> > > unsigned char *ptr = skb->data;
> > > u16 len = *ptr++; /* yes, it's 8bit on the wire */
> > >
> > > BUG_ON(len > 16); /* we've checked the contents earlier */
> > > opt->opt_optl = cpu_to_le16(len);
> > > opt->opt_status = 0;
> > > memcpy(opt->opt_data, ptr, len);
> > > skb_pull(skb, len + 1);
> > > }
> > >
> > >
> > > Despite the BUG_ON and comment suggesting these lengths have been
> > > validated, I don't think this is actually the case - it looks like these
> > > fields are validated for outbound data, but I see no validation for
> > > inbound data (unless I'm mistaken, which is entirely possible). If this
> > > is the case, this can allow remote attackers to cause controllable heap
> > > corruption. I'd appreciate it if someone who knows this protocol better
> > > than I do took a look at this and implemented appropriate error handling
> > > if it needs it.
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: bnx2 vlan issue
From: Seblu @ 2011-03-22 10:59 UTC (permalink / raw)
To: Jesse Gross; +Cc: netdev
In-Reply-To: <AANLkTik1JJO7mqxPzqfshMfH2JFUXn+yxbTqVdr4QDf6@mail.gmail.com>
On Tue, Mar 22, 2011 at 3:05 AM, Jesse Gross <jesse@nicira.com> wrote:
> On Thu, Mar 17, 2011 at 4:22 PM, Seblu <seblu@seblu.net> wrote:
>> On Thu, Mar 17, 2011 at 8:16 PM, Jesse Gross <jesse@nicira.com> wrote:
>>> On Thu, Mar 17, 2011 at 11:02 AM, Seblu <seblu@seblu.net> wrote:
>>>> On Thu, Mar 17, 2011 at 3:51 PM, Seblu <seblu@seblu.net> wrote:
>> How can I create a bridge with the untagged vlan from an interface?
>>
>>> * bridge on interface, vlans on bridge device. This gives you a
>>> bridge with all packets and vlan devices can give you specific vlans.
>> I cannot use this schema, i used bridge to bring together vnet
>> interface and vlan interface.
>
> I'm not sure I understand why you say you can't use this. You can
> combine vlans and bridging pretty much arbitrarily, including stacking
> multiple layers.
I don't see _how I can bridge an interface with an untagged vlan from
another interface_.
I little example is maybe more clear:
My dekstop have 2 NIC (eth0, eth1). I receive from network admin 2
vlans. 20 untag and 21 tagged. My laptop is plugged to eth1.
I want "export" untagged vlan 20 to eth1.
Before 2.6.37, i do something like br0 = (eth0 + eth1). I put an ip on
br0 and on eth0.21. And br0 just have untagged frame from eth0 which
was transmitted to eth1. eth0.21 have only tagged frame from vlan 21.
eth1 did not receive tagged vlan 21.
After 2.6.37, i can do a bridge like before (br0 = eth0 + eth1) but i
must use br0.21 to have access to vlan 21 network in my desktop. But,
my laptop can also access to tagged vlan 21, and i don't want this.
A lot of old xen based setup use this behaviour.
About my kvm test, I'm looking to the pci passtrough and macvtap, but
this requires configuration that supports it.
Why cannot have a eth0.U with only untagged frames?
>
>>
>>> * Use ebtables rules in the bridge to accept/reject certain packets as desired.
>> I don't see how use ebtables to push untagged frame to a dedicated
>> iface which can be added in a bridge.
>
> You could have a bridge on the raw interface and connect all of the
> VMs that need untagged traffic. If you add an ebtables rule to reject
> tagged traffic then vlan devices on the interface will continue to
> work as before.
>
If I ignores the fact that the name of the card is not fixed, i see.
But performance will follow? I don't believe this kind of config will
allow ~7/8Gbit/s of traffic.
Traversing ebtables rules is not free. And starting filtering traffic
is a really different job than just bridge cards together.
Regards,
--
Sébastien Luttringer
www.seblu.net
^ permalink raw reply
* Re: [PATCH] net: davinci_emac:Fix translation logic for buffer descriptor
From: David Miller @ 2011-03-22 10:22 UTC (permalink / raw)
To: sshtylyov; +Cc: srk, netdev, davinci-linux-open-source
In-Reply-To: <4D8875C1.9090004@mvista.com>
From: Sergei Shtylyov <sshtylyov@mvista.com>
Date: Tue, 22 Mar 2011 13:11:13 +0300
> Hello.
>
> On 22-03-2011 13:06, Sriramakrishnan wrote:
>
>> With recent changes to the driver(switch to new cpdma layer),
>> the support for buffer descriptor address translation logic
>> is broken. This affects platforms where the physical address of
>> the descriptors as seen by the DMA engine is different from the
>> physical address.
>
>> Original Patch adding translation logic support:
>> Commit: ad021ae8862209864dc8ebd3b7d3a55ce84b9ea2
>
>> Signed-off-by: Sriramakrishnan <srk@ti.com>
>
> AFAIK, full name is required for signoff.
Indeed, please provide your full name in your signoff lines.
Thanks.
^ permalink raw reply
* Re: oops / kernel panic in bonding.
From: Jiri Pirko @ 2011-03-22 10:16 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Jay Vosburgh, Andy Gospodarek, netdev@vger.kernel.org
In-Reply-To: <4D866F59.5070703@gmail.com>
Sun, Mar 20, 2011 at 10:19:21PM CET, nicolas.2p.debian@gmail.com wrote:
>Le 20/03/2011 21:17, Nicolas de Pesloüan a écrit :
>>Hi Jiri,
>>
>>I suspect we have a race condition somewhere in the new
>>bond_handle_frame function:
>>
>>The following commands produce one of the following errors:
>>
>>modprobe bonding max_bonds=0
>>echo +bond0>/sys/class/net/bonding_masters
>>echo +bond1>/sys/class/net/bonding_masters
>>echo +eth1>/sys/class/net/bond1/bonding/slaves
>>
>>This is mostly reproducible, under VirtualBox.
>>
>>All tests done with 08351fc6a75731226e1112fc7254542bd3a2912e at the top
>>commit (current net-next-2.6).
>
>I suspect netdev_rx_handler_register is called too early in bond_enslave.
>
>I think it should be the last thing we do in bond_enslave, if we
>don't want to face the risk to have bond_handle_frame being called
>before everything is properly setup.
>
> Nicolas.
Nicolas, would you please give the following patch a drive?
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 1a6e9eb..c339eb1 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1482,21 +1482,16 @@ static rx_handler_result_t bond_handle_frame(struct sk_buff **pskb)
{
struct sk_buff *skb = *pskb;
struct slave *slave;
- struct net_device *bond_dev;
struct bonding *bond;
- slave = bond_slave_get_rcu(skb->dev);
- bond_dev = ACCESS_ONCE(slave->dev->master);
- if (unlikely(!bond_dev))
- return RX_HANDLER_PASS;
-
skb = skb_share_check(skb, GFP_ATOMIC);
if (unlikely(!skb))
return RX_HANDLER_CONSUMED;
*pskb = skb;
- bond = netdev_priv(bond_dev);
+ slave = bond_slave_get_rcu(skb->dev);
+ bond = slave->bond;
if (bond->params.arp_interval)
slave->dev->last_rx = jiffies;
@@ -1505,10 +1500,10 @@ static rx_handler_result_t bond_handle_frame(struct sk_buff **pskb)
return RX_HANDLER_EXACT;
}
- skb->dev = bond_dev;
+ skb->dev = bond->dev;
if (bond->params.mode == BOND_MODE_ALB &&
- bond_dev->priv_flags & IFF_BRIDGE_PORT &&
+ bond->dev->priv_flags & IFF_BRIDGE_PORT &&
skb->pkt_type == PACKET_HOST) {
if (unlikely(skb_cow_head(skb,
@@ -1516,7 +1511,7 @@ static rx_handler_result_t bond_handle_frame(struct sk_buff **pskb)
kfree_skb(skb);
return RX_HANDLER_CONSUMED;
}
- memcpy(eth_hdr(skb)->h_dest, bond_dev->dev_addr, ETH_ALEN);
+ memcpy(eth_hdr(skb)->h_dest, bond->dev->dev_addr, ETH_ALEN);
}
return RX_HANDLER_ANOTHER;
@@ -1698,20 +1693,15 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
pr_debug("Error %d calling netdev_set_bond_master\n", res);
goto err_restore_mac;
}
- res = netdev_rx_handler_register(slave_dev, bond_handle_frame,
- new_slave);
- if (res) {
- pr_debug("Error %d calling netdev_rx_handler_register\n", res);
- goto err_unset_master;
- }
/* open the slave since the application closed it */
res = dev_open(slave_dev);
if (res) {
pr_debug("Opening slave %s failed\n", slave_dev->name);
- goto err_unreg_rxhandler;
+ goto err_unset_master;
}
+ new_slave->bond = bond;
new_slave->dev = slave_dev;
slave_dev->priv_flags |= IFF_BONDING;
@@ -1907,6 +1897,13 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
if (res)
goto err_close;
+ res = netdev_rx_handler_register(slave_dev, bond_handle_frame,
+ new_slave);
+ if (res) {
+ pr_debug("Error %d calling netdev_rx_handler_register\n", res);
+ goto err_dest_symlinks;
+ }
+
pr_info("%s: enslaving %s as a%s interface with a%s link.\n",
bond_dev->name, slave_dev->name,
bond_is_active_slave(new_slave) ? "n active" : " backup",
@@ -1916,13 +1913,12 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
return 0;
/* Undo stages on error */
+err_dest_symlinks:
+ bond_destroy_slave_symlinks(bond_dev, slave_dev);
+
err_close:
dev_close(slave_dev);
-err_unreg_rxhandler:
- netdev_rx_handler_unregister(slave_dev);
- synchronize_net();
-
err_unset_master:
netdev_set_bond_master(slave_dev, NULL);
@@ -1988,6 +1984,12 @@ int bond_release(struct net_device *bond_dev, struct net_device *slave_dev)
return -EINVAL;
}
+ /* unregister rx_handler early so bond_handle_frame wouldn't be called
+ * for this slave anymore.
+ */
+ netdev_rx_handler_unregister(slave_dev);
+ synchronize_net();
+
if (!bond->params.fail_over_mac) {
if (!compare_ether_addr(bond_dev->dev_addr, slave->perm_hwaddr) &&
bond->slave_cnt > 1)
@@ -2104,8 +2106,6 @@ int bond_release(struct net_device *bond_dev, struct net_device *slave_dev)
netif_addr_unlock_bh(bond_dev);
}
- netdev_rx_handler_unregister(slave_dev);
- synchronize_net();
netdev_set_bond_master(slave_dev, NULL);
slave_disable_netpoll(slave);
@@ -2171,13 +2171,20 @@ static int bond_release_all(struct net_device *bond_dev)
bond_change_active_slave(bond, NULL);
while ((slave = bond->first_slave) != NULL) {
+ slave_dev = slave->dev;
+
+ /* unregister rx_handler early so bond_handle_frame wouldn't
+ * be called for this slave anymore.
+ */
+ netdev_rx_handler_unregister(slave_dev);
+ synchronize_net();
+
/* Inform AD package of unbinding of slave
* before slave is detached from the list.
*/
if (bond->params.mode == BOND_MODE_8023AD)
bond_3ad_unbind_slave(slave);
- slave_dev = slave->dev;
bond_detach_slave(bond, slave);
/* now that the slave is detached, unlock and perform
@@ -2217,8 +2224,6 @@ static int bond_release_all(struct net_device *bond_dev)
netif_addr_unlock_bh(bond_dev);
}
- netdev_rx_handler_unregister(slave_dev);
- synchronize_net();
netdev_set_bond_master(slave_dev, NULL);
slave_disable_netpoll(slave);
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 6b26962..90736cb 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -187,6 +187,7 @@ struct slave {
struct net_device *dev; /* first - useful for panic debug */
struct slave *next;
struct slave *prev;
+ struct bonding *bond; /* our master */
int delay;
unsigned long jiffies;
unsigned long last_arp_rx;
^ permalink raw reply related
* Re: [PATCH] net: davinci_emac:Fix translation logic for buffer descriptor
From: Sergei Shtylyov @ 2011-03-22 10:11 UTC (permalink / raw)
To: Sriramakrishnan; +Cc: netdev, davinci-linux-open-source, davem
In-Reply-To: <1300788382-12658-1-git-send-email-srk@ti.com>
Hello.
On 22-03-2011 13:06, Sriramakrishnan wrote:
> With recent changes to the driver(switch to new cpdma layer),
> the support for buffer descriptor address translation logic
> is broken. This affects platforms where the physical address of
> the descriptors as seen by the DMA engine is different from the
> physical address.
> Original Patch adding translation logic support:
> Commit: ad021ae8862209864dc8ebd3b7d3a55ce84b9ea2
> Signed-off-by: Sriramakrishnan <srk@ti.com>
AFAIK, full name is required for signoff.
[...]
> diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
> index 082d6ea..df850fc 100644
> --- a/drivers/net/davinci_emac.c
> +++ b/drivers/net/davinci_emac.c
> @@ -1854,10 +1854,13 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
> dma_params.rxcp = priv->emac_base + 0x660;
> dma_params.num_chan = EMAC_MAX_TXRX_CHANNELS;
> dma_params.min_packet_size = EMAC_DEF_MIN_ETHPKTSIZE;
> - dma_params.desc_mem_phys = hw_ram_addr;
> + dma_params.desc_hw_addr = hw_ram_addr;
> dma_params.desc_mem_size = pdata->ctrl_ram_size;
> dma_params.desc_align = 16;
>
> + dma_params.desc_mem_phys = (pdata->no_bd_ram) ? 0 :
Parens not needed here.
> + ((u32 __force)res->start + pdata->ctrl_ram_offset);
Here either not necessary.
WBR, Sergei
^ permalink raw reply
* [PATCH] net: davinci_emac:Fix translation logic for buffer descriptor
From: Sriramakrishnan @ 2011-03-22 10:06 UTC (permalink / raw)
To: netdev; +Cc: davinci-linux-open-source, davem, srk
With recent changes to the driver(switch to new cpdma layer),
the support for buffer descriptor address translation logic
is broken. This affects platforms where the physical address of
the descriptors as seen by the DMA engine is different from the
physical address.
Original Patch adding translation logic support:
Commit: ad021ae8862209864dc8ebd3b7d3a55ce84b9ea2
Signed-off-by: Sriramakrishnan <srk@ti.com>
---
This patch has been generated against tip of Linus tree.
drivers/net/davinci_cpdma.c | 11 ++++++++---
drivers/net/davinci_cpdma.h | 1 +
drivers/net/davinci_emac.c | 5 ++++-
include/linux/davinci_emac.h | 1 +
4 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/net/davinci_cpdma.c b/drivers/net/davinci_cpdma.c
index e92b2b6..ae47f23 100644
--- a/drivers/net/davinci_cpdma.c
+++ b/drivers/net/davinci_cpdma.c
@@ -76,6 +76,7 @@ struct cpdma_desc {
struct cpdma_desc_pool {
u32 phys;
+ u32 hw_addr;
void __iomem *iomap; /* ioremap map */
void *cpumap; /* dma_alloc map */
int desc_size, mem_size;
@@ -137,7 +138,8 @@ struct cpdma_chan {
* abstract out these details
*/
static struct cpdma_desc_pool *
-cpdma_desc_pool_create(struct device *dev, u32 phys, int size, int align)
+cpdma_desc_pool_create(struct device *dev, u32 phys, u32 hw_addr,
+ int size, int align)
{
int bitmap_size;
struct cpdma_desc_pool *pool;
@@ -161,10 +163,12 @@ cpdma_desc_pool_create(struct device *dev, u32 phys, int size, int align)
if (phys) {
pool->phys = phys;
pool->iomap = ioremap(phys, size);
+ pool->hw_addr = hw_addr;
} else {
pool->cpumap = dma_alloc_coherent(dev, size, &pool->phys,
GFP_KERNEL);
pool->iomap = (void __force __iomem *)pool->cpumap;
+ pool->hw_addr = pool->phys;
}
if (pool->iomap)
@@ -201,14 +205,14 @@ static inline dma_addr_t desc_phys(struct cpdma_desc_pool *pool,
{
if (!desc)
return 0;
- return pool->phys + (__force dma_addr_t)desc -
+ return pool->hw_addr + (__force dma_addr_t)desc -
(__force dma_addr_t)pool->iomap;
}
static inline struct cpdma_desc __iomem *
desc_from_phys(struct cpdma_desc_pool *pool, dma_addr_t dma)
{
- return dma ? pool->iomap + dma - pool->phys : NULL;
+ return dma ? pool->iomap + dma - pool->hw_addr : NULL;
}
static struct cpdma_desc __iomem *
@@ -260,6 +264,7 @@ struct cpdma_ctlr *cpdma_ctlr_create(struct cpdma_params *params)
ctlr->pool = cpdma_desc_pool_create(ctlr->dev,
ctlr->params.desc_mem_phys,
+ ctlr->params.desc_hw_addr,
ctlr->params.desc_mem_size,
ctlr->params.desc_align);
if (!ctlr->pool) {
diff --git a/drivers/net/davinci_cpdma.h b/drivers/net/davinci_cpdma.h
index 868e50e..afa19a0 100644
--- a/drivers/net/davinci_cpdma.h
+++ b/drivers/net/davinci_cpdma.h
@@ -33,6 +33,7 @@ struct cpdma_params {
bool has_soft_reset;
int min_packet_size;
u32 desc_mem_phys;
+ u32 desc_hw_addr;
int desc_mem_size;
int desc_align;
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 082d6ea..df850fc 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -1854,10 +1854,13 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
dma_params.rxcp = priv->emac_base + 0x660;
dma_params.num_chan = EMAC_MAX_TXRX_CHANNELS;
dma_params.min_packet_size = EMAC_DEF_MIN_ETHPKTSIZE;
- dma_params.desc_mem_phys = hw_ram_addr;
+ dma_params.desc_hw_addr = hw_ram_addr;
dma_params.desc_mem_size = pdata->ctrl_ram_size;
dma_params.desc_align = 16;
+ dma_params.desc_mem_phys = (pdata->no_bd_ram) ? 0 :
+ ((u32 __force)res->start + pdata->ctrl_ram_offset);
+
priv->dma = cpdma_ctlr_create(&dma_params);
if (!priv->dma) {
dev_err(emac_dev, "DaVinci EMAC: Error initializing DMA\n");
diff --git a/include/linux/davinci_emac.h b/include/linux/davinci_emac.h
index 5dd4285..5428885 100644
--- a/include/linux/davinci_emac.h
+++ b/include/linux/davinci_emac.h
@@ -36,6 +36,7 @@ struct emac_platform_data {
u8 rmii_en;
u8 version;
+ bool no_bd_ram;
void (*interrupt_enable) (void);
void (*interrupt_disable) (void);
};
--
1.6.2.4
^ permalink raw reply related
* Re: [slab poison overwritten] Re: [GIT] Networking
From: Eric Dumazet @ 2011-03-22 10:00 UTC (permalink / raw)
To: Ingo Molnar
Cc: David Miller, torvalds, akpm, netdev, linux-kernel,
Peter Zijlstra, Thomas Gleixner, Arnd Bergmann, Pekka Enberg,
Simon Horman, Julian Anastasov
In-Reply-To: <20110322095638.GA26130@elte.hu>
Le mardi 22 mars 2011 à 10:56 +0100, Ingo Molnar a écrit :
> * Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > [PATCH] ipvs: fix a typo in __ip_vs_control_init()
>
> This fix and Simon's:
>
> IPVS: Use global mutex in ip_vs_app.c
>
> Did the trick here, the IPVS related SLAB corruptions are now gone.
>
> Thanks guys!
Thanks for testing Ingo ;)
^ permalink raw reply
* Re: [GIT] Networking
From: Ingo Molnar @ 2011-03-22 10:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Miller, akpm, netdev, linux-kernel
In-Reply-To: <AANLkTinN3qszBjbJdkXb2TPBkAW0mXGC=Ri1zKL9gdNg@mail.gmail.com>
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Sun, Mar 20, 2011 at 7:51 PM, David Miller <davem@davemloft.net> wrote:
> >
> > 1) The R8169 PHY fix from Eric Dumazet, which I see you've added to
> > your tree too. :-)
>
> Yeah, since my machine didn't have networking without it, and I could
> test it myself, I didn't wait to pull.
>
> That said, I'm delaying this pull request due to the known issues with
> it - let me know when you've updated it with the fix for the
> use-after-free fixes and the slab corruptor (the latter of which I
> haven't seen a patch for yet)
All problems i was able to trigger in this area are fixed by these patches:
ipvs: Fix a typo in __ip_vs_control_init()
IPVS: Use global mutex in ip_vs_app.c
ipx: Fix ipx_release()
net/appletalk: fix atalk_release use after free
Thanks,
Ingo
^ permalink raw reply
* [PATCH 4/4] drivers/net/fec: Don't mess with configured MAC addresses.
From: Lothar Waßmann @ 2011-03-22 10:00 UTC (permalink / raw)
To: netdev; +Cc: Shawn Guo, u.kleine-koenig, Lothar Waßmann
In-Reply-To: <49cf2dff25189eb7b7a0ff9eaceefab359f08b2e.1300724245.git.LW@KARO-electronics.de>
The FEC driver currently uses the MAC address assigned to the first
interface incremented by one for the second interface.
Change this to be able to configure distinct MAC addresses via
platform_data.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
---
drivers/net/fec.c | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 3666524..9d89e99 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -736,7 +736,7 @@ static void __inline__ fec_get_mac(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
struct fec_platform_data *pdata = fep->pdev->dev.platform_data;
- unsigned char *iap, tmpaddr[ETH_ALEN];
+ unsigned char iap[ETH_ALEN], tmpaddr[ETH_ALEN];
/*
* try to get mac address in following order:
@@ -744,7 +744,10 @@ static void __inline__ fec_get_mac(struct net_device *ndev)
* 1) module parameter via kernel command line in form
* fec.macaddr=0x00,0x04,0x9f,0x01,0x30,0xe0
*/
- iap = macaddr;
+ if (fep->pdev->id == 0)
+ memcpy(iap, macaddr, ETH_ALEN);
+ else
+ memset(iap, 0, ETH_ALEN);
/*
* 2) from flash or fuse (via platform data)
@@ -767,14 +770,10 @@ static void __inline__ fec_get_mac(struct net_device *ndev)
be32_to_cpu(readl(fep->hwp + FEC_ADDR_LOW));
*((unsigned short *) &tmpaddr[4]) =
be16_to_cpu(readl(fep->hwp + FEC_ADDR_HIGH) >> 16);
- iap = &tmpaddr[0];
+ memcpy(iap, tmpaddr, ETH_ALEN);
}
memcpy(ndev->dev_addr, iap, ETH_ALEN);
-
- /* Adjust MAC if using macaddr */
- if (iap == macaddr)
- ndev->dev_addr[ETH_ALEN-1] = macaddr[ETH_ALEN-1] + fep->pdev->id;
}
/* ------------------------------------------------------------------------- */
--
1.5.6.5
^ permalink raw reply related
* [PATCH 3/4] drivers/net/fec: Fix dual MAC support on i.MX28
From: Lothar Waßmann @ 2011-03-22 10:00 UTC (permalink / raw)
To: netdev; +Cc: Shawn Guo, u.kleine-koenig, Lothar Waßmann
In-Reply-To: <20110322092256.GG28098@S2100-06.ap.freescale.net>
The variant of the FEC chip found on i.MX28 features two distinct
ethernet MACs that both share a single MII interface. When
deconfiguring the eth0 interface, the MII interface is currently being
switched off, so that the second MAC won't work any more.
Make sure, the first MAC is never disabled when the second FEC device
is registered.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Acked-by: <shawn.guo@freescale.com>
Tested-by: <shawn.guo@freescale.com>
---
drivers/net/fec.c | 38 +++++++++++++++++++++++++++++++++-----
1 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 2436db8..3666524 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -82,6 +82,8 @@ static unsigned char macaddr[ETH_ALEN];
module_param_array(macaddr, byte, NULL, 0);
MODULE_PARM_DESC(macaddr, "FEC Ethernet MAC address");
+static int dual_mac;
+
#if defined(CONFIG_M5272)
/*
* Some hardware gets it MAC address out of local flash memory.
@@ -456,6 +459,8 @@ static void
fec_stop(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
+ const struct platform_device_id *id_entry =
+ platform_get_device_id(fep->pdev);
/* We cannot expect a graceful transmit stop without link !!! */
if (fep->link) {
@@ -466,11 +471,22 @@ fec_stop(struct net_device *ndev)
printk("fec_stop : Graceful transmit stop did not complete !\n");
}
- /* Whack a reset. We should wait for this. */
- writel(FEC_ECNTRL_RESET, fep->hwp + FEC_ECNTRL);
- udelay(10);
- writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
- writel(FEC_DEFAULT_IMASK, fep->hwp + FEC_IMASK);
+ if ((id_entry->driver_data & FEC_QUIRK_ENET_MAC) && dual_mac &&
+ fep->pdev->id == 0) {
+ /* clear the RDAR/TDAR bits to stop recv/xmit,
+ * but do not reset the controller since the second MAC
+ * may still be using the MII interface and requires ETHER_EN
+ * on the first MAC to be asserted for MII interrupts!
+ */
+ writel(0, fep->hwp + FEC_ECNTRL);
+ writel(FEC_ECNTRL_ETHER_EN, fep->hwp + FEC_ECNTRL);
+ } else {
+ /* Whack a reset. We should wait for this. */
+ writel(FEC_ECNTRL_RESET, fep->hwp + FEC_ECNTRL);
+ udelay(10);
+ writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
+ writel(FEC_DEFAULT_IMASK, fep->hwp + FEC_IMASK);
+ }
}
static void
@@ -1435,6 +1461,9 @@ fec_probe(struct platform_device *pdev)
if (ret)
goto failed_register;
+ if (pdev->id > 0)
+ dual_mac = 1;
+
return 0;
failed_register:
--
1.5.6.5
^ permalink raw reply related
* Re: [slab poison overwritten] Re: [GIT] Networking
From: Ingo Molnar @ 2011-03-22 9:56 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, torvalds, akpm, netdev, linux-kernel,
Peter Zijlstra, Thomas Gleixner, Arnd Bergmann, Pekka Enberg,
Simon Horman, Julian Anastasov
In-Reply-To: <1300738540.2837.5.camel@edumazet-laptop>
* Eric Dumazet <eric.dumazet@gmail.com> wrote:
> [PATCH] ipvs: fix a typo in __ip_vs_control_init()
This fix and Simon's:
IPVS: Use global mutex in ip_vs_app.c
Did the trick here, the IPVS related SLAB corruptions are now gone.
Thanks guys!
Ingo
^ permalink raw reply
* Re: [PATCH 3/4] drivers/net/fec: Fix dual MAC support on i.MX28
From: Shawn Guo @ 2011-03-22 9:22 UTC (permalink / raw)
To: Lothar Waßmann; +Cc: netdev, u.kleine-koenig
In-Reply-To: <19848.22512.18596.3017@ipc1.ka-ro>
On Tue, Mar 22, 2011 at 09:04:00AM +0100, Lothar Waßmann wrote:
> Hi,
>
> Shawn Guo writes:
> > Hi Lothar,
> >
> > On Mon, Mar 21, 2011 at 05:37:35PM +0100, Lothar Waßmann wrote:
> > > The variant of the FEC chip found on i.MX28 features two distinct
> > > ethernet MACs that both share a single MII interface. When
> > > deconfiguring the eth0 interface, the MII interface is currently being
> > > switched off, so that the second MAC won't work any more.
> > >
> > I'm wondering what the use case is you intend to support with this
> > patch.
> >
> The patch enables the use of both MACs independently from each other.
> Without this patch deconfiguring eth0 would leave eth1 in an unusable
> state.
>
Ah, I see. Just tested it. It really helps. Thanks for the patch.
With the patch cleaned up, please add:
Acked-by: <shawn.guo@freescale.com>
Tested-by: <shawn.guo@freescale.com>
--
Regards,
Shawn
^ permalink raw reply
* Re: [Security] [SECURITY] DECnet: need to validate user data and access data?
From: David Miller @ 2011-03-22 9:21 UTC (permalink / raw)
To: swhiteho; +Cc: eugeneteo, drosenberg, netdev, security, linux-decnet-user
In-Reply-To: <1300785230.2558.6.camel@dolmen>
From: Steven Whitehouse <swhiteho@redhat.com>
Date: Tue, 22 Mar 2011 09:13:50 +0000
> These functions are used in relation to conninit messages which, on the
> incoming side are checked in dn_nsp_in.c:dn_find_listener() via the
> calls to dn_check_idf() so that we should never queue an incorrectly
> formatted message to the socket. The intent was that all messages should
> be checked as early as possible on entry to the code so that we can then
> rely on their content later on without needing to check again.
Ok, so we should be find here.
Thanks for the explanation Steven.
^ permalink raw reply
* Re: [Security] [SECURITY] DECnet: need to validate user data and access data?
From: Steven Whitehouse @ 2011-03-22 9:13 UTC (permalink / raw)
To: Eugene Teo; +Cc: Dan Rosenberg, davem, netdev, security, linux-decnet-user
In-Reply-To: <AANLkTinbj295sZvXrQm6uhH9+DbAbY1AZU7Eo5_dC6HP@mail.gmail.com>
Hi,
On Tue, 2011-03-22 at 15:42 +0800, Eugene Teo wrote:
> Cc'ed the decnet list. Looks like it's still active even though the
> status is orphan.
>
Well, kind of active :-) I don't think there is a lot of development
going on despite davem's recent changes to the routing code.
These functions are used in relation to conninit messages which, on the
incoming side are checked in dn_nsp_in.c:dn_find_listener() via the
calls to dn_check_idf() so that we should never queue an incorrectly
formatted message to the socket. The intent was that all messages should
be checked as early as possible on entry to the code so that we can then
rely on their content later on without needing to check again.
I hope that answers your question, but let me know if you need anything
else,
Steve.
> On Tue, Mar 22, 2011 at 7:41 AM, Dan Rosenberg <drosenberg@vsecurity.com> wrote:
> > In net/decnet/af_decnet.c, in the dn_access_copy() and dn_user_copy()
> > functions, which are called from dn_connect(), length values are
> > retrieved from incoming skb data and used as size values to copy
> > functions:
> >
> > static void dn_access_copy(struct sk_buff *skb, struct accessdata_dn *acc)
> > {
> > unsigned char *ptr = skb->data;
> >
> > acc->acc_userl = *ptr++;
> > memcpy(&acc->acc_user, ptr, acc->acc_userl);
> > ptr += acc->acc_userl;
> >
> > acc->acc_passl = *ptr++;
> > memcpy(&acc->acc_pass, ptr, acc->acc_passl);
> > ptr += acc->acc_passl;
> >
> > acc->acc_accl = *ptr++;
> > memcpy(&acc->acc_acc, ptr, acc->acc_accl);
> >
> > skb_pull(skb, acc->acc_accl + acc->acc_passl + acc->acc_userl + 3);
> >
> > }
> >
> > static void dn_user_copy(struct sk_buff *skb, struct optdata_dn *opt)
> > {
> > unsigned char *ptr = skb->data;
> > u16 len = *ptr++; /* yes, it's 8bit on the wire */
> >
> > BUG_ON(len > 16); /* we've checked the contents earlier */
> > opt->opt_optl = cpu_to_le16(len);
> > opt->opt_status = 0;
> > memcpy(opt->opt_data, ptr, len);
> > skb_pull(skb, len + 1);
> > }
> >
> >
> > Despite the BUG_ON and comment suggesting these lengths have been
> > validated, I don't think this is actually the case - it looks like these
> > fields are validated for outbound data, but I see no validation for
> > inbound data (unless I'm mistaken, which is entirely possible). If this
> > is the case, this can allow remote attackers to cause controllable heap
> > corruption. I'd appreciate it if someone who knows this protocol better
> > than I do took a look at this and implemented appropriate error handling
> > if it needs it.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox