* Re: [PATCH] net_ns: add __rcu annotations
From: David Miller @ 2010-10-25 21:19 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1288012811.2826.119.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 25 Oct 2010 15:20:11 +0200
> add __rcu annotation to (struct net)->gen, and use
> rcu_dereference_protected() in net_assign_generic()
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] rps: add __rcu annotations
From: David Miller @ 2010-10-25 21:19 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1288011722.2826.116.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 25 Oct 2010 15:02:02 +0200
> Add __rcu annotations to :
> (struct netdev_rx_queue)->rps_map
> (struct netdev_rx_queue)->rps_flow_table
> struct rps_sock_flow_table *rps_sock_flow_table;
>
> And use appropriate rcu primitives.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: Reproducible VLAN/e1000e crash in 2.6.36 vanilla.
From: Ben Greear @ 2010-10-25 21:18 UTC (permalink / raw)
To: NetDev
In-Reply-To: <4CC5C51F.3000606@candelatech.com>
On 10/25/2010 10:57 AM, Ben Greear wrote:
>
> To re-create, setup 2 802.1q vlans on different physical interfaces on
> the same system,
> set up routing rules such that send-to-self works, and pass traffic
> (UDP/IPv4 in this case,
> but doesn't seem to matter).
> Stop traffic, then attempt to create additional 802.1q vlans on the same
> physical interfaces.
> The crash only appears to happen after having sent traffic on the
> interface.
>
> Likely it will also crash if one system is sending to another, but so
> far we've
> just tested sending-to-self.
>
> This appears very reproducible for us, and appears to be the same
> problem that
> I had reported against our hacked kernel here:
>
> http://www.spinics.net/lists/netdev/msg144748.html
Bleh, I think I see the problem.
If a NIC is in promis mode, it can receive VLAN packets for which there
are no VLAN devices.
static gro_result_t
vlan_gro_common(struct napi_struct *napi, struct vlan_group *grp,
unsigned int vlan_tci, struct sk_buff *skb)
{
struct sk_buff *p;
struct net_device *vlan_dev;
u16 vlan_id;
if (skb_bond_should_drop(skb, ACCESS_ONCE(skb->dev->master)))
skb->deliver_no_wcard = 1;
skb->skb_iif = skb->dev->ifindex;
__vlan_hwaccel_put_tag(skb, vlan_tci);
vlan_id = vlan_tci & VLAN_VID_MASK;
vlan_dev = vlan_group_get_device(grp, vlan_id);
if (vlan_dev)
skb->dev = vlan_dev;
else if (vlan_id) {
if (!(skb->dev->flags & IFF_PROMISC))
goto drop;
skb->pkt_type = PACKET_OTHERHOST;
}
You hit that else branch, and then skb->dev remains the physical
device.
Later, it's passed to:
int vlan_hwaccel_do_receive(struct sk_buff *skb)
{
struct net_device *dev = skb->dev;
struct vlan_rx_stats *rx_stats;
skb->dev = vlan_dev_info(dev)->real_dev;
netif_nit_deliver(skb);
which does no checking before assuming that skb->dev is a vlan
device.
Things go downhill rapidly after that.
Maybe this code in dev.c should check that skb->dev is
VLAN device before passing to the hwaccel code?
static int __netif_receive_skb(struct sk_buff *skb)
{
struct packet_type *ptype, *pt_prev;
rx_handler_func_t *rx_handler;
struct net_device *orig_dev;
struct net_device *master;
struct net_device *null_or_orig;
struct net_device *orig_or_bond;
int ret = NET_RX_DROP;
__be16 type;
if (!netdev_tstamp_prequeue)
net_timestamp_check(skb);
if (vlan_tx_tag_present(skb) && vlan_hwaccel_do_receive(skb))
return NET_RX_SUCCESS;
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2 1/9] tproxy: split off ipv6 defragmentation to a separate module
From: David Miller @ 2010-10-25 20:54 UTC (permalink / raw)
To: kaber; +Cc: eric.dumazet, hidden, netdev, netfilter-devel, bazsi
In-Reply-To: <4CC5EBC8.9000701@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Mon, 25 Oct 2010 22:42:48 +0200
> Am 25.10.2010 12:14, schrieb Eric Dumazet:
>>> netfilter: fix module dependency issues with IPv6 defragmentation, ip6tables and xt_TPROXY
>>>
>>> One of the previous tproxy related patches split IPv6 defragmentation and
>>> connection tracking, but did not correctly add Kconfig stanzas to handle the
>>> new dependencies correctly. This patch fixes that by making the config options
>>> mirror the setup we have for IPv4: a distinct config option for defragmentation
>>> that is automatically selected by both connection tracking and
>>> xt_TPROXY/xt_socket.
>>>
>>> The patch also changes the #ifdefs enclosing IPv6 specific code in xt_socket
>>> and xt_TPROXY: we only compile these in case we have ip6tables support enabled.
>>>
>>> Signed-off-by: KOVACS Krisztian <hidden@balabit.hu>
>>
>> Reported-and-tested-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Dave, please apply directly. Thanks!
Will do, thanks Patrick!
^ permalink raw reply
* Re: [PATCH v2 1/9] tproxy: split off ipv6 defragmentation to a separate module
From: Patrick McHardy @ 2010-10-25 20:42 UTC (permalink / raw)
To: Eric Dumazet
Cc: KOVACS Krisztian, netdev, netfilter-devel, Balazs Scheidler,
David Miller
In-Reply-To: <1288001640.2826.96.camel@edumazet-laptop>
Am 25.10.2010 12:14, schrieb Eric Dumazet:
> Le lundi 25 octobre 2010 à 11:38 +0200, KOVACS Krisztian a écrit :
>> Hi,
>>
>> On Fri, 2010-10-22 at 00:19 +0200, Eric Dumazet wrote:
>>> Le jeudi 21 octobre 2010 à 16:04 +0200, Patrick McHardy a écrit :
>>>> Am 21.10.2010 13:43, schrieb KOVACS Krisztian:
>>>>> tproxy: split off ipv6 defragmentation to a separate module
>>>>>
>>>>> Like with IPv4, TProxy needs IPv6 defragmentation but does not
>>>>> require connection tracking. Since defragmentation was coupled
>>>>> with conntrack, I split off the two, creating an nf_defrag_ipv6 module,
>>>>> similar to the already existing nf_defrag_ipv4.
>>>>
>>>> Applied, thanks.
>>>
>>> Hmm...
>>>
>>> CONFIG_IPV6=m
>>> CONFIG_NETFILTER_TPROXY=m
>>>
>>>
>>> MODPOST 201 modules
>>> ERROR: "nf_defrag_ipv6_enable" [net/netfilter/xt_TPROXY.ko] undefined!
>>> ERROR: "ipv6_find_hdr" [net/netfilter/xt_TPROXY.ko] undefined!
>>>
>>> Sorry, it's late here, I wont fix this ;)
>>
>> Oops, I guess this is because you do have IPv6 support but don't have
>> ip6tables enabled in your config. Does the patch below fix the issue for
>> you? (For me it now compiles with and without IPv6 conntrack, ip6tables
>> and IPv6 support, too.)
>>
>>
>
> I had ip6tables enabled, but not CONFIG_NF_CONNTRACK_IPV6 ;)
>
>>
>> netfilter: fix module dependency issues with IPv6 defragmentation, ip6tables and xt_TPROXY
>>
>> One of the previous tproxy related patches split IPv6 defragmentation and
>> connection tracking, but did not correctly add Kconfig stanzas to handle the
>> new dependencies correctly. This patch fixes that by making the config options
>> mirror the setup we have for IPv4: a distinct config option for defragmentation
>> that is automatically selected by both connection tracking and
>> xt_TPROXY/xt_socket.
>>
>> The patch also changes the #ifdefs enclosing IPv6 specific code in xt_socket
>> and xt_TPROXY: we only compile these in case we have ip6tables support enabled.
>>
>> Signed-off-by: KOVACS Krisztian <hidden@balabit.hu>
>
> Reported-and-tested-by: Eric Dumazet <eric.dumazet@gmail.com>
Dave, please apply directly. Thanks!
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Enhance AF_PACKET implementation to not require high order contiguous memory allocation
From: Eric Dumazet @ 2010-10-25 20:38 UTC (permalink / raw)
To: nhorman; +Cc: netdev, davem, jpirko
In-Reply-To: <1288033566-2091-1-git-send-email-nhorman@tuxdriver.com>
Le lundi 25 octobre 2010 à 15:06 -0400, nhorman@tuxdriver.com a écrit :
> From: Neil Horman <nhorman@tuxdriver.com>
>
> It was shown to me recently that systems under high load were driven very deep
> into swap when tcpdump was run. The reason this happened was because the
> AF_PACKET protocol has a SET_RINGBUFFER socket option that allows the user space
> application to specify how many entries an AF_PACKET socket will have and how
> large each entry will be. It seems the default setting for tcpdump is to set
> the ring buffer to 32 entries of 64 Kb each, which implies 32 order 5
> allocation. Thats difficult under good circumstances, and horrid under memory
> pressure.
>
> I thought it would be good to make that a bit more usable. I was going to do a
> simple conversion of the ring buffer from contigous pages to iovecs, but
> unfortunately, the metadata which AF_PACKET places in these buffers can easily
> span a page boundary, and given that these buffers get mapped into user space,
> and the data layout doesn't easily allow for a change to padding between frames
> to avoid that, a simple iovec change is just going to break user space ABI
> consistency.
>
> So instead I've done this. This patch does the aforementioned change,
> allocating an array of pages instead of one contiguous chunk, and then vmaps the
> array into a contiguous memory space, so that it can still be accessed in the
> same way it was before. This allows for a consisten user and kernel space
> behavior for memory mapped AF_PACKET sockets, which at the same time relieving
> the memory pressure placed on a system when tcpdump defaults are used.
>
> Tested successfully by me.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> ---
Strange because last time I took a look at this stuff, libpcap was doing
several tries, reducing page orders until it got no allocation
failures...
(It tries to get high order pages, maybe to reduce TLB pressure...)
I remember adding __GFP_NOWARN to avoid a kernel message, while tcpdump
was actually working...
^ permalink raw reply
* Re: [PATCH] Enhance AF_PACKET implementation to not require high order contiguous memory allocation
From: Francois Romieu @ 2010-10-25 20:17 UTC (permalink / raw)
To: nhorman; +Cc: netdev, davem, eric.dumazet, jpirko
In-Reply-To: <1288033566-2091-1-git-send-email-nhorman@tuxdriver.com>
nhorman@tuxdriver.com <nhorman@tuxdriver.com> :
[...]
> + if (order > 0) {
> + for (j = 0; j < pg_vec[i]->num_pages; j++)
> + pages[j] = virt_to_page(pg_vec[i]->pages[j]);
> +
> + if (unlikely(!pg_vec[i]))
> + goto out_free_pgvec;
Check pg_vec[i] sooner ?
--
Ueimor
^ permalink raw reply
* Re: [PATCH] net: b43legacy: fix compile error
From: Arnd Hannemann @ 2010-10-25 20:13 UTC (permalink / raw)
To: Larry Finger
Cc: David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Eric Dumazet
In-Reply-To: <4CC5D3A7.3080709-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Am 25.10.2010 20:59, schrieb Larry Finger:
> On 10/25/2010 01:44 PM, Arnd Hannemann wrote:
>> Am 25.10.2010 20:36, schrieb Larry Finger:
>>> On 10/25/2010 01:26 PM, Arnd Hannemann wrote:
>>>> Am 25.10.2010 17:32, schrieb Larry Finger:
>>>>> On 10/25/2010 09:41 AM, Arnd Hannemann wrote:
>>>>>> On todays linus tree the following compile error happened to me:
>>>>>>
>>>>>> CC [M] drivers/net/wireless/b43legacy/xmit.o
>>>>>> In file included from include/net/dst.h:11,
>>>>>> from drivers/net/wireless/b43legacy/xmit.c:31:
>>>>>> include/net/dst_ops.h:28: error: expected ':', ',', ';', '}' or '__attribute__' before '____cacheline_aligned_in_smp'
>>>>>> include/net/dst_ops.h: In function 'dst_entries_get_fast':
>>>>>> include/net/dst_ops.h:33: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>>>> include/net/dst_ops.h: In function 'dst_entries_get_slow':
>>>>>> include/net/dst_ops.h:41: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>>>> include/net/dst_ops.h: In function 'dst_entries_add':
>>>>>> include/net/dst_ops.h:49: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>>>> include/net/dst_ops.h: In function 'dst_entries_init':
>>>>>> include/net/dst_ops.h:55: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>>>> include/net/dst_ops.h: In function 'dst_entries_destroy':
>>>>>> include/net/dst_ops.h:60: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>>>> make[4]: *** [drivers/net/wireless/b43legacy/xmit.o] Error 1
>>>>>> make[3]: *** [drivers/net/wireless/b43legacy] Error 2
>>>>>> make[2]: *** [drivers/net/wireless] Error 2
>>>>>> make[1]: *** [drivers/net] Error 2
>>>>>> make: *** [drivers] Error 2
>>>>>>
>>>>>> This patch fixes this issue by adding "linux/cache.h" as an include to
>>>>>> "include/net/dst_ops.h".
>>>>>
>>>>> Strange. Compiling b43legacy from the linux-2.6.git tree (git describe is
>>>>> v2.6.36-4464-g229aebb) works fine on x86_64. I wonder what is different.
>>>>
>>>> Exactly the same git describe here.
>>>> Maybe your arch includes cache.h already, in my case its a compile for ARM (shmobile).
>>>
>>> That probably makes the difference. Using Eric's fix that removes the #include
>>> <linux/dst.h> should be better. Does it work for you?
>>>
>>> There are probably a lot more of the system includes that may not be needed. If
>>> I send you a patch removing them, could you test?
>>
>> As it turns out my card is not supported by b43legacy, but compilation testing,
>> sure I can test that.
>
> If it is a Broadcom card, it is likely handled by b43.
Yes. It seems it should work with b43 (its an SDIO card) and it almost does...
> Attached is a trial removal of a number of include statements. Does it compile?
Nope:
NSTALL_MOD_PATH=/home/arnd/projekte/renesas-2/nfs modules
CHK include/linux/version.h
CHK include/generated/utsrelease.h
make[1]: `include/generated/mach-types.h' is up to date.
CALL scripts/checksyscalls.sh
CC [M] drivers/net/wireless/b43legacy/main.o
drivers/net/wireless/b43legacy/main.c: In function 'b43legacy_upload_microcode':
drivers/net/wireless/b43legacy/main.c:1688: error: implicit declaration of function 'signal_pending'
make[4]: *** [drivers/net/wireless/b43legacy/main.o] Error 1
make[3]: *** [drivers/net/wireless/b43legacy] Error 2
make[2]: *** [drivers/net/wireless] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2
Thanks,
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 4/4] tunnels: add _rcu annotations
From: David Miller @ 2010-10-25 20:10 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1287991996.2658.5385.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 25 Oct 2010 09:33:16 +0200
> (struct ip6_tnl)->next is rcu protected :
> (struct ip_tunnel)->next is rcu protected :
> (struct xfrm6_tunnel)->next is rcu protected :
>
> add __rcu annotation and proper rcu primitives.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/4] net/802: add __rcu annotations
From: David Miller @ 2010-10-25 20:10 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1287991956.2658.5384.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 25 Oct 2010 09:32:36 +0200
> (struct net_device)->garp_port is rcu protected :
> (struct garp_port)->applicants is rcu protected :
>
> add __rcu annotation and proper rcu primitives.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/4] ipv6: ip6_ptr rcu annotations
From: David Miller @ 2010-10-25 20:10 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1287991925.2658.5380.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 25 Oct 2010 09:32:05 +0200
> (struct net_device)->ip6_ptr is rcu protected :
>
> add __rcu annotation and proper rcu primitives.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/4] vlan: rcu annotations
From: David Miller @ 2010-10-25 20:10 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1287991918.2658.5379.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 25 Oct 2010 09:31:58 +0200
> (struct net_device)->vlgrp is rcu protected :
>
> add __rcu annotation and proper rcu primitives.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: Nested GRE locking bug
From: Eric Dumazet @ 2010-10-25 20:08 UTC (permalink / raw)
To: David Miller; +Cc: ben, netdev, beatrice.barbe, 599816
In-Reply-To: <20101025.125347.28807251.davem@davemloft.net>
Le lundi 25 octobre 2010 à 12:53 -0700, David Miller a écrit :
> I'll commit the following to upstream, and submit a combined
> patch to -stable.
>
> --------------------
> net: Increase xmit RECURSION_LIMIT to 10.
>
> Three is definitely too low, and we know from reports that GRE tunnels
> stacked as deeply as 37 levels cause stack overflows, so pick some
> reasonable value between those two.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> net/core/dev.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 78b5a89..2c7da3a 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2213,7 +2213,7 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
> }
>
> static DEFINE_PER_CPU(int, xmit_recursion);
> -#define RECURSION_LIMIT 3
> +#define RECURSION_LIMIT 10
>
> /**
> * dev_queue_xmit - transmit a buffer
Perfect, thanks !
^ permalink raw reply
* Congratulations!! DEAR Winner
From: Jill Nash @ 2010-10-25 20:00 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: PAYMENT_OF_PRIZE_AND_CLAIM.pdf --]
[-- Type: application/pdf, Size: 191206 bytes --]
^ permalink raw reply
* Re: __bad_udelay in network driver breaks build
From: David Miller @ 2010-10-25 20:05 UTC (permalink / raw)
To: andi; +Cc: netdev
In-Reply-To: <20101018115230.GA27565@basil.fritz.box>
From: Andi Kleen <andi@firstfloor.org>
Date: Mon, 18 Oct 2010 13:52:30 +0200
>
> Current Linus master x86-64 allyesconfig fails with
>
> drivers/built-in.o: In function `tms380tr_chipset_init':
> tms380tr.c:(.text+0x10f02de): undefined reference to `__bad_udelay'
> tms380tr.c:(.text+0x10f03ab): undefined reference to `__bad_udelay'
> tms380tr.c:(.text+0x10f0400): undefined reference to `__bad_udelay'
> tms380tr.c:(.text+0x10f07b2): undefined reference to `__bad_udelay'
> tms380tr.c:(.text+0x10f08ed): undefined reference to `__bad_udelay'
> make[2]: *** [.tmp_vmlinux1] Error 1
Let me know if this fixes things:
--------------------
tms380tr: Use mdelay() in tms380tr_wait().
This driver tries to do up to half-second udelay()
calls, which overflows on x86-64.
Reported-by: Andi Kleen <andi@firstfloor.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/tokenring/tms380tr.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tokenring/tms380tr.c b/drivers/net/tokenring/tms380tr.c
index 663b886..7930203 100644
--- a/drivers/net/tokenring/tms380tr.c
+++ b/drivers/net/tokenring/tms380tr.c
@@ -1220,7 +1220,7 @@ void tms380tr_wait(unsigned long time)
tmp = schedule_timeout_interruptible(tmp);
} while(time_after(tmp, jiffies));
#else
- udelay(time);
+ mdelay(time / 1000);
#endif
}
--
1.7.3.2
^ permalink raw reply related
* Re: [net-next PATCH 1/3] qlge: Restoring the vlan setting.
From: Ron Mercer @ 2010-10-25 19:46 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, Jitendra Kalsaria, Ying Ping Lok
In-Reply-To: <20101025.120739.104054830.davem@davemloft.net>
>From 4981e8d94411b282040bcee89f08e16eef5c608c Mon Sep 17 00:00:00 2001
From: Ron Mercer <ron.mercer@qlogic.com>
Date: Mon, 25 Oct 2010 12:38:33 -0700
Subject: [net-next PATCH 1/3] qlge: Restoring the vlan setting.
Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
---
drivers/net/qlge/qlge_main.c | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/net/qlge/qlge_main.c b/drivers/net/qlge/qlge_main.c
index ba0053d..5077d38 100644
--- a/drivers/net/qlge/qlge_main.c
+++ b/drivers/net/qlge/qlge_main.c
@@ -2382,6 +2382,20 @@ static void qlge_vlan_rx_kill_vid(struct net_device *ndev, u16 vid)
}
+static void qlge_restore_vlan(struct ql_adapter *qdev)
+{
+ qlge_vlan_rx_register(qdev->ndev, qdev->vlgrp);
+
+ if (qdev->vlgrp) {
+ u16 vid;
+ for (vid = 0; vid < VLAN_N_VID; vid++) {
+ if (!vlan_group_get_device(qdev->vlgrp, vid))
+ continue;
+ qlge_vlan_rx_add_vid(qdev->ndev, vid);
+ }
+ }
+}
+
/* MSI-X Multiple Vector Interrupt Handler for inbound completions. */
static irqreturn_t qlge_msix_rx_isr(int irq, void *dev_id)
{
@@ -3957,6 +3971,9 @@ static int ql_adapter_up(struct ql_adapter *qdev)
clear_bit(QL_PROMISCUOUS, &qdev->flags);
qlge_set_multicast_list(qdev->ndev);
+ /* Restore vlan setting. */
+ qlge_restore_vlan(qdev);
+
ql_enable_interrupts(qdev);
ql_enable_all_completion_interrupts(qdev);
netif_tx_start_all_queues(qdev->ndev);
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH] net: b43legacy: fix compile error
From: Eric Dumazet @ 2010-10-25 19:56 UTC (permalink / raw)
To: Larry Finger
Cc: Arnd Hannemann, David S. Miller, netdev, linux-kernel,
linux-wireless
In-Reply-To: <4CC5C863.9070801@lwfinger.net>
Le lundi 25 octobre 2010 à 13:11 -0500, Larry Finger a écrit :
> I have no idea why that header was included - likely historical in the
> transformation from bcm43xx to b43legacy. For completeness, there are 2 more
> places to change:
Anyway, Arnd patch is fine by me, I didnt want to supply an alternate
patch.
I only was wondering why the include was in this driver...
^ permalink raw reply
* Re: Nested GRE locking bug
From: David Miller @ 2010-10-25 19:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: ben, netdev, beatrice.barbe, 599816
In-Reply-To: <1287478956.2676.13.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 19 Oct 2010 11:02:36 +0200
> Le mardi 19 octobre 2010 à 01:53 -0700, David Miller a écrit :
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Thu, 14 Oct 2010 06:11:59 +0200
>>
>> > net-next-2.6 contains a fix for this, adding the perc_cpu
>> > xmit_recursion limit. We might push it to net-2.6
>>
>> We need to think a bit more about this.
>>
>> We are essentially now saying that one can only configure
>> tunnels 3 levels deep, and no more.
>>
>> I can guarentee you someone out there uses at least 4,
>> perhaps more.
>>
>> And those people will be broken by the new limit.
>>
>> So putting this into net-2.6 with such a low limit will
>> be quite dangerous.
>
> Well limit is actually 4, but I get your point ;)
I'll commit the following to upstream, and submit a combined
patch to -stable.
--------------------
net: Increase xmit RECURSION_LIMIT to 10.
Three is definitely too low, and we know from reports that GRE tunnels
stacked as deeply as 37 levels cause stack overflows, so pick some
reasonable value between those two.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/core/dev.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 78b5a89..2c7da3a 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2213,7 +2213,7 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
}
static DEFINE_PER_CPU(int, xmit_recursion);
-#define RECURSION_LIMIT 3
+#define RECURSION_LIMIT 10
/**
* dev_queue_xmit - transmit a buffer
--
1.7.3.2
^ permalink raw reply related
* Re: [RFC] ixgbe: v3 normalize frag_list usage
From: David Miller @ 2010-10-25 19:47 UTC (permalink / raw)
To: alexander.h.duyck
Cc: jeffrey.t.kirsher, jesse.brandeburg, bruce.w.allan, netdev
In-Reply-To: <80769D7B14936844A23C0C43D9FBCF0F25BC8DEC85@orsmsx501.amr.corp.intel.com>
From: "Duyck, Alexander H" <alexander.h.duyck@intel.com>
Date: Fri, 8 Oct 2010 16:57:40 -0700
> Below is the new and improved version of the RSC chaining approach. Basically
> I am holding off on merging the SKB into the frame until the SKB has data in
> order to make it take a more standard approach.
>
> Let me know if this will work with the new pointer structure.
This variant looks great, thanks Alexander!
^ permalink raw reply
* Re: [PATCH] mlx4_en: Fix out of bounds array access
From: David Miller @ 2010-10-25 19:16 UTC (permalink / raw)
To: eli-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb
Cc: yevgenyp-VPRAkNaXOzVS1MOuV/RT9w, rdreier-FYB4Gu1CFyUAvxtiuMwx3w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20101025125647.GA7710@mtldesk30>
From: Eli Cohen <eli-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
Date: Mon, 25 Oct 2010 14:56:47 +0200
> When searching for a free entry in either mlx4_register_vlan() or
> mlx4_register_mac(), and there is no free entry, the loop terminates without
> updating the local variable free thus causing out of array bounds access. Fix
> this by adding a proper check outside the loop.
>
> Signed-off-by: Eli Cohen <eli-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] macb: Don't re-enable interrupts while in polling mode
From: David Miller @ 2010-10-25 19:15 UTC (permalink / raw)
To: Joshua.Hoke
Cc: nicolas.ferre, jpirko, peter.korsgaard, eric.dumazet,
haavard.skinnemoen, netdev, linux-kernel, akpm
In-Reply-To: <C8F551D39A7C724E987CF8DD11D3178304D7CC86@svr3.sixnetio.com>
From: "Joshua Hoke" <Joshua.Hoke@sixnet.com>
Date: Mon, 25 Oct 2010 07:44:22 -0400
> [PATCH] macb: Don't re-enable interrupts while in polling mode
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6] cxgb3: fix device opening error path
From: David Miller @ 2010-10-25 19:15 UTC (permalink / raw)
To: divy; +Cc: netdev, linux-kernel, swise
In-Reply-To: <20101025173502.27055.847.stgit@speedy5.asicdesigners.com>
From: Divy Le Ray <divy@chelsio.com>
Date: Mon, 25 Oct 2010 10:35:02 -0700
> From: Divy Le Ray <divy@chelsio.com>
>
> Only negative return from bind_qsets() should be considered an error and
> propagated.
> It fixes an issue reported by IBM on P Series platform.
>
> Signed-off-by: Divy Le Ray <divy@chelsio.com>
> Tested-by: Nishanth Aravamudan <nacc@us.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] be2net: Fix CSO for UDP packets
From: David Miller @ 2010-10-25 19:15 UTC (permalink / raw)
To: somnath.kotur; +Cc: netdev
In-Reply-To: <20101025111158.GA2009@emulex.com>
From: Somnath Kotur <somnath.kotur@emulex.com>
Date: Mon, 25 Oct 2010 16:41:58 +0530
> We're setting skb->ip_summed to CHECKSUM_NONE for all non-TCP pkts, making the stack
> recompute checksum.This is a bug for UDP pkts for which cso must be used.
>
> Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] be2net: Call netif_carier_off() after register_netdev()
From: David Miller @ 2010-10-25 19:15 UTC (permalink / raw)
To: somnath.kotur; +Cc: netdev
In-Reply-To: <20101025111110.GA1990@emulex.com>
From: Somnath Kotur <somnath.kotur@emulex.com>
Date: Mon, 25 Oct 2010 16:41:10 +0530
> Calling netif_carrier_off before register_netdev was causing the network interface
> to miss a linkwatch pending event leading to an inconsistent state if the link
> is not up when interface is initialized.This is now invoked after register_netdev.
>
> Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] can: Topcliff: PCH_CAN driver: Fix build warnings
From: David Miller @ 2010-10-25 19:14 UTC (permalink / raw)
To: tomoya-linux-ECg8zkTtlr0C6LszWs/t0g
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
masa-korg-ECg8zkTtlr0C6LszWs/t0g, sameo-VuQAYsv1563Yd54FQh9/CA,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w, wg-5Yr1BZd7O62+XT7JhA+gdA,
morinaga526-ECg8zkTtlr0C6LszWs/t0g,
joel.clark-ral2JQCrhuEAvxtiuMwx3w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w, chripell-VaTbYqLCNhc,
qi.wang-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <4CC4EC38.2040208-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
From: Tomoya <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
Date: Mon, 25 Oct 2010 11:32:24 +0900
> @@ -255,21 +255,21 @@ static void pch_can_set_optmode(struct
> pch_can_priv *priv)
This patch has been corrupted by your email client.
^ 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