Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH RESEND 0/9] OLPC: create a generic OLPC EC driver
From: Thomas Gleixner @ 2012-07-26 13:51 UTC (permalink / raw)
  To: Andres Salomon
  Cc: Andrew Morton, Paul Fox, Daniel Drake, Richard A. Smith,
	linux-kernel, libertas-dev, linux-wireless, netdev,
	platform-driver-x86, devel, Ingo Molnar, H. Peter Anvin, x86,
	Dan Williams, John W. Linville, Matthew Garrett, Anton Vorontsov,
	David Woodhouse, Chris Ball, Jon Nettleton, Greg Kroah-Hartman
In-Reply-To: <20120718213713.232e4161@dev.queued.net>

On Wed, 18 Jul 2012, Andres Salomon wrote:
> The OLPC EC (Embedded Controller) code that is currently upstream is
> x86-only, originally written for the XO-1.  Since then, we've had the
> XO-1.5 (also x86), and XO-1.75 (arm-based) enter mass production.  The
> 1.75 uses a vastly different EC protocol, and future hardware revisions
> are likely to change it even further.
> 
> However, the drivers do share quite a bit of code, so it makes sense to
> have a platform-agnostic driver that calls into platform-specific hooks
> for each XO's EC driver.  This is the first stab and creating such a
> beast (with further patches pending).  Aside from the lack of code
> duplication, this is helpful for fixing bugs in one place (for example,
> we fixed an EC suspend/resume bug in 1.75 that I've just seen happen on
> 1.5 without these patches.  With these patches, the problem goes away).
> 
> These patches are against Linus's current HEAD; let me know if they
> don't apply somewhere, and I'll happily redo them against the -next
> tree.  I'm assuming that these changes (which touch places like x86,
> wireless, and staging) should go through either the x86 tree, or
> through akpm's tree.
> 
> Alternatively, if the reviews are positive and I can get SOBs from the
> relevant maintainers, I can set up a platform-olpc tree somewhere and
> request a pull from Linus.

Either via akpm or a separate tree are fine with me.

Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
 

^ permalink raw reply

* Re: orphan process is causing deadlock in __kernel_vsyscall ()
From: Sri Ram Vemulpali @ 2012-07-26 12:54 UTC (permalink / raw)
  To: linux-kernel-mail, linux-newbie, linux-netdev, kernelnewbies,
	Kernel-newbies
In-Reply-To: <CALyraeOQZ+FPTqaOk6XjHsZwwCfNuo2XLo6bhw44maSEkDf7tA@mail.gmail.com>

> Hello All,
>
> I am debugging a problem which I do not know how to solve. I know what
> is happening, but cannot find solution to it. If anyone has any
> suggestions or solution that would be really grateful and I appreciate
> it.
>
> Here is the description.
>
> I have a thread which spawns a child process using fork() and in child
> context it execv to shell and parent thread waits on waitpid(). This
> child process is nothing but a shell /bin/sh, so that from program I
> can create shell and run some commands.
> In this shell instance, I run tshark for capturing network traffic. I
> have really high traffic going, so system is really busy. All is good
> so far, but when I send SIGKILL to child process (shell) from another
> thread from same application,
> child process (shell) gets terminated and tshark is assigned to
> init(1) process as orphan. The parent thread which spawned the child
> process unblocks from waitpid() after cleaning child instance and
> continues it execution.
>
> Here is the problem:
> Once the parent thread resumes from waitpid(), it hits fprintf to
> print message "exiting from shell" to console. In here the main thread
> gets blocked in __kernel_vsyscall () entered from fprintf. Following
> is my stack trace from gdb.
> But after some more debugging and found that, if I kill from another
> shell "tshark" process which is assigned to init(1) as child, the
> parent thread unblocks from __kernel_vsyscall ().
>
> Can anyone tell what is going on, is this related to futex spinning
> problem where lock is been held by tshark. How would I approach this
> problem?
> Or is there a way to kill all child process of a process without
> making them orphan. Because when a child process is running at the
> time parent is exiting, that child process is assigned to init(1) as
> orphan process.
> Can this behavior be modified. Please let me know any suggestions and
> thoughts. Thanks in advance.
>
> --
> Regards,
> Sri.
>
> (gdb) backtrace
> #0  0xffffe424 in __kernel_vsyscall ()
> #1  0xb7e6396b in write () from /lib/libc.so.6
> #2  0xb7e0c2ef in _IO_new_file_write () from /lib/libc.so.6
> #3  0xb7e0bf93 in new_do_write () from /lib/libc.so.6
> #4  0xb7e0c296 in _IO_new_do_write () from /lib/libc.so.6
> #5  0xb7e0ce20 in _IO_new_file_overflow () from /lib/libc.so.6
> #6  0xb7e0c0cd in _IO_new_file_xsputn () from /lib/libc.so.6
> #7  0xb7de3634 in vfprintf () from /lib/libc.so.6
> #8  0x09ad62a2 in acme_fprintf (stream=0xb7ee2560,
>     format=0x9f17694 "shell exited. returning to acli\n")
>     at /home/svemulpali/cc/svemulpali_SCOTTY_main/linux/private/common/src/coutOverride.cpp:42
> #9  0x094a9345 in vxShellCmdStartWait (syscmd=0x0)
>     at /home/svemulpali/cc/svemulpali_SCOTTY_main/linux/private/lib/stub/vxShellLib.cpp:210



-- 
Regards,
Sri.
--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

^ permalink raw reply

* r8169, 3.5.0, does't work at all
From: Denys Fedoryshchenko @ 2012-07-26 11:58 UTC (permalink / raw)
  To: netdev, romieu

Just pushed new kernel to test cluster and got this:

