* Socket send-buffer auto-sizing
From: Ben Greear @ 2012-06-07 17:59 UTC (permalink / raw)
To: netdev
I'm continuing to test one-way tcp streams in 3.5.0-rc1 on
a wifi network.
When I do not specify a send buffer size, and thus use the kernel
defaults, max speed is about 77Mbps.
When I specify 512KB send-buffer, I get speeds up to 185Mbps.
When set to 1MB, I get about 198Mbps (and setting higher does not
increase the throughput after this).
This is without any 'delack' patches applied.
My question is: Should the kernel auto-tuner work better?
I seem to recall a comments from some years ago that applications
should no longer attempt to tune send/recv buffers because the kernel
was smart enough to get it at least mostly right.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH (net.git) V2] stmmac: fix driver built w/ w/o both pci and platf modules
From: David Miller @ 2012-06-07 18:01 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev, wfg
In-Reply-To: <1339073322-23093-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Thu, 7 Jun 2012 14:48:42 +0200
> + pr_err("stmmac: do not register the PCI driver\n");
This is inappropriate, since this is called unconditionally.
^ permalink raw reply
* Re: tcp wifi upload performance and lots of ACKs
From: David Miller @ 2012-06-07 18:10 UTC (permalink / raw)
To: rick.jones2; +Cc: David.Laight, greearb, dbaluta, netdev
In-Reply-To: <4FD0EA18.3090606@hp.com>
From: Rick Jones <rick.jones2@hp.com>
Date: Thu, 07 Jun 2012 10:51:20 -0700
> This may not work well when the sender has a congestion window growth
> heuristic different from what the ACK avoidance heuristic assumes. If
> I recall correctly, the heuristic in HP-UX assumes the sender grows
> cwnd by the number of bytes/segments ACKnowledged.
Linux violates this assumption.
^ permalink raw reply
* [PATCH] fix kernel crash in the macvlan driver
From: Ani Sinha @ 2012-06-07 18:45 UTC (permalink / raw)
To: netdev; +Cc: Eric Biederman, Francesco Ruggeri
Hello folks :
We noticed a consistently reproducable kernel crash in the macvlan driver
when we were running our test script. I believe I have found the reason
for the crash and a patch that fixes it. I am attaching the patch for your
comments and opinions.
Cheers,
Ani
commit cd28ce3cb624ddaaf97935c1f34d44bb13ffb786
Author: Anirban Sinha <ani@aristanetworks.com>
Date: Thu Jun 7 11:21:02 2012 -0700
macvlan : The patch d5cd92448fded12c91f7574e49747c5f7d975a8d introduced reference
counting for macvlan_port. This patch fixes an issue where the reference
counts were being decremented incorrectly from macvlan_uninit() and not from
macvlan_dellink(). This was causing the kernel crash shown below :
BUG: unable to handle kernel paging request at 0000000100000000
IP: [<ffffffffa031f8e5>] macvlan_addr_busy+0x58/0x8d [macvlan]
PGD 3a2aa067 PUD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT1/energy_full
CPU 0
Modules linked in: macvlan rfcomm sco bnep l2cap sunrpc ipt_REJECT iptable_filter ip6t_REJECT xt_tcpudp
Pid: 2490, comm: ip Not tainted 2.6.38.8-705892.2012aniArora.7.fc14.x86_64 #1
RIP: 0010:[<ffffffffa031f8e5>] [<ffffffffa031f8e5>] macvlan_addr_busy+0x58/0x8d [macvlan]
RSP: 0018:ffff880037d2b698 EFLAGS: 00010296
RAX: 0000000100000000 RBX: ffff88003bf54000 RCX: 0000000000000000
RDX: 0000111111111102 RSI: 0000000000000092 RDI: 0000000000000246
RBP: ffff880037d2b6a8 R08: 0000000000000040 R09: ffffffff81a73f18
R10: ffffffff81e03a20 R11: 0000000000000020 R12: ffff88003c8e33d0
R13: ffff880037ecd000 R14: 00000000fffffff0 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffff88003e200000(0063) knlGS:00000000f75d26c0
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 0000000100000000 CR3: 00000000377e7000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process ip (pid: 2490, threadinfo ffff880037d2a000, task ffff88003d1206c0)
Stack:
ffff88003d031000 ffff88003d031680 ffff880037d2b6d8 ffffffffa031fbcc
ffff88003d031000 ffffffffa03211c0 ffff88003d031078 0000000000000000
ffff880037d2b708 ffffffff81345cf7 ffff88003d031000 0000000000001003
Call Trace:
[<ffffffffa031fbcc>] macvlan_open+0x7e/0x116 [macvlan]
[<ffffffff81345cf7>] __dev_open+0x90/0xc7
[<ffffffff81345f26>] __dev_change_flags+0xa8/0x12c
[<ffffffff81346021>] dev_change_flags+0x1c/0x52
[<ffffffff8134fce1>] do_setlink+0x2b4/0x67d
[<ffffffff813bc85f>] ? inet6_fill_link_af+0x1a/0x22
[<ffffffff8134f6bf>] ? rtnl_fill_ifinfo+0x99f/0xa7d
[<ffffffff81350d02>] rtnl_newlink+0x247/0x40d
[<ffffffff81350b7a>] ? rtnl_newlink+0xbf/0x40d
[<ffffffff81337ced>] ? sock_rmalloc+0x2e/0x90
[<ffffffff810dc46c>] ? arch_local_irq_save+0x16/0x1c
[<ffffffff810685fe>] ? arch_local_irq_save+0x18/0x1e
[<ffffffff813508dc>] rtnetlink_rcv_msg+0x1e6/0x1fc
[<ffffffff810af70a>] ? get_page_from_freelist+0x4dd/0x68d
[<ffffffff813506f6>] ? rtnetlink_rcv_msg+0x0/0x1fc
[<ffffffff81364239>] netlink_rcv_skb+0x40/0x8b
[<ffffffff813502c7>] rtnetlink_rcv+0x21/0x28
[<ffffffff81363d27>] netlink_unicast+0xec/0x155
[<ffffffff81364041>] netlink_sendmsg+0x2b1/0x2cf
[<ffffffff81332ec2>] ? __sock_recvmsg+0x75/0x84
[<ffffffff81332d70>] __sock_sendmsg+0x66/0x72
[<ffffffff81333521>] sock_sendmsg+0xa3/0xbc
[<ffffffff810b25da>] ? lru_cache_add_lru+0x3c/0x3e
[<ffffffff810cc1e3>] ? page_add_new_anon_rmap+0x5b/0x6d
[<ffffffff810c17cb>] ? set_pte_at+0x9/0xd
[<ffffffff810c2f31>] ? do_wp_page+0x496/0x541
[<ffffffff81333ec0>] ? move_addr_to_kernel+0x44/0x49
[<ffffffff813585a4>] ? verify_compat_iovec+0x6d/0xb9
[<ffffffff81334cac>] sys_sendmsg+0x230/0x2ae
[<ffffffff810c1965>] ? pmd_offset+0x14/0x3b
[<ffffffff810c4c0a>] ? handle_mm_fault+0x13a/0x14f
[<ffffffff81334756>] ? sys_sendto+0x13f/0x16c
[<ffffffff81334d76>] ? sys_recvmsg+0x4c/0x5b
[<ffffffff81358deb>] compat_sys_sendmsg+0xf/0x11
[<ffffffff81359005>] compat_sys_socketcall+0x14f/0x186
[<ffffffff8102c2b0>] sysenter_dispatch+0x7/0x2e
Code: 0e e1 48 8b 03 4c 89 e2 48 c7 c7 6c 10 32 a0 48 8b b0 80 02 00 00 31 c0 e8 f1 17 0e e1 48 8b 03 49 8b 14 24 48 8b 80 80 02 00 00 <48> 33 10 b8 01 00 00 00 48 c1 e2 10 74 22 48 c7 c7 93 10 32 a0
Signed-off-by: Anirban Sinha <ani@aristanetworks.com>
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 66a9bfe..d880bc8 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -481,7 +481,6 @@ static void macvlan_uninit(struct net_device *dev)
free_percpu(vlan->pcpu_stats);
- port->count -= 1;
if (!port->count)
macvlan_port_destroy(port->dev);
}
@@ -795,7 +794,9 @@ static int macvlan_newlink(struct net *src_net, struct net_device *dev,
void macvlan_dellink(struct net_device *dev, struct list_head *head)
{
struct macvlan_dev *vlan = netdev_priv(dev);
+ struct macvlan_port *port = vlan->port;
+ port->count -= 1;
list_del(&vlan->list);
unregister_netdevice_queue(dev, head);
}
^ permalink raw reply related
* Re: pull request: can-next 2012-06-07
From: David Miller @ 2012-06-07 19:02 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can
In-Reply-To: <4FD062D3.5010107@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Thu, 07 Jun 2012 10:14:11 +0200
> here two patches for net-next, by AnilKumar Ch, they add support for
> Bosch's d_can hardware to the existing c_can driver.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH] fix kernel crash in the macvlan driver
From: Eric W. Biederman @ 2012-06-07 19:49 UTC (permalink / raw)
To: Ani Sinha; +Cc: netdev, Francesco Ruggeri
In-Reply-To: <alpine.OSX.2.00.1206071137360.86561@animac.local>
Ani Sinha <ani@aristanetworks.com> writes:
> Hello folks :
>
> We noticed a consistently reproducable kernel crash in the macvlan driver
> when we were running our test script. I believe I have found the reason
> for the crash and a patch that fixes it. I am attaching the patch for your
> comments and opinions.
I don't completely follow the logic of your change. Crashing in
macvlan_addr_busy does seem to indicate you are using a corrupted data
structure.
My compiled version of macvlan_addr_busy is much smaller than yours so I
can't guess based on your disassembly what is wrong. But by reading the
code it must either be port->dev->dev_addr or the rcu
macvlan_hash_lookup.
Regardless all I see your patch doing is moving the decrement of
port->count earlier and possibly allowing newlink in
MACVLAN_MODE_PASSTHRU to succeed a smidge earlier.
I might just be dense today but I can't possibly see how moving that
decrement would solve the crash you have reported below.
Eric
> commit cd28ce3cb624ddaaf97935c1f34d44bb13ffb786
> Author: Anirban Sinha <ani@aristanetworks.com>
> Date: Thu Jun 7 11:21:02 2012 -0700
>
> macvlan : The patch d5cd92448fded12c91f7574e49747c5f7d975a8d introduced reference
> counting for macvlan_port. This patch fixes an issue where the reference
> counts were being decremented incorrectly from macvlan_uninit() and not from
> macvlan_dellink(). This was causing the kernel crash shown below :
>
> BUG: unable to handle kernel paging request at 0000000100000000
> IP: [<ffffffffa031f8e5>] macvlan_addr_busy+0x58/0x8d [macvlan]
> PGD 3a2aa067 PUD 0
> Oops: 0000 [#1] SMP
> last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT1/energy_full
> CPU 0
> Modules linked in: macvlan rfcomm sco bnep l2cap sunrpc ipt_REJECT iptable_filter ip6t_REJECT xt_tcpudp
>
> Pid: 2490, comm: ip Not tainted 2.6.38.8-705892.2012aniArora.7.fc14.x86_64 #1
> RIP: 0010:[<ffffffffa031f8e5>] [<ffffffffa031f8e5>] macvlan_addr_busy+0x58/0x8d [macvlan]
> RSP: 0018:ffff880037d2b698 EFLAGS: 00010296
> RAX: 0000000100000000 RBX: ffff88003bf54000 RCX: 0000000000000000
> RDX: 0000111111111102 RSI: 0000000000000092 RDI: 0000000000000246
> RBP: ffff880037d2b6a8 R08: 0000000000000040 R09: ffffffff81a73f18
> R10: ffffffff81e03a20 R11: 0000000000000020 R12: ffff88003c8e33d0
> R13: ffff880037ecd000 R14: 00000000fffffff0 R15: 0000000000000001
> FS: 0000000000000000(0000) GS:ffff88003e200000(0063) knlGS:00000000f75d26c0
> CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
> CR2: 0000000100000000 CR3: 00000000377e7000 CR4: 00000000000006f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process ip (pid: 2490, threadinfo ffff880037d2a000, task ffff88003d1206c0)
> Stack:
> ffff88003d031000 ffff88003d031680 ffff880037d2b6d8 ffffffffa031fbcc
> ffff88003d031000 ffffffffa03211c0 ffff88003d031078 0000000000000000
> ffff880037d2b708 ffffffff81345cf7 ffff88003d031000 0000000000001003
> Call Trace:
> [<ffffffffa031fbcc>] macvlan_open+0x7e/0x116 [macvlan]
> [<ffffffff81345cf7>] __dev_open+0x90/0xc7
> [<ffffffff81345f26>] __dev_change_flags+0xa8/0x12c
> [<ffffffff81346021>] dev_change_flags+0x1c/0x52
> [<ffffffff8134fce1>] do_setlink+0x2b4/0x67d
> [<ffffffff813bc85f>] ? inet6_fill_link_af+0x1a/0x22
> [<ffffffff8134f6bf>] ? rtnl_fill_ifinfo+0x99f/0xa7d
> [<ffffffff81350d02>] rtnl_newlink+0x247/0x40d
> [<ffffffff81350b7a>] ? rtnl_newlink+0xbf/0x40d
> [<ffffffff81337ced>] ? sock_rmalloc+0x2e/0x90
> [<ffffffff810dc46c>] ? arch_local_irq_save+0x16/0x1c
> [<ffffffff810685fe>] ? arch_local_irq_save+0x18/0x1e
> [<ffffffff813508dc>] rtnetlink_rcv_msg+0x1e6/0x1fc
> [<ffffffff810af70a>] ? get_page_from_freelist+0x4dd/0x68d
> [<ffffffff813506f6>] ? rtnetlink_rcv_msg+0x0/0x1fc
> [<ffffffff81364239>] netlink_rcv_skb+0x40/0x8b
> [<ffffffff813502c7>] rtnetlink_rcv+0x21/0x28
> [<ffffffff81363d27>] netlink_unicast+0xec/0x155
> [<ffffffff81364041>] netlink_sendmsg+0x2b1/0x2cf
> [<ffffffff81332ec2>] ? __sock_recvmsg+0x75/0x84
> [<ffffffff81332d70>] __sock_sendmsg+0x66/0x72
> [<ffffffff81333521>] sock_sendmsg+0xa3/0xbc
> [<ffffffff810b25da>] ? lru_cache_add_lru+0x3c/0x3e
> [<ffffffff810cc1e3>] ? page_add_new_anon_rmap+0x5b/0x6d
> [<ffffffff810c17cb>] ? set_pte_at+0x9/0xd
> [<ffffffff810c2f31>] ? do_wp_page+0x496/0x541
> [<ffffffff81333ec0>] ? move_addr_to_kernel+0x44/0x49
> [<ffffffff813585a4>] ? verify_compat_iovec+0x6d/0xb9
> [<ffffffff81334cac>] sys_sendmsg+0x230/0x2ae
> [<ffffffff810c1965>] ? pmd_offset+0x14/0x3b
> [<ffffffff810c4c0a>] ? handle_mm_fault+0x13a/0x14f
> [<ffffffff81334756>] ? sys_sendto+0x13f/0x16c
> [<ffffffff81334d76>] ? sys_recvmsg+0x4c/0x5b
> [<ffffffff81358deb>] compat_sys_sendmsg+0xf/0x11
> [<ffffffff81359005>] compat_sys_socketcall+0x14f/0x186
> [<ffffffff8102c2b0>] sysenter_dispatch+0x7/0x2e
> Code: 0e e1 48 8b 03 4c 89 e2 48 c7 c7 6c 10 32 a0 48 8b b0 80 02 00 00 31 c0 e8 f1 17 0e e1 48 8b 03 49 8b 14 24 48 8b 80 80 02 00 00 <48> 33 10 b8 01 00 00 00 48 c1 e2 10 74 22 48 c7 c7 93 10 32 a0
>
> Signed-off-by: Anirban Sinha <ani@aristanetworks.com>
>
> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
> index 66a9bfe..d880bc8 100644
> --- a/drivers/net/macvlan.c
> +++ b/drivers/net/macvlan.c
> @@ -481,7 +481,6 @@ static void macvlan_uninit(struct net_device *dev)
>
> free_percpu(vlan->pcpu_stats);
>
> - port->count -= 1;
> if (!port->count)
> macvlan_port_destroy(port->dev);
> }
> @@ -795,7 +794,9 @@ static int macvlan_newlink(struct net *src_net, struct net_device *dev,
> void macvlan_dellink(struct net_device *dev, struct list_head *head)
> {
> struct macvlan_dev *vlan = netdev_priv(dev);
> + struct macvlan_port *port = vlan->port;
>
> + port->count -= 1;
> list_del(&vlan->list);
> unregister_netdevice_queue(dev, head);
> }
^ permalink raw reply
* Re: [PATCH] net: l2tp_eth: fix kernel panic on rmmod l2tp_eth
From: David Miller @ 2012-06-07 20:02 UTC (permalink / raw)
To: eric.dumazet; +Cc: denys, netdev, jchapman
In-Reply-To: <1339063640.26966.113.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 07 Jun 2012 12:07:20 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> We must prevent module unloading if some devices are still attached to
> l2tp_eth driver.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Denys Fedoryshchenko <denys@visp.net.lb>
> Tested-by: Denys Fedoryshchenko <denys@visp.net.lb>
Applied.
^ permalink raw reply
* Re: [PATCH] net: neighbour: fix neigh_dump_info()
From: David Miller @ 2012-06-07 20:03 UTC (permalink / raw)
To: eric.dumazet; +Cc: denys, netdev, shemminger
In-Reply-To: <1339081115.5083.21.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 07 Jun 2012 16:58:35 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Denys found out "ip neigh" output was truncated to
> about 54 neighbours.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Denys Fedoryshchenko <denys@visp.net.lb>
Applied.
^ permalink raw reply
* Re: [PATCH] ipv6: fib: Restore NTF_ROUTER exception in fib6_age()
From: David Miller @ 2012-06-07 20:03 UTC (permalink / raw)
To: tgraf; +Cc: netdev
In-Reply-To: <6e43964ac82665f0257ac4f53c17b3b3403edcc3.1339087863.git.tgraf@suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Thu, 7 Jun 2012 18:51:04 +0200
> Commit 5339ab8b1dd82 (ipv6: fib: Convert fib6_age() to
> dst_neigh_lookup().) seems to have mistakenly inverted the
> exception for cached NTF_ROUTER routes.
>
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
Thanks for fixing this, applied.
^ permalink raw reply
* Re: [V2 RFC net-next PATCH 2/2] virtio_net: export more statistics through ethtool
From: David Miller @ 2012-06-07 20:05 UTC (permalink / raw)
To: bhutchings; +Cc: mst, netdev, linux-kernel, virtualization
In-Reply-To: <1339089306.2770.10.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 7 Jun 2012 18:15:06 +0100
> I would really like to see some sort of convention for presenting
> per-queue statistics through ethtool. At the moment we have a complete
> mess of different formats:
Indeed. Probably ${QUEUE_TYPE}-${INDEX}-${STATISTIC} is best.
With an agreed upon list of queue types such as "rx", "tx", "rxtx"
etc.
^ permalink raw reply
* Re: [PATCH] sky2: fix checksum bit management on some chips
From: David Miller @ 2012-06-07 20:07 UTC (permalink / raw)
To: shemminger; +Cc: kirr, mlindner, netdev
In-Reply-To: <20120606130130.5a86f94a@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 6 Jun 2012 13:01:30 -0700
> The newer flavors of Yukon II use a different method for receive
> checksum offload. This is indicated in the driver by the SKY2_HW_NEW_LE
> flag. On these newer chips, the BMU_ENA_RX_CHKSUM should not be set.
>
> The driver would get incorrectly toggle the bit, enabling the old
> checksum logic on these chips and cause a BUG_ON() assertion. If
> receive checksum was toggled via ethtool.
>
> Reported-by: Kirill Smelkov <kirr@mns.spb.ru>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied and queued up for -stable.
> Patch against net-next, please apply to net and stable kernels.
Stephen, please don't do this, generate your patches always
against the correct tree even if they are likely to still
apply when generated against the wrong tree.
^ permalink raw reply
* Re: [PATCH] ieee802154: verify packet size before trying to allocate it
From: David Miller @ 2012-06-07 20:10 UTC (permalink / raw)
To: levinsasha928
Cc: dbaryshkov, slapin, linux-zigbee-devel, netdev, linux-kernel
In-Reply-To: <1339018322-19360-1-git-send-email-levinsasha928@gmail.com>
From: Sasha Levin <levinsasha928@gmail.com>
Date: Wed, 6 Jun 2012 23:32:02 +0200
> Currently when sending data over datagram, the send function will attempt to
> allocate any size passed on from the userspace.
>
> We should make sure that this size is checked and limited. The maximum size
> of an IP packet seemed like the safest limit here.
>
> Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
This limit is arbitrary, I'm not applying a patch like this.
Use the actual limit, which is either the protocol limit or something
like the device mtu.
^ permalink raw reply
* Re: Remove out of date message in appletalk printk
From: David Miller @ 2012-06-07 20:12 UTC (permalink / raw)
To: davej; +Cc: netdev, acme
In-Reply-To: <20120606184559.GA27763@redhat.com>
From: Dave Jones <davej@redhat.com>
Date: Wed, 6 Jun 2012 14:45:59 -0400
> I accidentally triggered this printk, which amused me for a few moments.
> Given we're post 2.2, we could just -EACCES, but does anyone even care about Appletalk now ?
> I figure it's better to leave sleeping dogs lie, and just update the message.
>
> Signed-off-by: Dave Jones <davej@redhat.com>
Applied, but I made a few refinements. I made it use pr_warn() and
also prefixed the message with "atalk_connect: " so if someone sees
this it's easier to figure out where it's coming from.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: stmmac: Fix clock en-/disable calls
From: David Miller @ 2012-06-07 20:13 UTC (permalink / raw)
To: sr; +Cc: netdev, viresh.linux, peppe.cavallaro
In-Reply-To: <1338965351-6286-1-git-send-email-sr@denx.de>
From: Stefan Roese <sr@denx.de>
Date: Wed, 6 Jun 2012 08:49:11 +0200
> Signed-off-by: Stefan Roese <sr@denx.de>
This means nothing to me.
What is fixed by using the prepare/unprepare variants vs. the
plain ones?
It is absolutely inappropriate to not describe your change
completely in your commit message.
This patch is being rejected.
^ permalink raw reply
* Re: [patch] net/ethernet: ks8851_mll unregister_netdev() before freeing
From: David Miller @ 2012-06-07 20:15 UTC (permalink / raw)
To: dan.carpenter; +Cc: raffaele.recalcati, netdev, kernel-janitors
In-Reply-To: <20120606063129.GA26829@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 6 Jun 2012 09:31:29 +0300
> We added another error condition here, but if we were to hit it then
> we need to unregister_netdev() before doing the free_netdev().
> Otherwise we would hit the BUG_ON() in free_netdev():
>
> BUG_ON(dev->reg_state != NETREG_UNREGISTERED);
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, but please be explicit that your patch is against one
tree or another. This one was for net-next only, but I tried
initially to apply it to net which failed.
^ permalink raw reply
* Re: [PATCH net-next 0/3] qlcnic: Bug fixes
From: David Miller @ 2012-06-07 20:19 UTC (permalink / raw)
To: anirban.chakraborty; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1339004108-7356-1-git-send-email-anirban.chakraborty@qlogic.com>
From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
Date: Wed, 6 Jun 2012 13:35:05 -0400
> Please apply.
All applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: Update kernel-doc for __alloc_skb()
From: David Miller @ 2012-06-07 20:19 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, grant.b.edwards
In-Reply-To: <1339032217.2836.61.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 7 Jun 2012 02:23:37 +0100
> __alloc_skb() now extends tailroom to allow the use of padding added
> by the heap allocator.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [v4 net-next PATCH 0/3] Energy Efficient Ethernet (eee) support
From: David Miller @ 2012-06-07 20:19 UTC (permalink / raw)
To: yuvalmin; +Cc: netdev, eilong, peppe.cavallaro, bhutchings
In-Reply-To: <1339038788-3447-1-git-send-email-yuvalmin@broadcom.com>
From: "Yuval Mintz" <yuvalmin@broadcom.com>
Date: Thu, 7 Jun 2012 06:13:05 +0300
> This patch series adds energy efficient ethernet support for the
> bnx2x driver (for new chips with appropriate phys).
> It also extends the ethtool API to enable control of the eee feature.
>
> Another patch series has been sent to Ben to allow the ethtool application
> to use this new API.
All applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next] macvtap: use prepare_to_wait/finish_wait to ensure mb
From: David Miller @ 2012-06-07 20:19 UTC (permalink / raw)
To: honkiko; +Cc: netdev, arnd, zhiguo.hong, vikifang
In-Reply-To: <1339058187-6619-1-git-send-email-honkiko@gmail.com>
From: Hong Zhiguo <honkiko@gmail.com>
Date: Thu, 7 Jun 2012 16:36:27 +0800
> instead of raw assignment to current->state
>
> Signed-off-by: Hong Zhiguo <honkiko@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] be2net: Fix driver load for VFs for Lancer
From: David Miller @ 2012-06-07 20:19 UTC (permalink / raw)
To: padmanabh.ratnakar; +Cc: netdev
In-Reply-To: <e4b55390-7f60-4365-9203-fde4c661e339@exht1.ad.emulex.com>
From: Padmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
Date: Thu, 7 Jun 2012 20:07:08 +0530
> Permanent MAC is wrongly supplied in create iface command. Call the
> command with no MAC address and then MAC address should be later queried
> and applied.
>
> Signed-off-by: Padmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
Applied.
^ permalink raw reply
* Re: [V2 RFC net-next PATCH 2/2] virtio_net: export more statistics through ethtool
From: Ben Hutchings @ 2012-06-07 20:24 UTC (permalink / raw)
To: David Miller; +Cc: mst, netdev, linux-kernel, virtualization
In-Reply-To: <20120607.130512.219951433412203999.davem@davemloft.net>
On Thu, 2012-06-07 at 13:05 -0700, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Thu, 7 Jun 2012 18:15:06 +0100
>
> > I would really like to see some sort of convention for presenting
> > per-queue statistics through ethtool. At the moment we have a complete
> > mess of different formats:
>
> Indeed. Probably ${QUEUE_TYPE}-${INDEX}-${STATISTIC} is best.
> With an agreed upon list of queue types such as "rx", "tx", "rxtx"
> etc.
I think we should leave the type names open-ended, as there are other
useful groupings like per-virtual-port. In that case the separator
should be chosen to allow arbitrary type names without ambiguity.
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] fix kernel crash in the macvlan driver
From: Ani Sinha @ 2012-06-07 20:37 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netdev, Francesco Ruggeri
In-Reply-To: <87bokux5po.fsf@xmission.com>
Hi Eric :
On Thu, 7 Jun 2012, Eric W. Biederman wrote:
> I don't completely follow the logic of your change. Crashing in
> macvlan_addr_busy does seem to indicate you are using a corrupted data
> structure.
The logic of my change is as follows :
As far as I can see, macvlan_newlink() pairs with macvlan_dellink(). If
you are incrementing the reference count in newlink(), the corresponding
decrement should be, in my opinion in dellink(). If you are derementing
the count in uninit(), you are asuming that for every dellink() call,
there is a corresponding uninit() call. I am not sure if this assumption
is correct. Perhaps you can shed some more lights on this.
Now since, macvlan_common_newlink() symbol has been exported but dellink() is not, it
is possible to call the common_newlink() from some GPL driver code and
increment the reference count which will not have a corresponding
decrement. I am not sure what can be done about this issue either.
>
> My compiled version of macvlan_addr_busy is much smaller than yours so I
> can't guess based on your disassembly what is wrong. But by reading the
> code it must either be port->dev->dev_addr or the rcu
> macvlan_hash_lookup.
Yes, the corruption is in port->dev->dev_addr. The dev_addr seems to get a
bogus address value.
> I might just be dense today but I can't possibly see how moving that
> decrement would solve the crash you have reported below.
In my tests, I have confirmed that with my change, the crash I reported is
no longer reproducable with our scripts. I have also verified that when I
pull out your d5cd92448fded change, I can also no longer reproduce the
issue. So I believe that the crash is related to the above change.
However, I am not very familier with the code in the macvlan
driver, so I can not say for sure that the fix I made genuinely solves the
problem.
Cheers,
Ani
^ permalink raw reply
* Re: [PATCH v10] tilegx network driver: initial support
From: David Miller @ 2012-06-07 20:39 UTC (permalink / raw)
To: cmetcalf; +Cc: eric.dumazet, bhutchings, arnd, linux-kernel, netdev
In-Reply-To: <201206072031.q57KV0NG029301@farm-0023.internal.tilera.com>
From: Chris Metcalf <cmetcalf@tilera.com>
Date: Fri, 6 Apr 2012 16:42:03 -0400
> Date: Fri, 6 Apr 2012 16:42:03 -0400
You did not commit this file on April 6th.
Please don't use the date emitted by the GIT tools, just
let the email use the natural correct date which is the
one at the time you send the email out.
Otherwise your patch gets misordered as automated tools like
patchwork think this file should go all the way at the back
of the patch queue because of it's old date relative to
other pending patches.
^ permalink raw reply
* Re: [V2 RFC net-next PATCH 2/2] virtio_net: export more statistics through ethtool
From: Rick Jones @ 2012-06-07 20:39 UTC (permalink / raw)
To: Ben Hutchings; +Cc: mst, netdev, linux-kernel, virtualization, David Miller
In-Reply-To: <1339100649.2770.20.camel@bwh-desktop.uk.solarflarecom.com>
On 06/07/2012 01:24 PM, Ben Hutchings wrote:
> On Thu, 2012-06-07 at 13:05 -0700, David Miller wrote:
>> From: Ben Hutchings<bhutchings@solarflare.com>
>> Date: Thu, 7 Jun 2012 18:15:06 +0100
>>
>>> I would really like to see some sort of convention for presenting
>>> per-queue statistics through ethtool. At the moment we have a complete
>>> mess of different formats:
>>
>> Indeed. Probably ${QUEUE_TYPE}-${INDEX}-${STATISTIC} is best.
>> With an agreed upon list of queue types such as "rx", "tx", "rxtx"
>> etc.
>
> I think we should leave the type names open-ended, as there are other
> useful groupings like per-virtual-port. In that case the separator
> should be chosen to allow arbitrary type names without ambiguity.
So you mean like something along the lines of the presence of say '.'
indicating indent a level:
rx_bytes: 1234
myqueue1.rx_bytes: 234
myqueue2.rx_bytes: 345
...
rick jones
^ permalink raw reply
* Re: [PATCH v10] tilegx network driver: initial support
From: Chris Metcalf @ 2012-06-07 20:44 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, bhutchings, arnd, linux-kernel, netdev
In-Reply-To: <20120607.133900.1764130639940088009.davem@davemloft.net>
On 6/7/2012 4:39 PM, David Miller wrote:
> From: Chris Metcalf <cmetcalf@tilera.com>
> Date: Fri, 6 Apr 2012 16:42:03 -0400
>
>> Date: Fri, 6 Apr 2012 16:42:03 -0400
> You did not commit this file on April 6th.
>
> Please don't use the date emitted by the GIT tools, just
> let the email use the natural correct date which is the
> one at the time you send the email out.
>
> Otherwise your patch gets misordered as automated tools like
> patchwork think this file should go all the way at the back
> of the patch queue because of it's old date relative to
> other pending patches.
Yes, when I use "git rebase" to merge changes into the earlier patch, this
is the behavior I see. I don't know if there's some way to tell git to
take the date on the later change instead when I "squash" them. Or if,
perhaps, there is some other workflow I should be using. It does seem like
the git history should reflect the latest time.
The issue of the date on the email is separate. I tend to use "git
format-patch" to start with, munge up the headers to jam in some
"In-Reply-To" and "References" lines, manually update the "Date:", then
feed it to "sendmail -t". Perhaps there's a different workflow I should be
using there, too. (I tried deleting the "Date", but the one time I tried
that I ended up with some surprisingly bogus date in the email that hit
LKML, so I've been avoiding that approach.)
I'll resend the patch without a Date: line and see how it ends up this time.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ 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