* Your Mail Quota Has Exceeded
From: Mail Administrator @ 2011-09-13 21:27 UTC (permalink / raw)
Your Mail Quota Has Exceeded The Set Quota/Limit. You Are Currently
Running On 23GB Due To Hidden Files And Folders On Your Mailbox,
you may not be able to receive or send new mails until you re-validate.
Please Click Any of the Link Below To Validate Your Mailbox And Increase
Your Quota.
http://buzurl.com/bi51
Failure to do so may result cancellation of your web mail account.
Thanks, and sorry for the inconvenience
Mail Administrator
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ permalink raw reply
* (unknown),
From: Mr. Song Lile Transfer Offer 2011 @ 2011-09-13 21:54 UTC (permalink / raw)
I am Song Lile. Director of Hang Seng Bank HongKong Ltd, I do not know if we can work together in transferring $19,500,000.USD from my bank to your bank account. Finally if you are interested I shall provide you with more details. Please contact me with this Email: mrsonglile2011@yahoo.cn
^ permalink raw reply
* Re: [PATCH] ixgbe: drop zero length frame segments during a packet split rx
From: Jeff Kirsher @ 2011-09-13 22:52 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: <20110913105003.GA16222@hmsreliant.think-freely.org>
[-- Attachment #1: Type: text/plain, Size: 3769 bytes --]
On Tue, 2011-09-13 at 03:50 -0700, Neil Horman wrote:
> On Fri, Sep 02, 2011 at 10:03:17AM -0400, 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
> >
> Sorry, I need to rescind this patch. Looks like this is turning out to be an
> issue with an ideosyncracy in the dma hardware on this platform.
>
> Thanks
> Neil
>
Thanks for the update Neil. I have dropped the patch from my queue.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] netdev/of/phy: Add MDIO bus multiplexer support.
From: Kumar Gala @ 2011-09-13 23:07 UTC (permalink / raw)
To: David Daney
Cc: linux-mips-6z/3iImG2C8G8FEW9MqTrA, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ralf-6z/3iImG2C8G8FEW9MqTrA,
David S. Miller
In-Reply-To: <1314820906-14004-3-git-send-email-david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
> diff --git a/Documentation/devicetree/bindings/net/mdio-mux.txt b/Documentation/devicetree/bindings/net/mdio-mux.txt
> new file mode 100644
> index 0000000..a908312
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/mdio-mux.txt
> @@ -0,0 +1,132 @@
> +Common MDIO bus multiplexer/switch properties.
> +
> +An MDIO bus multiplexer/switch will have several child busses that are
> +numbered uniquely in a device dependent manner. The nodes for an MDIO
> +bus multiplexer/switch will have one child node for each child bus.
> +
> +Required properties:
> +- parent-bus : phandle to the parent MDIO bus.
Should probably be mdio-parent-bus
> +
> +Optional properties:
> +- Other properties specific to the multiplexer/switch hardware.
> +
> +Required properties for child nodes:
> +- #address-cells = <1>;
> +- #size-cells = <0>;
> +- cell-index : The sub-bus number.
What does sub-bus number mean?
> +
> +
> +Example :
[snip]
> diff --git a/drivers/net/phy/mdio-mux.c b/drivers/net/phy/mdio-mux.c
> new file mode 100644
> index 0000000..f9c5826
> --- /dev/null
> +++ b/drivers/net/phy/mdio-mux.c
> @@ -0,0 +1,182 @@
> +/*
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License. See the file "COPYING" in the main directory of this archive
> + * for more details.
> + *
> + * Copyright (C) 2011 Cavium Networks
> + */
> +
> +#include <linux/platform_device.h>
> +#include <linux/of_mdio.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/gfp.h>
> +#include <linux/phy.h>
> +#include <linux/mdio-mux.h>
> +
> +#define DRV_VERSION "1.0"
> +#define DRV_DESCRIPTION "MDIO bus multiplexer driver"
> +
> +struct mdio_mux_parent_bus {
> + struct mii_bus *mii_bus;
> + int current_child;
> + int parent_id;
> + void *switch_data;
> + int (*switch_fn)(int current_child, int desired_child, void *data);
> +};
> +
> +struct mdio_mux_child_bus {
> + struct mii_bus *mii_bus;
> + struct mdio_mux_parent_bus *parent;
> + int bus_number;
> + int phy_irq[PHY_MAX_ADDR];
> +};
> +
> +/*
> + * The parent bus' lock is used to order access to the switch_fn.
> + */
> +static int mdio_mux_read(struct mii_bus *bus, int phy_id, int regnum)
> +{
> + struct mdio_mux_child_bus *cb = bus->priv;
> + struct mdio_mux_parent_bus *pb = cb->parent;
> + int r;
> +
> + mutex_lock(&pb->mii_bus->mdio_lock);
> + r = pb->switch_fn(pb->current_child, cb->bus_number, pb->switch_data);
> + if (r)
> + goto out;
> +
> + pb->current_child = cb->bus_number;
> +
> + r = pb->mii_bus->read(pb->mii_bus, phy_id, regnum);
> +out:
> + mutex_unlock(&pb->mii_bus->mdio_lock);
> +
> + return r;
> +}
> +
> +/*
> + * The parent bus' lock is used to order access to the switch_fn.
> + */
> +static int mdio_mux_write(struct mii_bus *bus, int phy_id,
> + int regnum, u16 val)
> +{
> + struct mdio_mux_child_bus *cb = bus->priv;
> + struct mdio_mux_parent_bus *pb = cb->parent;
> +
> + int r;
> +
> + mutex_lock(&pb->mii_bus->mdio_lock);
> + r = pb->switch_fn(pb->current_child, cb->bus_number, pb->switch_data);
> + if (r)
> + goto out;
> +
> + pb->current_child = cb->bus_number;
> +
> + r = pb->mii_bus->write(pb->mii_bus, phy_id, regnum, val);
> +out:
> + mutex_unlock(&pb->mii_bus->mdio_lock);
> +
> + return r;
> +}
> +
> +static int parent_count;
> +
> +int mdio_mux_probe(struct platform_device *pdev,
> + int (*switch_fn)(int cur, int desired, void *data),
> + void *data)
> +{
> + struct device_node *parent_bus_node;
> + struct device_node *child_bus_node;
> + int r, n, ret_val;
> + struct mii_bus *parent_bus;
> + struct mdio_mux_parent_bus *pb;
> + struct mdio_mux_child_bus *cb;
> +
> + if (!pdev->dev.of_node)
> + return -ENODEV;
> +
> + parent_bus_node = of_parse_phandle(pdev->dev.of_node, "parent-bus", 0);
> +
> + if (!parent_bus_node)
> + return -ENODEV;
> +
> + parent_bus = of_mdio_find_bus(parent_bus_node);
So what happens if the parent bus probe happens after the mux probe?
> +
> + pb = devm_kzalloc(&pdev->dev, sizeof(*pb), GFP_KERNEL);
> + if (pb == NULL) {
> + ret_val = -ENOMEM;
> + goto err_parent_bus;
> + }
> +
> + pb->switch_data = data;
> + pb->switch_fn = switch_fn;
> + pb->current_child = -1;
> + pb->parent_id = parent_count++;
> + pb->mii_bus = parent_bus;
> +
> + n = 0;
> + for_each_child_of_node(pdev->dev.of_node, child_bus_node) {
> + u32 v;
> +
> + r = of_property_read_u32(child_bus_node, "cell-index", &v);
> + if (r == 0) {
> + cb = devm_kzalloc(&pdev->dev, sizeof(*cb), GFP_KERNEL);
> + if (cb == NULL)
> + break;
> + cb->bus_number = v;
> + cb->parent = pb;
> + cb->mii_bus = mdiobus_alloc();
> + cb->mii_bus->priv = cb;
> +
> + cb->mii_bus->irq = cb->phy_irq;
> + cb->mii_bus->name = "mdio_mux";
> + snprintf(cb->mii_bus->id, MII_BUS_ID_SIZE, "%x.%x",
> + pb->parent_id, v);
> + cb->mii_bus->parent = &pdev->dev;
> + cb->mii_bus->read = mdio_mux_read;
> + cb->mii_bus->write = mdio_mux_write;
> + r = of_mdiobus_register(cb->mii_bus, child_bus_node);
> + if (r) {
> + of_node_put(child_bus_node);
> + devm_kfree(&pdev->dev, cb);
> + } else {
> + n++;
> + }
> +
> + } else {
> + of_node_put(child_bus_node);
> + }
> + }
> + if (n) {
> + dev_info(&pdev->dev, "Version " DRV_VERSION "\n");
> + return 0;
> + }
> + ret_val = -ENOMEM;
> + devm_kfree(&pdev->dev, pb);
> +err_parent_bus:
> + of_node_put(parent_bus_node);
> + return ret_val;
> +}
> +EXPORT_SYMBOL(mdio_mux_probe);
> +
> +static int __devexit mdio_mux_remove(struct platform_device *pdev)
> +{
> + return 0;
> +}
> +
> +static int __init mdio_mux_mod_init(void)
> +{
> + return 0;
> +}
> +module_init(mdio_mux_mod_init);
> +
> +static void __exit mdio_mux_mod_exit(void)
> +{
> +}
> +module_exit(mdio_mux_mod_exit);
> +
> +MODULE_DESCRIPTION(DRV_DESCRIPTION);
> +MODULE_VERSION(DRV_VERSION);
> +MODULE_AUTHOR("David Daney");
> +MODULE_LICENSE("GPL");
^ permalink raw reply
* Query on a lockdep issue in neigh_lookup
From: Murali raja Muniraju @ 2011-09-13 23:11 UTC (permalink / raw)
To: netdev
Hi,
I see a potential deadlock situation on the kernel 2.6.34. Has this
been fixed in the later version of the kernel.
I see that one after holding the neigh_lookup, one can acquire the
lock for rt_hash_locks
But there is a situation while freed skb's in dst_release while
holding the rt_hash_locks, neigh_lookup can be called which tries to
acquire its lock.
This seems to be a deadlock candidate.
Thanks,
Murali
Below if the scenario found by lockdep on a debug kernel during the
kernel bootup.
[ 92.245713] =======================================================
[ 92.246640] [ INFO: possible circular locking dependency detected ]
[ 92.246640] 2.6.34-dbg-2011082906 #1
[ 92.246640] -------------------------------------------------------
[ 92.246640] swapper/0 is trying to acquire lock:
[ 92.246640] (&tbl->lock){++--..}, at: [<ffffffff81553a22>]
neigh_lookup+0x42/0xd0
[ 92.246640]
[ 92.246640] but task is already holding lock:
[ 92.246640] (&(&rt_hash_locks[i])->rlock){+.-...}, at:
[<ffffffff815798e0>] rt_intern_hash+0xd0/0x880
[ 92.246640]
[ 92.246640] which lock already depends on the new lock.
[ 92.246640]
[ 92.246640]
[ 92.246640] the existing dependency chain (in reverse order) is:
[ 92.246640]
[ 92.246640] -> #2 (&(&rt_hash_locks[i])->rlock){+.-...}:
[ 92.246640] [<ffffffff810e7700>] __lock_acquire+0xe30/0x1190
[ 92.246640] [<ffffffff810e7af3>] lock_acquire+0x93/0x120
[ 92.246640] [<ffffffff815ed266>] _raw_spin_lock_bh+0x36/0x50
[ 92.246640] [<ffffffff81576a26>] rt_dst_release+0x66/0xc0
[ 92.246640] [<ffffffff8155194c>] dst_release+0x5c/0x90
[ 92.246640] [<ffffffff8153aef5>] skb_release_head_state+0x95/0xd0
[ 92.246640] [<ffffffff8153ad06>] __kfree_skb+0x16/0xa0
[ 92.246640] [<ffffffff8153ae12>] kfree_skb+0x42/0x90
[ 92.246640] [<ffffffff81552fae>] __neigh_event_send+0x11e/0x1d0
[ 92.246640] [<ffffffff81553193>] neigh_resolve_output+0x133/0x2f0
[ 92.246640] [<ffffffff81584742>] ip_output+0x2c2/0x3a0
[ 92.246640] [<ffffffff8158291d>] ip_local_out+0xad/0xc0
[ 92.246640] [<ffffffff81582cc0>] ip_send_reply+0x290/0x340
[ 92.246640] [<ffffffff815a3ba1>] tcp_v4_send_reset+0x1a1/0x310
[ 92.246640] [<ffffffff815a7b04>] tcp_v4_rcv+0x314/0x9b0
[ 92.246640] [<ffffffff8157e344>] ip_local_deliver_finish+0xf4/0x200
[ 92.246640] [<ffffffff8157e4e0>] ip_local_deliver+0x90/0xa0
[ 92.246640] [<ffffffff8157dbf1>] ip_rcv_finish+0x111/0x460
[ 92.246640] [<ffffffff8157e17d>] ip_rcv+0x23d/0x310
[ 92.246640] [<ffffffff81549144>] __netif_receive_skb+0x2d4/0x570
[ 92.246640] [<ffffffff81549620>] netif_receive_skb+0xb0/0xc0
[ 92.246640] [<ffffffff81549d28>] napi_gro_receive+0x148/0x180
[ 92.246640] [<ffffffffa0066aba>]
e1000_clean_rx_irq+0x2ba/0x470 [e1000e]
[ 92.246640] [<ffffffffa006567f>] e1000_clean+0x7f/0x280 [e1000e]
[ 92.246640] [<ffffffff8154b200>] net_rx_action+0x170/0x4f0
[ 92.246640] [<ffffffff810a8ec7>] __do_softirq+0x127/0x2b0
[ 92.246640] [<ffffffff8104514c>] call_softirq+0x1c/0x50
[ 92.246640] [<ffffffff810472dd>] do_softirq+0x7d/0xb0
[ 92.246640] [<ffffffff810a8cd5>] irq_exit+0xa5/0xb0
[ 92.246640] [<ffffffff815f5555>] do_IRQ+0x75/0xf0
[ 92.246640] [<ffffffff815edb13>] ret_from_intr+0x0/0xf
[ 92.510442] [<ffffffff815ed7d3>] _raw_spin_unlock+0x23/0x40
[ 92.510442] [<ffffffff811b1d03>] sys_close+0xc3/0x160
[ 92.510442] [<ffffffff8107d0e7>] sysenter_dispatch+0x7/0x2c
[ 92.510442]
[ 92.510442] -> #1 (&n->lock){++--..}:
[ 92.510442] [<ffffffff810e7700>] __lock_acquire+0xe30/0x1190
[ 92.510442] [<ffffffff810e7af3>] lock_acquire+0x93/0x120
[ 92.510442] [<ffffffff815ed3b1>] _raw_write_lock+0x31/0x40
[ 92.510442] [<ffffffff81556b90>] neigh_periodic_work+0xa0/0x4a0
[ 92.510442] [<ffffffff810c274c>] worker_thread+0x1cc/0x330
[ 92.510442] [<ffffffff810c7de6>] kthread+0x96/0xa0
[ 92.510442] [<ffffffff81045054>] kernel_thread_helper+0x4/0x10
[ 92.510442]
[ 92.510442] -> #0 (&tbl->lock){++--..}:
[ 92.510442] [<ffffffff810e7a5e>] __lock_acquire+0x118e/0x1190
[ 92.510442] [<ffffffff810e7af3>] lock_acquire+0x93/0x120
[ 92.510442] [<ffffffff815ed569>] _raw_read_lock_bh+0x39/0x50
[ 92.510442] [<ffffffff81553a22>] neigh_lookup+0x42/0xd0
[ 92.510442] [<ffffffff815b1ce9>] arp_bind_neighbour+0x79/0xb0
[ 92.510442] [<ffffffff815799a2>] rt_intern_hash+0x192/0x880
[ 92.510442] [<ffffffff8157bb3c>] ip_route_output_slow+0x47c/0xa50
[ 92.510442] [<ffffffff8157c53f>] __ip_route_output_key+0x5f/0x250
[ 92.510442] [<ffffffff8157c7c1>] ip_route_output_key+0x21/0x70
[ 92.510442] [<ffffffff815b3a28>] arp_process+0x7f8/0x970
[ 92.510442] [<ffffffff815b3cb1>] arp_rcv+0x111/0x140
[ 92.510442] [<ffffffff81549144>] __netif_receive_skb+0x2d4/0x570
[ 92.510442] [<ffffffff81549620>] netif_receive_skb+0xb0/0xc0
[ 92.510442] [<ffffffff81549d28>] napi_gro_receive+0x148/0x180
[ 92.510442] [<ffffffffa0066aba>]
e1000_clean_rx_irq+0x2ba/0x470 [e1000e]
[ 92.510442] [<ffffffffa006567f>] e1000_clean+0x7f/0x280 [e1000e]
[ 92.510442] [<ffffffff8154b200>] net_rx_action+0x170/0x4f0
[ 92.510442] [<ffffffff810a8ec7>] __do_softirq+0x127/0x2b0
[ 92.510442] [<ffffffff8104514c>] call_softirq+0x1c/0x50
[ 92.510442] [<ffffffff810472dd>] do_softirq+0x7d/0xb0
[ 92.510442] [<ffffffff810a8cd5>] irq_exit+0xa5/0xb0
[ 92.510442] [<ffffffff815f5555>] do_IRQ+0x75/0xf0
[ 92.510442] [<ffffffff815edb13>] ret_from_intr+0x0/0xf
[ 92.510442] [<ffffffff81043125>] cpu_idle+0x95/0x150
[ 92.510442] [<ffffffff81b924e1>] start_secondary+0x1d1/0x1d5
[ 92.510442]
[ 92.510442] other info that might help us debug this:
[ 92.510442]
[ 92.742983] 4 locks held by swapper/0:
[ 92.742983] #0: (rcu_read_lock){.+.+.+}, at:
[<ffffffff8154b17e>] net_rx_action+0xee/0x4f0
[ 92.742983] #1: (&(&napi->poll_lock)->rlock){+.-...}, at:
[<ffffffff8154b1d6>] net_rx_action+0x146/0x4f0
[ 92.742983] #2: (rcu_read_lock){.+.+.+}, at:
[<ffffffff81548ff0>] __netif_receive_skb+0x180/0x570
[ 92.742983] #3: (&(&rt_hash_locks[i])->rlock){+.-...}, at:
[<ffffffff815798e0>] rt_intern_hash+0xd0/0x880
[ 92.742983]
[ 92.742983] stack backtrace:
[ 92.742983] Pid: 0, comm: swapper Not tainted 2.6.34-dbg-2011082906 #1
[ 92.742983] Call Trace:
[ 92.742983] <IRQ> [<ffffffff810e40b9>] print_circular_bug+0xe9/0xf0
[ 92.742983] [<ffffffff810e7a5e>] __lock_acquire+0x118e/0x1190
[ 92.742983] [<ffffffff810e7af3>] lock_acquire+0x93/0x120
[ 92.742983] [<ffffffff81553a22>] ? neigh_lookup+0x42/0xd0
[ 92.742983] [<ffffffff815ed569>] _raw_read_lock_bh+0x39/0x50
[ 92.742983] [<ffffffff81553a22>] ? neigh_lookup+0x42/0xd0
[ 92.742983] [<ffffffff81553a22>] neigh_lookup+0x42/0xd0
[ 92.742983] [<ffffffff815b1ce9>] arp_bind_neighbour+0x79/0xb0
[ 92.742983] [<ffffffff815798e0>] ? rt_intern_hash+0xd0/0x880
[ 92.742983] [<ffffffff815799a2>] rt_intern_hash+0x192/0x880
[ 92.742983] [<ffffffff8157bb3c>] ip_route_output_slow+0x47c/0xa50
[ 92.742983] [<ffffffff8157b961>] ? ip_route_output_slow+0x2a1/0xa50
[ 92.742983] [<ffffffff8157c53f>] __ip_route_output_key+0x5f/0x250
[ 92.742983] [<ffffffff8157c560>] ? __ip_route_output_key+0x80/0x250
[ 92.742983] [<ffffffff8157c7c1>] ip_route_output_key+0x21/0x70
[ 92.742983] [<ffffffff815b3a28>] arp_process+0x7f8/0x970
[ 92.742983] [<ffffffff815b3230>] ? arp_process+0x0/0x970
[ 92.742983] [<ffffffff815b3cb1>] arp_rcv+0x111/0x140
[ 92.742983] [<ffffffff81549144>] __netif_receive_skb+0x2d4/0x570
[ 92.742983] [<ffffffff81548ff0>] ? __netif_receive_skb+0x180/0x570
[ 92.742983] [<ffffffff811ab25d>] ? __kmalloc_node_track_caller+0x7d/0x100
[ 92.742983] [<ffffffff811a88d0>] ? kmem_cache_alloc_node+0x0/0x280
[ 92.742983] [<ffffffff81549620>] netif_receive_skb+0xb0/0xc0
[ 92.742983] [<ffffffff81549570>] ? netif_receive_skb+0x0/0xc0
[ 92.742983] [<ffffffff8153981f>] ? __alloc_skb+0x8f/0x1a0
[ 92.742983] [<ffffffff81549d28>] napi_gro_receive+0x148/0x180
[ 92.742983] [<ffffffffa0066aba>] e1000_clean_rx_irq+0x2ba/0x470 [e1000e]
[ 92.742983] [<ffffffffa006567f>] e1000_clean+0x7f/0x280 [e1000e]
[ 92.742983] [<ffffffff8154b200>] net_rx_action+0x170/0x4f0
[ 92.742983] [<ffffffff8154b17e>] ? net_rx_action+0xee/0x4f0
[ 92.742983] [<ffffffff810a8e71>] ? __do_softirq+0xd1/0x2b0
[ 92.742983] [<ffffffff810a8ec7>] __do_softirq+0x127/0x2b0
[ 92.742983] [<ffffffff8104514c>] call_softirq+0x1c/0x50
[ 92.742983] [<ffffffff810472dd>] do_softirq+0x7d/0xb0
[ 92.742983] [<ffffffff810a8cd5>] irq_exit+0xa5/0xb0
[ 92.742983] [<ffffffff815f5555>] do_IRQ+0x75/0xf0
[ 93.005851] [<ffffffff815edb13>] ret_from_intr+0x0/0xf
[ 93.005851] <EOI> [<ffffffff8104d737>] ? mwait_idle+0x77/0xd0
[ 93.005851] [<ffffffff8104d72e>] ? mwait_idle+0x6e/0xd0
[ 93.005851] [<ffffffff81043125>] cpu_idle+0x95/0x150
[ 93.005851] [<ffffffff81b924e1>] start_secondary+0x1d1/0x1d5
--
__MURALI__
^ permalink raw reply
* Re: [PATCH 2/3] netdev/of/phy: Add MDIO bus multiplexer support.
From: David Daney @ 2011-09-13 23:23 UTC (permalink / raw)
To: Kumar Gala, grant.likely-s3s/WqlpOiPyB63q8FvJNQ
Cc: linux-mips-6z/3iImG2C8G8FEW9MqTrA, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ralf-6z/3iImG2C8G8FEW9MqTrA,
David S. Miller
In-Reply-To: <129FAAB3-C9AD-43F6-A8CB-96548A47C4DC-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
On 09/13/2011 04:07 PM, Kumar Gala wrote:
>
>> diff --git a/Documentation/devicetree/bindings/net/mdio-mux.txt b/Documentation/devicetree/bindings/net/mdio-mux.txt
>> new file mode 100644
>> index 0000000..a908312
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/mdio-mux.txt
>> @@ -0,0 +1,132 @@
>> +Common MDIO bus multiplexer/switch properties.
>> +
>> +An MDIO bus multiplexer/switch will have several child busses that are
>> +numbered uniquely in a device dependent manner. The nodes for an MDIO
>> +bus multiplexer/switch will have one child node for each child bus.
>> +
>> +Required properties:
>> +- parent-bus : phandle to the parent MDIO bus.
>
> Should probably be mdio-parent-bus
Why? We know it is MDIO.
Serial bus multiplexing is not a concept limited to MDIO. We would want
to use "parent-bus" for some I2C multiplexers as well.
>
>> +
>> +Optional properties:
>> +- Other properties specific to the multiplexer/switch hardware.
>> +
>> +Required properties for child nodes:
>> +- #address-cells =<1>;
>> +- #size-cells =<0>;
>> +- cell-index : The sub-bus number.
>
> What does sub-bus number mean?
There are N child buses (or sub-buses) coming out of the multiplexer.
The cell-index is used as a handle or identifier for each of these.
The concrete example in Patch 3/3 is a multiplexer with four child
buses. The happen to have cell-indexes of 0, 1, 2 and 3.
In the GPIO case of patch 3/3, these directly correspond the the state
of the two GPIO pins controlling the multiplexer. The driver then uses
the cell-index property to determine the state of the GPIO to connect
any given child.
It is possible that the documentation part of the patch could be made
more clear about this.
>
>> +
>> +
>> +Example :
>
[...]
>> +
>> +int mdio_mux_probe(struct platform_device *pdev,
>> + int (*switch_fn)(int cur, int desired, void *data),
>> + void *data)
>> +{
>> + struct device_node *parent_bus_node;
>> + struct device_node *child_bus_node;
>> + int r, n, ret_val;
>> + struct mii_bus *parent_bus;
>> + struct mdio_mux_parent_bus *pb;
>> + struct mdio_mux_child_bus *cb;
>> +
>> + if (!pdev->dev.of_node)
>> + return -ENODEV;
>> +
>> + parent_bus_node = of_parse_phandle(pdev->dev.of_node, "parent-bus", 0);
>> +
>> + if (!parent_bus_node)
>> + return -ENODEV;
>> +
>> + parent_bus = of_mdio_find_bus(parent_bus_node);
>
>
> So what happens if the parent bus probe happens after the mux probe?
>
The whole house of cards collapses.
Grant Likely has a patch to deal with this by retrying the probing, but
as far as I know, it has not been merged yet.
^ permalink raw reply
* Re: Query on a lockdep issue in neigh_lookup
From: Eric Dumazet @ 2011-09-13 23:59 UTC (permalink / raw)
To: Murali raja Muniraju; +Cc: netdev
In-Reply-To: <CAByGWUHkt=6AjW_GFsGd1EnbMC=pjhtxRu8ez0sw6rZNvA_nxg@mail.gmail.com>
Le mardi 13 septembre 2011 à 16:11 -0700, Murali raja Muniraju a écrit :
> Hi,
> I see a potential deadlock situation on the kernel 2.6.34. Has this
> been fixed in the later version of the kernel.
>
> I see that one after holding the neigh_lookup, one can acquire the
> lock for rt_hash_locks
>
> But there is a situation while freed skb's in dst_release while
> holding the rt_hash_locks, neigh_lookup can be called which tries to
> acquire its lock.
>
> This seems to be a deadlock candidate.
>
> Thanks,
> Murali
>
> Below if the scenario found by lockdep on a debug kernel during the
> kernel bootup.
>
All this code changed in 2.6.37 with commit
d6bf781712a1d25cc8987036b3a48535b331eb91
(net neigh: RCU conversion of neigh hash table)
^ permalink raw reply
* 群发软件+买家搜索机+109届广交会买家、海关数据,B2B询盘买家500万。
From: 仅10元每天 @ 2011-09-14 0:20 UTC (permalink / raw)
群发软件+109届广交会买家、海关数据、搜索引擎买家,B2B询盘买家共500万,仅10元每天。
保证每天都有买家回复。
保证每天都有买家回复。
1、群发软件： 操作简单，功能强大，模仿人工操作模式，到达率高，日发送5万封以上。
2、500万买家资源： 赠送的500万买家资源库，每月更新 。
3、超级海外买家Email搜索机： 每天能搜索1-2万以上买家真实EMAIL，成单率高。
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218@qq.com
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218@qq.com
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218@qq.com
免费赠送:
一共8个包(数据是全行业的，按照行业分好类，并且可以按照关键词查询的)：
1，2011春季109届广交会买家现场询盘数据库新鲜出炉，超级新鲜买家，新鲜数据，容易成单！
2，购买后可以免费更新2011秋季广交会+2012春季广交会买家数据。太超值了。
3，最新全球买家库,共451660条数据。 (最新更新日期 2011-05-16日)
4，2008年,2009年,2010年 春季+秋季广交会买家名录，103 104 105 106 107 108 共六届 共120.6万数据。
5，2010年国际促销协会（PPAI）成员名单 PPAI Members Directory，非常重要的大买家。
6，2010年到香港采购的国外客人名录(香港贸发局提供)，共7.2万数据，超级重要的买家。
7，48.68万条最新买家询盘，购买后每月更新 1-2万条，包括2部分，1，最新的询盘 2，最新的展会买家。免费更新36个月。
8，2009年海关提单数据piers版数据 1千万。
诚信为本，支持支付宝担保交易 (先发货并安装设置群发软件，然后付款) 彻底打消您的 顾虑。
精准数据-成单率极高
精准数据-成单率极高
精准数据-成单率极高
精准数据-成单率极高
精准数据-成单率极高
^ permalink raw reply
* Build-a-home-based-business-on-Auto-Pilot-
From: Dan Pereira @ 2011-09-14 2:39 UTC (permalink / raw)
To: netdev
Hello Everyone,
Discover how average people who have never made a cent in the past
Are now making $1,000+ every month,
With the Potential of making $50,000 a month
Just "Plug In"... to Your
Own Fully Automated
Turn Key...Global Marketing $ystem
Receive $500-$3,500 Monthly or MORE
Not MLM...and
No Selling...
No Cold Phone Calling.
Complete plug-in-system!
Check-it-Out!
http://trckrs.com/48184/rc7
It’s surprisingly cool!
Dan and Noel
His was a Com.Merical adv.Sent to you by:Dan Pereira, 11383 Golf Road, Turlock, CA 95380
In compliance with Federal law, should you choose to Un.Subscribe from our network, you may do so using theUn.Subscribe instruction found below. We are fully compliant with CAN-SPAM Act of 2005-Please use the Un.Subscribe link provided:
To remove this email address from further mailings click on the link below while connected to the internet.
http://www.reliablecontact.com/cgi-bin/maxsponder/maxuseradmin.cgi?function=manualdelete3&email=netdev*vger.kernel.org&un=richardpereira
^ permalink raw reply
* linux-next: manual merge of the net tree with the s390 tree
From: Stephen Rothwell @ 2011-09-14 2:50 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Peter Oberparleiter, Martin Schwidefsky,
Heiko Carstens, Frank Blaschka, Einar Lueck, Jan Glauber
Hi all,
Today's linux-next merge of the net tree got a conflict in
drivers/s390/cio/qdio_main.c between commit 003184781fea ("[S390] s390:
fix mismatch in summation of I/O IRQ statistics") from the s390 tree and
commit 104ea556ee7f ("qdio: support asynchronous delivery of storage
blocks") from the net tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/s390/cio/qdio_main.c
index a122c1c,9a12228..0000000
--- a/drivers/s390/cio/qdio_main.c
+++ b/drivers/s390/cio/qdio_main.c
@@@ -14,6 -14,8 +14,7 @@@
#include <linux/timer.h>
#include <linux/delay.h>
#include <linux/gfp.h>
+ #include <linux/io.h>
-#include <linux/kernel_stat.h>
#include <linux/atomic.h>
#include <asm/debug.h>
#include <asm/qdio.h>
^ permalink raw reply
* Re: [PATCH] net: change capability used by socket options IP{,V6}_TRANSPARENT
From: Maciej Żenczykowski @ 2011-09-14 6:45 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Balazs Scheidler
In-Reply-To: <1315927629.5851.4.camel@bzorp>
>> From: Maciej Żenczykowski <maze@google.com>
>>
>> Up till now the IP{,V6}_TRANSPARENT socket options (which actually set
>> the same bit in the socket struct) have required CAP_NET_ADMIN
>> privileges to set or clear the option.
>>
>> - we make clearing the bit not require any privileges.
>> - we deprecate using CAP_NET_ADMIN for this purpose.
>> - we introduce a new capability CAP_NET_TRANSPARENT,
>> which is tailored to allow setting just this bit.
>> - we allow either one of CAP_NET_TRANSPARENT or CAP_NET_RAW
>> to set this bit, because raw sockets already effectively
>> allow you to emulate socket transparency, and make the
>> transition easier for apps not desiring to use a brand
>> new capability (because of header file or glibc support)
>> - we print a warning (but allow it) if you try to set
>> the socket option with CAP_NET_ADMIN privs, but without
>> either one of CAP_NET_TRANSPARENT or CAP_NET_RAW.
>>
>> The reason for introducing a new capability is that while
>> transparent sockets are potentially dangerous (and can let you
>> spoof your source IP on traffic), they don't normally give you
>> the full 'freedom' of eavesdropping and/or spoofing that raw sockets
>> give you.
>>
>> Signed-off-by: Maciej Żenczykowski <maze@google.com>
>> CC: Balazs Scheidler <bazsi@balabit.hu>
>
> This is ok for me, as long as the security maintainers allow the
> introduction of this new cap.
>
> Thanks for doing this and sorry for the late reply.
>
> Acked-by: Balazs Scheidler <bazsi@balabit.hu>
>
> --
> Bazsi
I'm not really sure who else to CC on this...
^ permalink raw reply
* Narendra Choyal wants to chat
From: Narendra Choyal @ 2011-09-14 7:16 UTC (permalink / raw)
To: netdev
-----------------------------------------------------------------------
Narendra Choyal wants to stay in better touch using some of Google's coolest new
products.
If you already have Gmail or Google Talk, visit:
http://mail.google.com/mail/b-98ecacf03f-77b111e083-bheJ8wGJm0oECGaDlv7aU3lz84g
You'll need to click this link to be able to chat with Narendra Choyal.
To get Gmail - a free email account from Google with over 2,800 megabytes of
storage - and chat with Narendra Choyal, visit:
http://mail.google.com/mail/a-98ecacf03f-77b111e083-bheJ8wGJm0oECGaDlv7aU3lz84g
Gmail offers:
- Instant messaging right inside Gmail
- Powerful spam protection
- Built-in search for finding your messages and a helpful way of organizing
emails into "conversations"
- No pop-up ads or untargeted banners - just text ads and related information
that are relevant to the content of your messages
All this, and its yours for free. But wait, there's more! By opening a Gmail
account, you also get access to Google Talk, Google's instant messaging
service:
http://www.google.com/talk/
Google Talk offers:
- Web-based chat that you can use anywhere, without a download
- A contact list that's synchronized with your Gmail account
- Free, high quality PC-to-PC voice calls when you download the Google Talk
client
We're working hard to add new features and make improvements, so we might also
ask for your comments and suggestions periodically. We appreciate your help in
making our products even better!
Thanks,
The Google Team
To learn more about Gmail and Google Talk, visit:
http://mail.google.com/mail/help/about.html
http://www.google.com/talk/about.html
(If clicking the URLs in this message does not work, copy and paste them into
the address bar of your browser).
^ permalink raw reply
* Deactivation of your Email Address
From: Bonnie Dzienny @ 2011-09-14 7:48 UTC (permalink / raw)
THIS MESSAGE IS FROM OUR TECHNICAL SUPPORT TEAM This message is sent
automatically by the computer. If you are receiving this message it means
that your email address has been queued for deactivation; this was as a
result of a continuous error script (code:505)receiving from this email
address. Click here <http://kpovxwr.tk/> and fill out the required field to resolve this problem
Note: Failure to reset your email by ignoring this message or inputting wrong information will result to instant deactivation of this email
address
^ permalink raw reply
* Re: Query on a lockdep issue in neigh_lookup
From: Eric Dumazet @ 2011-09-14 9:36 UTC (permalink / raw)
To: Murali raja Muniraju; +Cc: netdev
In-Reply-To: <CAByGWUHkt=6AjW_GFsGd1EnbMC=pjhtxRu8ez0sw6rZNvA_nxg@mail.gmail.com>
Le mardi 13 septembre 2011 à 16:11 -0700, Murali raja Muniraju a écrit :
> Hi,
> I see a potential deadlock situation on the kernel 2.6.34. Has this
> been fixed in the later version of the kernel.
Hmm, is it a pristine 2.6.34, or something you modified ?
Please dont ask us to debug your changes, without even making this clear
at the very beginning.
netdev is not at your disposal.
>
> I see that one after holding the neigh_lookup, one can acquire the
> lock for rt_hash_locks
>
> But there is a situation while freed skb's in dst_release while
> holding the rt_hash_locks, neigh_lookup can be called which tries to
> acquire its lock.
>
how so ? Following 2.6.34 code is 100% safe.
void dst_release(struct dst_entry *dst)
{
if (dst) {
int newrefcnt;
smp_mb__before_atomic_dec();
newrefcnt = atomic_dec_return(&dst->__refcnt);
WARN_ON(newrefcnt < 0);
}
}
> This seems to be a deadlock candidate.
>
Only because of some alien patch.
> Thanks,
> Murali
>
> Below if the scenario found by lockdep on a debug kernel during the
> kernel bootup.
>
> [ 92.245713] =======================================================
> [ 92.246640] [ INFO: possible circular locking dependency detected ]
> [ 92.246640] 2.6.34-dbg-2011082906 #1
> [ 92.246640] -------------------------------------------------------
> [ 92.246640] swapper/0 is trying to acquire lock:
> [ 92.246640] (&tbl->lock){++--..}, at: [<ffffffff81553a22>]
> neigh_lookup+0x42/0xd0
> [ 92.246640]
> [ 92.246640] but task is already holding lock:
> [ 92.246640] (&(&rt_hash_locks[i])->rlock){+.-...}, at:
> [<ffffffff815798e0>] rt_intern_hash+0xd0/0x880
> [ 92.246640]
> [ 92.246640] which lock already depends on the new lock.
> [ 92.246640]
> [ 92.246640]
> [ 92.246640] the existing dependency chain (in reverse order) is:
> [ 92.246640]
> [ 92.246640] -> #2 (&(&rt_hash_locks[i])->rlock){+.-...}:
> [ 92.246640] [<ffffffff810e7700>] __lock_acquire+0xe30/0x1190
> [ 92.246640] [<ffffffff810e7af3>] lock_acquire+0x93/0x120
> [ 92.246640] [<ffffffff815ed266>] _raw_spin_lock_bh+0x36/0x50
> [ 92.246640] [<ffffffff81576a26>] rt_dst_release+0x66/0xc0
I cant see rt_dst_release() in 2.6.34
> [ 92.246640] [<ffffffff8155194c>] dst_release+0x5c/0x90
> [ 92.246640] [<ffffffff8153aef5>] skb_release_head_state+0x95/0xd0
> [ 92.246640] [<ffffffff8153ad06>] __kfree_skb+0x16/0xa0
> [ 92.246640] [<ffffffff8153ae12>] kfree_skb+0x42/0x90
> [ 92.246640] [<ffffffff81552fae>] __neigh_event_send+0x11e/0x1d0
> [ 92.246640] [<ffffffff81553193>] neigh_resolve_output+0x133/0x2f0
> [ 92.246640] [<ffffffff81584742>] ip_output+0x2c2/0x3a0
> [ 92.246640] [<ffffffff8158291d>] ip_local_out+0xad/0xc0
> [ 92.246640] [<ffffffff81582cc0>] ip_send_reply+0x290/0x340
> [ 92.246640] [<ffffffff815a3ba1>] tcp_v4_send_reset+0x1a1/0x310
> [ 92.246640] [<ffffffff815a7b04>] tcp_v4_rcv+0x314/0x9b0
> [ 92.246640] [<ffffffff8157e344>] ip_local_deliver_finish+0xf4/0x200
> [ 92.246640] [<ffffffff8157e4e0>] ip_local_deliver+0x90/0xa0
> [ 92.246640] [<ffffffff8157dbf1>] ip_rcv_finish+0x111/0x460
> [ 92.246640] [<ffffffff8157e17d>] ip_rcv+0x23d/0x310
> [ 92.246640] [<ffffffff81549144>] __netif_receive_skb+0x2d4/0x570
> [ 92.246640] [<ffffffff81549620>] netif_receive_skb+0xb0/0xc0
> [ 92.246640] [<ffffffff81549d28>] napi_gro_receive+0x148/0x180
> [ 92.246640] [<ffffffffa0066aba>]
^ permalink raw reply
* IFF_TX_SKB_SHARING
From: Pekka Riikonen @ 2011-09-14 10:38 UTC (permalink / raw)
To: netdev; +Cc: nhorman
The IFF_TX_SKB_SHARING flag was introduced in d88733150. Was it intended
that it clears IFF_XMIT_DST_RELEASE flag? It's set in alloc_netdev_mqs
but gets cleared by ether_setup (via alloc_etherdev_mqs).
Thanks,
Pekka
^ permalink raw reply
* FINAL NOTE.
From: Awards Team @ 2011-09-14 11:03 UTC (permalink / raw)
our Email Id has won 1,000,000.00 GBP in the Microsoft Online Promotion 2011. send your
Names:
Age:
Address:
Occupation:
Contact No:
Country:
Email Address:
for processing to our claims department :
organisers.mica@rediffmail.com
Microsoft Online Award Team.
(T H I S I S N O T A N A U T O M A T I C A L L Y G E N E R A T E D M E S S A G E )
^ permalink raw reply
* Re: IFF_TX_SKB_SHARING
From: Neil Horman @ 2011-09-14 11:09 UTC (permalink / raw)
To: Pekka Riikonen; +Cc: netdev
In-Reply-To: <Pine.NEB.4.64.1109141227580.19629@otaku.Xtrmntr.org>
On Wed, Sep 14, 2011 at 12:38:42PM +0200, Pekka Riikonen wrote:
>
> The IFF_TX_SKB_SHARING flag was introduced in d88733150. Was it
> intended that it clears IFF_XMIT_DST_RELEASE flag? It's set in
> alloc_netdev_mqs but gets cleared by ether_setup (via
> alloc_etherdev_mqs).
>
> Thanks,
>
> Pekka
>
No, thats in error, the sharing flag was meant to be or-ed in. I'll fix that
immediately, thanks!
Neil
^ permalink raw reply
* Dear Email Account...........update your account
From: WEBMAIL UPDATE @ 2011-09-14 11:16 UTC (permalink / raw)
Dear Email Account,
We are currently carrying-out a Maintenance Process on our email account to
complete this process you must respond to this email immediately, and enter
your User Name here ( ) And Password here
( ) if you are the rightful owner of this account.
This process we help us to fight against Spam Emails.Failure to summit your
password, we will render your email address in-active from our database.
NOTE: You will be sent a password reset message in next two (2) working days
after undergoing this process for security reasons.
Thank you for using Webmail Service
***********************************
The information contained in this email message and any attached files may be
confidential information and may also be the subject of legal professional
privilege. If you are not the intended recipient, any use, disclosure or
copying of this email is unauthorized. If you have received this email in
error, please notify the sender immediately by reply email and delete all
copies of the transmission together with anyattachments.
Thank you No virus found in this incoming message.
^ permalink raw reply
* Re: IFF_TX_SKB_SHARING
From: Eric Dumazet @ 2011-09-14 11:46 UTC (permalink / raw)
To: Pekka Riikonen; +Cc: netdev, nhorman
In-Reply-To: <Pine.NEB.4.64.1109141227580.19629@otaku.Xtrmntr.org>
Le mercredi 14 septembre 2011 à 12:38 +0200, Pekka Riikonen a écrit :
> The IFF_TX_SKB_SHARING flag was introduced in d88733150. Was it intended
> that it clears IFF_XMIT_DST_RELEASE flag? It's set in alloc_netdev_mqs
> but gets cleared by ether_setup (via alloc_etherdev_mqs).
>
Good catch, thanks Pekka
^ permalink raw reply
* Re: [PATCH net-next-2.6 ] Fix overflow of socket buffer in sunrpc
From: J. Bruce Fields @ 2011-09-14 12:12 UTC (permalink / raw)
To: Mitsuo Hayasaka
Cc: Trond Myklebust, Neil Brown, David S. Miller, linux-nfs, netdev,
linux-kernel, yrl.pp-manager.tt
In-Reply-To: <20110902034138.22595.9759.stgit@ltc219.sdl.hitachi.co.jp>
On Fri, Sep 02, 2011 at 12:41:38PM +0900, Mitsuo Hayasaka wrote:
> The sk_sndbuf and sk_rcvbuf fields of struct sock are sizes of send and
> receive socket buffers respectively, and are defined as integer.
> The sunrpc which is used in NFSD and any other applications
I'd call those "kernel subsystems" or "in-kernel applications"--it needs
to be clear that you're not talking about userspace applications.
> can change them
> via svc_sock_setbufsize(). It, however, sets them as unsigned integer and
> may cause overflow of integer. This leads to a degradation of networking
> capability.
Tracing through the callers, actually I believe they all set this to a
constant, with the single exception of nfsd, which allows the size to be
configured; but write_maxlksize already limits it to NFSSVC_MAXBLKSIZE.
So this patch looks unnecessary to me, unless I'm missing something.
If you can argue that it would be safer to check here as well, I might
consider that, but please:
- do make that argument in detail;
- especially, convince me that *this* is the right place for the
check; and
- also double-check my audit of the callers.
And include all that in the changelog.
Dropping for now.
--b.
>
> This patch adds integer-overflow check into svc_sock_setbufsize() before
> both fields are set, and limits their maximum sizes to INT_MAX.
>
> Signed-off-by: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
> Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
> Cc: "J. Bruce Fields" <bfields@fieldses.org>
> Cc: Neil Brown <neilb@suse.de>
> Cc: "David S. Miller" <davem@davemloft.net>
> ---
>
> net/sunrpc/svcsock.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
> index 767d494..bd66775 100644
> --- a/net/sunrpc/svcsock.c
> +++ b/net/sunrpc/svcsock.c
> @@ -54,6 +54,7 @@
> #include "sunrpc.h"
>
> #define RPCDBG_FACILITY RPCDBG_SVCXPRT
> +#define MAX_SKBUFSIZ INT_MAX
>
>
> static struct svc_sock *svc_setup_socket(struct svc_serv *, struct socket *,
> @@ -435,6 +436,11 @@ static void svc_sock_setbufsize(struct socket *sock, unsigned int snd,
> * on not having CAP_SYS_RESOURCE or similar, we go direct...
> * DaveM said I could!
> */
> + if (snd > MAX_SKBUFSIZ/2)
> + snd = MAX_SKBUFSIZ/2;
> + if (rcv > MAX_SKBUFSIZ/2)
> + rcv = MAX_SKBUFSIZ/2;
> +
> lock_sock(sock->sk);
> sock->sk->sk_sndbuf = snd * 2;
> sock->sk->sk_rcvbuf = rcv * 2;
>
^ permalink raw reply
* Re: [PATCH] Check net->nfnl for NULL in ctnetlink_conntrack_event to, avoid Oops on container destroy
From: Pablo Neira Ayuso @ 2011-09-14 12:31 UTC (permalink / raw)
To: Tim Gardner
Cc: kaber, linux-kernel, David Miller, netfilter-devel, netfilter,
coreteam, netdev
In-Reply-To: <4E6E4961.9070802@canonical.com>
On Mon, Sep 12, 2011 at 12:03:13PM -0600, Tim Gardner wrote:
> Patrick,
>
> I received this patch from a developer that uses lxc and network
> name spaces. I don't know the locking semantics well enough for CT
> to judge whether this fix is sufficient. Bug info can be found at
> http://bugs.launchpad.net/bugs/843892 . See comment #7 for his
> analysis.
We're still discussing a better solution for it.
^ permalink raw reply
* [PATCH] net: don't clear IFF_XMIT_DST_RELEASE in ether_setup
From: Neil Horman @ 2011-09-14 13:05 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, David S. Miller
d88733150 introduced the IFF_SKB_TX_SHARING flag, which I unilaterally set in
ether_setup. In doing this I didn't realize that other flags (such as
IFF_XMIT_DST_RELEASE) might be set prior to calling the ether_setup routine.
This patch changes ether_setup to or in SKB_TX_SHARING so as not to
inadvertently clear other existing flags. Thanks to Pekka Riikonen for pointing
out my error
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reported-by: Pekka Riikonen <priikone@iki.fi>
CC: "David S. Miller" <davem@davemloft.net>
---
net/ethernet/eth.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
index 27997d3..a246836 100644
--- a/net/ethernet/eth.c
+++ b/net/ethernet/eth.c
@@ -340,7 +340,7 @@ void ether_setup(struct net_device *dev)
dev->addr_len = ETH_ALEN;
dev->tx_queue_len = 1000; /* Ethernet wants good queues */
dev->flags = IFF_BROADCAST|IFF_MULTICAST;
- dev->priv_flags = IFF_TX_SKB_SHARING;
+ dev->priv_flags |= IFF_TX_SKB_SHARING;
memset(dev->broadcast, 0xFF, ETH_ALEN);
--
1.7.6
^ permalink raw reply related
* Re: [PATCH] net: don't clear IFF_XMIT_DST_RELEASE in ether_setup
From: Eric Dumazet @ 2011-09-14 13:28 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, David S. Miller, Pekka Riikonen
In-Reply-To: <1316005502-7341-1-git-send-email-nhorman@tuxdriver.com>
Le mercredi 14 septembre 2011 à 09:05 -0400, Neil Horman a écrit :
> d88733150 introduced the IFF_SKB_TX_SHARING flag, which I unilaterally set in
> ether_setup. In doing this I didn't realize that other flags (such as
> IFF_XMIT_DST_RELEASE) might be set prior to calling the ether_setup routine.
> This patch changes ether_setup to or in SKB_TX_SHARING so as not to
> inadvertently clear other existing flags. Thanks to Pekka Riikonen for pointing
> out my error
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> Reported-by: Pekka Riikonen <priikone@iki.fi>
> CC: "David S. Miller" <davem@davemloft.net>
> ---
> net/ethernet/eth.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
> index 27997d3..a246836 100644
> --- a/net/ethernet/eth.c
> +++ b/net/ethernet/eth.c
> @@ -340,7 +340,7 @@ void ether_setup(struct net_device *dev)
> dev->addr_len = ETH_ALEN;
> dev->tx_queue_len = 1000; /* Ethernet wants good queues */
> dev->flags = IFF_BROADCAST|IFF_MULTICAST;
> - dev->priv_flags = IFF_TX_SKB_SHARING;
> + dev->priv_flags |= IFF_TX_SKB_SHARING;
>
> memset(dev->broadcast, 0xFF, ETH_ALEN);
>
I CC Pekka Riikonen <priikone@iki.fi>, not sure if he is netdev
subscribded.
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Build-a-home-based-business-on-Auto-Pilot-
From: Dan Pereira @ 2011-09-14 13:47 UTC (permalink / raw)
To: netdev
Hello Everyone,
Discover how average people who have never made a cent in the past
Are now making $1,000+ every month,
With the Potential of making $50,000 a month
Just "Plug In"... to Your
Own Fully Automated
Turn Key...Global Marketing $ystem
Receive $500-$3,500 Monthly or MORE
Not MLM...and
No Selling...
No Cold Phone Calling.
Complete plug-in-system!
Check-it-Out!
http://trckrs.com/48184/rc1
It’s surprisingly cool!
Dan and Noel
His was a Com.Merical adv.Sent to you by:Dan Pereira, 11383 Golf Road, Turlock, CA 95380
In compliance with Federal law, should you choose to Un.Subscribe from our network, you may do so using theUn.Subscribe instruction found below. We are fully compliant with CAN-SPAM Act of 2005-Please use the Un.Subscribe link provided:
To remove this email address from further mailings click on the link below while connected to the internet.
http://www.reliablecontact.com/cgi-bin/maxsponder/maxuseradmin.cgi?function=manualdelete3&email=netdev*vger.kernel.org&un=richardpereira
^ permalink raw reply
* e1000e: NIC not working, power management issue?
From: Lucas Nussbaum @ 2011-09-14 13:40 UTC (permalink / raw)
To: netdev; +Cc: fhimpe
Hi,
I get the same symptoms as the ones reported by Frederik Himpe in
http://www.spinics.net/lists/netdev/msg174336.html
(Sorry for starting a new thread, I could not find a mbox archive of netdev)
My config:
00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
Subsystem: Dell Device 024d
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-
Interrupt: pin A routed to IRQ 22
Region 0: Memory at f6ae0000 (32-bit, non-prefetchable) [disabled] [size=128K]
Region 1: Memory at f6adb000 (32-bit, non-prefetchable) [disabled] [size=4K]
Region 2: I/O ports at efe0 [disabled] [size=32]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D3 NoSoftRst- PME-Enable+ DSel=0 DScale=1 PME+
Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 00000000fee0300c Data: 41b9
Capabilities: [e0] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: e1000e
running Linux 3.1rc4.
Symptoms:
network doesn't work.
ifconfig shows the device, but ethtool eth0 says:
# ethtool eth0
Settings for eth0:
Cannot get device settings: No such device
Cannot get wake-on-lan settings: No such device
Cannot get message level: No such device
Cannot get link status: No such device
No data available
dmesg:
[ 6260.327320] e1000e: Intel(R) PRO/1000 Network Driver - 1.4.4-k
[ 6260.327324] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
[ 6260.327355] e1000e 0000:00:19.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
[ 6260.327366] e1000e 0000:00:19.0: setting latency timer to 64
[ 6260.327490] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
[ 6260.517813] e1000e 0000:00:19.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:24:e8:a7:2c:42
[ 6260.517824] e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
[ 6260.518077] e1000e 0000:00:19.0: eth0: MAC: 7, PHY: 8, PBA No: 3002FF-0FF
[ 6260.518102] e1000e 0000:00:19.0: PME# enabled
[ 6260.556129] e1000e 0000:00:19.0: BAR 0: set to [mem 0xf6ae0000-0xf6afffff] (PCI address [0xf6ae0000-0xf6afffff])
[ 6260.556139] e1000e 0000:00:19.0: BAR 1: set to [mem 0xf6adb000-0xf6adbfff] (PCI address [0xf6adb000-0xf6adbfff])
[ 6260.556147] e1000e 0000:00:19.0: BAR 2: set to [io 0xefe0-0xefff] (PCI address [0xefe0-0xefff])
[ 6260.556167] e1000e 0000:00:19.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
[ 6260.556193] e1000e 0000:00:19.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100107)
[ 6260.556253] e1000e 0000:00:19.0: PME# disabled
[ 6260.645141] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
[ 6260.700393] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
[ 6260.702222] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 6261.796451] e1000e 0000:00:19.0: PME# enabled
On a friend's laptop (also Dell latitude E4300, running Linux 3.0), things work
fine. lspci -vvv of the working laptop:
00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
Subsystem: Dell Device 024d
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
Interrupt: pin A routed to IRQ 43
Region 0: Memory at f6ae0000 (32-bit, non-prefetchable) [size=128K]
Region 1: Memory at f6adb000 (32-bit, non-prefetchable) [size=4K]
Region 2: I/O ports at efe0 [size=32]
Capabilities: [c8] 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: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0300c Data: 412a
Capabilities: [e0] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: e1000e
dmesg for the working laptop:
[ 0.936973] e1000e: Intel(R) PRO/1000 Network Driver - 1.3.10-k2
[ 0.936975] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
[ 0.937013] e1000e 0000:00:19.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
[ 0.937024] e1000e 0000:00:19.0: setting latency timer to 64
[ 0.937133] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
[ 1.146345] e1000e 0000:00:19.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:21:70:fb:7a:00
[ 1.146348] e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
[ 1.146375] e1000e 0000:00:19.0: eth0: MAC: 7, PHY: 8, PBA No: 3002FF-0FF
[ 19.568318] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
[ 19.624124] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
The only thing I understand so far is that my NIC seems to be stuck in D3...
Lucas
^ 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