* Re: Fw: [Bug 14470] New: freez in TCP stack
From: Eric Dumazet @ 2009-10-29 5:59 UTC (permalink / raw)
To: David S. Miller
Cc: Andrew Morton, Stephen Hemminger, netdev, kolo, bugzilla-daemon
In-Reply-To: <4AE9298C.1000204@gmail.com>
Eric Dumazet a écrit :
> Andrew Morton a écrit :
>> On Mon, 26 Oct 2009 08:41:32 -0700
>> Stephen Hemminger <shemminger@linux-foundation.org> wrote:
>>
>>> Begin forwarded message:
>>>
>>> Date: Mon, 26 Oct 2009 12:47:22 GMT
>>> From: bugzilla-daemon@bugzilla.kernel.org
>>> To: shemminger@linux-foundation.org
>>> Subject: [Bug 14470] New: freez in TCP stack
>>>
>> Stephen, please retain the bugzilla and reporter email cc's when
>> forwarding a report to a mailing list.
>>
>>
>>> http://bugzilla.kernel.org/show_bug.cgi?id=14470
>>>
>>> Summary: freez in TCP stack
>>> Product: Networking
>>> Version: 2.5
>>> Kernel Version: 2.6.31
>>> Platform: All
>>> OS/Version: Linux
>>> Tree: Mainline
>>> Status: NEW
>>> Severity: high
>>> Priority: P1
>>> Component: IPV4
>>> AssignedTo: shemminger@linux-foundation.org
>>> ReportedBy: kolo@albatani.cz
>>> Regression: No
>>>
>>>
>>> We are hiting kernel panics on Dell R610 servers with e1000e NICs; it apears
>>> usualy under a high network trafic ( around 100Mbit/s) but it is not a rule it
>>> has happened even on low trafic.
>>>
>>> Servers are used as reverse http proxy (varnish).
>>>
>>> On 6 equal servers this panic happens aprox 2 times a day depending on network
>>> load. Machine completly freezes till the management watchdog reboots.
>>>
>> Twice a day on six separate machines. That ain't no hardware glitch.
>>
>> Vaclav, are you able to say whether this is a regression? Did those
>> machines run 2.6.30 (for example)?
>>
>> Thanks.
>>
>>> We had to put serial console on these servers to catch the oops. Is there
>>> anything else We can do to debug this?
>>> The RIP is always the same:
>>>
>>> RIP: 0010:[<ffffffff814203cc>] [<ffffffff814203cc>]
>>> tcp_xmit_retransmit_queue+0x8c/0x290
>>>
>>> rest of the oops always differs a litle ... here is an example:
>>>
>>> RIP: 0010:[<ffffffff814203cc>] [<ffffffff814203cc>]
>>> tcp_xmit_retransmit_queue+0x8c/0x290
>>> RSP: 0018:ffffc90000003a40 EFLAGS: 00010246
>>> RAX: ffff8807e7420678 RBX: ffff8807e74205c0 RCX: 0000000000000000
>>> RDX: 000000004598a105 RSI: 0000000000000000 RDI: ffff8807e74205c0
>>> RBP: ffffc90000003a80 R08: 0000000000000003 R09: 0000000000000000
>>> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
>>> R13: ffff8807e74205c0 R14: ffff8807e7420678 R15: 0000000000000000
>>> FS: 0000000000000000(0000) GS:ffffc90000000000(0000) knlGS:0000000000000000
>>> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
>>> CR2: 0000000000000000 CR3: 0000000001001000 CR4: 00000000000006f0
>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>>> Process swapper (pid: 0, threadinfo ffffffff81608000, task ffffffff81631440)
>>> Stack:
>>> ffffc90000003a60 0000000000000000 4598a105e74205c0 000000004598a101
>>> <0> 000000000000050e ffff8807e74205c0 0000000000000003 0000000000000000
>>> <0> ffffc90000003b40 ffffffff8141ae4a ffff8807e7420678 0000000000000000
>>> Call Trace:
>>> <IRQ>
>>> [<ffffffff8141ae4a>] tcp_ack+0x170a/0x1dd0
>>> [<ffffffff8141c362>] tcp_rcv_state_process+0x122/0xab0
>>> [<ffffffff81422c6c>] tcp_v4_do_rcv+0xac/0x220
>>> [<ffffffff813fd02f>] ? nf_iterate+0x5f/0x90
>>> [<ffffffff81424b26>] tcp_v4_rcv+0x586/0x6b0
>>> [<ffffffff813fd0c5>] ? nf_hook_slow+0x65/0xf0
>>> [<ffffffff81406b70>] ? ip_local_deliver_finish+0x0/0x120
>>> [<ffffffff81406bcf>] ip_local_deliver_finish+0x5f/0x120
>>> [<ffffffff8140715b>] ip_local_deliver+0x3b/0x90
>>> [<ffffffff81406971>] ip_rcv_finish+0x141/0x340
>>> [<ffffffff8140701f>] ip_rcv+0x24f/0x350
>>> [<ffffffff813e7ced>] netif_receive_skb+0x20d/0x2f0
>>> [<ffffffff813e7e90>] napi_skb_finish+0x40/0x50
>>> [<ffffffff813e82f4>] napi_gro_receive+0x34/0x40
>>> [<ffffffff8133e0c8>] e1000_receive_skb+0x48/0x60
>>> [<ffffffff81342342>] e1000_clean_rx_irq+0xf2/0x330
>>> [<ffffffff813410a1>] e1000_clean+0x81/0x2a0
>>> [<ffffffff81054ce1>] ? ktime_get+0x11/0x50
>>> [<ffffffff813eaf1c>] net_rx_action+0x9c/0x130
>>> [<ffffffff81046940>] ? get_next_timer_interrupt+0x1d0/0x210
>>> [<ffffffff81041bd7>] __do_softirq+0xb7/0x160
>>> [<ffffffff8100c27c>] call_softirq+0x1c/0x30
>>> [<ffffffff8100e04d>] do_softirq+0x3d/0x80
>>> [<ffffffff81041b0b>] irq_exit+0x7b/0x90
>>> [<ffffffff8100d613>] do_IRQ+0x73/0xe0
>>> [<ffffffff8100bb13>] ret_from_intr+0x0/0xa
>>> <EOI>
>>> [<ffffffff81296e6c>] ? acpi_idle_enter_bm+0x245/0x271
>>> [<ffffffff81296e62>] ? acpi_idle_enter_bm+0x23b/0x271
>>> [<ffffffff813c7a08>] ? cpuidle_idle_call+0x98/0xf0
>>> [<ffffffff8100a104>] ? cpu_idle+0x94/0xd0
>>> [<ffffffff81468db6>] ? rest_init+0x66/0x70
>>> [<ffffffff816a082f>] ? start_kernel+0x2ef/0x340
>>> [<ffffffff8169fd54>] ? x86_64_start_reservations+0x84/0x90
>>> [<ffffffff8169fe32>] ? x86_64_start_kernel+0xd2/0x100
>>> Code: 00 eb 28 8b 83 d0 03 00 00 41 39 44 24 40 0f 89 00 01 00 00 41 0f b6 cd
>>> 41 bd 2f 00 00 00 83 e1 03 0f 84 fc 00 00 00 4d 8b 24 24 <49> 8b 04 24 4d 39 f4
>>> 0f 18 08 0f 84 d9 00 00 00 4c 3b a3 b8 01
>>> RIP [<ffffffff814203cc>] tcp_xmit_retransmit_queue+0x8c/0x290
>>> RSP <ffffc90000003a40>
>>> CR2: 0000000000000000
>>> ---[ end trace d97d99c9ae1d52cc ]---
>>> Kernel panic - not syncing: Fatal exception in interrupt
>>> Pid: 0, comm: swapper Tainted: G D 2.6.31 #2
>>> Call Trace:
>>> <IRQ> [<ffffffff8103cab0>] panic+0xa0/0x170
>>> [<ffffffff8100bb13>] ? ret_from_intr+0x0/0xa
>>> [<ffffffff8103c74e>] ? print_oops_end_marker+0x1e/0x20
>>> [<ffffffff8100f38e>] oops_end+0x9e/0xb0
>>> [<ffffffff81025b9a>] no_context+0x15a/0x250
>>> [<ffffffff81025e2b>] __bad_area_nosemaphore+0xdb/0x1c0
>>> [<ffffffff813e89e9>] ? dev_hard_start_xmit+0x269/0x2f0
>>> [<ffffffff81025fae>] bad_area_nosemaphore+0xe/0x10
>>> [<ffffffff8102639f>] do_page_fault+0x17f/0x260
>>> [<ffffffff8147eadf>] page_fault+0x1f/0x30
>>> [<ffffffff814203cc>] ? tcp_xmit_retransmit_queue+0x8c/0x290
>>> [<ffffffff8141ae4a>] tcp_ack+0x170a/0x1dd0
>>> [<ffffffff8141c362>] tcp_rcv_state_process+0x122/0xab0
>>> [<ffffffff81422c6c>] tcp_v4_do_rcv+0xac/0x220
>>> [<ffffffff813fd02f>] ? nf_iterate+0x5f/0x90
>>> [<ffffffff81424b26>] tcp_v4_rcv+0x586/0x6b0
>>> [<ffffffff813fd0c5>] ? nf_hook_slow+0x65/0xf0
>>> [<ffffffff81406b70>] ? ip_local_deliver_finish+0x0/0x120
>>> [<ffffffff81406bcf>] ip_local_deliver_finish+0x5f/0x120
>>> [<ffffffff8140715b>] ip_local_deliver+0x3b/0x90
>>> [<ffffffff81406971>] ip_rcv_finish+0x141/0x340
>>> [<ffffffff8140701f>] ip_rcv+0x24f/0x350
>>> [<ffffffff813e7ced>] netif_receive_skb+0x20d/0x2f0
>>> [<ffffffff813e7e90>] napi_skb_finish+0x40/0x50
>>> [<ffffffff813e82f4>] napi_gro_receive+0x34/0x40
>>> [<ffffffff8133e0c8>] e1000_receive_skb+0x48/0x60
>>> [<ffffffff81342342>] e1000_clean_rx_irq+0xf2/0x330
>>> [<ffffffff813410a1>] e1000_clean+0x81/0x2a0
>>> [<ffffffff81054ce1>] ? ktime_get+0x11/0x50
>>> [<ffffffff813eaf1c>] net_rx_action+0x9c/0x130
>>> [<ffffffff81046940>] ? get_next_timer_interrupt+0x1d0/0x210
>>> [<ffffffff81041bd7>] __do_softirq+0xb7/0x160
>>> [<ffffffff8100c27c>] call_softirq+0x1c/0x30
>>> [<ffffffff8100e04d>] do_softirq+0x3d/0x80
>>> [<ffffffff81041b0b>] irq_exit+0x7b/0x90
>>> [<ffffffff8100d613>] do_IRQ+0x73/0xe0
>>> [<ffffffff8100bb13>] ret_from_intr+0x0/0xa
>>> <EOI> [<ffffffff81296e6c>] ? acpi_idle_enter_bm+0x245/0x271
>>> [<ffffffff81296e62>] ? acpi_idle_enter_bm+0x23b/0x271
>>> [<ffffffff813c7a08>] ? cpuidle_idle_call+0x98/0xf0
>>> [<ffffffff8100a104>] ? cpu_idle+0x94/0xd0
>>> [<ffffffff81468db6>] ? rest_init+0x66/0x70
>>> [<ffffffff816a082f>] ? start_kernel+0x2ef/0x340
>>> [<ffffffff8169fd54>] ? x86_64_start_reservations+0x84/0x90
>>> [<ffffffff8169fe32>] ? x86_64_start_kernel+0xd2/0x100
>>>
>
>
> Code: 00 eb 28 8b 83 d0 03 00 00
> 41 39 44 24 40 cmp %eax,0x40(%r12)
> 0f 89 00 01 00 00 jns ...
> 41 0f b6 cd movzbl %r13b,%ecx
> 41 bd 2f 00 00 00 mov $0x2f000000,%r13d
> 83 e1 03 and $0x3,%ecx
> 0f 84 fc 00 00 00 je ...
> 4d 8b 24 24 mov (%r12),%r12 skb = skb->next
> <>49 8b 04 24 mov (%r12),%rax << NULL POINTER dereference >>
> 4d 39 f4 cmp %r14,%r12
> 0f 18 08 prefetcht0 (%rax)
> 0f 84 d9 00 00 00 je ...
> 4c 3b a3 b8 01 cmp
>
>
> crash is in
> void tcp_xmit_retransmit_queue(struct sock *sk)
> {
>
> << HERE >> tcp_for_write_queue_from(skb, sk) {
>
> }
>
>
> Some skb in sk_write_queue has a NULL ->next pointer
>
> Strange thing is R14 and RAX =ffff8807e7420678 (&sk->sk_write_queue)
> R14 is the stable value during the loop, while RAW is scratch register.
>
> I dont have full disassembly for this function, but I guess we just entered the loop
> (or RAX should be really different at this point)
>
> So, maybe list head itself is corrupted (sk->sk_write_queue->next = NULL)
>
> or, retransmit_skb_hint problem ? (we forget to set it to NULL in some cases ?)
>
David, what do you think of following patch ?
I wonder if we should reorganize code to add sanity checks in tcp_unlink_write_queue()
that the skb we delete from queue is not still referenced.
[PATCH] tcp: clear retrans hints in tcp_send_synack()
There is a small possibility the skb we unlink from write queue
is still referenced by retrans hints.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index fcd278a..b22a72d 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2201,6 +2201,7 @@ int tcp_send_synack(struct sock *sk)
struct sk_buff *nskb = skb_copy(skb, GFP_ATOMIC);
if (nskb == NULL)
return -ENOMEM;
+ tcp_clear_all_retrans_hints(tcp_sk(sk));
tcp_unlink_write_queue(skb, sk);
skb_header_release(nskb);
__tcp_add_write_queue_head(sk, nskb);
^ permalink raw reply related
* Re: [Bug 14470] New: freez in TCP stack
From: David Miller @ 2009-10-29 6:02 UTC (permalink / raw)
To: eric.dumazet; +Cc: akpm, shemminger, netdev, kolo, bugzilla-daemon
In-Reply-To: <4AE92F4D.6070101@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 29 Oct 2009 06:59:41 +0100
> David, what do you think of following patch ?
>
> I wonder if we should reorganize code to add sanity checks in tcp_unlink_write_queue()
> that the skb we delete from queue is not still referenced.
>
> [PATCH] tcp: clear retrans hints in tcp_send_synack()
>
> There is a small possibility the skb we unlink from write queue
> is still referenced by retrans hints.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Yes, the first thing I thought of when I saw this crash was the hints.
I'll think this over.
^ permalink raw reply
* Re: [PATCH] hso: fix debug routines
From: Antti Kaijanmäki @ 2009-10-29 6:57 UTC (permalink / raw)
To: Andrew Morton; +Cc: Greg KH, linux-kernel, netdev, Jan Dumon
In-Reply-To: <20091028161617.26a58618.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 457 bytes --]
On Wed, 2009-10-28 at 16:16 -0700, Andrew Morton wrote:
> This patch has no changelog, and I'm not seeing any description of what
> it fixes and how it fixes it up-thread.
The patch fixes debug routines of the hso driver. Debug has to be
enabled manually with a #define so this patch has 0 impact by default.
Broken down from original patch:
http://bugzilla.kernel.org/show_bug.cgi?id=14469
http://lkml.org/lkml/2009/10/22/37
-- Antti
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: nfs broken in net-next?
From: Suresh Jayaraman @ 2009-10-29 7:02 UTC (permalink / raw)
To: Yinghai Lu; +Cc: David Miller, Linux Kernel Mailing List, NetDev
In-Reply-To: <86802c440910281313h2ca89c94w99121edffbf6ce53@mail.gmail.com>
On 10/29/2009 01:43 AM, Yinghai Lu wrote:
> pk12-3214-189-102:~ # mount -t nfs 10.6.75.100:/data/shared/pxeboot /x
> mount.nfs: rpc.statd is not running but is required for remote locking.
> mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
>
Is statd running on the server? The in-kernel statd has been replaced by
userspace statd.
> using opensuse11.1
>
> YH
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Suresh Jayaraman
^ permalink raw reply
* Re: nfs broken in net-next?
From: Suresh Jayaraman @ 2009-10-29 7:23 UTC (permalink / raw)
To: Yinghai Lu; +Cc: David Miller, Linux Kernel Mailing List, NetDev
In-Reply-To: <86802c440910281313h2ca89c94w99121edffbf6ce53@mail.gmail.com>
On 10/29/2009 01:43 AM, Yinghai Lu wrote:
> pk12-3214-189-102:~ # mount -t nfs 10.6.75.100:/data/shared/pxeboot /x
> mount.nfs: rpc.statd is not running but is required for remote locking.
> mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
rpc.statd on client should have be started by mount.nfs when a nfs
filesystem is mounted. Is this not happening for some reason or do you
see any errors in syslog?
>
> using opensuse11.1
>
Are you using 11.1 betas? I know of a problem where non-root user mounts
fail to start rpc.statd in betas that got fixed later:
http://marc.info/?l=linux-nfs&m=122748525624094&w=2
Is the problem seen only recently (after updating to net-next)?
Thanks,
--
Suresh Jayaraman
^ permalink raw reply
* Re: [Bug 14470] New: freez in TCP stack
From: David Miller @ 2009-10-29 8:00 UTC (permalink / raw)
To: eric.dumazet; +Cc: akpm, shemminger, netdev, kolo, bugzilla-daemon
In-Reply-To: <4AE92F4D.6070101@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 29 Oct 2009 06:59:41 +0100
> [PATCH] tcp: clear retrans hints in tcp_send_synack()
>
> There is a small possibility the skb we unlink from write queue
> is still referenced by retrans hints.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
So, this would only be true if we were dealing with a data
packet here. We're not, this is a SYN+ACK which happens to
be cloned in the write queue.
The hint SKBs pointers can only point to real data packets.
And we're only dealing with data packets once we enter established
state, and when we enter established by definition we have unlinked
and freed up any SYN and SYN+ACK SKBs in the write queue.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/4] net: Add ndo_fcoe_get_wwn to net_device_ops
From: David Miller @ 2009-10-29 8:04 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, linux-scsi, yi.zou
In-Reply-To: <20091029042434.15957.82934.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 28 Oct 2009 21:24:35 -0700
> From: Yi Zou <yi.zou@intel.com>
>
> Add ndo_fcoe_get_wwn so Fiber Channel over Ethernet (FCoE) can make use of
> the provided World Wide Port Name (WWPN) and World Wide Node Name (WWNN)
> from the underlying network interface driver.
>
> Signed-off-by: Yi Zou <yi.zou@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/4] ixgbe: Add support for 82599 alternative WWNN/WWPN prefix
From: David Miller @ 2009-10-29 8:04 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: netdev, gospo, linux-scsi, yi.zou, peter.p.waskiewicz.jr
In-Reply-To: <20091029042339.15957.37676.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 28 Oct 2009 21:23:57 -0700
> From: Yi Zou <yi.zou@intel.com>
>
> The 82599 EEPROM supports alternative prefix for World Wide Node Name
> (WWNN) and World Wide Port Name (WWPN). The prefixes can be used together
> with the SAN MAC address to form the WWNN and WWPN, which can be used by
> upper layer drivers such as Fiber Channel over Ethernet (FCoE).
>
> Signed-off-by: Yi Zou <yi.zou@intel.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] e1000e: flow control doesn't re-enable
From: David Miller @ 2009-10-29 8:05 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20091029042829.16444.58687.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 28 Oct 2009 21:28:30 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> When changing flow control (pause) parameters, the flow control thresholds
> (i.e. when to send XON/XOFF frames) may not be setup correctly on parts
> with copper media. Call the existing e1000_set_fc_watermarks()
> function to set these thresholds.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 3/4] ixgbe: Add support for netdev_ops.ndo_fcoe_get_wwn to 82599
From: David Miller @ 2009-10-29 8:04 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, linux-scsi, yi.zou
In-Reply-To: <20091029042455.15957.87665.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 28 Oct 2009 21:24:56 -0700
> From: Yi Zou <yi.zou@intel.com>
>
> Implements the netdev_ops.ndo_fcoe_get_wwn in 82599 if it finds valid
> prefix for the World Wide Node Name (WWNN) or World Wide Port Name (WWPN),
> as well as valid SAN MAC address.
>
> Signed-off-by: Yi Zou <yi.zou@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 4/4] vlan: Add support to netdev_ops.ndo_fcoe_get_wwn for VLAN device
From: David Miller @ 2009-10-29 8:04 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, linux-scsi, yi.zou
In-Reply-To: <20091029042515.15957.86107.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 28 Oct 2009 21:25:16 -0700
> From: Yi Zou <yi.zou@intel.com>
>
> Implements the netdev_ops.ndo_fcoe_get_wwn for VLAN device.
>
> Signed-off-by: Yi Zou <yi.zou@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: pull request: wireless-2.6 2009-10-28
From: David Miller @ 2009-10-29 8:07 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20091028205346.GE2856@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 28 Oct 2009 16:53:46 -0400
> Here is a collection of fixes (mostly (almost-)one-liners) intended
> for 2.6.32. There are a couple of fixes relating to behavior when an
> association failes, as well as spelling fixes, simply endian fixes,
> a MAINTAINERS change...I don't think there is anything controversial
> here...
>
> Please let me know if there are problems!
Pulled, thanks a lot John.
^ permalink raw reply
* Re: [PATCH] AF_RAW: Augment raw_send_hdrinc to expand skb to fit iphdr->ihl (v2)
From: David Miller @ 2009-10-29 8:10 UTC (permalink / raw)
To: eric.dumazet; +Cc: nhorman, netdev
In-Reply-To: <4AE8B114.6050504@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 28 Oct 2009 22:01:08 +0100
> Neil Horman a écrit :
>>
>>> I believe we should drop the request, since padding it is not what was expected by user.
>>
>> Yeah, I had a feeling. Ok, version 2, this time drop the invalid frame and
>> report it to user space, instead of expanding it:
>>
>>
>> Augment raw_send_hdrinc to correct for incorrect ip header length values
...
>> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
>
Applied to net-2.6, thanks everyone!
^ permalink raw reply
* Re: [PATCH net-next-2.6] be2net: Add the new PCI IDs to PCI_DEVICE_TABLE.
From: David Miller @ 2009-10-29 8:11 UTC (permalink / raw)
To: ajitk; +Cc: netdev
In-Reply-To: <20091028172358.GA2190@serverengines.com>
From: Ajit Khaparde <ajitk@serverengines.com>
Date: Wed, 28 Oct 2009 22:53:59 +0530
> This patch adds the PCI IDs for the next generation chip to the
> PCI_DEVICE_ID table.
>
> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv6 sit: Optimize multiple unregistration
From: David Miller @ 2009-10-29 8:14 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AE85737.4000809@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 28 Oct 2009 15:37:43 +0100
> Speedup module unloading by factorizing synchronize_rcu() calls
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ip6mr: Optimize multiple unregistration
From: David Miller @ 2009-10-29 8:14 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AE859AB.8030801@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 28 Oct 2009 15:48:11 +0100
> Speedup module unloading by factorizing synchronize_rcu() calls
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ip6tnl: Optimize multiple unregistration
From: David Miller @ 2009-10-29 8:14 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AE86063.3080005@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 28 Oct 2009 16:16:51 +0100
> Speedup module unloading by factorizing synchronize_rcu() calls
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipmr: Optimize multiple unregistration
From: David Miller @ 2009-10-29 8:14 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AE86182.80804@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 28 Oct 2009 16:21:38 +0100
> Speedup module unloading by factorizing synchronize_rcu() calls
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] bridge: Optimize multiple unregistration
From: David Miller @ 2009-10-29 8:14 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AE864C7.3060100@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 28 Oct 2009 16:35:35 +0100
> Speedup module unloading by factorizing synchronize_rcu() calls
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 0/2] qlge: Fixes for qlge.
From: David Miller @ 2009-10-29 8:17 UTC (permalink / raw)
To: ron.mercer; +Cc: netdev
In-Reply-To: <1256755161-29606-1-git-send-email-ron.mercer@qlogic.com>
From: Ron Mercer <ron.mercer@qlogic.com>
Date: Wed, 28 Oct 2009 11:39:19 -0700
> Fix EEH and firmware mailbox command processor.
Both applied to net-2.6, thanks Ron.
^ permalink raw reply
* Re: iproute uses too small of a receive buffer
From: David Miller @ 2009-10-29 8:17 UTC (permalink / raw)
To: kaber; +Cc: eric.dumazet, shemminger, greearb, netdev
In-Reply-To: <4AE895E8.60308@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Wed, 28 Oct 2009 20:05:12 +0100
> How about this? It will double the receive queue limit on ENOBUFS
> up to 1024 * 1024b, then bail out with the normal error message on
> further ENOBUFS.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCHv4 0/7] Per route TCP options support kill switches
From: David Miller @ 2009-10-29 8:29 UTC (permalink / raw)
To: gilad; +Cc: netdev, ori
In-Reply-To: <1256739327-11576-1-git-send-email-gilad@codefidence.com>
From: Gilad Ben-Yossef <gilad@codefidence.com>
Date: Wed, 28 Oct 2009 16:15:20 +0200
> Allow selectively turning off support for specific TCP options
> on a per route basis.
Ok, I can live with these changes, good job.
All applied to net-next-2.6, thanks!
^ permalink raw reply
* Re: [PATCH kernel 2.6.32-rc5] [RESEND] netdev: usb: dm9601.c can drive a device not supported yet, add support for it
From: David Miller @ 2009-10-29 8:32 UTC (permalink / raw)
To: jkrzyszt; +Cc: jacmet, netdev
In-Reply-To: <200910281634.23635.jkrzyszt@tis.icnet.pl>
From: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Date: Wed, 28 Oct 2009 16:34:21 +0100
> I found that the current version of drivers/net/usb/dm9601.c can be used to
> successfully drive a low-power, low-cost network adapter with USB ID
> 0a46:9000, based on a DM9000E chipset. As no device with this ID is yet
> present in the kernel, I have created a patch that adds support for the device
> to the dm9601 driver.
>
> Created and tested against linux-2.6.32-rc5.
>
> Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
> Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
Applied to net-2.6, thanks.
^ permalink raw reply
* Re: [PATCH 0/9] Gigaset driver patches for 2.6.33
From: David Miller @ 2009-10-29 8:37 UTC (permalink / raw)
To: tilman; +Cc: isdn, hjlipp, netdev, linux-kernel, isdn4linux, i4ldeveloper
In-Reply-To: <20091023-patch-gigaset-00.tilman@imap.cc>
From: Tilman Schmidt <tilman@imap.cc>
Date: Sun, 25 Oct 2009 20:29:27 +0100 (CET)
> David, Karsten,
>
> here's a series of patches that should be applied on top of those
> currently in net-next. I'm sending them now to leave you enough time
> before the next merge window to decide who wants to handle them.
> In particular, patch 3 provides an important bugfix to the new CAPI
> interface which is necessary for using it with pppd capiplugin.
All of these patches look reasonable, so I've applied them
to net-next-2.6
Thanks!
^ permalink raw reply
* Re: [PATCH] net: Cleanup redundant tests on unsigned
From: David Miller @ 2009-10-29 8:40 UTC (permalink / raw)
To: roel.kluin; +Cc: netdev, akpm
In-Reply-To: <4AE1D2D9.5000906@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Fri, 23 Oct 2009 17:59:21 +0200
> optlen is unsigned so the `< 0' test is never true.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Applied.
^ 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