[    1.604470] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[    1.604709] r8169 0000:02:00.0: irq 43 for MSI/MSI-X
[    1.605211] r8169 0000:02:00.0: eth0: RTL8168b/8111b at 0xf8604000, 
00:08:54:57:7a:54, XID 18000000 IRQ 43
[    1.605364] r8169 0000:02:00.0: eth0: jumbo features [frames: 4080 
bytes, tx checksumming: ko]
[    1.605549] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[    1.605780] r8169 0000:03:00.0: irq 44 for MSI/MSI-X
[    1.606212] r8169 0000:03:00.0: eth1: RTL8168b/8111b at 0xf8606000, 
00:08:54:57:7a:33, XID 18000000 IRQ 44
[    1.606366] r8169 0000:03:00.0: eth1: jumbo features [frames: 4080 
bytes, tx checksumming: ko]
....
[   20.406090]     input device check on
[   20.406177]     Actions configured
[   21.526836] r8169 0000:02:00.0: eth0: link up
[   28.038386] ------------[ cut here ]------------
[   28.038438] WARNING: at net/sched/sch_generic.c:255 
dev_watchdog+0xd6/0x12a()
[   28.038489] Hardware name:
[   28.038534] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed 
out
[   28.038584] Modules linked in: cls_flow cls_u32 em_meta cls_basic 
xt_dscp ts_bm xt_string xt_hl ifb cls_fw sch_tbf sch_htb act_ipt 
act_mirred ipt_REDIRECT ipt_REJECT xt_TCPMSS xt_DSCP xt_mark 
iptable_mangle iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack 
nf_defrag_ipv4 iptable_filter 8021q garp stp llc loop usb_storage mei 
lpc_ich mfd_core ahci libahci libata sr_mod cdrom tulip r8169 sky2 
via_velocity via_rhine sis900 ne2k_pci 8390 skge tg3 libphy 8139too 
e1000 e100 usbhid ohci_hcd uhci_hcd ehci_hcd usbcore usb_common [last 
unloaded: usb_storage]
[   28.038616] Pid: 4, comm: kworker/0:0 Not tainted 3.5.0-build-0063 
#4
[   28.038617] Call Trace:
[   28.038620]  [<c0127962>] warn_slowpath_common+0x77/0x8c
[   28.038623]  [<c02f507e>] ? dev_watchdog+0xd6/0x12a
[   28.038625]  [<c02f507e>] ? dev_watchdog+0xd6/0x12a
[   28.038628]  [<c01279f3>] warn_slowpath_fmt+0x2e/0x30
[   28.038630]  [<c02f507e>] dev_watchdog+0xd6/0x12a
[   28.038633]  [<c0131c45>] run_timer_softirq+0x1ab/0x254
[   28.038635]  [<c0131bc9>] ? run_timer_softirq+0x12f/0x254
[   28.038638]  [<c015d181>] ? trace_hardirqs_on_caller+0xf5/0x13f
[   28.038640]  [<c02f4fa8>] ? netif_tx_unlock+0x41/0x41
[   28.038643]  [<c012d38e>] __do_softirq+0x7b/0x118
[   28.038644]  [<c012d313>] ? local_bh_enable+0xd/0xd
[   28.038645]  <IRQ>  [<c012d5a9>] ? irq_exit+0x41/0x91
[   28.038650]  [<c0118ac0>] ? smp_apic_timer_interrupt+0x64/0x71
[   28.038652]  [<c023054c>] ? trace_hardirqs_off_thunk+0xc/0x10
[   28.038655]  [<c0353977>] ? apic_timer_interrupt+0x2f/0x34
[   28.038661]  [<f85f7e9f>] ? rtl_slow_event_work+0x14/0x1a2 [r8169]
[   28.038664]  [<c0351898>] ? mutex_lock_nested+0x20/0x22
[   28.038667]  [<f85f49d1>] ? rtl_task+0x49/0x5f [r8169]
[   28.038670]  [<c013992a>] ? process_one_work+0x1a1/0x2ab
[   28.038672]  [<c01398b9>] ? process_one_work+0x130/0x2ab
[   28.038675]  [<f85f4988>] ? rtl8169_set_features+0x39/0x39 [r8169]
[   28.038678]  [<c013a3be>] ? worker_thread+0xd1/0x14c
[   28.038680]  [<c013a2ed>] ? manage_workers.clone.20+0x14e/0x14e
[   28.038682]  [<c013d3ec>] ? kthread+0x67/0x6c
[   28.038685]  [<c0350000>] ? migration_call+0x10/0x189
[   28.038687]  [<c013d385>] ? __init_kthread_worker+0x47/0x47
[   28.038689]  [<c03542fa>] ? kernel_thread_helper+0x6/0xd
[   28.038690] ---[ end trace 9701f577e9a74181 ]---
[   28.043532] r8169 0000:02:00.0: eth0: link up
[   34.043357] r8169 0000:02:00.0: eth0: link up
[   40.043202] r8169 0000:02:00.0: eth0: link up
[   46.043052] r8169 0000:02:00.0: eth0: link up
[   52.042893] r8169 0000:02:00.0: eth0: link up
[   58.042739] r8169 0000:02:00.0: eth0: link up
[   64.042584] r8169 0000:02:00.0: eth0: link up
[   70.042430] r8169 0000:02:00.0: eth0: link up
[   76.042276] r8169 0000:02:00.0: eth0: link up
[   82.042123] r8169 0000:02:00.0: eth0: link up
[   88.041968] r8169 0000:02:00.0: eth0: link up
[   94.041813] r8169 0000:02:00.0: eth0: link up

---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.

^ permalink raw reply

* [net] ixgbe: fix panic while dumping packets on Tx hang with IOMMU
From: Jeff Kirsher @ 2012-07-26 11:21 UTC (permalink / raw)
  To: davem; +Cc: Emil Tantilov, netdev, gospo, sassmann, Jeff Kirsher

From: Emil Tantilov <emil.s.tantilov@intel.com>

This patch resolves a "BUG: unable to handle kernel paging request at ..."
oops while dumping packet data. The issue occurs with IOMMU enabled due to
the address provided by phys_to_virt().

This patch makes use of skb->data on Tx and the virtual address of the pages
allocated for Rx.

Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 3b6784c..c709eae 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -396,11 +396,10 @@ static void ixgbe_dump(struct ixgbe_adapter *adapter)
 				pr_cont("\n");
 
 			if (netif_msg_pktdata(adapter) &&
-			    dma_unmap_len(tx_buffer, len) != 0)
+			    tx_buffer->skb)
 				print_hex_dump(KERN_INFO, "",
 					DUMP_PREFIX_ADDRESS, 16, 1,
-					phys_to_virt(dma_unmap_addr(tx_buffer,
-								    dma)),
+					tx_buffer->skb->data,
 					dma_unmap_len(tx_buffer, len),
 					true);
 		}
@@ -474,10 +473,12 @@ rx_ring_summary:
 					(u64)rx_buffer_info->dma,
 					rx_buffer_info->skb);
 
-				if (netif_msg_pktdata(adapter)) {
+				if (netif_msg_pktdata(adapter) &&
+				    rx_buffer_info->dma) {
 					print_hex_dump(KERN_INFO, "",
 					   DUMP_PREFIX_ADDRESS, 16, 1,
-					   phys_to_virt(rx_buffer_info->dma),
+					   page_address(rx_buffer_info->page) +
+						    rx_buffer_info->page_offset,
 					   ixgbe_rx_bufsz(rx_ring), true);
 				}
 			}
-- 
1.7.11.2

^ permalink raw reply related

* [PATCH] ipv6: Early TCP socket demux
From: Eric Dumazet @ 2012-07-26 10:34 UTC (permalink / raw)
  To: David Miller; +Cc: netdev

From: Eric Dumazet <edumazet@google.com>

This is the IPv6 missing bits for infratructure added in commit
41063e9dd1195 (ipv4: Early TCP socket demux.)

Signed-off-by: Eric Dumazet <edumazet@google.com>
---
 include/net/protocol.h |    2 ++
 net/ipv6/ip6_input.c   |   13 +++++++++++--
 net/ipv6/tcp_ipv6.c    |   38 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 51 insertions(+), 2 deletions(-)

