* Re: [PATCH 19/20 V2] drivers/net/ethernet/marvell/skge.c: fix error return code
From: David Miller @ 2012-10-07 18:39 UTC (permalink / raw)
To: peter.senna; +Cc: mlindner, shemminger, netdev, linux-kernel, kernel-janitors
In-Reply-To: <1349476856-16075-4-git-send-email-peter.senna@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 20/20 V2] drivers/net/ethernet/marvell/sky2.c: fix error return code
From: David Miller @ 2012-10-07 18:39 UTC (permalink / raw)
To: peter.senna; +Cc: mlindner, shemminger, netdev, linux-kernel, kernel-janitors
In-Reply-To: <1349476856-16075-5-git-send-email-peter.senna@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH V2] net: Fix skb_under_panic oops in neigh_resolve_output
From: David Miller @ 2012-10-07 18:43 UTC (permalink / raw)
To: ramesh.nagappa
Cc: netdev, edumazet, ebiederm, xemul, linux-kernel, ramesh.nagappa
In-Reply-To: <1349500215-22765-1-git-send-email-ramesh.nagappa@gmail.com>
From: ramesh.nagappa@gmail.com
Date: Fri, 5 Oct 2012 22:10:15 -0700
> The retry loop in neigh_resolve_output() and neigh_connected_output()
> call dev_hard_header() with out reseting the skb to network_header.
> This causes the retry to fail with skb_under_panic. The fix is to
> reset the network_header within the retry loop.
>
> Signed-off-by: Ramesh Nagappa <ramesh.nagappa@ericsson.com>
> Reviewed-by: Shawn Lu <shawn.lu@ericsson.com>
> Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
> Reviewed-by: Billie Alsup <billie.alsup@ericsson.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH v2] ipv6: GRO should be ECN friendly
From: David Miller @ 2012-10-07 18:45 UTC (permalink / raw)
To: eric.dumazet; +Cc: herbert, netdev
In-Reply-To: <1349505810.21172.198.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 06 Oct 2012 08:43:30 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> IPv4 side of the problem was addressed in commit a9e050f4e7f9d
> (net: tcp: GRO should be ECN friendly)
>
> This patch does the same, but for IPv6 : A Traffic Class mismatch
> doesnt mean flows are different, but instead should force a flush
> of previous packets.
>
> This patch removes artificial packet reordering problem.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] net: gro: fix a potential crash in skb_gro_reset_offset
From: David Miller @ 2012-10-07 18:50 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, herbert
In-Reply-To: <1349598486.21172.2063.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 07 Oct 2012 10:28:06 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Before accessing skb first fragment, better make sure there
> is one.
>
> This is probably not needed for old kernels, since an ethernet frame
> cannot contain only an ethernet header, but the recent GRO addition
> to tunnels makes this patch needed.
>
> Also skb_gro_reset_offset() can be static, it actually allows
> compiler to inline it.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] vxlan: remove unused including <linux/version.h>
From: David Miller @ 2012-10-07 18:51 UTC (permalink / raw)
To: weiyj.lk; +Cc: shemminger, yongjun_wei, netdev
In-Reply-To: <CAPgLHd-AeX16JeZJv6D6K_wFr2_r4Zp=Q_Hw5BK-iF+mSWRE4w@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Sun, 7 Oct 2012 21:23:06 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Remove including <linux/version.h> that don't need it.
>
> dpatch engine is used to auto generate this patch.
> (https://github.com/weiyj/dpatch)
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ptp: use list_move instead of list_del/list_add
From: David Miller @ 2012-10-07 18:53 UTC (permalink / raw)
To: weiyj.lk; +Cc: linux-net-drivers, bhutchings, yongjun_wei, netdev
In-Reply-To: <CAPgLHd87UYDK7f=scccBq7AAO67=9pcg5CdKBG0+8i0kPFtXAw@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Sun, 7 Oct 2012 21:41:50 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Using list_move() instead of list_del() + list_add().
>
> dpatch engine is used to auto generate this patch.
> (https://github.com/weiyj/dpatch)
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied.
^ permalink raw reply
* Re: [PATCH] Fix PTP dependencies: explicitly select all the possible dependencies.
From: David Miller @ 2012-10-07 18:54 UTC (permalink / raw)
To: haicheng.li; +Cc: fengguang.wu, netdev, linux-kernel
In-Reply-To: <50718E45.1070706@linux.intel.com>
From: Haicheng Li <haicheng.li@linux.intel.com>
Date: Sun, 07 Oct 2012 22:14:29 +0800
Use "pch_gbe: " as the prefix in your patch Subject line,
also:
> @@ -26,6 +26,9 @@ if PCH_GBE
> config PCH_PTP
> bool "PCH PTP clock support"
> default n
> + depends on EXPERIMENTAL
> + select PPS
> + select PTP_1588_CLOCK
This patch is corrupted by your email client.
DO NOT resend this patch without first emailing it to yourself
and verifying that you can in fact apply what you receive in
the email cleanly.
^ permalink raw reply
* Re: [STABLE][3.0][3.2][Add PATCH] phy/fixed: use an unique MDIO bus name
From: David Miller @ 2012-10-07 18:56 UTC (permalink / raw)
To: ben; +Cc: rostedt, linux-kernel, stable, gregkh, florian, netdev
In-Reply-To: <1349624019.16173.113.camel@deadeye.wl.decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Sun, 07 Oct 2012 16:33:39 +0100
> Networking stable fixes are normally vetted, backported and bundled up
> by David, so I'll let him decide on this.
>
> There are a lot more MDIO bus drivers that don't play nicely with
> others, most of which seem to be fixed in mainline. If David agrees
> that these are generally worthwhile then perhaps someone could try to
> gather those up?
I very much am not inclined to backport this stuff, it impacts
an extremely small group of people so the risk/benefit ratio is
simply not worth it for me to do the work.
If someone else does the work and tests it, I'm willing to ACK
it going into -stable.
But this change impacted a lot of MDIO drivers and there were
regressions that needed to be fixed up the first time this stuff
went in.
^ permalink raw reply
* Re: 3.4.1 and 3.5-rc1 Packet lost at 250Mb/s
From: Nieścierowicz Adam @ 2012-10-07 19:18 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Netdev
W dniu 06.07.2012 12:13, Eric Dumazet napisał(a):
> On Fri, 2012-07-06 at 11:47 +0200, Nieścierowicz Adam wrote:
>
>> Hello, Can I send something that will help determine the cause of
>> the
>> problem? W dniu 08.06.2012 11:41, Eric Dumazet napisał(a):
>>
>>> On Fri, 2012-06-08 at 10:58 +0200, Nieścierowicz Adam wrote:
>>>
>>>> Hello, recently we changed on the router kernel from 2.6.38.1 to
>>>> 3.4.1 and noticed 30% packet loss when traffic increases up to
>>>> 250MB / s. Similar is for kernel 3.5-rc1 Here a link to ifstat
>>>> http://wklej.org/id/767577/ [1] [2]
>>> You should give as much as possible delails on your setup
>>> (hardware,
>>> software) lspci cat /proc/cpuinfo cat /proc/interrupts ifconfig -a
>>> tc
>>> -s -d qdisc dmesg netstat -s
>> currently running on 2.6.38.1 and traffic is 100Mb / s lspci:
>> http://wklej.org/id/769102/ [2] /proc/cpuinfo:
>> http://wklej.org/id/769104/ [3] /proc/interrupts:
>> http://wklej.org/id/769106/ [4] ifconfig -a:
>> http://wklej.org/id/769108/ [5] tc -s -d qdisc:
>> http://wklej.org/id/769109/ [6] dmesg: here are some logs from
>> iptables
>> netstat -s: http://wklej.org/id/769110/ [7] lsmod:
>> http://wklej.org/id/769117/ [8] /proc/net/softnet_stat:
>> http://wklej.org/id/769116/ [9]
>
> Same infos of 3.5-rcX kernel would be nice.
>
> What NIC is eth0 ? (dmesg please)
>
> It seems all network traffic on 2.6.38 is handled by a single cpu
> (cpu0)
>
> (seen in /proc/interrupts)
>
> I suspect that with 3.4 or 3.5 kernels, traffic is handled by many
> cpus
> and they hit false sharing and contention.
>
> You probably get better performance doing some affinity tuning :
>
> For example,
> eth0 serviced by cpu0
> eth2 serviced by cpu1
> eth3 serviced by cpu2
> eth5 serviced by cpu3
>
> and so on...
>
> check and/or set /proc/irq/${NUM}/smp_affinity
hello
I would go back to an earlier thread.
Currently is installed kernel 3.6.0 and symptoms are the same
about configuration:
- affinity on
- lspci: http://wklej.org/id/843156/ [10]
- /proc/cpuinfo: http://wklej.org/id/843158/ [11]
- /proc/interrupts: http://wklej.org/id/843161/ [12]
- ifconfig -a: http://wklej.org/id/843162/ [13]
- tc -s -d qdisc: http://wklej.org/id/843164/ [14]
- dmesg: http://wklej.org/id/843166/ [15]
- lsmod: http://wklej.org/id/843167/ [16]
- /proc/net/softnet_stat: /proc/net/softnet_stat
attach something else?
Thanks
^ permalink raw reply
* Re: [PATCH] net, bluetooth: don't attempt to free a channel that wasn't created
From: Gustavo Padovan @ 2012-10-07 21:41 UTC (permalink / raw)
To: Sasha Levin
Cc: Andrei Emeltchenko, marcel-kz+m5ild9QBg9hUCZPvPmw,
johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, davej-H+wXaHxf7aLQT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <506EF827.3060100-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Hi Sasha,
* Sasha Levin <sasha.levin-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> [2012-10-05 11:09:27 -0400]:
> On 10/05/2012 06:22 AM, Andrei Emeltchenko wrote:
> > Hi Sasha,
> >
> > On Thu, Oct 04, 2012 at 07:59:57PM -0400, Sasha Levin wrote:
> >> We may currently attempt to free a channel which wasn't created due to
> >> an error in the initialization path, this would cause a NULL ptr deref.
> >
> > Please put oops dump here.
>
> [ 12.919073] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
> [ 12.919131] IP: [<ffffffff836645c4>] l2cap_chan_put+0x34/0x50
> [ 12.919135] PGD 0
> [ 12.919138] Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [ 12.919193] Dumping ftrace buffer:
> [ 12.919242] (ftrace buffer empty)
> [ 12.919314] Modules linked in:
> [ 12.919318] CPU 1
> [ 12.919319] Pid: 6210, comm: krfcommd Tainted: G W 3.6.0-next-20121004-sasha-00005-gb010653-dirty #30
> [ 12.919374] RIP: 0010:[<ffffffff836645c4>] [<ffffffff836645c4>] l2cap_chan_put+0x34/0x50
> [ 12.919377] RSP: 0000:ffff880066933c38 EFLAGS: 00010246
> [ 12.919378] RAX: ffffffff8366c780 RBX: 0000000000000000 RCX: 6666666666666667
> [ 12.919379] RDX: 0000000000000fa0 RSI: ffffffff84d3f79e RDI: 0000000000000010
> [ 12.919381] RBP: ffff880066933c48 R08: ffffffff859989f8 R09: 0000000000000001
> [ 12.919382] R10: 0000000000000000 R11: 7fffffffffffffff R12: 0000000000000000
> [ 12.919383] R13: ffff88009b00a200 R14: ffff88009b00a200 R15: 0000000000000001
> [ 12.919385] FS: 0000000000000000(0000) GS:ffff880033600000(0000) knlGS:0000000000000000
> [ 12.919437] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 12.919440] CR2: 0000000000000010 CR3: 0000000005026000 CR4: 00000000000406e0
> [ 12.919446] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 12.919451] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 12.919504] Process krfcommd (pid: 6210, threadinfo ffff880066932000, task ffff880065c4b000)
> [ 12.919506] Stack:
> [ 12.919510] ffff88009b00a200 ffff880032084000 ffff880066933c68 ffffffff8366c7bc
> [ 12.919513] 7fffffffffffffff ffff880032084000 ffff880066933c98 ffffffff833ae0ae
> [ 12.919516] ffff880066933ca8 0000000000000000 0000000000000000 ffff88009b00a200
> [ 12.919517] Call Trace:
> [ 12.919522] [<ffffffff8366c7bc>] l2cap_sock_destruct+0x3c/0x80
> [ 12.919527] [<ffffffff833ae0ae>] __sk_free+0x1e/0x1f0
> [ 12.919530] [<ffffffff833ae2f7>] sk_free+0x17/0x20
> [ 12.919585] [<ffffffff8366ca4e>] l2cap_sock_alloc.constprop.5+0x9e/0xd0
> [ 12.919591] [<ffffffff8366cb9e>] l2cap_sock_create+0x7e/0x100
> [ 12.919652] [<ffffffff83a4f32a>] ? _raw_read_lock+0x6a/0x80
> [ 12.919658] [<ffffffff836402c4>] ? bt_sock_create+0x74/0x110
> [ 12.919660] [<ffffffff83640308>] bt_sock_create+0xb8/0x110
> [ 12.919664] [<ffffffff833aa232>] __sock_create+0x282/0x3b0
> [ 12.919720] [<ffffffff833aa0b0>] ? __sock_create+0x100/0x3b0
> [ 12.919725] [<ffffffff836785b0>] ? rfcomm_process_sessions+0x17e0/0x17e0
> [ 12.919779] [<ffffffff833aa37f>] sock_create_kern+0x1f/0x30
> [ 12.919784] [<ffffffff83675714>] rfcomm_l2sock_create+0x44/0x70
> [ 12.919787] [<ffffffff836785b0>] ? rfcomm_process_sessions+0x17e0/0x17e0
> [ 12.919790] [<ffffffff836785fe>] rfcomm_run+0x4e/0x1f0
> [ 12.919846] [<ffffffff836785b0>] ? rfcomm_process_sessions+0x17e0/0x17e0
> [ 12.919852] [<ffffffff81138ee3>] kthread+0xe3/0xf0
> [ 12.919908] [<ffffffff8117b12e>] ? put_lock_stats.isra.14+0xe/0x40
> [ 12.919914] [<ffffffff81138e00>] ? flush_kthread_work+0x1f0/0x1f0
> [ 12.919968] [<ffffffff83a5077c>] ret_from_fork+0x7c/0x90
> [ 12.919973] [<ffffffff81138e00>] ? flush_kthread_work+0x1f0/0x1f0
> [ 12.920161] Code: 83 ec 08 f6 05 ff 58 44 02 04 74 1b 8b 4f 10 48 89 fa 48 c7 c6 d9 d7 d4 84 48 c7 c7 80 9e aa 85 31 c0 e8 80
> ac 3a fe 48 8d 7b 10 <f0> 83 6b 10 01 0f 94 c0 84 c0 74 05 e8 8b e0 ff ff 48 83 c4 08
> [ 12.920165] RIP [<ffffffff836645c4>] l2cap_chan_put+0x34/0x50
> [ 12.920166] RSP <ffff880066933c38>
> [ 12.920167] CR2: 0000000000000010
> [ 12.920417] ---[ end trace 5a9114e8a158ab84 ]---
Can you append the crash output to the commit message and resend this patch?
Gustavo
^ permalink raw reply
* [ANNOUNCE] iptables 1.4.16 release
From: Pablo Neira Ayuso @ 2012-10-07 22:24 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, netfilter, netfilter-announce, lwn
[-- Attachment #1: Type: text/plain, Size: 422 bytes --]
Hi!
The Netfilter project proudly presents:
iptables 1.4.16
This release includes minor bugfixes, improvements and the aliasing
support that allows us to remove superseded matches/targets in the
Linux kernel.
See ChangeLog that comes attached to this email for more details.
You can download it from:
http://www.netfilter.org/projects/iptables/downloads.html
ftp://ftp.netfilter.org/pub/iptables/
Have fun!
[-- Attachment #2: changes-iptables-1.4.16.txt --]
[-- Type: text/plain, Size: 1821 bytes --]
Andreas Schwab (1):
libxt_tcp: print space before, not after "flags:"
Jan Engelhardt (23):
iptables-restore: warn about -t in rule lines
doc: grammatical updates to libxt_SET
libxt_u32: do bounds checking for @'s operands
libxt_devgroup: consolidate devgroup specification parsing
libxt_devgroup: guard against negative numbers
libxt_LED: guard against negative numbers
libxt_*limit: avoid division by zero
Merge remote-tracking branch 'nf/stable'
build: support for automake-1.12
build: separate AC variable replacements from xtables.h
build: have `make clean` remove dep files too
libxtables: consolidate preference logic
iptables: support for target aliases
libxt_NOTRACK: replace as an alias to CT --notrack
iptables: support for match aliases
libxt_state: replace as an alias to xt_conntrack
Merge branch 'master' of git://git.inai.de/iptables
doc: clean up interpunction in state list for xt_conntrack
doc: deduplicate extension descriptions into a new manpage
doc: trim "state" manpage and reference conntrack instead
doc: have NOTRACK manpage point to CT instead
doc: mention iptables-apply in the SEE ALSO sections
Merge branch 'master' of git://git.inai.de/iptables
Jozsef Kadlecsik (1):
New set match revision with --return-nomatch flag support
Michal Kubeček (1):
libip6t_frag: match any frag id by default
Pablo Neira Ayuso (6):
include: add missing linux/netfilter_ipv4/ip_queue.h
ip[6]tables-restore: cleanup to reduce one level of indentation
include: add missing linux/netfilter_ipv4/ip_queue.h
iptables: fix wrong error messages
extensions: libxt_addrtype: fix type in help message
bump version to 1.4.16
^ permalink raw reply
* [ANNOUNCE] iptables 1.4.16.1 release
From: Pablo Neira Ayuso @ 2012-10-07 23:17 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, netfilter, netfilter-announce, lwn
[-- Attachment #1: Type: text/plain, Size: 775 bytes --]
On Mon, Oct 08, 2012 at 12:24:41AM +0200, Pablo Neira Ayuso wrote:
Hi!
The Netfilter project proudly presents:
iptables 1.4.16.1
This release fixes a major breakage introduced by:
commit cd2f9bdbb7f9b737e5d640aafeb78bcd8e3a7adf
Author: Jan Engelhardt <jengelh@inai.de>
Date: Tue Sep 4 05:24:47 2012 +0200
iptables: support for target aliases
This is really unfortunate, it seems this patch has been pushed
mainstream without sufficient testing. We are really sorry for the
inconvenience. Please, don't use 1.4.16, this bug reders it
completely useless.
See ChangeLog that comes attached to this email for more details.
You can download it from:
http://www.netfilter.org/projects/iptables/downloads.html
ftp://ftp.netfilter.org/pub/iptables/
Have fun!
[-- Attachment #2: changes-iptables-1.4.16.1.txt --]
[-- Type: text/plain, Size: 91 bytes --]
Pablo Neira Ayuso (2):
iptables: fix standard target
bump version to 1.4.16.1
^ permalink raw reply
* Re: [ANNOUNCE] iptables 1.4.16.1 release
From: Jan Engelhardt @ 2012-10-08 0:14 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netfilter-devel, netdev, netfilter, netfilter-announce, lwn
In-Reply-To: <20121007231706.GA7400@1984>
On Monday 2012-10-08 01:17, Pablo Neira Ayuso wrote:
>The Netfilter project proudly presents:
>
> iptables 1.4.16.1
>
>iptables -I INPUT -j ACCEPT
>says:
>iptables: No chain/target/match by that name.
>This also breaks iptables-restore, of course. Jan, you'll have to explain
>me how you have tested this.
This was tested by adding rules with different targets that had both
aliases defined and those without.
./iptables/xtables-multi main4 -t raw -N foo
./iptables/xtables-multi main4 -t raw -A foo -j NOTRACK
with kernels that had xt_CT and no xt_CT at all
./iptables/xtables-multi main4 -N foo
./iptables/xtables-multi main4 -A foo -m state --state NEW
with kernels that had xt_conntrack.3, and xt_conntrack.3 removed
(leaving only xt_conntrack.2)
./iptables/xtables-multi main4 -t raw -N bar
./iptables/xtables-multi main4 -t raw -A bar -j MARK --set-xmark 1
./iptables/xtables-multi main4 -t raw -A foo -j bar
plus of course the "standard" (no pun intended) testsuite that we
had so far:
# ./iptables/xtables-multi restore6 tests/options-most.rules
WARNING: --localtz is being replaced by --kerneltz, since "local" is ambiguous.
Note the kernel timezone has caveats - see manpage for details.
As you spotted, options-most.rules did not include -j <verdict>.
While v1.4.16-1-g2aaa7ec fixes -j verdict, it breaks NOTRACK in all
instances. To reuse a line, "you'll have to explain me how you have
tested this."
A patch to what I think should fly is posted as a reply hereto.
Please give that a spin.
^ permalink raw reply
* [PATCH] ath5k: fix potential NULL pointer dereference in ath5k_beacon_update()
From: Wei Yongjun @ 2012-10-08 0:42 UTC (permalink / raw)
To: jirislaby, mickflemm, mcgrof, linville
Cc: yongjun_wei, linux-wireless, ath5k-devel, netdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
The dereference should be moved below the NULL test.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/net/wireless/ath/ath5k/base.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 9fd6d9a..9f31cfa 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -1804,7 +1804,7 @@ ath5k_beacon_update(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
{
int ret;
struct ath5k_hw *ah = hw->priv;
- struct ath5k_vif *avf = (void *)vif->drv_priv;
+ struct ath5k_vif *avf;
struct sk_buff *skb;
if (WARN_ON(!vif)) {
@@ -1819,6 +1819,7 @@ ath5k_beacon_update(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
goto out;
}
+ avf = (void *)vif->drv_priv;
ath5k_txbuf_free_skb(ah, avf->bbuf);
avf->bbuf->skb = skb;
ret = ath5k_beacon_setup(ah, avf->bbuf);
^ permalink raw reply related
* [PATCH v2] vlan: don't deliver frames for unknown vlans to protocols
From: Florian Zumbiehl @ 2012-10-08 1:51 UTC (permalink / raw)
To: Patrick McHardy, David S. Miller, eric.dumazet
Cc: netdev, linux-kernel, jpirko
6a32e4f9dd9219261f8856f817e6655114cfec2f made the vlan code skip marking
vlan-tagged frames for not locally configured vlans as PACKET_OTHERHOST if
there was an rx_handler, as the rx_handler could cause the frame to be received
on a different (virtual) vlan-capable interface where that vlan might be
configured.
As rx_handlers do not necessarily return RX_HANDLER_ANOTHER, this could cause
frames for unknown vlans to be delivered to the protocol stack as if they had
been received untagged.
For example, if an ipv6 router advertisement that's tagged for a locally not
configured vlan is received on an interface with macvlan interfaces attached,
macvlan's rx_handler returns RX_HANDLER_PASS after delivering the frame to the
macvlan interfaces, which caused it to be passed to the protocol stack, leading
to ipv6 addresses for the announced prefix being configured even though those
are completely unusable on the underlying interface.
The fix moves marking as PACKET_OTHERHOST after the rx_handler so the
rx_handler, if there is one, sees the frame unchanged, but afterwards,
before the frame is delivered to the protocol stack, it gets marked whether
there is an rx_handler or not.
Signed-off-by: Florian Zumbiehl <florz@florz.de>
---
NOTE: This was tested on 3.5.4, but massaged to apply on a recent stable
head--in any case this should be carefully reviewed by someone who knows the
code well, in case that wasn't obvious anyhow.
This version completely avoids any new state that could need to be spilled
to RAM, and instead re-checks existence and non-zeroness of the tag. What
do you think?
diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
index a810987..561e130 100644
--- a/include/linux/if_vlan.h
+++ b/include/linux/if_vlan.h
@@ -82,6 +82,8 @@ static inline int is_vlan_dev(struct net_device *dev)
}
#define vlan_tx_tag_present(__skb) ((__skb)->vlan_tci & VLAN_TAG_PRESENT)
+#define vlan_tx_nonzero_tag_present(__skb) \
+ (vlan_tx_tag_present(__skb) && ((__skb)->vlan_tci & VLAN_VID_MASK))
#define vlan_tx_tag_get(__skb) ((__skb)->vlan_tci & ~VLAN_TAG_PRESENT)
#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
@@ -91,7 +93,7 @@ extern struct net_device *__vlan_find_dev_deep(struct net_device *real_dev,
extern struct net_device *vlan_dev_real_dev(const struct net_device *dev);
extern u16 vlan_dev_vlan_id(const struct net_device *dev);
-extern bool vlan_do_receive(struct sk_buff **skb, bool last_handler);
+extern bool vlan_do_receive(struct sk_buff **skb);
extern struct sk_buff *vlan_untag(struct sk_buff *skb);
extern int vlan_vid_add(struct net_device *dev, unsigned short vid);
@@ -120,10 +122,8 @@ static inline u16 vlan_dev_vlan_id(const struct net_device *dev)
return 0;
}
-static inline bool vlan_do_receive(struct sk_buff **skb, bool last_handler)
+static inline bool vlan_do_receive(struct sk_buff **skb)
{
- if (((*skb)->vlan_tci & VLAN_VID_MASK) && last_handler)
- (*skb)->pkt_type = PACKET_OTHERHOST;
return false;
}
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index 8ca533c..f981d37 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -5,7 +5,7 @@
#include <linux/export.h>
#include "vlan.h"
-bool vlan_do_receive(struct sk_buff **skbp, bool last_handler)
+bool vlan_do_receive(struct sk_buff **skbp)
{
struct sk_buff *skb = *skbp;
u16 vlan_id = skb->vlan_tci & VLAN_VID_MASK;
@@ -13,14 +13,8 @@ bool vlan_do_receive(struct sk_buff **skbp, bool last_handler)
struct vlan_pcpu_stats *rx_stats;
vlan_dev = vlan_find_dev(skb->dev, vlan_id);
- if (!vlan_dev) {
- /* Only the last call to vlan_do_receive() should change
- * pkt_type to PACKET_OTHERHOST
- */
- if (vlan_id && last_handler)
- skb->pkt_type = PACKET_OTHERHOST;
+ if (!vlan_dev)
return false;
- }
skb = *skbp = skb_share_check(skb, GFP_ATOMIC);
if (unlikely(!skb))
diff --git a/net/core/dev.c b/net/core/dev.c
index 8398836..c580708 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3273,18 +3273,18 @@ ncls:
&& !skb_pfmemalloc_protocol(skb))
goto drop;
- rx_handler = rcu_dereference(skb->dev->rx_handler);
if (vlan_tx_tag_present(skb)) {
if (pt_prev) {
ret = deliver_skb(skb, pt_prev, orig_dev);
pt_prev = NULL;
}
- if (vlan_do_receive(&skb, !rx_handler))
+ if (vlan_do_receive(&skb))
goto another_round;
else if (unlikely(!skb))
goto unlock;
}
+ rx_handler = rcu_dereference(skb->dev->rx_handler);
if (rx_handler) {
if (pt_prev) {
ret = deliver_skb(skb, pt_prev, orig_dev);
@@ -3304,6 +3304,9 @@ ncls:
}
}
+ if (vlan_tx_nonzero_tag_present(skb))
+ skb->pkt_type = PACKET_OTHERHOST;
+
/* deliver only exact match when indicated */
null_or_dev = deliver_exact ? skb->dev : NULL;
^ permalink raw reply related
* Re: [RFC PATCH net-next] tcp: introduce tcp_tw_interval to specifiy the time of TIME-WAIT
From: Cong Wang @ 2012-10-08 3:17 UTC (permalink / raw)
To: Neil Horman
Cc: netdev, David S. Miller, Alexey Kuznetsov, Patrick McHardy,
Eric Dumazet
In-Reply-To: <20121002120927.GA691@hmsreliant.think-freely.org>
On Tue, 2012-10-02 at 08:09 -0400, Neil Horman wrote:
> No, its not very friendly, but the people using this are violating the RFC,
> which isn't very friendly. :)
Could you be more specific? In RFC 793, AFAIK, it is allowed to be
changed:
http://tools.ietf.org/html/rfc793
" To be sure that a TCP does not create a segment that carries a
sequence number which may be duplicated by an old segment remaining in
the network, the TCP must keep quiet for a maximum segment lifetime
(MSL) before assigning any sequence numbers upon starting up or
recovering from a crash in which memory of sequence numbers in use was
lost. For this specification the MSL is taken to be 2 minutes. This
is an engineering choice, and may be changed if experience indicates
it is desirable to do so."
or I must still be missing something here... :)
^ permalink raw reply
* Re: skge: Add DMA mask quirk for Marvell 88E8001 on ASUS P5NSLI motherboard.
From: Graham Gower @ 2012-10-08 5:33 UTC (permalink / raw)
To: Jan Ceuleers; +Cc: netdev, Stephen Hemminger
In-Reply-To: <50714C45.3080103@computer.org>
On 10/07/2012 08:02 PM, Jan Ceuleers wrote:
> On 10/07/2012 07:55 AM, Graham Gower wrote:
>> Signed-off-by: Graham Gower <graham.gower@gmail.com>
>>
>> --- skge.c.bak 2012-10-07 13:00:56.000000000 +1030
>> +++ skge.c 2012-10-07 13:26:03.000000000 +1030
>> @@ -4143,6 +4143,13 @@
>
> Graham,
>
> Your patch should include the path to the file being patched relative to
> the base directory. So in this case something like
>
> --- a/drivers/net/ethernet/marvell/skge.c ...
> +++ b/drivers/net/ethernet/marvell/skge.c ...
>
> HTH, Jan
>
Thanks, I should know this stuff. Just an oversight because I was
too lazy to clone a repository and diffed against the single file.
-Graham
^ permalink raw reply
* [PATCH v2] skge: Add DMA mask quirk for Marvell 88E8001 on ASUS P5NSLI motherboard.
From: Graham Gower @ 2012-10-08 5:33 UTC (permalink / raw)
To: netdev, Stephen Hemminger
In-Reply-To: <50711961.1010101@gmail.com>
Marvell 88E8001 on an ASUS P5NSLI motherboard is unable to send/receive
packets on a system with >4gb ram unless a 32bit DMA mask is used.
This issue has been around for years and a fix was sent 3.5 years ago, but
there was some debate as to whether it should instead be fixed as a PCI quirk.
http://www.spinics.net/lists/netdev/msg88670.html
However, 18 months later a similar workaround was introduced for another
chipset exhibiting the same problem.
http://www.spinics.net/lists/netdev/msg142287.html
Signed-off-by: Graham Gower <graham.gower@gmail.com>
--- a/drivers/net/ethernet/marvell/skge.c
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -4143,6 +4143,13 @@
DMI_MATCH(DMI_BOARD_NAME, "nForce"),
},
},
+ {
+ .ident = "ASUS P5NSLI",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
+ DMI_MATCH(DMI_BOARD_NAME, "P5NSLI")
+ },
+ },
{}
};
^ permalink raw reply
* Re: [PATCH v2] skge: Add DMA mask quirk for Marvell 88E8001 on ASUS P5NSLI motherboard.
From: David Miller @ 2012-10-08 5:36 UTC (permalink / raw)
To: graham.gower; +Cc: netdev, shemminger
In-Reply-To: <507265B8.5070406@gmail.com>
From: Graham Gower <graham.gower@gmail.com>
Date: Mon, 08 Oct 2012 16:03:44 +1030
> + .ident = "ASUS P5NSLI",
> + .matches = {
> + DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
> + DMI_MATCH(DMI_BOARD_NAME, "P5NSLI")
This is poorly formatted, and your commit message has newlines
in very abrupt places as if you formatted it in your email client
GUI rather than in a text editor.
^ permalink raw reply
* [PATCH v3] skge: Add DMA mask quirk for Marvell 88E8001 on ASUS P5NSLI motherboard.
From: Graham Gower @ 2012-10-08 5:54 UTC (permalink / raw)
To: David Miller; +Cc: netdev, shemminger
In-Reply-To: <20121008.013635.1877246075568372072.davem@davemloft.net>
Marvell 88E8001 on an ASUS P5NSLI motherboard is unable to send/receive
packets on a system with >4gb ram unless a 32bit DMA mask is used.
This issue has been around for years and a fix was sent 3.5 years ago, but
there was some debate as to whether it should instead be fixed as a PCI quirk.
http://www.spinics.net/lists/netdev/msg88670.html
However, 18 months later a similar workaround was introduced for another
chipset exhibiting the same problem.
http://www.spinics.net/lists/netdev/msg142287.html
Signed-off-by: Graham Gower <graham.gower@gmail.com>
--- a/drivers/net/ethernet/marvell/skge.c
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -4143,6 +4143,13 @@
DMI_MATCH(DMI_BOARD_NAME, "nForce"),
},
},
+ {
+ .ident = "ASUS P5NSLI",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
+ DMI_MATCH(DMI_BOARD_NAME, "P5NSLI")
+ },
+ },
{}
};
^ permalink raw reply
* Re: [PATCH v3] skge: Add DMA mask quirk for Marvell 88E8001 on ASUS P5NSLI motherboard.
From: David Miller @ 2012-10-08 6:11 UTC (permalink / raw)
To: graham.gower; +Cc: netdev, shemminger
In-Reply-To: <50726AA4.7080901@gmail.com>
From: Graham Gower <graham.gower@gmail.com>
Date: Mon, 08 Oct 2012 16:24:44 +1030
> Marvell 88E8001 on an ASUS P5NSLI motherboard is unable to
> send/receive
> packets on a system with >4gb ram unless a 32bit DMA mask is used.
This is still oddly formatted.
> + {
> + .ident = "ASUS P5NSLI",
> + .matches = {
> + DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
And this is even worse than before.
^ permalink raw reply
* Re: [PATCH v3] skge: Add DMA mask quirk for Marvell 88E8001 on ASUS P5NSLI motherboard.
From: Graham Gower @ 2012-10-08 6:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev, shemminger
In-Reply-To: <20121008.021128.763232338754014461.davem@davemloft.net>
Thunderbird must be screwing it. I hate mail clients. If I just pipe
the message to 'mail',
with a correct 'From:' line is that ok, or do I have to figure
something else out?
On 8 October 2012 16:41, David Miller <davem@davemloft.net> wrote:
> From: Graham Gower <graham.gower@gmail.com>
> Date: Mon, 08 Oct 2012 16:24:44 +1030
>
>> Marvell 88E8001 on an ASUS P5NSLI motherboard is unable to
>> send/receive
>> packets on a system with >4gb ram unless a 32bit DMA mask is used.
>
> This is still oddly formatted.
>
>> + {
>> + .ident = "ASUS P5NSLI",
>> + .matches = {
>> + DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
>
> And this is even worse than before.
^ permalink raw reply
* Re: [PATCH v3] skge: Add DMA mask quirk for Marvell 88E8001 on ASUS P5NSLI motherboard.
From: David Miller @ 2012-10-08 6:21 UTC (permalink / raw)
To: graham.gower; +Cc: netdev, shemminger
In-Reply-To: <CAFk90B8ZBr+2tpav1b7gYU0s+F-suo85ts-UHLKVarcj7Ptj=A@mail.gmail.com>
From: Graham Gower <graham.gower@gmail.com>
Date: Mon, 8 Oct 2012 16:45:33 +1030
> Thunderbird must be screwing it. I hate mail clients. If I just pipe
> the message to 'mail',
> with a correct 'From:' line is that ok, or do I have to figure
> something else out?
Documentation/email-clients.txt
^ permalink raw reply
* Re: 3.4.1 and 3.5-rc1 Packet lost at 250Mb/s
From: Eric Dumazet @ 2012-10-08 6:22 UTC (permalink / raw)
To: adam.niescierowicz; +Cc: Netdev
In-Reply-To: <409ac8b30a6994028562e1a159ac60aa@justnet.pl>
On Sun, 2012-10-07 at 21:18 +0200, Nieścierowicz Adam wrote:
> W dniu 06.07.2012 12:13, Eric Dumazet napisał(a):
>
> > On Fri, 2012-07-06 at 11:47 +0200, Nieścierowicz Adam wrote:
> >
> >> Hello, Can I send something that will help determine the cause of
> >> the
> >> problem? W dniu 08.06.2012 11:41, Eric Dumazet napisał(a):
> >>
> >>> On Fri, 2012-06-08 at 10:58 +0200, Nieścierowicz Adam wrote:
> >>>
> >>>> Hello, recently we changed on the router kernel from 2.6.38.1 to
> >>>> 3.4.1 and noticed 30% packet loss when traffic increases up to
> >>>> 250MB / s. Similar is for kernel 3.5-rc1 Here a link to ifstat
> >>>> http://wklej.org/id/767577/ [1] [2]
> >>> You should give as much as possible delails on your setup
> >>> (hardware,
> >>> software) lspci cat /proc/cpuinfo cat /proc/interrupts ifconfig -a
> >>> tc
> >>> -s -d qdisc dmesg netstat -s
> >> currently running on 2.6.38.1 and traffic is 100Mb / s lspci:
> >> http://wklej.org/id/769102/ [2] /proc/cpuinfo:
> >> http://wklej.org/id/769104/ [3] /proc/interrupts:
> >> http://wklej.org/id/769106/ [4] ifconfig -a:
> >> http://wklej.org/id/769108/ [5] tc -s -d qdisc:
> >> http://wklej.org/id/769109/ [6] dmesg: here are some logs from
> >> iptables
> >> netstat -s: http://wklej.org/id/769110/ [7] lsmod:
> >> http://wklej.org/id/769117/ [8] /proc/net/softnet_stat:
> >> http://wklej.org/id/769116/ [9]
> >
> > Same infos of 3.5-rcX kernel would be nice.
> >
> > What NIC is eth0 ? (dmesg please)
> >
> > It seems all network traffic on 2.6.38 is handled by a single cpu
> > (cpu0)
> >
> > (seen in /proc/interrupts)
> >
> > I suspect that with 3.4 or 3.5 kernels, traffic is handled by many
> > cpus
> > and they hit false sharing and contention.
> >
> > You probably get better performance doing some affinity tuning :
> >
> > For example,
> > eth0 serviced by cpu0
> > eth2 serviced by cpu1
> > eth3 serviced by cpu2
> > eth5 serviced by cpu3
> >
> > and so on...
> >
> > check and/or set /proc/irq/${NUM}/smp_affinity
>
> hello
> I would go back to an earlier thread.
>
> Currently is installed kernel 3.6.0 and symptoms are the same
>
> about configuration:
>
> - affinity on
>
> - lspci: http://wklej.org/id/843156/ [10]
>
> - /proc/cpuinfo: http://wklej.org/id/843158/ [11]
>
> - /proc/interrupts: http://wklej.org/id/843161/ [12]
>
> - ifconfig -a: http://wklej.org/id/843162/ [13]
>
> - tc -s -d qdisc: http://wklej.org/id/843164/ [14]
>
> - dmesg: http://wklej.org/id/843166/ [15]
>
> - lsmod: http://wklej.org/id/843167/ [16]
>
> - /proc/net/softnet_stat: /proc/net/softnet_stat
>
> attach something else?
>
> Thanks
You should use RPS on eth2/eth3 because they are non multi queue.
Documentation/networking/scaling.txt should give you all the needed info
^ 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