* [PATCH] caif: fix a potential NULL dereference
From: Eric Dumazet @ 2011-09-02 12:19 UTC (permalink / raw)
To: Sjur Brændeland, David Miller; +Cc: netdev
In-Reply-To: <CAJK669Yb6V=xr9ZvQGOKGEvmzO1JGhrHD+sR69b04EQxUjOOrQ@mail.gmail.com>
Commit bd30ce4bc0b7 (caif: Use RCU instead of spin-lock in caif_dev.c)
added a potential NULL dereference in case alloc_percpu() fails.
caif_device_alloc() can also use GFP_KERNEL instead of GFP_ATOMIC.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Sjur Brændeland <sjur.brandeland@stericsson.com>
---
net/caif/caif_dev.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/caif/caif_dev.c b/net/caif/caif_dev.c
index 7c2fa0a..7f9ac07 100644
--- a/net/caif/caif_dev.c
+++ b/net/caif/caif_dev.c
@@ -93,10 +93,14 @@ static struct caif_device_entry *caif_device_alloc(struct net_device *dev)
caifdevs = caif_device_list(dev_net(dev));
BUG_ON(!caifdevs);
- caifd = kzalloc(sizeof(*caifd), GFP_ATOMIC);
+ caifd = kzalloc(sizeof(*caifd), GFP_KERNEL);
if (!caifd)
return NULL;
caifd->pcpu_refcnt = alloc_percpu(int);
+ if (!caifd->pcpu_refcnt) {
+ kfree(caifd);
+ return NULL;
+ }
caifd->netdev = dev;
dev_hold(dev);
return caifd;
^ permalink raw reply related
* [patch net-next-2.6 v2] net: consolidate and fix ethtool_ops->get_settings calling
From: Jiri Pirko @ 2011-09-02 12:26 UTC (permalink / raw)
To: netdev
Cc: ralf, fubar, andy, kaber, bprakash, JBottomley, robert.w.love,
davem, shemminger, decot, bhutchings, mirq-linux,
alexander.h.duyck, amit.salecha, eric.dumazet, therbert, paulmck,
laijs, xiaosuo, greearb, loke.chetan, linux-mips, linux-scsi,
devel, bridge
In-Reply-To: <1314905304-16485-1-git-send-email-jpirko@redhat.com>
This patch does several things:
- introduces __ethtool_get_settings which is called from ethtool code and
from dev_ethtool_get_settings() as well.
- dev_ethtool_get_settings() becomes rtnl wrapper for
__ethtool_get_settings()
- changes calling in drivers so rtnl locking is respected. In
iboe_get_rate was previously ->get_settings() called unlocked. This
fixes it
- introduces rtnl_lock in bnx2fc_vport_create() and fcoe_vport_create()
so bnx2fc_if_create() and fcoe_if_create() are called locked as they
are from other places.
- prb_calc_retire_blk_tmo() in af_packet.c was not calling get_settings
with rntl_lock. So use dev_ethtool_get_settings here.
- use __ethtool_get_settings() in bonding code
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
v1->v2:
add missing export_symbol
---
arch/mips/txx9/generic/setup_tx4939.c | 2 +-
drivers/net/bonding/bond_main.c | 13 ++++------
drivers/net/macvlan.c | 3 +-
drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 4 ++-
drivers/scsi/fcoe/fcoe.c | 4 ++-
include/linux/ethtool.h | 3 ++
net/8021q/vlan_dev.c | 3 +-
net/bridge/br_if.c | 2 +-
net/core/dev.c | 17 +++++---------
net/core/ethtool.c | 18 ++++++++++----
net/core/net-sysfs.c | 4 +-
net/packet/af_packet.c | 41 +++++++++++++++-----------------
12 files changed, 60 insertions(+), 54 deletions(-)
diff --git a/arch/mips/txx9/generic/setup_tx4939.c b/arch/mips/txx9/generic/setup_tx4939.c
index e9f95dc..ba3cec3 100644
--- a/arch/mips/txx9/generic/setup_tx4939.c
+++ b/arch/mips/txx9/generic/setup_tx4939.c
@@ -321,7 +321,7 @@ void __init tx4939_sio_init(unsigned int sclk, unsigned int cts_mask)
static u32 tx4939_get_eth_speed(struct net_device *dev)
{
struct ethtool_cmd cmd;
- if (dev_ethtool_get_settings(dev, &cmd))
+ if (__ethtool_get_settings(dev, &cmd))
return 100; /* default 100Mbps */
return ethtool_cmd_speed(&cmd);
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 8cb75a6..1dcb07c 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -557,7 +557,7 @@ down:
static int bond_update_speed_duplex(struct slave *slave)
{
struct net_device *slave_dev = slave->dev;
- struct ethtool_cmd etool = { .cmd = ETHTOOL_GSET };
+ struct ethtool_cmd ecmd;
u32 slave_speed;
int res;
@@ -565,18 +565,15 @@ static int bond_update_speed_duplex(struct slave *slave)
slave->speed = SPEED_100;
slave->duplex = DUPLEX_FULL;
- if (!slave_dev->ethtool_ops || !slave_dev->ethtool_ops->get_settings)
- return -1;
-
- res = slave_dev->ethtool_ops->get_settings(slave_dev, &etool);
+ res = __ethtool_get_settings(slave_dev, &ecmd);
if (res < 0)
return -1;
- slave_speed = ethtool_cmd_speed(&etool);
+ slave_speed = ethtool_cmd_speed(&ecmd);
if (slave_speed == 0 || slave_speed == ((__u32) -1))
return -1;
- switch (etool.duplex) {
+ switch (ecmd.duplex) {
case DUPLEX_FULL:
case DUPLEX_HALF:
break;
@@ -585,7 +582,7 @@ static int bond_update_speed_duplex(struct slave *slave)
}
slave->speed = slave_speed;
- slave->duplex = etool.duplex;
+ slave->duplex = ecmd.duplex;
return 0;
}
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 836e13f..b100c90 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -543,7 +543,8 @@ static int macvlan_ethtool_get_settings(struct net_device *dev,
struct ethtool_cmd *cmd)
{
const struct macvlan_dev *vlan = netdev_priv(dev);
- return dev_ethtool_get_settings(vlan->lowerdev, cmd);
+
+ return __ethtool_get_settings(vlan->lowerdev, cmd);
}
static const struct ethtool_ops macvlan_ethtool_ops = {
diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
index 2c780a7..820a184 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
@@ -673,7 +673,7 @@ static void bnx2fc_link_speed_update(struct fc_lport *lport)
struct net_device *netdev = interface->netdev;
struct ethtool_cmd ecmd;
- if (!dev_ethtool_get_settings(netdev, &ecmd)) {
+ if (!__ethtool_get_settings(netdev, &ecmd)) {
lport->link_supported_speeds &=
~(FC_PORTSPEED_1GBIT | FC_PORTSPEED_10GBIT);
if (ecmd.supported & (SUPPORTED_1000baseT_Half |
@@ -1001,9 +1001,11 @@ static int bnx2fc_vport_create(struct fc_vport *vport, bool disabled)
"this interface\n");
return -EIO;
}
+ rtnl_lock();
mutex_lock(&bnx2fc_dev_lock);
vn_port = bnx2fc_if_create(interface, &vport->dev, 1);
mutex_unlock(&bnx2fc_dev_lock);
+ rtnl_unlock();
if (IS_ERR(vn_port)) {
printk(KERN_ERR PFX "bnx2fc_vport_create (%s) failed\n",
diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
index 3416ab6..83aa3ac 100644
--- a/drivers/scsi/fcoe/fcoe.c
+++ b/drivers/scsi/fcoe/fcoe.c
@@ -2043,7 +2043,7 @@ int fcoe_link_speed_update(struct fc_lport *lport)
struct net_device *netdev = fcoe_netdev(lport);
struct ethtool_cmd ecmd;
- if (!dev_ethtool_get_settings(netdev, &ecmd)) {
+ if (!__ethtool_get_settings(netdev, &ecmd)) {
lport->link_supported_speeds &=
~(FC_PORTSPEED_1GBIT | FC_PORTSPEED_10GBIT);
if (ecmd.supported & (SUPPORTED_1000baseT_Half |
@@ -2452,7 +2452,9 @@ static int fcoe_vport_create(struct fc_vport *vport, bool disabled)
}
mutex_lock(&fcoe_config_mutex);
+ rtnl_lock();
vn_port = fcoe_if_create(fcoe, &vport->dev, 1);
+ rtnl_unlock();
mutex_unlock(&fcoe_config_mutex);
if (IS_ERR(vn_port)) {
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 3829712..8571f18 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -728,6 +728,9 @@ enum ethtool_sfeatures_retval_bits {
/* needed by dev_disable_lro() */
extern int __ethtool_set_flags(struct net_device *dev, u32 flags);
+extern int __ethtool_get_settings(struct net_device *dev,
+ struct ethtool_cmd *cmd);
+
/**
* enum ethtool_phys_id_state - indicator state for physical identification
* @ETHTOOL_ID_INACTIVE: Physical ID indicator should be deactivated
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index eba705b..c8cf939 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -610,7 +610,8 @@ static int vlan_ethtool_get_settings(struct net_device *dev,
struct ethtool_cmd *cmd)
{
const struct vlan_dev_info *vlan = vlan_dev_info(dev);
- return dev_ethtool_get_settings(vlan->real_dev, cmd);
+
+ return __ethtool_get_settings(vlan->real_dev, cmd);
}
static void vlan_ethtool_get_drvinfo(struct net_device *dev,
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index b365bba..043a5eb 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -35,7 +35,7 @@ static int port_cost(struct net_device *dev)
{
struct ethtool_cmd ecmd;
- if (!dev_ethtool_get_settings(dev, &ecmd)) {
+ if (!__ethtool_get_settings(dev, &ecmd)) {
switch (ethtool_cmd_speed(&ecmd)) {
case SPEED_10000:
return 2;
diff --git a/net/core/dev.c b/net/core/dev.c
index 11b0fc7..abdc0e3 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4570,22 +4570,17 @@ void dev_set_rx_mode(struct net_device *dev)
* @dev: device
* @cmd: memory area for ethtool_ops::get_settings() result
*
- * The cmd arg is initialized properly (cleared and
- * ethtool_cmd::cmd field set to ETHTOOL_GSET).
- *
- * Return device's ethtool_ops::get_settings() result value or
- * -EOPNOTSUPP when device doesn't expose
- * ethtool_ops::get_settings() operation.
+ * This is wrapper taking rtnl lock for __ethtool_get_settings()
*/
int dev_ethtool_get_settings(struct net_device *dev,
struct ethtool_cmd *cmd)
{
- if (!dev->ethtool_ops || !dev->ethtool_ops->get_settings)
- return -EOPNOTSUPP;
+ int ret;
- memset(cmd, 0, sizeof(struct ethtool_cmd));
- cmd->cmd = ETHTOOL_GSET;
- return dev->ethtool_ops->get_settings(dev, cmd);
+ rtnl_lock();
+ ret = __ethtool_get_settings(dev, cmd);
+ rtnl_unlock();
+ return ret;
}
EXPORT_SYMBOL(dev_ethtool_get_settings);
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 6cdba5f..307297c 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -569,15 +569,23 @@ int __ethtool_set_flags(struct net_device *dev, u32 data)
return 0;
}
+int __ethtool_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+{
+ if (!dev->ethtool_ops || !dev->ethtool_ops->get_settings)
+ return -EOPNOTSUPP;
+
+ memset(cmd, 0, sizeof(struct ethtool_cmd));
+ cmd->cmd = ETHTOOL_GSET;
+ return dev->ethtool_ops->get_settings(dev, cmd);
+}
+EXPORT_SYMBOL(__ethtool_get_settings);
+
static int ethtool_get_settings(struct net_device *dev, void __user *useraddr)
{
- struct ethtool_cmd cmd = { .cmd = ETHTOOL_GSET };
int err;
+ struct ethtool_cmd cmd;
- if (!dev->ethtool_ops->get_settings)
- return -EOPNOTSUPP;
-
- err = dev->ethtool_ops->get_settings(dev, &cmd);
+ err = __ethtool_get_settings(dev, &cmd);
if (err < 0)
return err;
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 90fdb46..48e6279 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -172,7 +172,7 @@ static ssize_t show_speed(struct device *dev,
if (netif_running(netdev)) {
struct ethtool_cmd cmd;
- if (!dev_ethtool_get_settings(netdev, &cmd))
+ if (!__ethtool_get_settings(netdev, &cmd))
ret = sprintf(buf, fmt_udec, ethtool_cmd_speed(&cmd));
}
rtnl_unlock();
@@ -190,7 +190,7 @@ static ssize_t show_duplex(struct device *dev,
if (netif_running(netdev)) {
struct ethtool_cmd cmd;
- if (!dev_ethtool_get_settings(netdev, &cmd))
+ if (!__ethtool_get_settings(netdev, &cmd))
ret = sprintf(buf, "%s\n",
cmd.duplex ? "full" : "half");
}
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 2ea3d63..1bcc794 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -530,33 +530,30 @@ static int prb_calc_retire_blk_tmo(struct packet_sock *po,
{
struct net_device *dev;
unsigned int mbits = 0, msec = 0, div = 0, tmo = 0;
+ struct ethtool_cmd ecmd;
dev = dev_get_by_index(sock_net(&po->sk), po->ifindex);
if (unlikely(dev == NULL))
return DEFAULT_PRB_RETIRE_TOV;
- if (dev->ethtool_ops && dev->ethtool_ops->get_settings) {
- struct ethtool_cmd ecmd = { .cmd = ETHTOOL_GSET, };
-
- if (!dev->ethtool_ops->get_settings(dev, &ecmd)) {
- switch (ecmd.speed) {
- case SPEED_10000:
- msec = 1;
- div = 10000/1000;
- break;
- case SPEED_1000:
- msec = 1;
- div = 1000/1000;
- break;
- /*
- * If the link speed is so slow you don't really
- * need to worry about perf anyways
- */
- case SPEED_100:
- case SPEED_10:
- default:
- return DEFAULT_PRB_RETIRE_TOV;
- }
+ if (!dev_ethtool_get_settings(dev, &ecmd)) {
+ switch (ecmd.speed) {
+ case SPEED_10000:
+ msec = 1;
+ div = 10000/1000;
+ break;
+ case SPEED_1000:
+ msec = 1;
+ div = 1000/1000;
+ break;
+ /*
+ * If the link speed is so slow you don't really
+ * need to worry about perf anyways
+ */
+ case SPEED_100:
+ case SPEED_10:
+ default:
+ return DEFAULT_PRB_RETIRE_TOV;
}
}
--
1.7.6
^ permalink raw reply related
* Re: [linux-firmware v4 1/2] rtl_nic: update firmware for RTL8111E-VL
From: Ben Hutchings @ 2011-09-02 13:15 UTC (permalink / raw)
To: Hayes Wang; +Cc: dwmw2, romieu, netdev
In-Reply-To: <1314860833-4000-1-git-send-email-hayeswang@realtek.com>
[-- Attachment #1: Type: text/plain, Size: 143 bytes --]
On Thu, 2011-09-01 at 15:07 +0800, Hayes Wang wrote:
> Updated firmware with stability fixes.
> Version: 0.0.2
[...]
Applied.
Ben.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [linux-firmware v4 2/2] rtl_nic: add new firmware for RTL8111F
From: Ben Hutchings @ 2011-09-02 13:16 UTC (permalink / raw)
To: Hayes Wang; +Cc: dwmw2, romieu, netdev
In-Reply-To: <1314860833-4000-2-git-send-email-hayeswang@realtek.com>
[-- Attachment #1: Type: text/plain, Size: 306 bytes --]
On Thu, 2011-09-01 at 15:07 +0800, Hayes Wang wrote:
> Add new firmware:
> 1. rtl_nic/rtl8168f-1.fw
> version: 0.0.2
> 2. rtl_nic/rtl8168f-2.fw
> version: 0.0.2
[...]
Applied. (And please do send firmware files to me as well as David; we
can both commit to linux-firmware.git.)
Ben.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] caif: fix a potential NULL dereference
From: Sjur Brændeland @ 2011-09-02 13:13 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1314965963.2573.23.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Eric Dumazet wrote:
> Commit bd30ce4bc0b7 (caif: Use RCU instead of spin-lock in caif_dev.c)
> added a potential NULL dereference in case alloc_percpu() fails.
>
> caif_device_alloc() can also use GFP_KERNEL instead of GFP_ATOMIC.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Looks good thanks,
Acked-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
^ permalink raw reply
* Re: [PATCH] af_packet: flush complete kernel cache in packet_sendmsg
From: Ben Hutchings @ 2011-09-02 13:46 UTC (permalink / raw)
To: Phil Sutter; +Cc: linux-arm-kernel, netdev, Russell King, David S. Miller
In-Reply-To: <1314961686-30870-1-git-send-email-phil.sutter@viprinet.com>
On Fri, 2011-09-02 at 13:08 +0200, Phil Sutter wrote:
> This flushes the cache before and after accessing the mmapped packet
> buffer. It seems like the call to flush_dcache_page from inside
> __packet_get_status is not enough on Kirkwood (or ARM in general).
> ---
> I know this is far from an optimal solution, but it's in fact the only working
> one I found.
[...]
This is ridiculous. If flush_dcache_page() isn't doing everything it
should, you need to fix that.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] af_packet: flush complete kernel cache in packet_sendmsg
From: Phil Sutter @ 2011-09-02 13:59 UTC (permalink / raw)
To: Ben Hutchings; +Cc: linux-arm-kernel, netdev, Russell King, David S. Miller
In-Reply-To: <1314971179.3092.159.camel@deadeye>
On Fri, Sep 02, 2011 at 02:46:17PM +0100, Ben Hutchings wrote:
> On Fri, 2011-09-02 at 13:08 +0200, Phil Sutter wrote:
> > This flushes the cache before and after accessing the mmapped packet
> > buffer. It seems like the call to flush_dcache_page from inside
> > __packet_get_status is not enough on Kirkwood (or ARM in general).
> > ---
> > I know this is far from an optimal solution, but it's in fact the only working
> > one I found.
> [...]
>
> This is ridiculous. If flush_dcache_page() isn't doing everything it
> should, you need to fix that.
You're absolutely correct. But in fact this problem goes way too deep
for me to find it's cause. And since my time is finite, I doubt this
will change in the near future. So I asked for help, a pointer in
whatever direction or anything I could try to help further analyzing -
without any response (unless I missed it, in which case I apologize).
Please don't get me wrong. I have no intend in this patch becoming
mainline, just want to give others with the same problem a starting
point.
Greetings, Phil
--
Viprinet GmbH
Mainzer Str. 43
55411 Bingen am Rhein
Germany
Zentrale: +49-6721-49030-0
Durchwahl: +49-6721-49030-134
Fax: +49-6721-49030-209
phil.sutter@viprinet.com
http://www.viprinet.com
Sitz der Gesellschaft: Bingen am Rhein
Handelsregister: Amtsgericht Mainz HRB40380
Geschäftsführer: Simon Kissel
^ permalink raw reply
* Re: FW: [PATCH] af_packet: flush complete kernel cache in packet_sendmsg
From: chetan loke @ 2011-09-02 14:00 UTC (permalink / raw)
To: phil.sutter, linux-arm-kernel; +Cc: netdev, linux, davem
In-Reply-To: <D3F292ADF945FB49B35E96C94C2061B90A239361@nsmail.netscout.com>
>
> This flushes the cache before and after accessing the mmapped packet
> buffer. It seems like the call to flush_dcache_page from inside
> __packet_get_status is not enough on Kirkwood (or ARM in general).
> + kw_extra_cache_flush();
> + rc = po->tx_ring.pg_vec ? tpacket_snd(po, msg) :
> + packet_snd(sock, msg, len);
> + kw_extra_cache_flush();
> + return rc;
> }
If a workaround is needed for mmap, then why not change tpacket_snd?
Also, is this workaround actually working for all the cases? Because
packet_get_status is not being touched in your patch.
Also, I don't see any changes for the Rx-path. Is that working ok?
Chetan Loke
^ permalink raw reply
* [PATCH] ixgbe: drop zero length frame segments during a packet split rx
From: Neil Horman @ 2011-09-02 14:03 UTC (permalink / raw)
To: netdev
Cc: Neil Horman, Thadeu Lima de Souza Cascardo, Jesse Brandeburg,
Alexander Duyck, John Fastabend, Jeff Kirsher, David S. Miller
This oops was reported recently no ppc64 hardware:
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc0000000004dda0c
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=1024 NUMA pSeries
Modules linked in: sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4
iptable_fi
lter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state
nf_conntrack ip6table_filter ip6_tables ipv6 jsm ses enclosure sg ixgbe
mdio e1000 ehea ext4 jbd2 mbcache sd_mod crc_t10dif ipr dm_mod
NIP: c0000000004dda0c LR: c0000000004e3e50 CTR: c0000000004e3e20
REGS: c0000001bffeb8d0 TRAP: 0300 Not tainted (3.1.0-rc2-10121-gab7e2db)
MSR: 8000000000009032 <EE,ME,IR,DR> CR: 28002042 XER: 20000000
CFAR: c000000000004d70
DAR: 0000000000000000, DSISR: 40000000
TASK = c000000000d548e0[0] 'swapper' THREAD: c000000000dfc000 CPU: 0
GPR04: c0000000010f4d80 c0000001bffebd80 0000000000000000 c0000001b18a8200
GPR08: 0000000000000280 c0000001bcc517a8 c0000001b18a7f80 0000000000000000
GPR12: d0000000047e5bb0 c000000001f10000 c0000001b19c8700 0000000000000000
GPR16: c0000001bffebd80 0000000000000083 c00000018f2447a0 0000000000000002
GPR20: 0000000000000000 c0000001ba860010 c0000001ba860000 d000000003d40000
GPR24: 0000000000000000 0000000000000083 d000000003d40000 0000000000000001
GPR28: c00000018f244780 c0000001b2b94310 c000000000da95f0 c0000001bcc51780
NIP [c0000000004dda0c] .skb_gro_reset_offset+0x5c/0xe0
LR [c0000000004e3e50] .napi_gro_receive+0x30/0x120
Call Trace:
[c0000001bffebb50] [c000000000da95f0] perf_callchain_user+0x0/0x10 (unreliable)
[c0000001bffebbf0] [d0000000047bd118] .ixgbe_clean_rx_irq+0x7a8/0x8a0 [ixgbe]
[c0000001bffebd10] [d0000000047bd414] .ixgbe_poll+0x64/0x160 [ixgbe]
[c0000001bffebdd0] [c0000000004e3358] .net_rx_action+0x108/0x2a0
[c0000001bffebea0] [c00000000009b220] .__do_softirq+0x110/0x2a0
[c0000001bffebf90] [c000000000023798] .call_do_softirq+0x14/0x24
[c000000000dff830] [c000000000011148] .do_softirq+0xf8/0x130
[c000000000dff8d0] [c00000000009aeb4] .irq_exit+0xb4/0xc0
[c000000000dff950] [c000000000011254] .do_IRQ+0xd4/0x300
[c000000000dffa10] [c000000000005024] hardware_interrupt_entry+0x18/0x74
--- Exception: 501 at .pseries_dedicated_idle_sleep+0xe4/0x210
LR = .pseries_dedicated_idle_sleep+0x8c/0x210
[c000000000dffd00] [c00000000005b194] .pseries_dedicated_idle_sleep+0x194/0x210
(unreliable)
[c000000000dffdc0] [c000000000018c84] .cpu_idle+0x164/0x210
[c000000000dffe70] [c00000000000b0d0] .rest_init+0x90/0xb0
[c000000000dffef0] [c000000000830bc0] .start_kernel+0x54c/0x56c
[c000000000dfff90] [c00000000000953c] .start_here_common+0x1c/0x60
Its caused when skb_gro_reset_offset attempts to call PageHighMem on
skb_shinfo(skb)->frags[0].page, when the frags array was left uninitalized.
This can happen in the ixgbe driver if the hardware reports a zero length rx
descriptor ni the middle of a packet split receive transaction. I've consulted
with Jesse Brandeburg on this, who is attempting to root cause the issue at
Intel, but it seems prudent to add this check to the driver to discard frames of
that encounter this error to avoid the opps
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
CC: Alexander Duyck <alexander.h.duyck@intel.com>
CC: John Fastabend <john.r.fastabend@intel.com>
CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
CC: David S. Miller <davem@davemloft.net>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 17 +++++++++++------
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index d20e804..6d59185 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -1326,6 +1326,13 @@ static void ixgbe_clean_rx_irq(struct ixgbe_q_vector *q_vector,
rx_buffer_info = &rx_ring->rx_buffer_info[i];
+ i++;
+ if (i == rx_ring->count)
+ i = 0;
+
+ next_rxd = IXGBE_RX_DESC_ADV(rx_ring, i);
+ prefetch(next_rxd);
+
skb = rx_buffer_info->skb;
rx_buffer_info->skb = NULL;
prefetch(skb->data);
@@ -1367,6 +1374,10 @@ static void ixgbe_clean_rx_irq(struct ixgbe_q_vector *q_vector,
} else {
/* assume packet split since header is unmapped */
upper_len = le16_to_cpu(rx_desc->wb.upper.length);
+ if (!upper_len) {
+ rx_buffer_info->skb = skb;
+ goto next_desc;
+ }
}
if (upper_len) {
@@ -1391,12 +1402,6 @@ static void ixgbe_clean_rx_irq(struct ixgbe_q_vector *q_vector,
skb->truesize += upper_len;
}
- i++;
- if (i == rx_ring->count)
- i = 0;
-
- next_rxd = IXGBE_RX_DESC_ADV(rx_ring, i);
- prefetch(next_rxd);
cleaned_count++;
if (pkt_is_rsc) {
--
1.7.6
^ permalink raw reply related
* Re: FW: [PATCH] af_packet: flush complete kernel cache in packet_sendmsg
From: Phil Sutter @ 2011-09-02 15:31 UTC (permalink / raw)
To: chetan loke; +Cc: linux-arm-kernel, netdev, linux, davem
In-Reply-To: <CAAsGZS6Tt9FLXfanH1+DgKt_9gR_YPJ8kX_pryhnzWTQVkNkNw@mail.gmail.com>
On Fri, Sep 02, 2011 at 10:00:16AM -0400, chetan loke wrote:
> >
> > This flushes the cache before and after accessing the mmapped packet
> > buffer. It seems like the call to flush_dcache_page from inside
> > __packet_get_status is not enough on Kirkwood (or ARM in general).
>
>
>
> > + kw_extra_cache_flush();
> > + rc = po->tx_ring.pg_vec ? tpacket_snd(po, msg) :
> > + packet_snd(sock, msg, len);
> > + kw_extra_cache_flush();
> > + return rc;
> > }
>
> If a workaround is needed for mmap, then why not change tpacket_snd?
I did not verify that packet_snd() is not affected. OTOH, adding it
there was quite "intuitive".
> Also, is this workaround actually working for all the cases? Because
> packet_get_status is not being touched in your patch.
>
> Also, I don't see any changes for the Rx-path. Is that working ok?
So far we haven't noticed problems in that direction. I just tried some
explicit test: having tcpdump print local timestamps (not the pcap-ones)
on every received packet, activating icmp_echo_ignore_all and pinging
the host on a dedicated line. I expected to sometimes see a second
difference between the two timestamps, as like with sending from time to
time a packet should get "lost" in the cache, and then occur to
userspace after the next one arrived. Maybe my test is broken, or RX is
indeed unaffected.
Greetings and thanks for the hints, Phil
--
Viprinet GmbH
Mainzer Str. 43
55411 Bingen am Rhein
Germany
Zentrale: +49-6721-49030-0
Durchwahl: +49-6721-49030-134
Fax: +49-6721-49030-209
phil.sutter@viprinet.com
http://www.viprinet.com
Sitz der Gesellschaft: Bingen am Rhein
Handelsregister: Amtsgericht Mainz HRB40380
Geschäftsführer: Simon Kissel
^ permalink raw reply
* Re: [patch -next] caif: add error handling for allocation
From: Dan Carpenter @ 2011-09-02 15:51 UTC (permalink / raw)
To: Sjur Brændeland
Cc: David S. Miller, open list:CAIF NETWORK LAYER, kernel-janitors
In-Reply-To: <CAJK669Yb6V=xr9ZvQGOKGEvmzO1JGhrHD+sR69b04EQxUjOOrQ@mail.gmail.com>
On Fri, Sep 02, 2011 at 11:40:23AM +0200, Sjur Brændeland wrote:
> Thank you for your patch.
> When reviewing this I found another potential memory leak as well.
> If cffrml_create fails, we might be leaking the phy_driver.
> So perhaps you could do kfree(phy_driver) in out_err: as well, while
> you are at it?
>
Good point. A kfree(phy_driver) would fix the leak. But why does
cfserl_create() return &this->layer; instead of just "return this;"
Their equivalent now, but if you change the cfserl struct it will
break the kfree().
I'll be travelling for a while, so I may be out of reach until
Wednessday.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] ixgbe: drop zero length frame segments during a packet split rx
From: Jeff Kirsher @ 2011-09-02 16:04 UTC (permalink / raw)
To: Neil Horman
Cc: netdev@vger.kernel.org, Thadeu Lima de Souza Cascardo,
Brandeburg, Jesse, Duyck, Alexander H, Fastabend, John R,
David S. Miller
In-Reply-To: <1314972197-31557-1-git-send-email-nhorman@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 4094 bytes --]
On Fri, 2011-09-02 at 07:03 -0700, Neil Horman wrote:
> This oops was reported recently no ppc64 hardware:
> Unable to handle kernel paging request for data at address 0x00000000
> Faulting instruction address: 0xc0000000004dda0c
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=1024 NUMA pSeries
> Modules linked in: sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4
> iptable_fi
> lter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state
> nf_conntrack ip6table_filter ip6_tables ipv6 jsm ses enclosure sg
> ixgbe
> mdio e1000 ehea ext4 jbd2 mbcache sd_mod crc_t10dif ipr dm_mod
> NIP: c0000000004dda0c LR: c0000000004e3e50 CTR: c0000000004e3e20
> REGS: c0000001bffeb8d0 TRAP: 0300 Not tainted
> (3.1.0-rc2-10121-gab7e2db)
> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 28002042 XER: 20000000
> CFAR: c000000000004d70
> DAR: 0000000000000000, DSISR: 40000000
> TASK = c000000000d548e0[0] 'swapper' THREAD: c000000000dfc000 CPU: 0
> GPR04: c0000000010f4d80 c0000001bffebd80 0000000000000000
> c0000001b18a8200
> GPR08: 0000000000000280 c0000001bcc517a8 c0000001b18a7f80
> 0000000000000000
> GPR12: d0000000047e5bb0 c000000001f10000 c0000001b19c8700
> 0000000000000000
> GPR16: c0000001bffebd80 0000000000000083 c00000018f2447a0
> 0000000000000002
> GPR20: 0000000000000000 c0000001ba860010 c0000001ba860000
> d000000003d40000
> GPR24: 0000000000000000 0000000000000083 d000000003d40000
> 0000000000000001
> GPR28: c00000018f244780 c0000001b2b94310 c000000000da95f0
> c0000001bcc51780
> NIP [c0000000004dda0c] .skb_gro_reset_offset+0x5c/0xe0
> LR [c0000000004e3e50] .napi_gro_receive+0x30/0x120
> Call Trace:
> [c0000001bffebb50] [c000000000da95f0] perf_callchain_user+0x0/0x10
> (unreliable)
> [c0000001bffebbf0] [d0000000047bd118] .ixgbe_clean_rx_irq+0x7a8/0x8a0
> [ixgbe]
> [c0000001bffebd10] [d0000000047bd414] .ixgbe_poll+0x64/0x160 [ixgbe]
> [c0000001bffebdd0] [c0000000004e3358] .net_rx_action+0x108/0x2a0
> [c0000001bffebea0] [c00000000009b220] .__do_softirq+0x110/0x2a0
> [c0000001bffebf90] [c000000000023798] .call_do_softirq+0x14/0x24
> [c000000000dff830] [c000000000011148] .do_softirq+0xf8/0x130
> [c000000000dff8d0] [c00000000009aeb4] .irq_exit+0xb4/0xc0
> [c000000000dff950] [c000000000011254] .do_IRQ+0xd4/0x300
> [c000000000dffa10] [c000000000005024] hardware_interrupt_entry
> +0x18/0x74
> --- Exception: 501 at .pseries_dedicated_idle_sleep+0xe4/0x210
> LR = .pseries_dedicated_idle_sleep+0x8c/0x210
> [c000000000dffd00] [c00000000005b194] .pseries_dedicated_idle_sleep
> +0x194/0x210
> (unreliable)
> [c000000000dffdc0] [c000000000018c84] .cpu_idle+0x164/0x210
> [c000000000dffe70] [c00000000000b0d0] .rest_init+0x90/0xb0
> [c000000000dffef0] [c000000000830bc0] .start_kernel+0x54c/0x56c
> [c000000000dfff90] [c00000000000953c] .start_here_common+0x1c/0x60
>
> Its caused when skb_gro_reset_offset attempts to call PageHighMem on
> skb_shinfo(skb)->frags[0].page, when the frags array was left
> uninitalized.
> This can happen in the ixgbe driver if the hardware reports a zero
> length rx
> descriptor ni the middle of a packet split receive transaction. I've
> consulted
> with Jesse Brandeburg on this, who is attempting to root cause the
> issue at
> Intel, but it seems prudent to add this check to the driver to discard
> frames of
> that encounter this error to avoid the opps
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> Signed-off-by: Thadeu Lima de Souza Cascardo
> <cascardo@linux.vnet.ibm.com>
> CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
> CC: Alexander Duyck <alexander.h.duyck@intel.com>
> CC: John Fastabend <john.r.fastabend@intel.com>
> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> CC: David S. Miller <davem@davemloft.net>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 17
> +++++++++++------
> 1 files changed, 11 insertions(+), 6 deletions(-)
Thanks Neil, I have added the patch to my queue of ixgbe patches.
This patch was made against net-next, was this issue only seen on the
net-next kernel?
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [next] unix stream crashes
From: Valdis.Kletnieks @ 2011-09-02 16:12 UTC (permalink / raw)
To: Tim Chen; +Cc: Jiri Slaby, David S. Miller, ML netdev, LKML
In-Reply-To: <1314927645.2576.2939.camel@schen9-DESK>
[-- Attachment #1.1: Type: text/plain, Size: 750 bytes --]
On Thu, 01 Sep 2011 18:40:45 PDT, Tim Chen said:
> Yes, Jiri's log does indicate that something went wrong when releasing
> the skb, most likely due to changes in the pid and credentials ref
> count. Unfortunately, I cannot duplicate the problem on my system. Any
> info on your system to help me debug will be appreciated. I'll try to
> take another look at the patch tomorrow.
Dell Latitude E6500, Core2 T8700 processor, x86_64 kernel, a slightly mangled
Fedora Rawhide userspace. I'd not be surprised if there's an idiocyncratic
setting in my .config that makes the bug crawl out of the woodwork on my box,
so I'm attaching the .config in case it provides some enlightenment.
If you want me to try a debugging or test patch, let me know...
[-- Attachment #1.2: config.gz --]
[-- Type: application/x-gzip , Size: 18974 bytes --]
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: [PATCH] ixgbe: drop zero length frame segments during a packet split rx
From: Alexander Duyck @ 2011-09-02 16:17 UTC (permalink / raw)
To: Neil Horman
Cc: netdev, Thadeu Lima de Souza Cascardo, Jesse Brandeburg,
John Fastabend, Jeff Kirsher, David S. Miller
In-Reply-To: <1314972197-31557-1-git-send-email-nhorman@tuxdriver.com>
This kind of fix just opens up a whole can of security related worms.
If you are going to discard a packet you should do it after we have
reached the EOP in the series. My advice would be to determine what
traits identify this packet and add those to the check for the
IXGBE_RXDADV_ERR_FRAME_ERR_MASK check further down in the code. Likely
what you are seeing is skb_headlen(skb) will be equal to 0.
I'm suspecting this is some sort of read corruption. It looks like in
order to trigger it you have to either be reading rx_buffer_info->dma as
0, or the header length is being read as 0. Do you know if you actually
have header split enabled when this is occuring? Are you running with
jumbo frames enabled to see the issue? If not then packet split
wouldn't be enabled.
Is this occurring on net-next or on an older kernel? I just want to be
sure since we added a read memory barrier in 2.6.34 to address the fact
that the length and descriptor DD bits were being read in the wrong
order resulting in the length being corrupted on PowerPC systems. The
fact that we are now seeing another length error on PowerPC seems very odd.
Thanks,
Alex
On 09/02/2011 07:03 AM, Neil Horman wrote:
> This oops was reported recently no ppc64 hardware:
> Unable to handle kernel paging request for data at address 0x00000000
> Faulting instruction address: 0xc0000000004dda0c
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=1024 NUMA pSeries
> Modules linked in: sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4
> iptable_fi
> lter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state
> nf_conntrack ip6table_filter ip6_tables ipv6 jsm ses enclosure sg ixgbe
> mdio e1000 ehea ext4 jbd2 mbcache sd_mod crc_t10dif ipr dm_mod
> NIP: c0000000004dda0c LR: c0000000004e3e50 CTR: c0000000004e3e20
> REGS: c0000001bffeb8d0 TRAP: 0300 Not tainted (3.1.0-rc2-10121-gab7e2db)
> MSR: 8000000000009032<EE,ME,IR,DR> CR: 28002042 XER: 20000000
> CFAR: c000000000004d70
> DAR: 0000000000000000, DSISR: 40000000
> TASK = c000000000d548e0[0] 'swapper' THREAD: c000000000dfc000 CPU: 0
> GPR04: c0000000010f4d80 c0000001bffebd80 0000000000000000 c0000001b18a8200
> GPR08: 0000000000000280 c0000001bcc517a8 c0000001b18a7f80 0000000000000000
> GPR12: d0000000047e5bb0 c000000001f10000 c0000001b19c8700 0000000000000000
> GPR16: c0000001bffebd80 0000000000000083 c00000018f2447a0 0000000000000002
> GPR20: 0000000000000000 c0000001ba860010 c0000001ba860000 d000000003d40000
> GPR24: 0000000000000000 0000000000000083 d000000003d40000 0000000000000001
> GPR28: c00000018f244780 c0000001b2b94310 c000000000da95f0 c0000001bcc51780
> NIP [c0000000004dda0c] .skb_gro_reset_offset+0x5c/0xe0
> LR [c0000000004e3e50] .napi_gro_receive+0x30/0x120
> Call Trace:
> [c0000001bffebb50] [c000000000da95f0] perf_callchain_user+0x0/0x10 (unreliable)
> [c0000001bffebbf0] [d0000000047bd118] .ixgbe_clean_rx_irq+0x7a8/0x8a0 [ixgbe]
> [c0000001bffebd10] [d0000000047bd414] .ixgbe_poll+0x64/0x160 [ixgbe]
> [c0000001bffebdd0] [c0000000004e3358] .net_rx_action+0x108/0x2a0
> [c0000001bffebea0] [c00000000009b220] .__do_softirq+0x110/0x2a0
> [c0000001bffebf90] [c000000000023798] .call_do_softirq+0x14/0x24
> [c000000000dff830] [c000000000011148] .do_softirq+0xf8/0x130
> [c000000000dff8d0] [c00000000009aeb4] .irq_exit+0xb4/0xc0
> [c000000000dff950] [c000000000011254] .do_IRQ+0xd4/0x300
> [c000000000dffa10] [c000000000005024] hardware_interrupt_entry+0x18/0x74
> --- Exception: 501 at .pseries_dedicated_idle_sleep+0xe4/0x210
> LR = .pseries_dedicated_idle_sleep+0x8c/0x210
> [c000000000dffd00] [c00000000005b194] .pseries_dedicated_idle_sleep+0x194/0x210
> (unreliable)
> [c000000000dffdc0] [c000000000018c84] .cpu_idle+0x164/0x210
> [c000000000dffe70] [c00000000000b0d0] .rest_init+0x90/0xb0
> [c000000000dffef0] [c000000000830bc0] .start_kernel+0x54c/0x56c
> [c000000000dfff90] [c00000000000953c] .start_here_common+0x1c/0x60
>
> Its caused when skb_gro_reset_offset attempts to call PageHighMem on
> skb_shinfo(skb)->frags[0].page, when the frags array was left uninitalized.
> This can happen in the ixgbe driver if the hardware reports a zero length rx
> descriptor ni the middle of a packet split receive transaction. I've consulted
> with Jesse Brandeburg on this, who is attempting to root cause the issue at
> Intel, but it seems prudent to add this check to the driver to discard frames of
> that encounter this error to avoid the opps
>
> Signed-off-by: Neil Horman<nhorman@tuxdriver.com>
> Signed-off-by: Thadeu Lima de Souza Cascardo<cascardo@linux.vnet.ibm.com>
> CC: Jesse Brandeburg<jesse.brandeburg@intel.com>
> CC: Alexander Duyck<alexander.h.duyck@intel.com>
> CC: John Fastabend<john.r.fastabend@intel.com>
> CC: Jeff Kirsher<jeffrey.t.kirsher@intel.com>
> CC: David S. Miller<davem@davemloft.net>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 17 +++++++++++------
> 1 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index d20e804..6d59185 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -1326,6 +1326,13 @@ static void ixgbe_clean_rx_irq(struct ixgbe_q_vector *q_vector,
>
> rx_buffer_info =&rx_ring->rx_buffer_info[i];
>
> + i++;
> + if (i == rx_ring->count)
> + i = 0;
> +
> + next_rxd = IXGBE_RX_DESC_ADV(rx_ring, i);
> + prefetch(next_rxd);
> +
> skb = rx_buffer_info->skb;
> rx_buffer_info->skb = NULL;
> prefetch(skb->data);
> @@ -1367,6 +1374,10 @@ static void ixgbe_clean_rx_irq(struct ixgbe_q_vector *q_vector,
> } else {
> /* assume packet split since header is unmapped */
> upper_len = le16_to_cpu(rx_desc->wb.upper.length);
> + if (!upper_len) {
> + rx_buffer_info->skb = skb;
> + goto next_desc;
> + }
> }
>
> if (upper_len) {
> @@ -1391,12 +1402,6 @@ static void ixgbe_clean_rx_irq(struct ixgbe_q_vector *q_vector,
> skb->truesize += upper_len;
> }
>
> - i++;
> - if (i == rx_ring->count)
> - i = 0;
> -
> - next_rxd = IXGBE_RX_DESC_ADV(rx_ring, i);
> - prefetch(next_rxd);
> cleaned_count++;
>
> if (pkt_is_rsc) {
^ permalink raw reply
* Re: [PATCH] ixgbe: drop zero length frame segments during a packet split rx
From: Neil Horman @ 2011-09-02 16:43 UTC (permalink / raw)
To: Jeff Kirsher
Cc: netdev@vger.kernel.org, Thadeu Lima de Souza Cascardo,
Brandeburg, Jesse, Duyck, Alexander H, Fastabend, John R,
David S. Miller
In-Reply-To: <1314979493.3532.4.camel@jtkirshe-linux>
On Fri, Sep 02, 2011 at 09:04:53AM -0700, Jeff Kirsher wrote:
> On Fri, 2011-09-02 at 07:03 -0700, Neil Horman wrote:
> > This oops was reported recently no ppc64 hardware:
> > Unable to handle kernel paging request for data at address 0x00000000
> > Faulting instruction address: 0xc0000000004dda0c
> > Oops: Kernel access of bad area, sig: 11 [#1]
> > SMP NR_CPUS=1024 NUMA pSeries
> > Modules linked in: sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4
> > iptable_fi
> > lter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state
> > nf_conntrack ip6table_filter ip6_tables ipv6 jsm ses enclosure sg
> > ixgbe
> > mdio e1000 ehea ext4 jbd2 mbcache sd_mod crc_t10dif ipr dm_mod
> > NIP: c0000000004dda0c LR: c0000000004e3e50 CTR: c0000000004e3e20
> > REGS: c0000001bffeb8d0 TRAP: 0300 Not tainted
> > (3.1.0-rc2-10121-gab7e2db)
> > MSR: 8000000000009032 <EE,ME,IR,DR> CR: 28002042 XER: 20000000
> > CFAR: c000000000004d70
> > DAR: 0000000000000000, DSISR: 40000000
> > TASK = c000000000d548e0[0] 'swapper' THREAD: c000000000dfc000 CPU: 0
> > GPR04: c0000000010f4d80 c0000001bffebd80 0000000000000000
> > c0000001b18a8200
> > GPR08: 0000000000000280 c0000001bcc517a8 c0000001b18a7f80
> > 0000000000000000
> > GPR12: d0000000047e5bb0 c000000001f10000 c0000001b19c8700
> > 0000000000000000
> > GPR16: c0000001bffebd80 0000000000000083 c00000018f2447a0
> > 0000000000000002
> > GPR20: 0000000000000000 c0000001ba860010 c0000001ba860000
> > d000000003d40000
> > GPR24: 0000000000000000 0000000000000083 d000000003d40000
> > 0000000000000001
> > GPR28: c00000018f244780 c0000001b2b94310 c000000000da95f0
> > c0000001bcc51780
> > NIP [c0000000004dda0c] .skb_gro_reset_offset+0x5c/0xe0
> > LR [c0000000004e3e50] .napi_gro_receive+0x30/0x120
> > Call Trace:
> > [c0000001bffebb50] [c000000000da95f0] perf_callchain_user+0x0/0x10
> > (unreliable)
> > [c0000001bffebbf0] [d0000000047bd118] .ixgbe_clean_rx_irq+0x7a8/0x8a0
> > [ixgbe]
> > [c0000001bffebd10] [d0000000047bd414] .ixgbe_poll+0x64/0x160 [ixgbe]
> > [c0000001bffebdd0] [c0000000004e3358] .net_rx_action+0x108/0x2a0
> > [c0000001bffebea0] [c00000000009b220] .__do_softirq+0x110/0x2a0
> > [c0000001bffebf90] [c000000000023798] .call_do_softirq+0x14/0x24
> > [c000000000dff830] [c000000000011148] .do_softirq+0xf8/0x130
> > [c000000000dff8d0] [c00000000009aeb4] .irq_exit+0xb4/0xc0
> > [c000000000dff950] [c000000000011254] .do_IRQ+0xd4/0x300
> > [c000000000dffa10] [c000000000005024] hardware_interrupt_entry
> > +0x18/0x74
> > --- Exception: 501 at .pseries_dedicated_idle_sleep+0xe4/0x210
> > LR = .pseries_dedicated_idle_sleep+0x8c/0x210
> > [c000000000dffd00] [c00000000005b194] .pseries_dedicated_idle_sleep
> > +0x194/0x210
> > (unreliable)
> > [c000000000dffdc0] [c000000000018c84] .cpu_idle+0x164/0x210
> > [c000000000dffe70] [c00000000000b0d0] .rest_init+0x90/0xb0
> > [c000000000dffef0] [c000000000830bc0] .start_kernel+0x54c/0x56c
> > [c000000000dfff90] [c00000000000953c] .start_here_common+0x1c/0x60
> >
> > Its caused when skb_gro_reset_offset attempts to call PageHighMem on
> > skb_shinfo(skb)->frags[0].page, when the frags array was left
> > uninitalized.
> > This can happen in the ixgbe driver if the hardware reports a zero
> > length rx
> > descriptor ni the middle of a packet split receive transaction. I've
> > consulted
> > with Jesse Brandeburg on this, who is attempting to root cause the
> > issue at
> > Intel, but it seems prudent to add this check to the driver to discard
> > frames of
> > that encounter this error to avoid the opps
> >
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> > Signed-off-by: Thadeu Lima de Souza Cascardo
> > <cascardo@linux.vnet.ibm.com>
> > CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
> > CC: Alexander Duyck <alexander.h.duyck@intel.com>
> > CC: John Fastabend <john.r.fastabend@intel.com>
> > CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > CC: David S. Miller <davem@davemloft.net>
> > ---
> > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 17
> > +++++++++++------
> > 1 files changed, 11 insertions(+), 6 deletions(-)
>
> Thanks Neil, I have added the patch to my queue of ixgbe patches.
>
> This patch was made against net-next, was this issue only seen on the
> net-next kernel?
You can see all the details here:
https://bugzilla.redhat.com/buglist.cgi?quicksearch=683611
My understanding was that it was seen in RHEL, net-next, and with the
sourceforge driver.
Regards
Neil
^ permalink raw reply
* Re: [PATCH net-next v4 4/4] r8169: support new chips of RTL8111F
From: Francois Romieu @ 2011-09-02 16:28 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-kernel
In-Reply-To: <1314956953-1568-4-git-send-email-hayeswang@realtek.com>
Hayes Wang <hayeswang@realtek.com> :
> Support new chips of RTL8111F.
Amongst other things :o)
> diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
> index 175c769..8e6a200 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
[...]
> @@ -711,7 +719,10 @@ MODULE_FIRMWARE(FIRMWARE_8168D_1);
> MODULE_FIRMWARE(FIRMWARE_8168D_2);
> MODULE_FIRMWARE(FIRMWARE_8168E_1);
> MODULE_FIRMWARE(FIRMWARE_8168E_2);
> +MODULE_FIRMWARE(FIRMWARE_8168E_3);
This one is relevant for Linus's tree.
Don't worry about submitting again, I'll send it separately.
No opinion regarding the jumbo fixes patches I sent on 2011/07/17 ?
--
Ueimor
^ permalink raw reply
* Re: FW: [PATCH] af_packet: flush complete kernel cache in packet_sendmsg
From: chetan loke @ 2011-09-02 16:49 UTC (permalink / raw)
To: Phil Sutter; +Cc: linux-arm-kernel, netdev, linux, davem
In-Reply-To: <20110902153147.GB29025@philter>
On Fri, Sep 2, 2011 at 11:31 AM, Phil Sutter <phil.sutter@viprinet.com> wrote:
> So far we haven't noticed problems in that direction. I just tried some
> explicit test: having tcpdump print local timestamps (not the pcap-ones)
> on every received packet, activating icmp_echo_ignore_all and pinging
> the host on a dedicated line. I expected to sometimes see a second
> difference between the two timestamps, as like with sending from time to
> time a packet should get "lost" in the cache, and then occur to
> userspace after the next one arrived. Maybe my test is broken, or RX is
> indeed unaffected.
>
You will need high traffic rate. If interested, you could try
pktgen(with varying packet-load). Keep the packet-payload under 1500
bytes (don't send jumbo frames) unless you have the following fix:
commit cc9f01b246ca8e4fa245991840b8076394f86707
Your Tx path is working because flush_cache_call gets triggered before
flush_dcache_page. On the Rx path, since you don't have that
workaround, you will eventually(it's just a matter of time) see this
problem.
Or, delete your patch and try this workaround (in
__packet_get/set_status) and you may be able to cover both Tx and Rx
paths.
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 2ea3d63..35d71dc 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -412,11 +412,19 @@ static void __packet_set_status(struct
packet_sock *po, void *frame, int status)
switch (po->tp_version) {
case TPACKET_V1:
h.h1->tp_status = status;
- flush_dcache_page(pgv_to_page(&h.h1->tp_status));
+ #ifndef ENABLE_CACHEPROB_WORKAROUND
+ flush_dcache_page(pgv_to_page(&h.h1->tp_status));
+ #else
+ kw_extra_cache_flush();
+ endif
break;
case TPACKET_V2:
h.h2->tp_status = status;
- flush_dcache_page(pgv_to_page(&h.h2->tp_status));
+ #ifndef ENABLE_CACHEPROB_WORKAROUND
+ flush_dcache_page(pgv_to_page(&h.h2->tp_status));
+ #else
+ kw_extra_cache_flush();
+ #endif
break;
case TPACKET_V3:
default:
@@ -437,13 +445,19 @@ static int __packet_get_status(struct
packet_sock *po, void *frame)
smp_rmb();
+ kw_extra_cache_flush();
+
h.raw = frame;
switch (po->tp_version) {
case TPACKET_V1:
- flush_dcache_page(pgv_to_page(&h.h1->tp_status));
+ #ifndef ENABLE_CACHEPROB_WORKAROUND
+ flush_dcache_page(pgv_to_page(&h.h1->tp_status));
+ #endif
return h.h1->tp_status;
case TPACKET_V2:
- flush_dcache_page(pgv_to_page(&h.h2->tp_status));
+ #ifndef ENABLE_CACHEPROB_WORKAROUND
+ flush_dcache_page(pgv_to_page(&h.h2->tp_status));
+ #endif
return h.h2->tp_status;
case TPACKET_V3:
default:
> Greetings and thanks for the hints, Phil
Chetan Loke
^ permalink raw reply related
* Re: [PATCH] ixgbe: drop zero length frame segments during a packet split rx
From: Neil Horman @ 2011-09-02 16:55 UTC (permalink / raw)
To: Alexander Duyck
Cc: netdev, Thadeu Lima de Souza Cascardo, Jesse Brandeburg,
John Fastabend, Jeff Kirsher, David S. Miller
In-Reply-To: <4E6101A4.4060802@intel.com>
On Fri, Sep 02, 2011 at 09:17:40AM -0700, Alexander Duyck wrote:
> This kind of fix just opens up a whole can of security related
> worms. If you are going to discard a packet you should do it after
> we have reached the EOP in the series. My advice would be to
> determine what traits identify this packet and add those to the
> check for the IXGBE_RXDADV_ERR_FRAME_ERR_MASK check further down in
> the code. Likely what you are seeing is skb_headlen(skb) will be
> equal to 0.
>
Well, the traits of the bogus descriptor are almost exactly as you describe
them, i.e. rx_buffer_info->dma is zero, which the driver takes to mean packet
split is enabled, and this is a buffer in the middle of that operation
(according to the comments in ixgbe_clean_rx_irq), and the upper_len value we
read from the rx_descriptior rx_dex->wb.upper.length is zero. This implies we
have a frame which is in the middle of a packet split receive, and one of the
page long buffers has a length value of zero, which is non-sensical. I suppose
we could wait until the next frame with EOP set to discard the whole thing, but
I'm not sure how that amounts to anything different than just skipping to the
next descriptor.
> I'm suspecting this is some sort of read corruption. It looks like
> in order to trigger it you have to either be reading
> rx_buffer_info->dma as 0, or the header length is being read as 0.
Correct, which drops us into the else clause of the if(rx_buffer_info->dma)
conditional in ixgbe_clean_rx_irq.
> Do you know if you actually have header split enabled when this is
> occuring? Are you running with jumbo frames enabled to see the
Yes, packet split is enabled. and no, Jumbo frames are not in use.
> issue? If not then packet split wouldn't be enabled.
>
> Is this occurring on net-next or on an older kernel? I just want to
> be sure since we added a read memory barrier in 2.6.34 to address
> the fact that the length and descriptor DD bits were being read in
> the wrong order resulting in the length being corrupted on PowerPC
> systems. The fact that we are now seeing another length error on
> PowerPC seems very odd.
>
According to the bz:
https://bugzilla.redhat.com/show_bug.cgi?id=683611
This appears to be happening on RHEL, and on upstream kernels, as well as the
sourceforge driver. Don't quote me on the SF driver though, because I never got
a clear answer on that. Although, fwiw, the RHEL version of the driver in which
we were definately seeing this problem has a read memory barrrier at the top of
the loop in ixgbe_clean_rx_irq, pulled in from commit
3c945e5b3719bcc18c6ddd31bbcae8ef94f3d19a, so I think thats handled.
Regards
Neil
^ permalink raw reply
* Re: [PATCH] af_packet: flush complete kernel cache in packet_sendmsg
From: Russell King - ARM Linux @ 2011-09-02 17:28 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, Phil Sutter, David S. Miller, linux-arm-kernel
In-Reply-To: <1314971179.3092.159.camel@deadeye>
On Fri, Sep 02, 2011 at 02:46:17PM +0100, Ben Hutchings wrote:
> On Fri, 2011-09-02 at 13:08 +0200, Phil Sutter wrote:
> > This flushes the cache before and after accessing the mmapped packet
> > buffer. It seems like the call to flush_dcache_page from inside
> > __packet_get_status is not enough on Kirkwood (or ARM in general).
> > ---
> > I know this is far from an optimal solution, but it's in fact the only working
> > one I found.
> [...]
>
> This is ridiculous. If flush_dcache_page() isn't doing everything it
> should, you need to fix that.
It does do everything it should - which is to perform maintanence on
page cache pages. It flushes the kernel mapping of the page. It
also flushes the userspace mappings of the page which it finds by
walking the mmap list via the associated struct page. It does not
touch vmalloc mappings because it has no way to know whether they
exist or not.
It doesn't do so much for anonymous pages - to do so would only
duplicate what flush_anon_page() does at the very same callsites.
Plus the mmap list isn't available for such pages so there's no
way to find out what userspace addresses to flush.
If the AF_PACKET buffers are created from anonymous pages and it's
using flush_dcache_page(), it's using the wrong interface.
^ permalink raw reply
* [PATCH 1/2] bridge: leave carrier on for empty bridge
From: Stephen Hemminger @ 2011-09-02 17:22 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20110902172220.830228928@vyatta.com>
[-- Attachment #1: br-carrier-default.patch --]
[-- Type: text/plain, Size: 955 bytes --]
This resolves a regression seen by some users of bridging.
Some users use the bridge like a dummy device.
They expect to be able to put an IPv6 address on the device
with no ports attached during boot.
Note: the bridge still will reflect the state of ports in the
bridge if there are any added.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
This fix needs to go to stable for 3.0 and 2.6.39
--- a/net/bridge/br_device.c 2011-09-01 08:52:27.596631192 -0700
+++ b/net/bridge/br_device.c 2011-09-01 09:01:03.256611801 -0700
@@ -91,7 +91,6 @@ static int br_dev_open(struct net_device
{
struct net_bridge *br = netdev_priv(dev);
- netif_carrier_off(dev);
netdev_update_features(dev);
netif_start_queue(dev);
br_stp_enable_bridge(br);
@@ -108,8 +107,6 @@ static int br_dev_stop(struct net_device
{
struct net_bridge *br = netdev_priv(dev);
- netif_carrier_off(dev);
-
br_stp_disable_bridge(br);
br_multicast_stop(br);
^ permalink raw reply
* [PATCH 2/2] bridge: set flags in RTM_NEWNEIGH message correctly
From: Stephen Hemminger @ 2011-09-02 17:22 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20110902172220.830228928@vyatta.com>
[-- Attachment #1: bridge-newneigh-state.patch --]
[-- Type: text/plain, Size: 1409 bytes --]
The functionality for notification was added with 3.0. kernel
but bridge would always send new neighbour message with state == 0.
The problem is that the notify needs to be done after
the flags on ther forwarding engry are set.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
--- a/net/bridge/br_fdb.c 2011-08-26 09:41:25.966304883 -0700
+++ b/net/bridge/br_fdb.c 2011-09-01 17:21:43.755481630 -0700
@@ -347,7 +347,6 @@ static struct net_bridge_fdb_entry *fdb_
fdb->is_static = 0;
fdb->updated = fdb->used = jiffies;
hlist_add_head_rcu(&fdb->hlist, head);
- fdb_notify(fdb, RTM_NEWNEIGH);
}
return fdb;
}
@@ -379,6 +378,7 @@ static int fdb_insert(struct net_bridge
return -ENOMEM;
fdb->is_local = fdb->is_static = 1;
+ fdb_notify(fdb, RTM_NEWNEIGH);
return 0;
}
@@ -424,8 +424,11 @@ void br_fdb_update(struct net_bridge *br
}
} else {
spin_lock(&br->hash_lock);
- if (likely(!fdb_find(head, addr)))
- fdb_create(head, source, addr);
+ if (!fdb_find(head, addr)) {
+ fdb = fdb_create(head, source, addr);
+ if (fdb)
+ fdb_notify(fdb, RTM_NEWNEIGH);
+ }
/* else we lose race and someone else inserts
* it first, don't bother updating
@@ -576,6 +579,8 @@ static int fdb_add_entry(struct net_brid
fdb->is_local = fdb->is_static = 1;
else if (state & NUD_NOARP)
fdb->is_static = 1;
+
+ fdb_notify(fdb, RTM_NEWNEIGH);
return 0;
}
^ permalink raw reply
* Re: [Bugme-new] [Bug 42132] New: Support BCM5750M in tg3
From: Matt Carlson @ 2011-09-02 17:43 UTC (permalink / raw)
To: Francesco Piccinno
Cc: Matthew Carlson, Andrew Morton, netdev@vger.kernel.org,
bugme-daemon@bugzilla.kernel.org, Benjamin Li, Michael Chan
In-Reply-To: <CAA7bCn5DJjrdZtyYN2g75Ty1=5s1Zcs5A4x0WksOM4oRLLaGOQ@mail.gmail.com>
The output shows that the device's firmware isn't running. Since the
firmware version also doesn't show up in the 'ethtool -i' output, it
might mean that firmware is completely missing.
You probably don't want to leave the device the way it is now. I'd
contact your vendor to see if you can get your firmware reprogrammed.
On Fri, Sep 02, 2011 at 02:20:10AM -0700, Francesco Piccinno wrote:
> The patch did not apply cleanly. BTW I have figured out an alternative
> method. I modified by hand pci_ids.h and tg3.c files. The device seems
> to work now.
>
> The output of ethtool -i eth0 gives me:
> driver: tg3
> version: 3.119
> firmware-version:
> bus-info: 0000:08:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: yes
>
> Messages produced by the driver:
>
> [ 728.741487] tg3 0000:08:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> [ 728.741498] tg3 0000:08:00.0: setting latency timer to 64
> [ 728.819963] tg3 0000:08:00.0: vpd r/w failed. This is likely a
> firmware bug on this device. Contact the card vendor for a firmware
> update.
> [ 728.879960] tg3 0000:08:00.0: vpd r/w failed. This is likely a
> firmware bug on this device. Contact the card vendor for a firmware
> update.
> [ 728.939957] tg3 0000:08:00.0: vpd r/w failed. This is likely a
> firmware bug on this device. Contact the card vendor for a firmware
> update.
> [ 728.942680] tg3 0000:08:00.0: eth0: Tigon3 [partno(none) rev 4201]
> (PCI Express) MAC address 00:1b:38:38:c6:60
> [ 728.942685] tg3 0000:08:00.0: eth0: attached PHY is 5750
> (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
> [ 728.942689] tg3 0000:08:00.0: eth0: RXcsums[1] LinkChgREG[0]
> MIirq[0] ASF[0] TSOcap[1]
> [ 728.942692] tg3 0000:08:00.0: eth0: dma_rwctrl[76180000] dma_mask[64-bit]
> [ 728.949503] tg3 0000:08:00.0: irq 45 for MSI/MSI-X
> [ 730.633610] tg3 0000:08:00.0: eth0: No firmware running
> [ 730.650658] ADDRCONF(NETDEV_UP): eth0: link is not ready
> [ 811.811298] tg3 0000:08:00.0: eth0: Link is up at 100 Mbps, full duplex
> [ 811.811306] tg3 0000:08:00.0: eth0: Flow control is on for TX and on for RX
>
> --
> Best regards,
> Francesco Piccinno
>
>
>
> On Fri, Sep 2, 2011 at 3:25 AM, Matt Carlson <mcarlson@broadcom.com> wrote:
> > Yes. ??Sorry. ??Please revert that patch. ??If you really had a bcm5750,
> > you'd need to revert another patch too, but let's see where we stand
> > before going down that road.
> >
> > On Thu, Sep 01, 2011 at 06:14:57PM -0700, Francesco Piccinno wrote:
> >> The only message I get regarding the firmware is the following:
> >>
> >> [51503.038205] pci 0000:08:00.0: vpd r/w failed. ??This is likely a
> >> firmware bug on this device. ??Contact the card vendor for a firmware
> >> update.
> >>
> >> Unfortunately I can not post the output of ethtool since the interface
> >> is not available. Shall I recompile the tg3 module with the proper
> >> patch and post the output?
> >>
> >> --
> >> Best regards,
> >> Francesco Piccinno
> >>
> >> On Fri, Sep 2, 2011 at 3:04 AM, Matt Carlson <mcarlson@broadcom.com> wrote:
> >> > It's showing up on lspci as a PCIe device, so it can't be the 5750M.
> >> > The bcm5750M is a pci device.
> >> >
> >> > I'm wondering if bootcode is failing. ??Do you see any messages in your
> >> > syslogs that say "No firmware running"?
> >> >
> >> > Can you post the output of 'ethtool -i ethX'?
> >> >
> >> > On Thu, Sep 01, 2011 at 05:48:50PM -0700, Francesco Piccinno wrote:
> >> >> Yes sure.
> >> >>
> >> >> # lspci -vvv -s 08:00.0
> >> >> 08:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5750M
> >> >> Gigabit Ethernet
> >> >> ?? ?? ?? Subsystem: Broadcom Corporation NetXtreme BCM5750M Gigabit Ethernet
> >> >> ?? ?? ?? Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> >> >> Stepping- SERR- FastB2B- DisINTx-
> >> >> ?? ?? ?? Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> >> >> <TAbort- <MAbort- >SERR- <PERR- INTx-
> >> >> ?? ?? ?? Latency: 0, Cache Line Size: 64 bytes
> >> >> ?? ?? ?? Interrupt: pin A routed to IRQ 10
> >> >> ?? ?? ?? Region 0: Memory at f4100000 (64-bit, non-prefetchable) [size=64K]
> >> >> ?? ?? ?? Capabilities: [48] Power Management version 2
> >> >> ?? ?? ?? ?? ?? ?? ?? Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
> >> >> ?? ?? ?? ?? ?? ?? ?? Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
> >> >> ?? ?? ?? Capabilities: [50] Vital Product Data
> >> >> pcilib: sysfs_read_vpd: read failed: Connection timed out
> >> >> ?? ?? ?? ?? ?? ?? ?? Not readable
> >> >> ?? ?? ?? Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
> >> >> ?? ?? ?? ?? ?? ?? ?? Address: 5149526521410124 ??Data: 8b60
> >> >> ?? ?? ?? Capabilities: [d0] Express (v1) Endpoint, MSI 00
> >> >> ?? ?? ?? ?? ?? ?? ?? DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
> >> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset-
> >> >> ?? ?? ?? ?? ?? ?? ?? DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
> >> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
> >> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? MaxPayload 128 bytes, MaxReadReq 512 bytes
> >> >> ?? ?? ?? ?? ?? ?? ?? DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
> >> >> ?? ?? ?? ?? ?? ?? ?? LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 <4us, L1 <64us
> >> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ClockPM- Surprise- LLActRep- BwNot-
> >> >> ?? ?? ?? ?? ?? ?? ?? LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
> >> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> >> >> ?? ?? ?? ?? ?? ?? ?? LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive-
> >> >> BWMgmt- ABWMgmt-
> >> >> ?? ?? ?? Capabilities: [100 v1] Advanced Error Reporting
> >> >> ?? ?? ?? ?? ?? ?? ?? UESta: ??DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
> >> >> MalfTLP- ECRC- UnsupReq- ACSViol-
> >> >> ?? ?? ?? ?? ?? ?? ?? UEMsk: ??DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
> >> >> MalfTLP- ECRC- UnsupReq- ACSViol-
> >> >> ?? ?? ?? ?? ?? ?? ?? UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
> >> >> MalfTLP+ ECRC- UnsupReq- ACSViol-
> >> >> ?? ?? ?? ?? ?? ?? ?? CESta: ??RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
> >> >> ?? ?? ?? ?? ?? ?? ?? CEMsk: ??RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
> >> >> ?? ?? ?? ?? ?? ?? ?? AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
> >> >> ?? ?? ?? Capabilities: [13c v1] Virtual Channel
> >> >> ?? ?? ?? ?? ?? ?? ?? Caps: ?? LPEVC=0 RefClk=100ns PATEntryBits=1
> >> >> ?? ?? ?? ?? ?? ?? ?? Arb: ?? ??Fixed- WRR32- WRR64- WRR128-
> >> >> ?? ?? ?? ?? ?? ?? ?? Ctrl: ?? ArbSelect=Fixed
> >> >> ?? ?? ?? ?? ?? ?? ?? Status: InProgress-
> >> >> ?? ?? ?? ?? ?? ?? ?? VC0: ?? ??Caps: ?? PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
> >> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? Arb: ?? ??Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
> >> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? Ctrl: ?? Enable+ ID=0 ArbSelect=Fixed TC/VC=01
> >> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? Status: NegoPending- InProgress-
> >> >> ?? ?? ?? Capabilities: [160 v1] Device Serial Number 00-00-00-ff-fe-00-00-00
> >> >>
> >> >> Serial number is CND71700K6.
> >> >> --
> >> >> Best regards,
> >> >> Francesco Piccinno
> >> >>
> >> >>
> >> >>
> >> >> On Fri, Sep 2, 2011 at 2:06 AM, Matt Carlson <mcarlson@broadcom.com> wrote:
> >> >> > On Thu, Sep 01, 2011 at 04:40:11PM -0700, Andrew Morton wrote:
> >> >> >>
> >> >> >> (switched to email. ??Please respond via emailed reply-to-all, not via the
> >> >> >> bugzilla web interface).
> >> >> >>
> >> >> >> On Wed, 31 Aug 2011 18:18:40 GMT
> >> >> >> bugzilla-daemon@bugzilla.kernel.org wrote:
> >> >> >>
> >> >> >> > https://bugzilla.kernel.org/show_bug.cgi?id=42132
> >> >> >> >
> >> >> >> > ?? ?? ?? ?? ?? ??Summary: Support BCM5750M in tg3
> >> >> >> > ?? ?? ?? ?? ?? ??Product: Drivers
> >> >> >> > ?? ?? ?? ?? ?? ??Version: 2.5
> >> >> >> > ?? ?? Kernel Version: 3.0.3
> >> >> >> > ?? ?? ?? ?? ?? Platform: All
> >> >> >> > ?? ?? ?? ?? OS/Version: Linux
> >> >> >> > ?? ?? ?? ?? ?? ?? ?? Tree: Mainline
> >> >> >> > ?? ?? ?? ?? ?? ?? Status: NEW
> >> >> >> > ?? ?? ?? ?? ?? Severity: normal
> >> >> >> > ?? ?? ?? ?? ?? Priority: P1
> >> >> >> > ?? ?? ?? ?? ??Component: Network
> >> >> >> > ?? ?? ?? ?? AssignedTo: drivers_network@kernel-bugs.osdl.org
> >> >> >> > ?? ?? ?? ?? ReportedBy: stack.box@gmail.com
> >> >> >> > ?? ?? ?? ?? Regression: Yes
> >> >> >> >
> >> >> >> >
> >> >> >> > I have a notebook (HP TC4400) which has a BCM5750 ethernet card inside. The
> >> >> >> > ouput of lspci is:
> >> >> >> >
> >> >> >> > 08:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5750M
> >> >> >> > Gigabit Ethernet [14e4:167c]
> >> >> >> >
> >> >> >> > Commit 67b284d476bcb3d100e946da23d6cf9acfd0465c removed the support for this
> >> >> >> > device.
> >> >> >> >
> >> >> >>
> >> >> >> 67b284d476bcb3d100 says "These devices were never released to the public".
> >> >> >>
> >> >> >> > I wish to have the support for this network card back again. Thanks!
> >> >> >>
> >> >> >> oops ;)
> >> >> >
> >> >> > Really? ??All the TC4400 documentation I find says it uses a bcm5753M on a
> >> >> > PCIe bus. ??Can you post the full output of 'lspci -vvv -s 08:00.0' ?
> >> >> >
> >> >> >
> >> >>
> >> >
> >> >
> >>
> >
> >
>
^ permalink raw reply
* Re: [PATCH] ixgbe: drop zero length frame segments during a packet split rx
From: Alexander Duyck @ 2011-09-02 17:54 UTC (permalink / raw)
To: Neil Horman
Cc: netdev, Thadeu Lima de Souza Cascardo, Jesse Brandeburg,
John Fastabend, Jeff Kirsher, David S. Miller
In-Reply-To: <20110902165523.GB27571@hmsreliant.think-freely.org>
On 09/02/2011 09:55 AM, Neil Horman wrote:
> On Fri, Sep 02, 2011 at 09:17:40AM -0700, Alexander Duyck wrote:
>> This kind of fix just opens up a whole can of security related
>> worms. If you are going to discard a packet you should do it after
>> we have reached the EOP in the series. My advice would be to
>> determine what traits identify this packet and add those to the
>> check for the IXGBE_RXDADV_ERR_FRAME_ERR_MASK check further down in
>> the code. Likely what you are seeing is skb_headlen(skb) will be
>> equal to 0.
>>
> Well, the traits of the bogus descriptor are almost exactly as you describe
> them, i.e. rx_buffer_info->dma is zero, which the driver takes to mean packet
> split is enabled, and this is a buffer in the middle of that operation
> (according to the comments in ixgbe_clean_rx_irq), and the upper_len value we
> read from the rx_descriptior rx_dex->wb.upper.length is zero. This implies we
> have a frame which is in the middle of a packet split receive, and one of the
> page long buffers has a length value of zero, which is non-sensical. I suppose
> we could wait until the next frame with EOP set to discard the whole thing, but
> I'm not sure how that amounts to anything different than just skipping to the
> next descriptor.
>
>> I'm suspecting this is some sort of read corruption. It looks like
>> in order to trigger it you have to either be reading
>> rx_buffer_info->dma as 0, or the header length is being read as 0.
> Correct, which drops us into the else clause of the if(rx_buffer_info->dma)
> conditional in ixgbe_clean_rx_irq.
>
>> Do you know if you actually have header split enabled when this is
>> occuring? Are you running with jumbo frames enabled to see the
> Yes, packet split is enabled. and no, Jumbo frames are not in use.
>
>> issue? If not then packet split wouldn't be enabled.
>>
>> Is this occurring on net-next or on an older kernel? I just want to
>> be sure since we added a read memory barrier in 2.6.34 to address
>> the fact that the length and descriptor DD bits were being read in
>> the wrong order resulting in the length being corrupted on PowerPC
>> systems. The fact that we are now seeing another length error on
>> PowerPC seems very odd.
>>
> According to the bz:
> https://bugzilla.redhat.com/show_bug.cgi?id=683611
> This appears to be happening on RHEL, and on upstream kernels, as well as the
> sourceforge driver. Don't quote me on the SF driver though, because I never got
> a clear answer on that. Although, fwiw, the RHEL version of the driver in which
> we were definately seeing this problem has a read memory barrrier at the top of
> the loop in ixgbe_clean_rx_irq, pulled in from commit
> 3c945e5b3719bcc18c6ddd31bbcae8ef94f3d19a, so I think thats handled.
>
>
> Regards
> Neil
I'll review the bugzilla and submit my comments there.
Thanks,
Alex
^ permalink raw reply
* WEBMASTER SERVICE
From: WEBMASTER SERVICE @ 2011-09-02 17:47 UTC (permalink / raw)
To: ofat1
CONFIRM YOUR EMAIL ACCOUNT
We are upgrading our data base and center of e-mail View page Initial
accounts as well. We will delete e-mail accounts that are no longer of
working age to create more space for other users. We have also innovated
new accounts a security audit of all system to improve and strengthen our
current security.
To continue using our services, you need to update and re-confirm your
account information clicking on this link to complete your email account
http://buzurl.com/bf16 confirmation of new account, you must fill out the
account information and then submit immediately your account will be
confirmed.
We have confirm others without security, yours has to be done for your
email account to remain valid.
WEBMASTER SERVICE.
^ permalink raw reply
* Re: [patch net-next-2.6 v2] net: consolidate and fix ethtool_ops->get_settings calling
From: Ben Hutchings @ 2011-09-02 18:46 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, ralf, fubar, andy, kaber, bprakash, JBottomley,
robert.w.love, davem, shemminger, decot, mirq-linux,
alexander.h.duyck, amit.salecha, eric.dumazet, therbert, paulmck,
laijs, xiaosuo, greearb, loke.chetan, linux-mips, linux-scsi,
devel, bridge
In-Reply-To: <20110902122630.GC1991@minipsycho>
On Fri, 2011-09-02 at 14:26 +0200, Jiri Pirko wrote:
> This patch does several things:
> - introduces __ethtool_get_settings which is called from ethtool code and
> from dev_ethtool_get_settings() as well.
> - dev_ethtool_get_settings() becomes rtnl wrapper for
> __ethtool_get_settings()
[...]
I don't like this locking change. Most other dev_*() functions require
the caller to hold RTNL, and it will break any OOT module calling
dev_ethtool_get_settings() without producing any warning at compile
time. Why not put an ASSERT_RTNL() in it instead?
The rest of this looks fine.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
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