diff --git a/include/net/protocol.h b/include/net/protocol.h
index 057f2d3..929528c 100644
--- a/include/net/protocol.h
+++ b/include/net/protocol.h
@@ -52,6 +52,8 @@ struct net_protocol {
 
 #if IS_ENABLED(CONFIG_IPV6)
 struct inet6_protocol {
+	void	(*early_demux)(struct sk_buff *skb);
+
 	int	(*handler)(struct sk_buff *skb);
 
 	void	(*err_handler)(struct sk_buff *skb,
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
index 5ab923e..47975e3 100644
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -47,9 +47,18 @@
 
 
 
-inline int ip6_rcv_finish( struct sk_buff *skb)
+int ip6_rcv_finish(struct sk_buff *skb)
 {
-	if (skb_dst(skb) == NULL)
+	if (sysctl_ip_early_demux && !skb_dst(skb)) {
+		const struct inet6_protocol *ipprot;
+
+		rcu_read_lock();
+		ipprot = rcu_dereference(inet6_protos[ipv6_hdr(skb)->nexthdr]);
+		if (ipprot && ipprot->early_demux)
+			ipprot->early_demux(skb);
+		rcu_read_unlock();
+	}
+	if (!skb_dst(skb))
 		ip6_route_input(skb);
 
 	return dst_input(skb);
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index f49476e..221224e 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1674,6 +1674,43 @@ do_time_wait:
 	goto discard_it;
 }
 
+static void tcp_v6_early_demux(struct sk_buff *skb)
+{
+	const struct ipv6hdr *hdr;
+	const struct tcphdr *th;
+	struct sock *sk;
+
+	if (skb->pkt_type != PACKET_HOST)
+		return;
+
+	if (!pskb_may_pull(skb, skb_transport_offset(skb) + sizeof(struct tcphdr)))
+		return;
+
+	hdr = ipv6_hdr(skb);
+	th = tcp_hdr(skb);
+
+	if (th->doff < sizeof(struct tcphdr) / 4)
+		return;
+
+	sk = __inet6_lookup_established(dev_net(skb->dev), &tcp_hashinfo,
+					&hdr->saddr, th->source,
+					&hdr->daddr, ntohs(th->dest),
+					inet6_iif(skb));
+	if (sk) {
+		skb->sk = sk;
+		skb->destructor = sock_edemux;
+		if (sk->sk_state != TCP_TIME_WAIT) {
+			struct dst_entry *dst = sk->sk_rx_dst;
+			struct inet_sock *icsk = inet_sk(sk);
+			if (dst)
+				dst = dst_check(dst, 0);
+			if (dst &&
+			    icsk->rx_dst_ifindex == inet6_iif(skb))
+				skb_dst_set_noref(skb, dst);
+		}
+	}
+}
+
 static struct timewait_sock_ops tcp6_timewait_sock_ops = {
 	.twsk_obj_size	= sizeof(struct tcp6_timewait_sock),
 	.twsk_unique	= tcp_twsk_unique,
@@ -1984,6 +2021,7 @@ struct proto tcpv6_prot = {
 };
 
 static const struct inet6_protocol tcpv6_protocol = {
+	.early_demux	=	tcp_v6_early_demux,
 	.handler	=	tcp_v6_rcv,
 	.err_handler	=	tcp_v6_err,
 	.gso_send_check	=	tcp_v6_gso_send_check,

^ permalink raw reply related

* Re: [PATCH] bcma: fix regression in pmu workaround reg masks
From: David Miller @ 2012-07-26 10:06 UTC (permalink / raw)
  To: hauke
  Cc: torvalds, linville, brcm80211-dev-list, linux-wireless, netdev,
	linux-kernel, seth.forshee, pieterpg, brudley, arend, zajec5
In-Reply-To: <1343294151-5691-1-git-send-email-hauke@hauke-m.de>

From: Hauke Mehrtens <hauke@hauke-m.de>
Date: Thu, 26 Jul 2012 11:15:51 +0200

> This fixes a regression introduced in:
> commit b9562545ef0b13c0440ccd8d6dd4111fb77cb17a
> Author: Hauke Mehrtens <hauke@hauke-m.de>
> Date:   Sat Jun 30 01:44:41 2012 +0200
> 
>     bcma: complete workaround for BCMA43224 and BCM4313
> 
> The regression broke reading of the sprom from the chip and seamed to
> cause a change of the pci id on a BCMA43224 device so that it is
> rejected by brcmsmac. If this problem occurred, after applying this
> patch, a cold boot is needed to make the device work again.
> 
> In the original patch the workaround set the intended bits in the chip
> common core chip control registers, but the patch also unset all the
> other bits in that register, because of a wrong mask. The original
> patch was based on code from brcmsmac and there was an additional
> inversing of the mask in the code setting these regs which was missing
> here. Now the regs are set like brcmsmac did it before.
> 
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
> Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
> Tested-by: Seth Forshee <seth.forshee@canonical.com>

Acked-by: David S. Miller <davem@davemloft.net>

^ permalink raw reply

* [PATCH iproute2] ss: report SK_MEMINFO_BACKLOG
From: Eric Dumazet @ 2012-07-26  9:20 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: netdev, Vijay Subramanian

From: Eric Dumazet <edumazet@google.com>

linux-3.6-rc1 supports SK_MEMINFO_BACKLOG with commit d594e987c6f54
(sock_diag: add SK_MEMINFO_BACKLOG)

ss command can display it if provided by the kernel.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Vijay Subramanian <subramanian.vijay@gmail.com>
---
 include/linux/sock_diag.h |    1 +
 misc/ss.c                 |   13 ++++++++++---
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/include/linux/sock_diag.h b/include/linux/sock_diag.h
index 39e4b1c..ac9db19 100644
--- a/include/linux/sock_diag.h
+++ b/include/linux/sock_diag.h
@@ -18,6 +18,7 @@ enum {
 	SK_MEMINFO_FWD_ALLOC,
 	SK_MEMINFO_WMEM_QUEUED,
 	SK_MEMINFO_OPTMEM,
+	SK_MEMINFO_BACKLOG,
 
 	SK_MEMINFO_VARS,
 };
diff --git a/misc/ss.c b/misc/ss.c
index cf529ef..d8429cc 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -1337,8 +1337,9 @@ static void tcp_show_info(const struct nlmsghdr *nlh, struct inet_diag_msg *r)
 		     nlh->nlmsg_len - NLMSG_LENGTH(sizeof(*r)));
 
 	if (tb[INET_DIAG_SKMEMINFO]) {
-		const __u32 *skmeminfo =  RTA_DATA(tb[INET_DIAG_SKMEMINFO]);
-		printf(" skmem:(r%u,rb%u,t%u,tb%u,f%u,w%u,o%u)",
+		const __u32 *skmeminfo = RTA_DATA(tb[INET_DIAG_SKMEMINFO]);
+
+		printf(" skmem:(r%u,rb%u,t%u,tb%u,f%u,w%u,o%u",
 			skmeminfo[SK_MEMINFO_RMEM_ALLOC],
 			skmeminfo[SK_MEMINFO_RCVBUF],
 			skmeminfo[SK_MEMINFO_WMEM_ALLOC],
@@ -1346,7 +1347,13 @@ static void tcp_show_info(const struct nlmsghdr *nlh, struct inet_diag_msg *r)
 			skmeminfo[SK_MEMINFO_FWD_ALLOC],
 			skmeminfo[SK_MEMINFO_WMEM_QUEUED],
 			skmeminfo[SK_MEMINFO_OPTMEM]);
-	}else if (tb[INET_DIAG_MEMINFO]) {
+
+		if (RTA_PAYLOAD(tb[INET_DIAG_SKMEMINFO]) >=
+			(SK_MEMINFO_BACKLOG + 1) * sizeof(__u32))
+			printf(",bl%u", skmeminfo[SK_MEMINFO_BACKLOG]);
+
+		printf(")");
+	} else if (tb[INET_DIAG_MEMINFO]) {
 		const struct inet_diag_meminfo *minfo
 			= RTA_DATA(tb[INET_DIAG_MEMINFO]);
 		printf(" mem:(r%u,w%u,f%u,t%u)",

^ permalink raw reply related

* [PATCH] bcma: fix regression in pmu workaround reg masks
From: Hauke Mehrtens @ 2012-07-26  9:15 UTC (permalink / raw)
  To: torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
  Cc: linville-2XuSBdqkA4R54TAoqtyWWQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
	brcm80211-dev-list-dY08KVG/lbpWk0Htik3J/w,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	seth.forshee-Z7WLFzj8eWMS+FvcfC7Uqw,
	pieterpg-dY08KVG/lbpWk0Htik3J/w, brudley-dY08KVG/lbpWk0Htik3J/w,
	Hauke Mehrtens, Arend van Spriel, Rafał Miłecki

This fixes a regression introduced in:
commit b9562545ef0b13c0440ccd8d6dd4111fb77cb17a
Author: Hauke Mehrtens <hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
Date:   Sat Jun 30 01:44:41 2012 +0200

    bcma: complete workaround for BCMA43224 and BCM4313

The regression broke reading of the sprom from the chip and seamed to
cause a change of the pci id on a BCMA43224 device so that it is
rejected by brcmsmac. If this problem occurred, after applying this
patch, a cold boot is needed to make the device work again.

In the original patch the workaround set the intended bits in the chip
common core chip control registers, but the patch also unset all the
other bits in that register, because of a wrong mask. The original
patch was based on code from brcmsmac and there was an additional
inversing of the mask in the code setting these regs which was missing
here. Now the regs are set like brcmsmac did it before.

Signed-off-by: Hauke Mehrtens <hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
Reported-by: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Tested-by: Seth Forshee <seth.forshee-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Cc: Arend van Spriel <arend-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Cc: Rafał Miłecki <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 drivers/bcma/driver_chipcommon_pmu.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/bcma/driver_chipcommon_pmu.c b/drivers/bcma/driver_chipcommon_pmu.c
index 4432617..c9a4f46 100644
--- a/drivers/bcma/driver_chipcommon_pmu.c
+++ b/drivers/bcma/driver_chipcommon_pmu.c
@@ -110,7 +110,7 @@ void bcma_pmu_workarounds(struct bcma_drv_cc *cc)
 		/* enable 12 mA drive strenth for 4313 and set chipControl
 		   register bit 1 */
 		bcma_chipco_chipctl_maskset(cc, 0,
-					    BCMA_CCTRL_4313_12MA_LED_DRIVE,
+					    ~BCMA_CCTRL_4313_12MA_LED_DRIVE,
 					    BCMA_CCTRL_4313_12MA_LED_DRIVE);
 		break;
 	case BCMA_CHIP_ID_BCM4331:
@@ -124,14 +124,14 @@ void bcma_pmu_workarounds(struct bcma_drv_cc *cc)
 		   register bit 15 */
 		if (bus->chipinfo.rev == 0) {
 			bcma_cc_maskset32(cc, BCMA_CC_CHIPCTL,
-					  BCMA_CCTRL_43224_GPIO_TOGGLE,
+					  ~BCMA_CCTRL_43224_GPIO_TOGGLE,
 					  BCMA_CCTRL_43224_GPIO_TOGGLE);
 			bcma_chipco_chipctl_maskset(cc, 0,
-						    BCMA_CCTRL_43224A0_12MA_LED_DRIVE,
+						    ~BCMA_CCTRL_43224A0_12MA_LED_DRIVE,
 						    BCMA_CCTRL_43224A0_12MA_LED_DRIVE);
 		} else {
 			bcma_chipco_chipctl_maskset(cc, 0,
-						    BCMA_CCTRL_43224B0_12MA_LED_DRIVE,
+						    ~BCMA_CCTRL_43224B0_12MA_LED_DRIVE,
 						    BCMA_CCTRL_43224B0_12MA_LED_DRIVE);
 		}
 		break;
-- 
1.7.9.5

--
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 related

* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: Eric Dumazet @ 2012-07-26  9:12 UTC (permalink / raw)
  To: David Miller; +Cc: alexander.duyck, netdev
In-Reply-To: <20120726.014736.1066206957795563053.davem@davemloft.net>

On Thu, 2012-07-26 at 01:47 -0700, David Miller wrote:

> Indeed, thanks for catching this bug.
> 
> Here's a new version of the patch, as I found another error.  In
> fib_semantics.c, we have to change dst_release() to dst_free() for the
> liberation the nexthop cached routes.

Excellent, I did tests here and this seems ok to me

Tested-by: Eric Dumazet <edumazet@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>

^ permalink raw reply

* [PATCH] iproute: Add route showdump command
From: Pavel Emelyanov @ 2012-07-26  8:53 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: Dan Smith, Linux Netdev List

Some time ago the save+restore commands were added to ip route (git
id f4ff11e3, Add ip route save/restore). These two save the raw rtnl
stream into a file and restore one (reading it from stdin).

The problem is that there's no way to get the contents of the dump
file in a human readable form. How about adding a command that reads
the rtnl stream from stdin and prints the data in a way the usual
"ip route list" does?

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

---

diff --git a/ip/iproute.c b/ip/iproute.c
index 5cd313e..585a7d8 100644
--- a/ip/iproute.c
+++ b/ip/iproute.c
@@ -60,6 +60,7 @@ static void usage(void)
 	fprintf(stderr, "Usage: ip route { list | flush } SELECTOR\n");
 	fprintf(stderr, "       ip route save SELECTOR\n");
 	fprintf(stderr, "       ip route restore\n");
+	fprintf(stderr, "       ip route showdump\n");
 	fprintf(stderr, "       ip route get ADDRESS [ from ADDRESS iif STRING ]\n");
 	fprintf(stderr, "                            [ oif STRING ]  [ tos TOS ]\n");
 	fprintf(stderr, "                            [ mark NUMBER ]\n");
@@ -1526,6 +1527,17 @@ int iproute_restore(void)
 	exit(rtnl_from_file(stdin, &restore_handler, NULL));
 }
 
+static int show_handler(const struct sockaddr_nl *nl, struct nlmsghdr *n, void *arg)
+{
+	print_route(nl, n, stdout);
+	return 0;
+}
+
+static int iproute_showdump(void)
+{
+	exit(rtnl_from_file(stdin, &show_handler, NULL));
+}
+
 void iproute_reset_filter()
 {
 	memset(&filter, 0, sizeof(filter));
@@ -1570,6 +1582,8 @@ int do_iproute(int argc, char **argv)
 		return iproute_list_flush_or_save(argc-1, argv+1, IPROUTE_SAVE);
 	if (matches(*argv, "restore") == 0)
 		return iproute_restore();
+	if (matches(*argv, "showdump") == 0)
+		return iproute_showdump();
 	if (matches(*argv, "help") == 0)
 		usage();
 	fprintf(stderr, "Command \"%s\" is unknown, try \"ip route help\".\n", *argv);

^ permalink raw reply related

* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: David Miller @ 2012-07-26  8:47 UTC (permalink / raw)
  To: eric.dumazet; +Cc: alexander.duyck, netdev
In-Reply-To: <1343291278.2626.11188.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 26 Jul 2012 10:27:58 +0200

> But isnt DST_NOCACHE intent reverted then ?
> 
> like you meant :
> 
> +       } else {
> +               /* Routes we intend to cache in the FIB nexthop have
> +                * the DST_NOCACHE bit unset.  However, if we are
> +                * unsuccessful at storing this route into the cache
> +                * we really need to set that bit.
> +                */
> +               rt->dst.flags |= DST_NOCACHE;
>         }

Indeed, thanks for catching this bug.

Here's a new version of the patch, as I found another error.  In
fib_semantics.c, we have to change dst_release() to dst_free() for the
liberation the nexthop cached routes.

diff --git a/include/net/route.h b/include/net/route.h
index c29ef27..8c52bc6 100644
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -30,6 +30,7 @@
 #include <net/inet_sock.h>
 #include <linux/in_route.h>
 #include <linux/rtnetlink.h>
+#include <linux/rcupdate.h>
 #include <linux/route.h>
 #include <linux/ip.h>
 #include <linux/cache.h>
@@ -157,8 +158,22 @@ static inline struct rtable *ip_route_output_gre(struct net *net, struct flowi4
 	return ip_route_output_key(net, fl4);
 }
 
-extern int ip_route_input(struct sk_buff *skb, __be32 dst, __be32 src,
-			  u8 tos, struct net_device *devin);
+extern int ip_route_input_noref(struct sk_buff *skb, __be32 dst, __be32 src,
+				u8 tos, struct net_device *devin);
+
+static inline int ip_route_input(struct sk_buff *skb, __be32 dst, __be32 src,
+				 u8 tos, struct net_device *devin)
+{
+	int err;
+
+	rcu_read_lock();
+	err = ip_route_input_noref(skb, dst, src, tos, devin);
+	if (!err)
+		skb_dst_force(skb);
+	rcu_read_unlock();
+
+	return err;
+}
 
 extern void ipv4_update_pmtu(struct sk_buff *skb, struct net *net, u32 mtu,
 			     int oif, u32 mark, u8 protocol, int flow_flags);
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index a0124eb..77e87af 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -827,7 +827,7 @@ static int arp_process(struct sk_buff *skb)
 	}
 
 	if (arp->ar_op == htons(ARPOP_REQUEST) &&
-	    ip_route_input(skb, tip, sip, 0, dev) == 0) {
+	    ip_route_input_noref(skb, tip, sip, 0, dev) == 0) {
 
 		rt = skb_rtable(skb);
 		addr_type = rt->rt_type;
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index e55171f..da0cc2e 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -172,9 +172,9 @@ static void free_fib_info_rcu(struct rcu_head *head)
 		if (nexthop_nh->nh_exceptions)
 			free_nh_exceptions(nexthop_nh);
 		if (nexthop_nh->nh_rth_output)
-			dst_release(&nexthop_nh->nh_rth_output->dst);
+			dst_free(&nexthop_nh->nh_rth_output->dst);
 		if (nexthop_nh->nh_rth_input)
-			dst_release(&nexthop_nh->nh_rth_input->dst);
+			dst_free(&nexthop_nh->nh_rth_input->dst);
 	} endfor_nexthops(fi);
 
 	release_net(fi->fib_net);
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index 7ad88e5..8d07c97 100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -258,8 +258,8 @@ static void ip_expire(unsigned long arg)
 		/* skb dst is stale, drop it, and perform route lookup again */
 		skb_dst_drop(head);
 		iph = ip_hdr(head);
-		err = ip_route_input(head, iph->daddr, iph->saddr,
-				     iph->tos, head->dev);
+		err = ip_route_input_noref(head, iph->daddr, iph->saddr,
+					   iph->tos, head->dev);
 		if (err)
 			goto out_rcu_unlock;
 
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 93134b0..bda8cac 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -339,8 +339,8 @@ static int ip_rcv_finish(struct sk_buff *skb)
 	 *	how the packet travels inside Linux networking.
 	 */
 	if (!skb_dst(skb)) {
-		int err = ip_route_input(skb, iph->daddr, iph->saddr,
-					 iph->tos, skb->dev);
+		int err = ip_route_input_noref(skb, iph->daddr, iph->saddr,
+					       iph->tos, skb->dev);
 		if (unlikely(err)) {
 			if (err == -EXDEV)
 				NET_INC_STATS_BH(dev_net(skb->dev),
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 3f7bb71..7a591aa 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1199,10 +1199,9 @@ restart:
 	fnhe->fnhe_stamp = jiffies;
 }
 
-static inline void rt_release_rcu(struct rcu_head *head)
+static inline void rt_free(struct rtable *rt)
 {
-	struct dst_entry *dst = container_of(head, struct dst_entry, rcu_head);
-	dst_release(dst);
+	call_rcu_bh(&rt->dst.rcu_head, dst_rcu_free);
 }
 
 static void rt_cache_route(struct fib_nh *nh, struct rtable *rt)
@@ -1216,9 +1215,15 @@ static void rt_cache_route(struct fib_nh *nh, struct rtable *rt)
 
 	prev = cmpxchg(p, orig, rt);
 	if (prev == orig) {
-		dst_clone(&rt->dst);
 		if (orig)
-			call_rcu_bh(&orig->dst.rcu_head, rt_release_rcu);
+			rt_free(orig);
+	} else {
+		/* Routes we intend to cache in the FIB nexthop have
+		 * the DST_NOCACHE bit clear.  However, if we are
+		 * unsuccessful at storing this route into the cache
+		 * we really need to set it.
+		 */
+		rt->dst.flags |= DST_NOCACHE;
 	}
 }
 
@@ -1245,7 +1250,7 @@ static void rt_set_nexthop(struct rtable *rt, __be32 daddr,
 #ifdef CONFIG_IP_ROUTE_CLASSID
 		rt->dst.tclassid = nh->nh_tclassid;
 #endif
-		if (!(rt->dst.flags & DST_HOST))
+		if (!(rt->dst.flags & DST_NOCACHE))
 			rt_cache_route(nh, rt);
 	}
 
@@ -1261,7 +1266,7 @@ static struct rtable *rt_dst_alloc(struct net_device *dev,
 				   bool nopolicy, bool noxfrm, bool will_cache)
 {
 	return dst_alloc(&ipv4_dst_ops, dev, 1, DST_OBSOLETE_FORCE_CHK,
-			 (will_cache ? 0 : DST_HOST) | DST_NOCACHE |
+			 (will_cache ? 0 : (DST_HOST | DST_NOCACHE)) |
 			 (nopolicy ? DST_NOPOLICY : 0) |
 			 (noxfrm ? DST_NOXFRM : 0));
 }
@@ -1588,8 +1593,9 @@ local_input:
 		if (!itag) {
 			rth = FIB_RES_NH(res).nh_rth_input;
 			if (rt_cache_valid(rth)) {
-				dst_hold(&rth->dst);
-				goto set_and_out;
+				skb_dst_set_noref(skb, &rth->dst);
+				err = 0;
+				goto out;
 			}
 			do_cache = true;
 		}
@@ -1620,7 +1626,6 @@ local_input:
 	}
 	if (do_cache)
 		rt_cache_route(&FIB_RES_NH(res), rth);
-set_and_out:
 	skb_dst_set(skb, &rth->dst);
 	err = 0;
 	goto out;
@@ -1658,8 +1663,8 @@ martian_source_keep_err:
 	goto out;
 }
 
-int ip_route_input(struct sk_buff *skb, __be32 daddr, __be32 saddr,
-		   u8 tos, struct net_device *dev)
+int ip_route_input_noref(struct sk_buff *skb, __be32 daddr, __be32 saddr,
+			 u8 tos, struct net_device *dev)
 {
 	int res;
 
@@ -1702,7 +1707,7 @@ int ip_route_input(struct sk_buff *skb, __be32 daddr, __be32 saddr,
 	rcu_read_unlock();
 	return res;
 }
-EXPORT_SYMBOL(ip_route_input);
+EXPORT_SYMBOL(ip_route_input_noref);
 
 /* called with rcu_read_lock() */
 static struct rtable *__mkroute_output(const struct fib_result *res,
diff --git a/net/ipv4/xfrm4_input.c b/net/ipv4/xfrm4_input.c
index 58d23a5..06814b6 100644
--- a/net/ipv4/xfrm4_input.c
+++ b/net/ipv4/xfrm4_input.c
@@ -27,8 +27,8 @@ static inline int xfrm4_rcv_encap_finish(struct sk_buff *skb)
 	if (skb_dst(skb) == NULL) {
 		const struct iphdr *iph = ip_hdr(skb);
 
-		if (ip_route_input(skb, iph->daddr, iph->saddr,
-				   iph->tos, skb->dev))
+		if (ip_route_input_noref(skb, iph->daddr, iph->saddr,
+					 iph->tos, skb->dev))
 			goto drop;
 	}
 	return dst_input(skb);

^ permalink raw reply related

* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: Eric Dumazet @ 2012-07-26  8:27 UTC (permalink / raw)
  To: David Miller; +Cc: alexander.duyck, netdev
In-Reply-To: <20120726.011853.973075299731735416.davem@davemloft.net>

On Thu, 2012-07-26 at 01:18 -0700, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 26 Jul 2012 10:13:34 +0200
> 
> > On Wed, 2012-07-25 at 17:54 -0700, David Miller wrote:
> >> @@ -1216,9 +1215,15 @@ static void rt_cache_route(struct fib_nh *nh, struct rtable *rt)
> >>  
> >>  	prev = cmpxchg(p, orig, rt);
> >>  	if (prev == orig) {
> >> -		dst_clone(&rt->dst);
> >>  		if (orig)
> >> -			call_rcu_bh(&orig->dst.rcu_head, rt_release_rcu);
> >> +			rt_free(orig);
> >> +	} else {
> >> +		/* Routes we intend to cache in the FIB nexthop have
> >> +		 * the DST_NOCACHE bit set.  However, if we are
> >> +		 * unsuccessful at storing this route into the cache
> >> +		 * we really need to clear that bit.
> >> +		 */
> >> +		rt->dst.flags &= ~DST_NOCACHE;
> >>  	}
> >>  }
> >>  
> > 
> > Not sure why you removed the dst_clone(&rt->dst) ?
> 
> Because "cached" dst objects have no reference count.  When such a
> cached dst is "released", it is dst_free()'d instead of
> dst_release()'d.
> 
> > If it is not needed, we might need to release a reference in the else {}
> > clause, no ?
> 
> Nope.  'rt' has a reference count of one, which is for the caller, not
> for this cached location.

But isnt DST_NOCACHE intent reverted then ?

like you meant :

+       } else {
+               /* Routes we intend to cache in the FIB nexthop have
+                * the DST_NOCACHE bit unset.  However, if we are
+                * unsuccessful at storing this route into the cache
+                * we really need to set that bit.
+                */
+               rt->dst.flags |= DST_NOCACHE;
        }

^ permalink raw reply

* Re: [net-next RFC V5 2/5] virtio_ring: move queue_index to vring_virtqueue
From: Paolo Bonzini @ 2012-07-26  8:20 UTC (permalink / raw)
  To: Sasha Levin
  Cc: krkumar2, habanero, kvm, mst, netdev, mashirle, linux-kernel,
	virtualization, edumazet, tahm, jwhan, davem, sri
In-Reply-To: <1341488454.18786.15.camel@lappy>

Il 05/07/2012 13:40, Sasha Levin ha scritto:
> @@ -275,7 +274,7 @@ static void vm_del_vq(struct virtqueue *vq)
>         vring_del_virtqueue(vq);
>  
>         /* Select and deactivate the queue */
> -       writel(info->queue_index, vm_dev->base + VIRTIO_MMIO_QUEUE_SEL);
> +       writel(virtqueue_get_queue_index(vq), vm_dev->base + VIRTIO_MMIO_QUEUE_SEL);
>         writel(0, vm_dev->base + VIRTIO_MMIO_QUEUE_PFN);
>  

This accesses vq after vring_del_virtqueue has freed it.

Paolo

^ permalink raw reply

* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: David Miller @ 2012-07-26  8:18 UTC (permalink / raw)
  To: eric.dumazet; +Cc: alexander.duyck, netdev
In-Reply-To: <1343290414.2626.11181.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 26 Jul 2012 10:13:34 +0200

> On Wed, 2012-07-25 at 17:54 -0700, David Miller wrote:
>> @@ -1216,9 +1215,15 @@ static void rt_cache_route(struct fib_nh *nh, struct rtable *rt)
>>  
>>  	prev = cmpxchg(p, orig, rt);
>>  	if (prev == orig) {
>> -		dst_clone(&rt->dst);
>>  		if (orig)
>> -			call_rcu_bh(&orig->dst.rcu_head, rt_release_rcu);
>> +			rt_free(orig);
>> +	} else {
>> +		/* Routes we intend to cache in the FIB nexthop have
>> +		 * the DST_NOCACHE bit set.  However, if we are
>> +		 * unsuccessful at storing this route into the cache
>> +		 * we really need to clear that bit.
>> +		 */
>> +		rt->dst.flags &= ~DST_NOCACHE;
>>  	}
>>  }
>>  
> 
> Not sure why you removed the dst_clone(&rt->dst) ?

Because "cached" dst objects have no reference count.  When such a
cached dst is "released", it is dst_free()'d instead of
dst_release()'d.

> If it is not needed, we might need to release a reference in the else {}
> clause, no ?

Nope.  'rt' has a reference count of one, which is for the caller, not
for this cached location.

^ permalink raw reply

* Re: bonding: sync netpoll code with bridge
From: Dan Carpenter @ 2012-07-26  8:17 UTC (permalink / raw)
  To: Cong Wang; +Cc: netdev
In-Reply-To: <1343286905.12207.7.camel@cr0>

On Thu, Jul 26, 2012 at 03:15:05PM +0800, Cong Wang wrote:
> On Wed, 2012-07-25 at 16:47 +0300, Dan Carpenter wrote:
> > Hello Amerigo Wang,
> > 
> > The patch 8a8efa22f51b: "bonding: sync netpoll code with bridge" from 
> > Feb 17, 2011, leads to the following warning:
> > drivers/net/bonding/bond_main.c:1849 bond_enslave()
> > 	 error: scheduling with locks held: 'read_lock:&bond->lock'
> 
> Yeah, makes sense. Just wondering why I didn't catch it when I tested
> that patch. Anyway, could you try the following patch?
> 

The warnings were static checker warnings, not something I tested.

regards,
dan carpenter

^ permalink raw reply

* Re: [PATCH] be2net: Fix to parse RSS hash from Receive completions correctly.
From: David Miller @ 2012-07-26  8:14 UTC (permalink / raw)
  To: sarveshwar.bandi; +Cc: netdev
In-Reply-To: <2594050c-c887-436e-a6ba-01f7d804c03c@exht1.ad.emulex.com>

From: <sarveshwar.bandi@emulex.com>
Date: Thu, 26 Jul 2012 12:59:50 +0530

> From: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>
> 
> Wrong pointer variable is being used to parse the rss hash from
> receive completions leading to corrupted rss_hash values filled into skb.
> 
> Please apply to net.
  ^^^^^^^^^^^^^^^^^^^^

This doesn't belong in the commit message body, put it after the "---"
demarcation.

> Signed-off-by: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: Eric Dumazet @ 2012-07-26  8:13 UTC (permalink / raw)
  To: David Miller; +Cc: alexander.duyck, netdev
In-Reply-To: <20120725.175406.1331203183232530233.davem@davemloft.net>

On Wed, 2012-07-25 at 17:54 -0700, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Wed, 25 Jul 2012 16:39:39 -0700 (PDT)
> 
> > From: David Miller <davem@davemloft.net>
> > Date: Wed, 25 Jul 2012 16:17:32 -0700 (PDT)
> > 
> >> From: Alexander Duyck <alexander.duyck@gmail.com>
> >> Date: Wed, 25 Jul 2012 16:02:45 -0700
> >> 
> >>> Since your patches are in I have started to re-run my tests. I am
> >>> seeing a significant drop in throughput with 8 flows which I expected,
> >>> however it looks like one of the biggest issues I am seeing is that
> >>> the dst_hold and dst_release calls seem to be causing some serious
> >>> cache thrash.  I was at 12.5Mpps w/ 8 flows before the patches, after
> >>> your patches it drops to 8.3Mpps.
> >> 
> >> Yes, this is something we knew would start happening.
> >> 
> >> One idea is to make cached dsts be per-cpu in the nexthops.
> > 
> > Actually I think what really kills your case is the removal of the
> > noref path for route lookups.  I'll work on a patch to restore that
> > in the case where we use cached routes from the FIB nexthops.
> 
> Alex, here is something I tossed together, does it help with the
> dst_hold()/dst_release() overhead at all?
> 

seems good to me, only one question :


>  static void rt_cache_route(struct fib_nh *nh, struct rtable *rt)
> @@ -1216,9 +1215,15 @@ static void rt_cache_route(struct fib_nh *nh, struct rtable *rt)
>  
>  	prev = cmpxchg(p, orig, rt);
>  	if (prev == orig) {
> -		dst_clone(&rt->dst);
>  		if (orig)
> -			call_rcu_bh(&orig->dst.rcu_head, rt_release_rcu);
> +			rt_free(orig);
> +	} else {
> +		/* Routes we intend to cache in the FIB nexthop have
> +		 * the DST_NOCACHE bit set.  However, if we are
> +		 * unsuccessful at storing this route into the cache
> +		 * we really need to clear that bit.
> +		 */
> +		rt->dst.flags &= ~DST_NOCACHE;
>  	}
>  }
>  

Not sure why you removed the dst_clone(&rt->dst) ?

If it is not needed, we might need to release a reference in the else {}
clause, no ?

^ permalink raw reply

* [PATCH] be2net: Fix to parse RSS hash from Receive completions correctly.
From: sarveshwar.bandi @ 2012-07-26  7:29 UTC (permalink / raw)
  To: davem; +Cc: netdev, Sarveshwar Bandi

From: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>

Wrong pointer variable is being used to parse the rss hash from
receive completions leading to corrupted rss_hash values filled into skb.

Please apply to net.

Signed-off-by: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>
---
 drivers/net/ethernet/emulex/benet/be_main.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 4d96771..d38bf6c 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -1397,7 +1397,7 @@ static void be_parse_rx_compl_v1(struct be_eth_rx_compl *compl,
 	rxcp->pkt_type =
 		AMAP_GET_BITS(struct amap_eth_rx_compl_v1, cast_enc, compl);
 	rxcp->rss_hash =
-		AMAP_GET_BITS(struct amap_eth_rx_compl_v1, rsshash, rxcp);
+		AMAP_GET_BITS(struct amap_eth_rx_compl_v1, rsshash, compl);
 	if (rxcp->vlanf) {
 		rxcp->vtm = AMAP_GET_BITS(struct amap_eth_rx_compl_v1, vtm,
 					  compl);
@@ -1429,7 +1429,7 @@ static void be_parse_rx_compl_v0(struct be_eth_rx_compl *compl,
 	rxcp->pkt_type =
 		AMAP_GET_BITS(struct amap_eth_rx_compl_v0, cast_enc, compl);
 	rxcp->rss_hash =
-		AMAP_GET_BITS(struct amap_eth_rx_compl_v0, rsshash, rxcp);
+		AMAP_GET_BITS(struct amap_eth_rx_compl_v0, rsshash, compl);
 	if (rxcp->vlanf) {
 		rxcp->vtm = AMAP_GET_BITS(struct amap_eth_rx_compl_v0, vtm,
 					  compl);
-- 
1.7.9.5

^ permalink raw reply related

* Re: [PATCH net V1] net/mlx4_en: Limit the RFS filter IDs to be < RPS_NO_FILTER
From: David Miller @ 2012-07-26  7:24 UTC (permalink / raw)
  To: ogerlitz; +Cc: oren, netdev, amirv, bhutchings
In-Reply-To: <1343287276-21584-1-git-send-email-ogerlitz@mellanox.com>

From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Thu, 26 Jul 2012 10:21:16 +0300

> From: Amir Vadai <amirv@mellanox.com>
> 
> RFS filter id can't have the special value RPS_NO_FILTER,
> need to skip it when allocating id's.
> 
> CC: Ben Hutchings <bhutchings@solarflare.com>
> Signed-off-by: Amir Vadai <amirv@mellanox.com>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>

Applied, thanks.

^ permalink raw reply

* [PATCH net V1] net/mlx4_en: Limit the RFS filter IDs to be < RPS_NO_FILTER
From: Or Gerlitz @ 2012-07-26  7:21 UTC (permalink / raw)
  To: davem; +Cc: oren, netdev, Amir Vadai, Ben Hutchings, Or Gerlitz

From: Amir Vadai <amirv@mellanox.com>

RFS filter id can't have the special value RPS_NO_FILTER,
need to skip it when allocating id's.

CC: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---

changes from V0:

- only deal with RPS_NO_FILTER

 drivers/net/ethernet/mellanox/mlx4/en_netdev.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index 8864d8b..edd9cb8 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -201,7 +201,7 @@ mlx4_en_filter_alloc(struct mlx4_en_priv *priv, int rxq_index, __be32 src_ip,
 
 	filter->flow_id = flow_id;
 
-	filter->id = priv->last_filter_id++;
+	filter->id = priv->last_filter_id++ % RPS_NO_FILTER;
 
 	list_add_tail(&filter->next, &priv->filters);
 	hlist_add_head(&filter->filter_chain,
-- 
1.7.1

^ permalink raw reply related

* re: bonding: sync netpoll code with bridge
From: Cong Wang @ 2012-07-26  7:15 UTC (permalink / raw)
  To: Dan Carpenter; +Cc: netdev
In-Reply-To: <20120725134710.GA25625@elgon.mountain>

On Wed, 2012-07-25 at 16:47 +0300, Dan Carpenter wrote:
> Hello Amerigo Wang,
> 
> The patch 8a8efa22f51b: "bonding: sync netpoll code with bridge" from 
> Feb 17, 2011, leads to the following warning:
> drivers/net/bonding/bond_main.c:1849 bond_enslave()
> 	 error: scheduling with locks held: 'read_lock:&bond->lock'

Yeah, makes sense. Just wondering why I didn't catch it when I tested
that patch. Anyway, could you try the following patch?

----------->

diff --git a/drivers/net/bonding/bond_main.c
b/drivers/net/bonding/bond_main.c
index 6fae5f3..ab773d4 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1235,7 +1235,7 @@ static inline int slave_enable_netpoll(struct
slave *slave)
 	struct netpoll *np;
 	int err = 0;
 
-	np = kzalloc(sizeof(*np), GFP_KERNEL);
+	np = kzalloc(sizeof(*np), GFP_ATOMIC);
 	err = -ENOMEM;
 	if (!np)
 		goto out;
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index b4c90e4..c78a966 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -734,7 +734,7 @@ int __netpoll_setup(struct netpoll *np, struct
net_device *ndev)
 	}
 
 	if (!ndev->npinfo) {
-		npinfo = kmalloc(sizeof(*npinfo), GFP_KERNEL);
+		npinfo = kmalloc(sizeof(*npinfo), GFP_ATOMIC);
 		if (!npinfo) {
 			err = -ENOMEM;
 			goto out;

^ permalink raw reply related

* Silly dog video brings in over 30K
From: John @ 2012-07-25 18:21 UTC (permalink / raw)
  To: netdev

Hey,

You have to see it to believe it.

What you'll see in this video just brought in
$30K...

http://www.dog-gone-truth.com/lavenia/DGT.aspx

All my best,
John

^ permalink raw reply

* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: David Miller @ 2012-07-26  5:32 UTC (permalink / raw)
  To: alexander.duyck; +Cc: eric.dumazet, netdev
In-Reply-To: <CAKgT0UeNunHysvJvXcPN38B=mAD5FbSiKigsuS7AYC5TEH6BQg@mail.gmail.com>

From: Alexander Duyck <alexander.duyck@gmail.com>
Date: Wed, 25 Jul 2012 19:30:13 -0700

> I downloaded your patch, applied it, rebuilt the kernel, and then
> rebooted.  However after the reboot I am unable to access the system
> remotely.  It looks like I will have to wait until I get into the
> office tomorrow to figure out what happened to the system.
> 
> I will get you an update on if it helped or not once I figure out what
> happened in the morning.

Ok, I may have flubbed the patch, I'll let you know if I find any bugs
in it.

Thanks.

^ permalink raw reply

* Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling
From: Xufeng Zhang @ 2012-07-26  3:12 UTC (permalink / raw)
  To: Vlad Yasevich
  Cc: Neil Horman, xufeng zhang, sri, davem, linux-sctp, netdev,
	linux-kernel
In-Reply-To: <8ea83e51-81d1-407a-be06-98d2c99c876d@email.android.com>

On 7/26/12, Vlad Yasevich <vyasevich@gmail.com> wrote:
> Xufeng Zhang <xufengzhang.main@gmail.com> wrote:
>
>>On 7/26/12, Xufeng Zhang <xufengzhang.main@gmail.com> wrote:
>>> On 7/25/12, Vlad Yasevich <vyasevich@gmail.com> wrote:
>>>>> And after take a moment to look into the relative codes, I think we
>>>>> can implement it
>>>>> by below way:
>>>>> 1). Add a flag(isi_err_needed) in the embedded struct peer of
>>struct
>>>>> struct sctp_association
>>>>> just like sack_needed flag.
>>>>> 2). When "invalid stream identifier" ERROR happens in
>>sctp_eat_data()
>>>>> function, we just
>>>>> set isi_err_needed flag and don't create ERROR chunk and also don't
>>>>> insert SCTP_CMD_REPLY command.
>>>>> 3). In sctp_gen_sack() function, we create ERROR chunk and also
>>insert
>>>>> SCTP_CMD_REPLY command if isi_err_needed flag is set.
>>>>>
>>>>> Is this way proper?
>>>>>
>>>>
>>>> So, I looked at the code, and it looks very simple to do.  We
>>already
>>>> return a specific status from sctp_eat_data() when the error was
>>>> generated.  All you have to do is take the code that generates the
>>error
>>>> and adds it to the command list and give it its own small function
>>that
>>>> you can then call if SCTP_IERROR_BAD_STREAM error was returned.
>>>
>>> No, it will still has the same problem by just doing this.
>>> SCTP_CMD_GEN_SACK command actually don't enqueue SACK to outqueue,
>>> sctp_gen_sack() do this things when processing SCTP_CMD_GEN_SACK
>>command
>>> in sctp_cmd_interpreter().
>>> So it's not enough if we just insert SCTP_ERROR_INV_STRM command
>>after
>>> sctp_eat_data() return SCTP_IERROR_BAD_STREAM in
>>sctp_sf_eat_data_6_2().
>>
>>Yes, I just tried this way, SACK is still bundled after ERROR chunk.
>>But I think my above method is also not fine if there are multiple
>>error DATA chunks
>>bundled in a packet.
>>Really awesome!
>
> 1. Catch the error return.
> 2.  Set flag indicating error is needed.
> 3.  Queue sack as needed.
> 4.  If error flag set call new function to queue error chunk.

Both step 3 and 4 need lots of changes to make it working since
SACK is ready to queue only at the end of the packet and we also
need to deal with multiple "invalid stream identifier" ERROR chunks
in a single packet.


Thanks,
Xufeng Zhang
>
> That should fix things.  Do this in all callers of sctp_eat_data.
>
> -vlad
>
>>
>>
>>Thanks,
>>Xufeng Zhang
>>
>>>
>>>
>>>
>>> Thanks,
>>> Xufeng Zhang
>>>
>>>>
>>>> -vlad
>>>>
>>>>>
>>>>> Thanks,
>>>>> Xufeng Zhang
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Xufeng Zhang
>>>>>>>
>>>>>>> -vlad
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Xufeng Zhang
>>>>>>>>>
>>>>>>>>> -vlad
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Sent from my Android phone with SkitMail. Please excuse my
>>brevity.
>>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>
>
>
> --
> Sent from my Android phone with SkitMail. Please excuse my brevity.
>

^ permalink raw reply

* Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling
From: Vlad Yasevich @ 2012-07-26  2:55 UTC (permalink / raw)
  To: Xufeng Zhang
  Cc: Neil Horman, xufeng zhang, sri, davem, linux-sctp, netdev,
	linux-kernel
In-Reply-To: <CA+=dFziK09TVcK29x1SLg+JanOj6o__bJKf8yohw6dTYCUCF5A@mail.gmail.com>

Xufeng Zhang <xufengzhang.main@gmail.com> wrote:

>On 7/26/12, Xufeng Zhang <xufengzhang.main@gmail.com> wrote:
>> On 7/25/12, Vlad Yasevich <vyasevich@gmail.com> wrote:
>>>> And after take a moment to look into the relative codes, I think we
>>>> can implement it
>>>> by below way:
>>>> 1). Add a flag(isi_err_needed) in the embedded struct peer of
>struct
>>>> struct sctp_association
>>>> just like sack_needed flag.
>>>> 2). When "invalid stream identifier" ERROR happens in
>sctp_eat_data()
>>>> function, we just
>>>> set isi_err_needed flag and don't create ERROR chunk and also don't
>>>> insert SCTP_CMD_REPLY command.
>>>> 3). In sctp_gen_sack() function, we create ERROR chunk and also
>insert
>>>> SCTP_CMD_REPLY command if isi_err_needed flag is set.
>>>>
>>>> Is this way proper?
>>>>
>>>
>>> So, I looked at the code, and it looks very simple to do.  We
>already
>>> return a specific status from sctp_eat_data() when the error was
>>> generated.  All you have to do is take the code that generates the
>error
>>> and adds it to the command list and give it its own small function
>that
>>> you can then call if SCTP_IERROR_BAD_STREAM error was returned.
>>
>> No, it will still has the same problem by just doing this.
>> SCTP_CMD_GEN_SACK command actually don't enqueue SACK to outqueue,
>> sctp_gen_sack() do this things when processing SCTP_CMD_GEN_SACK
>command
>> in sctp_cmd_interpreter().
>> So it's not enough if we just insert SCTP_ERROR_INV_STRM command
>after
>> sctp_eat_data() return SCTP_IERROR_BAD_STREAM in
>sctp_sf_eat_data_6_2().
>
>Yes, I just tried this way, SACK is still bundled after ERROR chunk.
>But I think my above method is also not fine if there are multiple
>error DATA chunks
>bundled in a packet.
>Really awesome!

1. Catch the error return. 
2.  Set flag indicating error is needed.
3.  Queue sack as needed.
4.  If error flag set call new function to queue error chunk.

That should fix things.  Do this in all callers of sctp_eat_data.

-vlad

>
>
>Thanks,
>Xufeng Zhang
>
>>
>>
>>
>> Thanks,
>> Xufeng Zhang
>>
>>>
>>> -vlad
>>>
>>>>
>>>> Thanks,
>>>> Xufeng Zhang
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Xufeng Zhang
>>>>>>
>>>>>> -vlad
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Xufeng Zhang
>>>>>>>>
>>>>>>>> -vlad
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sent from my Android phone with SkitMail. Please excuse my
>brevity.
>>>>>>
>>>>>
>>>
>>>
>>>
>>


-- 
Sent from my Android phone with SkitMail. Please excuse my brevity.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox