* Re: [RFC PATCH] bridge: netfilter: fix skb->nf_bridge NULL panic in br_nf_forward_finish
From: Massimo Cetra @ 2012-07-09 9:26 UTC (permalink / raw)
To: Lin Ming
Cc: Massimo Cetra, Eric Dumazet, netdev, Stephen Hemminger,
David S. Miller, Julian Anastasov
In-Reply-To: <1341584394.4789.34.camel@chief-river-32>
On 06/07/2012 16:19, Lin Ming wrote:
> I can reproduce similiar panic with 3.5-rc5 kernel as Massimo reported at:
> http://marc.info/?l=linux-netdev&m=134089242113979&w=2
>
> The steps to reproduce as follow,
>
> 1. On Host1, setup brige br0(192.168.1.106)
> 2. Boot a kvm guest(192.168.1.105) on Host1 and start httpd
> 3. Start IPVS service on Host1
> ipvsadm -A -t 192.168.1.106:80 -s rr
> ipvsadm -a -t 192.168.1.106:80 -r 192.168.1.105:80 -m
> 4. Run apache benchmark on Host2(192.168.1.101)
> ab -n 1000 http://192.168.1.106/
Thank you Lin,
i spent a couple of days trying to figure out how to reproduce but you
were quicker and smarter than me.
Massimo
^ permalink raw reply
* Re: 82571EB: Detected Hardware Unit Hang
From: Eric Dumazet @ 2012-07-09 9:21 UTC (permalink / raw)
To: Joe Jin; +Cc: e1000-devel, netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <4FFA9B96.6040901@oracle.com>
On Mon, 2012-07-09 at 16:51 +0800, Joe Jin wrote:
> Hi list,
>
> I'm seeing a Unit Hang even with the latest e1000e driver 2.0.0 when doing
> scp test. this issue is easy do reproduced on SUN FIRE X2270 M2, just copy
> a big file (>500M) from another server will hit it at once.
>
> Would you please help on this?
>
Its a known problem.
But apparently Intel guys are not very responsive, as they have another
patch than the following :
http://permalink.gmane.org/gmane.linux.network/232669
We only have to wait they push their alternative patch, eventually.
In the mean time, you can use Hiroaki SHIMODA patch, it works.
^ permalink raw reply
* Re: [PATCH 1/2] netfilter: ipset: timeout fixing bug broke SET target special timeout value
From: Pablo Neira Ayuso @ 2012-07-09 8:58 UTC (permalink / raw)
To: David Miller; +Cc: netfilter-devel, netdev
In-Reply-To: <20120709.002903.592402805831614695.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 530 bytes --]
On Mon, Jul 09, 2012 at 12:29:03AM -0700, David Miller wrote:
> From: pablo@netfilter.org
> Date: Fri, 6 Jul 2012 13:39:38 +0200
>
> > + if (add_opt.timeout != IPSET_NO_TIMEOUT
> > + && add_opt.timeout > UINT_MAX/MSEC_PER_SEC)
>
> We do not write conditionals like this, with operators beginning
> a continued line. Instead, write this as:
>
> if (a &&
> b)
Oops, indeed, sorry. New patch attached.
I've also rebased my tree to include this change. Should I send a new
pull request?
Let me know what you prefer.
[-- Attachment #2: 0001-netfilter-ipset-timeout-fixing-bug-broke-SET-target-.patch --]
[-- Type: text/x-diff, Size: 1501 bytes --]
>From a73f89a61f92b364f0b4a3be412b5b70553afc23 Mon Sep 17 00:00:00 2001
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Date: Fri, 29 Jun 2012 09:42:28 +0000
Subject: [PATCH] netfilter: ipset: timeout fixing bug broke SET target
special timeout value
The patch "127f559 netfilter: ipset: fix timeout value overflow bug"
broke the SET target when no timeout was specified.
Reported-by: Jean-Philippe Menil <jean-philippe.menil@univ-nantes.fr>
Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/xt_set.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/netfilter/xt_set.c b/net/netfilter/xt_set.c
index 035960e..c6f7db7 100644
--- a/net/netfilter/xt_set.c
+++ b/net/netfilter/xt_set.c
@@ -16,6 +16,7 @@
#include <linux/netfilter/x_tables.h>
#include <linux/netfilter/xt_set.h>
+#include <linux/netfilter/ipset/ip_set_timeout.h>
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>");
@@ -310,7 +311,8 @@ set_target_v2(struct sk_buff *skb, const struct xt_action_param *par)
info->del_set.flags, 0, UINT_MAX);
/* Normalize to fit into jiffies */
- if (add_opt.timeout > UINT_MAX/MSEC_PER_SEC)
+ if (add_opt.timeout != IPSET_NO_TIMEOUT &&
+ add_opt.timeout > UINT_MAX/MSEC_PER_SEC)
add_opt.timeout = UINT_MAX/MSEC_PER_SEC;
if (info->add_set.index != IPSET_INVALID_ID)
ip_set_add(info->add_set.index, skb, par, &add_opt);
--
1.7.10
^ permalink raw reply related
* 82571EB: Detected Hardware Unit Hang
From: Joe Jin @ 2012-07-09 8:51 UTC (permalink / raw)
To: e1000-devel; +Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Hi list,
I'm seeing a Unit Hang even with the latest e1000e driver 2.0.0 when doing
scp test. this issue is easy do reproduced on SUN FIRE X2270 M2, just copy
a big file (>500M) from another server will hit it at once.
Would you please help on this?
device info:
# lspci -s 05:00.0
05:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06)
# lspci -s 05:00.0 -n
05:00.0 0200: 8086:10bc (rev 06)
# ethtool -i eth0
driver: e1000e
version: 2.0.0-NAPI
firmware-version: 5.10-2
bus-info: 0000:05:00.0
# ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
udp fragmentation offload: off
generic segmentation offload: on
generic-receive-offload: on
kernel log:
-----------
e1000e 0000:05:00.0: eth0: Detected Hardware Unit Hang:
TDH <6c>
TDT <81>
next_to_use <81>
next_to_clean <6b>
buffer_info[next_to_clean]:
time_stamp <fffc7a23>
next_to_watch <71>
jiffies <fffc8c0c>
next_to_watch.status <0>
MAC Status <80387>
PHY Status <792d>
PHY 1000BASE-T Status <3c00>
PHY Extended Status <3000>
PCI Status <10>
e1000e 0000:05:00.0: eth0: Detected Hardware Unit Hang:
TDH <6c>
TDT <81>
next_to_use <81>
next_to_clean <6b>
buffer_info[next_to_clean]:
time_stamp <fffc7a23>
next_to_watch <71>
jiffies <fffc9bac>
next_to_watch.status <0>
MAC Status <80387>
PHY Status <792d>
PHY 1000BASE-T Status <3c00>
PHY Extended Status <3000>
PCI Status <10>
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x225/0x230()
Hardware name: SUN FIRE X2270 M2
NETDEV WATCHDOG: eth0 (e1000e): transmit queue 0 timed out
Modules linked in: autofs4 hidp rfcomm bluetooth rfkill lockd sunrpc cpufreq_ondemand acpi_cpufreq mperf be2iscsi iscsi_boot_sysfs ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp bnx2i cnic uio ipv6 cxgb3i libcxgbi cxgb3 mdio libiscsi_tcp libiscsi scsi_transport_iscsi video sbs sbshc acpi_pad acpi_ipmi ipmi_msghandler parport_pc lp parport e1000e(U) snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device igb snd_pcm_oss serio_raw snd_mixer_oss snd_pcm tpm_infineon snd_timer snd soundcore snd_page_alloc i2c_i801 iTCO_wdt i2c_core pcspkr i7core_edac iTCO_vendor_support ioatdma ghes dca edac_core hed dm_snapshot dm_zero dm_mirror dm_region_hash dm_log dm_mod usb_storage sd_mod crc_t10dif sg ahci libahci ext3 jbd mbcache [last unloaded: microcode]
Pid: 0, comm: swapper Not tainted 2.6.39-200.24.1.el5uek #1
Call Trace:
[<c07d9ac5>] ? dev_watchdog+0x225/0x230
[<c045ba61>] warn_slowpath_common+0x81/0xa0
[<c07d9ac5>] ? dev_watchdog+0x225/0x230
[<c045bb23>] warn_slowpath_fmt+0x33/0x40
[<c07d9ac5>] dev_watchdog+0x225/0x230
[<c07d98a0>] ? dev_activate+0xb0/0xb0
[<c0468e82>] call_timer_fn+0x32/0xf0
[<c04bceb0>] ? rcu_check_callbacks+0x80/0x80
[<c046a76d>] run_timer_softirq+0xed/0x1b0
[<c07d98a0>] ? dev_activate+0xb0/0xb0
[<c0461a81>] __do_softirq+0x91/0x1a0
[<c04619f0>] ? local_bh_enable+0x80/0x80
<IRQ> [<c0462295>] ? irq_exit+0x95/0xa0
[<c087f8b8>] ? smp_apic_timer_interrupt+0x38/0x42
[<c08784f5>] ? apic_timer_interrupt+0x31/0x38
[<c046007b>] ? do_exit+0x11b/0x370
[<c065eae4>] ? intel_idle+0xa4/0x100
[<c078d9b9>] ? cpuidle_idle_call+0xb9/0x1e0
[<c0411d77>] ? cpu_idle+0x97/0xd0
[<c085cbbd>] ? rest_init+0x5d/0x70
[<c0b07a7a>] ? start_kernel+0x28a/0x340
[<c0b074b0>] ? obsolete_checksetup+0xb0/0xb0
[<c0b070a4>] ? i386_start_kernel+0x64/0xb0
---[ end trace 5502b55cd4d4e5cb ]---
e1000e 0000:05:00.0: eth0: Reset adapter
e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Thanks,
Joe
^ permalink raw reply
* Re: [RFC PATCH] tcp: limit data skbs in qdisc layer
From: Eric Dumazet @ 2012-07-09 8:48 UTC (permalink / raw)
To: David Miller; +Cc: nanditad, netdev, ycheng, codel, mattmathis, ncardwell
In-Reply-To: <1341821036.3265.2161.camel@edumazet-glaptop>
On Mon, 2012-07-09 at 10:04 +0200, Eric Dumazet wrote:
> Only that ixgbe is not yet BQL enabled so I could not add
> skb_try_orphan() in its start_xmit() : So if TX completion is a bit
> delayed, we can have a throughput slowdown.
Oops, ixgbe already is BQL enabled, so I can add the skb_try_orphan()
^ permalink raw reply
* [PATCH v6 4/7] net, ethernet, davinci_emac: add OF support
From: Heiko Schocher @ 2012-07-09 8:44 UTC (permalink / raw)
To: davinci-linux-open-source
Cc: Heiko Schocher, linux-arm-kernel, devicetree-discuss, netdev,
Grant Likely, Sekhar Nori, Wolfgang Denk, Anatoly Sivov,
David Miller
add of support for the davinci_emac driver.
Signed-off-by: Heiko Schocher <hs@denx.de>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Cc: davinci-linux-open-source@linux.davincidsp.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: netdev@vger.kernel.org
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Anatoly Sivov <mm05@mail.ru>
Cc: David Miller <davem@davemloft.net>
---
- changes for v2:
- add comment from Anatoly Sivov
- fix typo in davinci_emac.txt
- add comment from Grant Likely:
- add prefix "ti,davinci-" to davinci specific property names
- remove version property
- use compatible name "ti,davinci-dm6460-emac"
- use devm_kzalloc()
- use of_match_ptr()
- document all new properties
- remove of_address_to_resource() and do not overwrite
resource table
- whitespace fixes
- remove hw_ram_addr as it is not used in current
board code
- no changes for v3
- changes for v4:
add comments from Nori Sekhar:
- move devictree documentation to:
Documentation/devicetree/bindings/net/davinci_emac.txt
- fix typo in it
- rename compatible property to "ti,davinci-dm6467-emac"
- remove pinmux-handle
- set version directly in pdata->version
- no changes for v5
- changes for v6:
add comment from Nori, Sekhar:
- use mac address in DT data only if no valid address is passed
through platform data
- added Acked-by from Sekhar Nori
- changes Subject line from "ARM: davinci: net:" to
"net, ethernet, davinci_emac:"
- add David Miller to Cc
.../devicetree/bindings/net/davinci_emac.txt | 41 +++++++++
drivers/net/ethernet/ti/davinci_emac.c | 89 +++++++++++++++++++-
2 files changed, 129 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/davinci_emac.txt
diff --git a/Documentation/devicetree/bindings/net/davinci_emac.txt b/Documentation/devicetree/bindings/net/davinci_emac.txt
new file mode 100644
index 0000000..48b259e
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/davinci_emac.txt
@@ -0,0 +1,41 @@
+* Texas Instruments Davinci EMAC
+
+This file provides information, what the device node
+for the davinci_emac interface contains.
+
+Required properties:
+- compatible: "ti,davinci-dm6467-emac";
+- reg: Offset and length of the register set for the device
+- ti,davinci-ctrl-reg-offset: offset to control register
+- ti,davinci-ctrl-mod-reg-offset: offset to control module register
+- ti,davinci-ctrl-ram-offset: offset to control module ram
+- ti,davinci-ctrl-ram-size: size of control module ram
+- ti,davinci-rmii-en: use RMII
+- ti,davinci-no-bd-ram: has the emac controller BD RAM
+- phy-handle: Contains a phandle to an Ethernet PHY.
+ if not, davinci_emac driver defaults to 100/FULL
+- interrupts: interrupt mapping for the davinci emac interrupts sources:
+ 4 sources: <Receive Threshold Interrupt
+ Receive Interrupt
+ Transmit Interrupt
+ Miscellaneous Interrupt>
+
+Optional properties:
+- local-mac-address : 6 bytes, mac address
+
+Example (enbw_cmc board):
+ eth0: emac@1e20000 {
+ compatible = "ti,davinci-dm6467-emac";
+ reg = <0x220000 0x4000>;
+ ti,davinci-ctrl-reg-offset = <0x3000>;
+ ti,davinci-ctrl-mod-reg-offset = <0x2000>;
+ ti,davinci-ctrl-ram-offset = <0>;
+ ti,davinci-ctrl-ram-size = <0x2000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <33
+ 34
+ 35
+ 36
+ >;
+ interrupt-parent = <&intc>;
+ };
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index 4da93a5..6b4b0fe 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -58,6 +58,12 @@
#include <linux/io.h>
#include <linux/uaccess.h>
#include <linux/davinci_emac.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_net.h>
+
+#include <mach/mux.h>
#include <asm/irq.h>
#include <asm/page.h>
@@ -339,6 +345,9 @@ struct emac_priv {
u32 rx_addr_type;
atomic_t cur_tx;
const char *phy_id;
+#ifdef CONFIG_OF
+ struct device_node *phy_node;
+#endif
struct phy_device *phydev;
spinlock_t lock;
/*platform specific members*/
@@ -1762,6 +1771,77 @@ static const struct net_device_ops emac_netdev_ops = {
#endif
};
+#ifdef CONFIG_OF
+static struct emac_platform_data
+ *davinci_emac_of_get_pdata(struct platform_device *pdev,
+ struct emac_priv *priv)
+{
+ struct device_node *np;
+ struct emac_platform_data *pdata = NULL;
+ const u8 *mac_addr;
+ u32 data;
+ int ret;
+
+ pdata = pdev->dev.platform_data;
+ if (!pdata) {
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ goto nodata;
+ }
+
+ np = pdev->dev.of_node;
+ if (!np)
+ goto nodata;
+ else
+ pdata->version = EMAC_VERSION_2;
+
+ if (!is_valid_ether_addr(pdata->mac_addr)) {
+ mac_addr = of_get_mac_address(np);
+ if (mac_addr)
+ memcpy(pdata->mac_addr, mac_addr, ETH_ALEN);
+ }
+
+ ret = of_property_read_u32(np, "ti,davinci-ctrl-reg-offset", &data);
+ if (!ret)
+ pdata->ctrl_reg_offset = data;
+
+ ret = of_property_read_u32(np, "ti,davinci-ctrl-mod-reg-offset",
+ &data);
+ if (!ret)
+ pdata->ctrl_mod_reg_offset = data;
+
+ ret = of_property_read_u32(np, "ti,davinci-ctrl-ram-offset", &data);
+ if (!ret)
+ pdata->ctrl_ram_offset = data;
+
+ ret = of_property_read_u32(np, "ti,davinci-ctrl-ram-size", &data);
+ if (!ret)
+ pdata->ctrl_ram_size = data;
+
+ ret = of_property_read_u32(np, "ti,davinci-rmii-en", &data);
+ if (!ret)
+ pdata->rmii_en = data;
+
+ ret = of_property_read_u32(np, "ti,davinci-no-bd-ram", &data);
+ if (!ret)
+ pdata->no_bd_ram = data;
+
+ priv->phy_node = of_parse_phandle(np, "phy-handle", 0);
+ if (!priv->phy_node)
+ pdata->phy_id = "";
+
+ pdev->dev.platform_data = pdata;
+nodata:
+ return pdata;
+}
+#else
+static struct emac_platform_data
+ *davinci_emac_of_get_pdata(struct platform_device *pdev,
+ struct emac_priv *priv)
+{
+ return pdev->dev.platform_data;
+}
+#endif
/**
* davinci_emac_probe: EMAC device probe
* @pdev: The DaVinci EMAC device that we are removing
@@ -1804,7 +1884,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
spin_lock_init(&priv->lock);
- pdata = pdev->dev.platform_data;
+ pdata = davinci_emac_of_get_pdata(pdev, priv);
if (!pdata) {
dev_err(&pdev->dev, "no platform data\n");
rc = -ENODEV;
@@ -2015,6 +2095,12 @@ static const struct dev_pm_ops davinci_emac_pm_ops = {
.resume = davinci_emac_resume,
};
+static const struct of_device_id davinci_emac_of_match[] = {
+ {.compatible = "ti,davinci-dm6467-emac", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, davinci_emac_of_match);
+
/**
* davinci_emac_driver: EMAC platform driver structure
*/
@@ -2023,6 +2109,7 @@ static struct platform_driver davinci_emac_driver = {
.name = "davinci_emac",
.owner = THIS_MODULE,
.pm = &davinci_emac_pm_ops,
+ .of_match_table = of_match_ptr(davinci_emac_of_match),
},
.probe = davinci_emac_probe,
.remove = __devexit_p(davinci_emac_remove),
--
1.7.7.6
^ permalink raw reply related
* Re: [PATCH v5 4/7] ARM: davinci: net: davinci_emac: add OF support
From: Heiko Schocher @ 2012-07-09 8:25 UTC (permalink / raw)
To: Sekhar Nori
Cc: davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
Wolfgang Denk, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Anatoly Sivov,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <4FF998A7.50309-l0cyMroinI0@public.gmane.org>
Hello Sekhar,
On 08.07.2012 16:26, Sekhar Nori wrote:
[...]
> On 5/30/2012 3:49 PM, Heiko Schocher wrote:
>> add of support for the davinci_emac driver.
>>
>> Signed-off-by: Heiko Schocher<hs-ynQEQJNshbs@public.gmane.org>
>> Cc: davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org
>> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
>> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Cc: Grant Likely<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
>> Cc: Sekhar Nori<nsekhar-l0cyMroinI0@public.gmane.org>
>> Cc: Wolfgang Denk<wd-ynQEQJNshbs@public.gmane.org>
>> Cc: Anatoly Sivov<mm05-JGs/UdohzUI@public.gmane.org>
>>
>> ---
>
>> +#ifdef CONFIG_OF
>> +static struct emac_platform_data
>> + *davinci_emac_of_get_pdata(struct platform_device *pdev,
>> + struct emac_priv *priv)
>> +{
>> + struct device_node *np;
>> + struct emac_platform_data *pdata = NULL;
>> + const u8 *mac_addr;
>> + u32 data;
>> + int ret;
>> +
>> + pdata = pdev->dev.platform_data;
>> + if (!pdata) {
>> + pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
>> + if (!pdata)
>> + goto nodata;
>> + }
>> +
>> + np = pdev->dev.of_node;
>> + if (!np)
>> + goto nodata;
>> + else
>> + pdata->version = EMAC_VERSION_2;
>> +
>> + mac_addr = of_get_mac_address(np);
>> + if (mac_addr)
>> + memcpy(pdata->mac_addr, mac_addr, ETH_ALEN);
>
> I suspect that even in the DT case, many boards will continue to
> read mac address from on-board EEPROMs or from an on-chip eFUSE.
> To take care of such cases, I propose use mac address in DT data
> only if no valid address is passed through platform data. The
> attached patch does this change.
Ok, understand. I am fine with this.
> If you are OK with this modification, can you please merge it and
> repost just this patch for review? Please CC David Miller
> (davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org) on your next post as he is the netdev maintainer
> and this patch needs to be merged through him or at least needs his ack.
Merged, done.
> With this modification, you can add my:
>
> Acked-by: Sekhar Nori<nsekhar-l0cyMroinI0@public.gmane.org>
Ok, thanks. Post this patch soon, if I am finished with testing this
change.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [PATCH] net: cgroup: fix out of bounds accesses
From: Gao feng @ 2012-07-09 8:15 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, nhorman, linux-kernel, netdev, lizefan, tj
In-Reply-To: <1341819910.3265.2106.camel@edumazet-glaptop>
于 2012年07月09日 15:45, Eric Dumazet 写道:
> From: Eric Dumazet <edumazet@google.com>
>
> dev->priomap is allocated by extend_netdev_table() called from
> update_netdev_tables().
> And this is only called if write_priomap() is called.
>
> But if write_priomap() is not called, it seems we can have out of bounds
> accesses in cgrp_destroy(), read_priomap() & skb_update_prio()
>
> With help from Gao Feng
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>
> Cc: Gao feng <gaofeng@cn.fujitsu.com>
> ---
> net/core/dev.c | 8 ++++++--
> net/core/netprio_cgroup.c | 4 ++--
> 2 files changed, 8 insertions(+), 4 deletions(-)
Acked-by: Gao feng <gaofeng@cn.fujitsu.com>
^ permalink raw reply
* Re: [RFC PATCH] tcp: limit data skbs in qdisc layer
From: Eric Dumazet @ 2012-07-09 8:03 UTC (permalink / raw)
To: David Miller; +Cc: nanditad, netdev, ycheng, codel, mattmathis, ncardwell
In-Reply-To: <20120709.000834.1182150057463599677.davem@davemloft.net>
On Mon, 2012-07-09 at 00:08 -0700, David Miller wrote:
> I'm suspicious and anticipate that 10G will need more queueing than
> you are able to get away with tg3 at 1G speeds. But it is an exciting
> idea nonetheless :-)
I tested the patch on 10G NIC and had no problem on netperf tests.
Only that ixgbe is not yet BQL enabled so I could not add
skb_try_orphan() in its start_xmit() : So if TX completion is a bit
delayed, we can have a throughput slowdown.
I added a /proc/sys/net/ipv4/tcp_limit_output_segs to play with various
limits.
^ permalink raw reply
* [PATCH] net: cgroup: fix out of bounds accesses
From: Eric Dumazet @ 2012-07-09 7:45 UTC (permalink / raw)
To: David Miller; +Cc: nhorman, linux-kernel, netdev, lizefan, tj, Gao feng
From: Eric Dumazet <edumazet@google.com>
dev->priomap is allocated by extend_netdev_table() called from
update_netdev_tables().
And this is only called if write_priomap() is called.
But if write_priomap() is not called, it seems we can have out of bounds
accesses in cgrp_destroy(), read_priomap() & skb_update_prio()
With help from Gao Feng
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: Gao feng <gaofeng@cn.fujitsu.com>
---
net/core/dev.c | 8 ++++++--
net/core/netprio_cgroup.c | 4 ++--
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 84f01ba..0f28a9e 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2444,8 +2444,12 @@ static void skb_update_prio(struct sk_buff *skb)
{
struct netprio_map *map = rcu_dereference_bh(skb->dev->priomap);
- if ((!skb->priority) && (skb->sk) && map)
- skb->priority = map->priomap[skb->sk->sk_cgrp_prioidx];
+ if (!skb->priority && skb->sk && map) {
+ unsigned int prioidx = skb->sk->sk_cgrp_prioidx;
+
+ if (prioidx < map->priomap_len)
+ skb->priority = map->priomap[prioidx];
+ }
}
#else
#define skb_update_prio(skb)
diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
index aa907ed..3e953ea 100644
--- a/net/core/netprio_cgroup.c
+++ b/net/core/netprio_cgroup.c
@@ -142,7 +142,7 @@ static void cgrp_destroy(struct cgroup *cgrp)
rtnl_lock();
for_each_netdev(&init_net, dev) {
map = rtnl_dereference(dev->priomap);
- if (map)
+ if (map && cs->prioidx < map->priomap_len)
map->priomap[cs->prioidx] = 0;
}
rtnl_unlock();
@@ -166,7 +166,7 @@ static int read_priomap(struct cgroup *cont, struct cftype *cft,
rcu_read_lock();
for_each_netdev_rcu(&init_net, dev) {
map = rcu_dereference(dev->priomap);
- priority = map ? map->priomap[prioidx] : 0;
+ priority = (map && prioidx < map->priomap_len) ? map->priomap[prioidx] : 0;
cb->fill(cb, dev->name, priority);
}
rcu_read_unlock();
^ permalink raw reply related
* [PATCH] fix RTPROT_RA markup of some RA routes in netlink
From: Denis Ovsienko @ 2012-07-09 7:37 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 547 bytes --]
Hello, list.
This is a small patch I have produced after thoroughly studying the coupling between addrconf and FIB6 functions. I believe this change to improve the transparency of FIB6 as viewed from userspace (by iproute2 in particular). It does resolve an issue I was debugging, where a default route derived from a router advertisement couldn't be told from kernel routes derived from other sources. The difference is meaningful at least for dynamic routing purposes, but other good uses are also possible.
Thank you.
--
Denis Ovsienko
[-- Attachment #2: 0001-fix-RTPROT_RA-markup-of-some-RA-routes-in-netlink.patch --]
[-- Type: text/plain, Size: 2241 bytes --]
From 1d969903c6221980360f76abb5e063300e5cf3bb Mon Sep 17 00:00:00 2001
From: Denis Ovsienko <infrastation@yandex.ru>
Date: Fri, 6 Jul 2012 18:08:18 +0400
Subject: [PATCH] fix RTPROT_RA markup of some RA routes in netlink
There are three types of IPv6 routes originated by kernel ND RA code:
* Default routes standing for RA packets with non-zero router lifetime.
* Connected prefix routes standing for a Prefix Information (3) RA TLV.
* Any prefix routes standing for a Route Information (24) RA TLV.
All three types are internally stored using RTPROT_KERNEL or RTPROT_BOOT
protocol code and RTF_ADDRCONF route flag (this is the only purpose for
this flag). The flag isn't directly available in netlink socket space.
Given the need to tell route origin in userspace, for routes with
nexthops in the first turn, rt6_fill_node() tries to distinguish default
router case sending the netlink route structure with RTPROT_RA (this is
respectively the only use case for this protocol code), but to no
success due to a test condition taken wrong. All three types are
delivered with RTPROT_KERNEL.
This change is modelled after the original mailing list posting by Jeff
Haran. It fixes the test condition for the default router case and
extends it for the Route Information case.
---
net/ipv6/route.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 999a982..2f070d6 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2441,9 +2441,15 @@ static int rt6_fill_node(struct net *net,
if (rt->rt6i_flags & RTF_DYNAMIC)
rtm->rtm_protocol = RTPROT_REDIRECT;
else if (rt->rt6i_flags & RTF_ADDRCONF)
- rtm->rtm_protocol = RTPROT_KERNEL;
- else if (rt->rt6i_flags & RTF_DEFAULT)
- rtm->rtm_protocol = RTPROT_RA;
+ {
+ /* any ND RA route, most probably originated by kernel */
+ if (rt->rt6i_flags & RTF_DEFAULT) /* default router */
+ rtm->rtm_protocol = RTPROT_RA;
+ else if (rt->rt6i_flags & RTF_ROUTEINFO) /* any route w/nexthop */
+ rtm->rtm_protocol = RTPROT_RA;
+ else /* RTF_PREFIX_RT, interface connected prefix route */
+ rtm->rtm_protocol = RTPROT_KERNEL;
+ }
if (rt->rt6i_flags & RTF_CACHE)
rtm->rtm_flags |= RTM_F_CLONED;
--
1.7.7.6
^ permalink raw reply related
* Re: pull request: wireless 2012-07-06
From: David Miller @ 2012-07-09 7:31 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20120706192034.GA1879@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 6 Jul 2012 15:20:35 -0400
> Please let me know if there are problems!
This indentation is not correct:
commit 01f9cb073c827c60c43f769763b49a2026f1a897
Author: Thomas Huehn <thomas@net.t-labs.tu-berlin.de>
Date: Thu Jun 28 14:39:51 2012 -0700
mwl8k: fix possible race condition in info->control.sta use
...
+ sta = ieee80211_find_sta_by_ifaddr(hw, wh->addr1,
+ wh->addr2);
^ permalink raw reply
* Re: [PATCH 1/2] netfilter: ipset: timeout fixing bug broke SET target special timeout value
From: David Miller @ 2012-07-09 7:29 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1341574779-3373-2-git-send-email-pablo@netfilter.org>
From: pablo@netfilter.org
Date: Fri, 6 Jul 2012 13:39:38 +0200
> + if (add_opt.timeout != IPSET_NO_TIMEOUT
> + && add_opt.timeout > UINT_MAX/MSEC_PER_SEC)
We do not write conditionals like this, with operators beginning
a continued line. Instead, write this as:
if (a &&
b)
Thanks.
^ permalink raw reply
* Re: [PATCH net] cnic: Don't use netdev->base_addr
From: David Miller @ 2012-07-09 7:18 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1341534115-710-1-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Thu, 5 Jul 2012 17:21:55 -0700
> commit c0357e975afdbbedab5c662d19bef865f02adc17
> bnx2: stop using net_device.{base_addr, irq}.
>
> removed netdev->base_addr so we need to update cnic to get the MMIO
> base address from pci_resource_start(). Otherwise, mmap of the uio
> device will fail.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] net: qmi_wwan: add ZTE MF60
From: David Miller @ 2012-07-09 7:18 UTC (permalink / raw)
To: bjorn; +Cc: netdev
In-Reply-To: <1341486813-27600-1-git-send-email-bjorn@mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Thu, 5 Jul 2012 13:13:33 +0200
> Adding a device with limited QMI support. It does not support
> normal QMI_WDS commands for connection management. Instead,
> sending a QMI_CTL SET_INSTANCE_ID command is required to
> enable the network interface:
>
> 01 0f 00 00 00 00 00 00 20 00 04 00 01 01 00 00
>
> A number of QMI_DMS and QMI_NAS commands are also supported
> for optional device management.
>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
Applied.
^ permalink raw reply
* Re: [PATCH v2] cgroup: fix panic in netprio_cgroup
From: David Miller @ 2012-07-09 7:18 UTC (permalink / raw)
To: gaofeng; +Cc: netdev, linux-kernel, nhorman, tj, lizefan, eric.dumazet
In-Reply-To: <1341480520-25081-1-git-send-email-gaofeng@cn.fujitsu.com>
From: Gao feng <gaofeng@cn.fujitsu.com>
Date: Thu, 5 Jul 2012 17:28:40 +0800
> we set max_prioidx to the first zero bit index of prioidx_map in
> function get_prioidx.
>
> So when we delete the low index netprio cgroup and adding a new
> netprio cgroup again,the max_prioidx will be set to the low index.
>
> when we set the high index cgroup's net_prio.ifpriomap,the function
> write_priomap will call update_netdev_tables to alloc memory which
> size is sizeof(struct netprio_map) + sizeof(u32) * (max_prioidx + 1),
> so the size of array that map->priomap point to is max_prioidx +1,
> which is low than what we actually need.
>
> fix this by adding check in get_prioidx,only set max_prioidx when
> max_prioidx low than the new prioidx.
>
> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
Applied.
^ permalink raw reply
* Re: [patch] [AX.25]: small cleanup in ax25_addr_parse()
From: David Miller @ 2012-07-09 7:16 UTC (permalink / raw)
To: dan.carpenter; +Cc: ralf, linux-hams, netdev, kernel-janitors
In-Reply-To: <20120705082718.GA14993@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 5 Jul 2012 11:27:18 +0300
> The comments were wrong here because "AX25_MAX_DIGIS" is 8 but the
> comments say 6. Also I've changed the "7" to "AX25_ADDR_LEN".
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, thanks Dan.
^ permalink raw reply
* [PATCH 2/2] stmmac: Fix for higher mtu size handling
From: Deepak Sikri @ 2012-07-09 7:14 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: spear--sw-devel, netdev, Deepak Sikri
In-Reply-To: <1341818086-28897-2-git-send-email-deepak.sikri@st.com>
For the higher mtu sizes requiring the buffer size greater than 8192,
the buffers are sent or received using multiple dma descriptors/ same
descriptor with option of multi buffer handling.
It was observed during tests that the driver was missing on data
packets during the normal ping operations if the data buffers being used
catered to jumbo frame handling.
The memory barrriers are added in between preparation of dma descriptors
in the jumbo frame handling path to ensure all instructions before
enabling the dma are complete.
Signed-off-by: Deepak Sikri <deepak.sikri@st.com>
---
drivers/net/ethernet/stmicro/stmmac/ring_mode.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/ring_mode.c b/drivers/net/ethernet/stmicro/stmmac/ring_mode.c
index fb8377d..4b785e1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/ring_mode.c
+++ b/drivers/net/ethernet/stmicro/stmmac/ring_mode.c
@@ -51,7 +51,7 @@ static unsigned int stmmac_jumbo_frm(void *p, struct sk_buff *skb, int csum)
desc->des3 = desc->des2 + BUF_SIZE_4KiB;
priv->hw->desc->prepare_tx_desc(desc, 1, bmax,
csum);
-
+ wmb();
entry = (++priv->cur_tx) % txsize;
desc = priv->dma_tx + entry;
@@ -59,6 +59,7 @@ static unsigned int stmmac_jumbo_frm(void *p, struct sk_buff *skb, int csum)
len, DMA_TO_DEVICE);
desc->des3 = desc->des2 + BUF_SIZE_4KiB;
priv->hw->desc->prepare_tx_desc(desc, 0, len, csum);
+ wmb();
priv->hw->desc->set_tx_owner(desc);
priv->tx_skbuff[entry] = NULL;
} else {
--
1.7.2.2
^ permalink raw reply related
* Re: [PATCH 1/2] be2net: Fix Endian
From: David Miller @ 2012-07-09 7:14 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev, somnath.kotur
In-Reply-To: <1341453942-4198-1-git-send-email-roy.qing.li@gmail.com>
From: roy.qing.li@gmail.com
Date: Thu, 5 Jul 2012 10:05:42 +0800
> From: Li RongQing <roy.qing.li@gmail.com>
>
> ETH_P_IP is host Endian, skb->protocol is big Endian, when
> compare them, we should change ETH_P_IP from host endian
> to big endian, htons, not ntohs.
>
> CC: Somnath Kotur <somnath.kotur@emulex.com>
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Applied to net-next since this actually doesn't cause any real
problems winc htons() and ntohs() are implemented identically
and perform the same operation.
Thanks.
^ permalink raw reply
* [PATCH 1/2] stmmac: Fix for nfs hang on multiple reboot
From: Deepak Sikri @ 2012-07-09 7:14 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: spear--sw-devel, netdev, Deepak Sikri
In-Reply-To: <1341818086-28897-1-git-send-email-deepak.sikri@st.com>
It was observed that during multiple reboots nfs hangs. The status of
receive descriptors shows that all the descriptors were in control of
CPU, and none were assigned to DMA.
Also the DMA status register confirmed that the Rx buffer is
unavailable.
This patch adds the fix for the same by adding the memory barriers to
ascertain that the all instructions before enabling the Rx or Tx DMA are
completed which involves the proper setting of the ownership bit in DMA
descriptors.
Signed-off-by: Deepak Sikri <deepak.sikri@st.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 51b3b68..ea3003e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1212,6 +1212,7 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
priv->hw->desc->prepare_tx_desc(desc, 0, len, csum_insertion);
wmb();
priv->hw->desc->set_tx_owner(desc);
+ wmb();
}
/* Interrupt on completition only for the latest segment */
@@ -1227,6 +1228,7 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
/* To avoid raise condition */
priv->hw->desc->set_tx_owner(first);
+ wmb();
priv->cur_tx++;
@@ -1290,6 +1292,7 @@ static inline void stmmac_rx_refill(struct stmmac_priv *priv)
}
wmb();
priv->hw->desc->set_rx_owner(p + entry);
+ wmb();
}
}
--
1.7.2.2
^ permalink raw reply related
* [PATCH 0/2] stmmac: nfs reboot crash & jumbo frame handling fix
From: Deepak Sikri @ 2012-07-09 7:14 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: spear--sw-devel, netdev, Deepak Sikri
This patch set handles in the fixes for following bugs that were
observed during testing.
1. On Multiple reboot operations using nfs, system crash were observed
with inconsistency in status of dma descriptors.
2. There were data losses observed whenever the jumbo frames were used
for data transfers.
Deepak Sikri (2):
stmmac: Fix for nfs hang on multiple reboot
stmmac: Fix for higher mtu size handling
drivers/net/ethernet/stmicro/stmmac/ring_mode.c | 3 ++-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 +++
2 files changed, 5 insertions(+), 1 deletions(-)
--
1.7.2.2
^ permalink raw reply
* Re: [PATCH] netdev/phy: Fixup lockdep warnings in mdio-mux.c
From: David Miller @ 2012-07-09 7:13 UTC (permalink / raw)
To: ddaney.cavm; +Cc: netdev, linux-kernel, david.daney
In-Reply-To: <1341439576-1413-1-git-send-email-ddaney.cavm@gmail.com>
From: David Daney <ddaney.cavm@gmail.com>
Date: Wed, 4 Jul 2012 15:06:16 -0700
> From: David Daney <david.daney@cavium.com>
>
> With lockdep enabled we get:
...
> This is a false positive, since we are indeed using 'nested' locking,
> we need to use mutex_lock_nested().
>
> Now in theory we can stack multiple MDIO multiplexers, but that would
> require passing the nesting level (which is difficult to know) to
> mutex_lock_nested(). Instead we assume the simple case of a single
> level of nesting. Since these are only warning messages, it isn't so
> important to solve the general case.
>
> Signed-off-by: David Daney <david.daney@cavium.com>
Applied to 'net', thanks.
^ permalink raw reply
* Re: [PATCH] bcm87xx: fix reg-init comment typo
From: David Miller @ 2012-07-09 7:12 UTC (permalink / raw)
To: ddaney.cavm; +Cc: jacmet, netdev, david.daney
In-Reply-To: <4FF47BDE.3010002@gmail.com>
From: David Daney <ddaney.cavm@gmail.com>
Date: Wed, 04 Jul 2012 10:22:38 -0700
> On 07/04/2012 08:05 AM, Peter Korsgaard wrote:
>> broadcom, not marvell.
>>
>> Signed-off-by: Peter Korsgaard<jacmet@sunsite.dk>
>
> Indeed, it was a cut-and-paste error. Thanks for fixing it...
>
> Acked-by: David Daney <david.daney@cavium.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] phylib: Support registering a bunch of drivers
From: David Miller @ 2012-07-09 7:11 UTC (permalink / raw)
To: chohnstaedt; +Cc: netdev
In-Reply-To: <20120704154434.GZ19422@elara.bln.innominate.local>
From: Christian Hohnstaedt <chohnstaedt@innominate.com>
Date: Wed, 4 Jul 2012 17:44:34 +0200
> If registering of one of them fails, all already registered drivers
> of this module will be unregistered.
>
> Use the new register/unregister functions in all drivers
> registering more than one driver.
>
> amd.c, realtek.c: Simplify: directly return registration result.
>
> Tested with broadcom.c
> All others compile-tested.
>
> Signed-off-by: Christian Hohnstaedt <chohnstaedt@innominate.com>
Applied, thanks.
^ permalink raw reply
* Re: [net] ixgbe: DCB and SR-IOV can not co-exist and will cause hangs
From: David Miller @ 2012-07-09 7:10 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: alexander.h.duyck, netdev, gospo, sassmann
In-Reply-To: <1341403225-1326-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 4 Jul 2012 05:00:25 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> DCB and SR-IOV cannot currently be enabled at the same time as the queueing
> schemes are incompatible. If they are both enabled it will result in Tx
> hangs since only the first Tx queue will be able to transmit any traffic.
>
> This simple fix for this is to block us from enabling TCs in ixgbe_setup_tc
> if SR-IOV is enabled. This change will be reverted once we can support
> SR-IOV and DCB coexistence.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Acked-by: John Fastabend <john.r.fastabend@intel.com>
> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
> Tested-by: Ross Brattain <ross.b.brattain@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox