* BUSINESS PROPOSAL, PLEASE CONTACT ME
From: MR RAYMOND CHOONG YEE @ 2011-10-25 23:16 UTC (permalink / raw)
Hello, I am Mr.Raymond Choong Yee H, i seek your attention for the confirmation of a Project. I shall provide you with more details after hearing from you.contact me via (raymondchoongyh@9.cn)
^ permalink raw reply
* Re: Linux 3.1-rc9
From: David Miller @ 2011-10-25 23:18 UTC (permalink / raw)
To: tglx
Cc: torvalds, sim, netdev, a.p.zijlstra, linux-kernel, davej,
schwidefsky, mingo
In-Reply-To: <alpine.LFD.2.02.1110251419170.21837@ionos>
From: Thomas Gleixner <tglx@linutronix.de>
Date: Tue, 25 Oct 2011 14:30:50 +0200 (CEST)
> Subject: net: Unlock sock before calling sk_free()
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Good spotting, applied, thanks Thomas!
^ permalink raw reply
* [PATCH] net/ethernet: sc92031 is not Realtek
From: Cesar Eduardo Barros @ 2011-10-25 22:32 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, David S. Miller, Jeff Kirsher,
Realtek linux nic maintainers, Francois Romieu, Jeff Garzik,
Donald Becker, Cesar Eduardo Barros
While the SC92031 could be found on fake "Realtek" NICs, it has no
relationship to Realtek, and is actually from Silan.
Create a new subdirectory for silan and move sc92031 there.
Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.net>
---
drivers/net/ethernet/Kconfig | 1 +
drivers/net/ethernet/Makefile | 1 +
drivers/net/ethernet/realtek/Kconfig | 12 -------
drivers/net/ethernet/realtek/Makefile | 1 -
drivers/net/ethernet/silan/Kconfig | 33 +++++++++++++++++++++
drivers/net/ethernet/silan/Makefile | 5 +++
drivers/net/ethernet/{realtek => silan}/sc92031.c | 0
7 files changed, 40 insertions(+), 13 deletions(-)
create mode 100644 drivers/net/ethernet/silan/Kconfig
create mode 100644 drivers/net/ethernet/silan/Makefile
rename drivers/net/ethernet/{realtek => silan}/sc92031.c (100%)
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index 6dff5a0..597f4d4 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -159,6 +159,7 @@ config S6GMAC
will be called s6gmac.
source "drivers/net/ethernet/seeq/Kconfig"
+source "drivers/net/ethernet/silan/Kconfig"
source "drivers/net/ethernet/sis/Kconfig"
source "drivers/net/ethernet/sfc/Kconfig"
source "drivers/net/ethernet/sgi/Kconfig"
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index c53ad3a..be5dde0 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_SH_ETH) += renesas/
obj-$(CONFIG_NET_VENDOR_RDC) += rdc/
obj-$(CONFIG_S6GMAC) += s6gmac.o
obj-$(CONFIG_NET_VENDOR_SEEQ) += seeq/
+obj-$(CONFIG_NET_VENDOR_SILAN) += silan/
obj-$(CONFIG_NET_VENDOR_SIS) += sis/
obj-$(CONFIG_SFC) += sfc/
obj-$(CONFIG_NET_VENDOR_SGI) += sgi/
diff --git a/drivers/net/ethernet/realtek/Kconfig b/drivers/net/ethernet/realtek/Kconfig
index 84083ec..0578859 100644
--- a/drivers/net/ethernet/realtek/Kconfig
+++ b/drivers/net/ethernet/realtek/Kconfig
@@ -115,16 +115,4 @@ config R8169
To compile this driver as a module, choose M here: the module
will be called r8169. This is recommended.
-config SC92031
- tristate "Silan SC92031 PCI Fast Ethernet Adapter driver (EXPERIMENTAL)"
- depends on PCI && EXPERIMENTAL
- select CRC32
- ---help---
- This is a driver for the Fast Ethernet PCI network cards based on
- the Silan SC92031 chip (sometimes also called Rsltek 8139D). If you
- have one of these, say Y here.
-
- To compile this driver as a module, choose M here: the module
- will be called sc92031. This is recommended.
-
endif # NET_VENDOR_REALTEK
diff --git a/drivers/net/ethernet/realtek/Makefile b/drivers/net/ethernet/realtek/Makefile
index e48cfb6..71b1da3 100644
--- a/drivers/net/ethernet/realtek/Makefile
+++ b/drivers/net/ethernet/realtek/Makefile
@@ -6,4 +6,3 @@ obj-$(CONFIG_8139CP) += 8139cp.o
obj-$(CONFIG_8139TOO) += 8139too.o
obj-$(CONFIG_ATP) += atp.o
obj-$(CONFIG_R8169) += r8169.o
-obj-$(CONFIG_SC92031) += sc92031.o
diff --git a/drivers/net/ethernet/silan/Kconfig b/drivers/net/ethernet/silan/Kconfig
new file mode 100644
index 0000000..ae1ce17
--- /dev/null
+++ b/drivers/net/ethernet/silan/Kconfig
@@ -0,0 +1,33 @@
+#
+# Silan device configuration
+#
+
+config NET_VENDOR_SILAN
+ bool "Silan devices"
+ default y
+ depends on PCI && EXPERIMENTAL
+ ---help---
+ If you have a network (Ethernet) card belonging to this class, say Y
+ and read the Ethernet-HOWTO, available from
+ <http://www.tldp.org/docs.html#howto>.
+
+ Note that the answer to this question doesn't directly affect the
+ kernel: saying N will just cause the configurator to skip all
+ the questions about Silan devices. If you say Y, you will be asked for
+ your specific card in the following questions.
+
+if NET_VENDOR_SILAN
+
+config SC92031
+ tristate "Silan SC92031 PCI Fast Ethernet Adapter driver (EXPERIMENTAL)"
+ depends on PCI && EXPERIMENTAL
+ select CRC32
+ ---help---
+ This is a driver for the Fast Ethernet PCI network cards based on
+ the Silan SC92031 chip (sometimes also called Rsltek 8139D). If you
+ have one of these, say Y here.
+
+ To compile this driver as a module, choose M here: the module
+ will be called sc92031. This is recommended.
+
+endif # NET_VENDOR_SILAN
diff --git a/drivers/net/ethernet/silan/Makefile b/drivers/net/ethernet/silan/Makefile
new file mode 100644
index 0000000..4ad3523
--- /dev/null
+++ b/drivers/net/ethernet/silan/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the Silan network device drivers.
+#
+
+obj-$(CONFIG_SC92031) += sc92031.o
diff --git a/drivers/net/ethernet/realtek/sc92031.c b/drivers/net/ethernet/silan/sc92031.c
similarity index 100%
rename from drivers/net/ethernet/realtek/sc92031.c
rename to drivers/net/ethernet/silan/sc92031.c
--
1.7.6.4
^ permalink raw reply related
* unres_qlen and arp resolution/cache behavior
From: Gabe Black @ 2011-10-25 22:12 UTC (permalink / raw)
To: linux-kernel, netdev
Documentation about net.ipv4.neigh.*.unres_qlen seems to indicate that
it determines the number of frames that will be held while an arp is
being resolved.
Say packets start transmitting at a destination that needs to be (arp)
resolved. If the number of backlogged packets exceeds the queue
length, then the frames are dropped (from what I understand). My
question is what if the arp cached address expires and another arp is
issued. Does the same scenario occur (i.e. packets are backlogged
until that arp returns)? Or is the kernel smart enough to use the old
cached value until the arp returns, at which point it then uses the
updated address?
Thank you for your time,
Gabe
^ permalink raw reply
* Re: [PATCH v13 0/6] flexcan: Add support for powerpc flexcan (freescale p1010)
From: Scott Wood @ 2011-10-25 21:37 UTC (permalink / raw)
To: Kumar Gala
Cc: Robin Holt, netdev, U Bhaskar-B22300, socketcan-core, PPC list,
David S. Miller
In-Reply-To: <D79CB818-C14E-4C8D-9A8D-42B39ADE20B2@kernel.crashing.org>
On 10/18/2011 06:43 AM, Kumar Gala wrote:
>
>>> Robin,
>>>
>>> Do you remember why we went with just 'fsl,p1010-flexcan' as the device tree compatible? Do we feel the flex can on P1010 isn't the same as on MPC5xxx? or the ARM SoCs?
>>
>> The decision was due to the fact there is no true "generic" fsl.flexcan
>> chip free of any SOC implementation and therefore not something which
>> could be separately defined. That decision was made by Grant Likely.
>> I will inline that email below.
>>
>> Robin
>
>
> Thanks, I'll look into this internally at FSL. I think its confusing as hell to have "fsl,p1010-flexcan" in an ARM .dts
It's confusing to have devices labelled in vague ways that we can't tie
back to any real piece of hardware, or even a public architectural spec.
If you're talking to our hardware people, ask them to put public names
and versions, guaranteed unique throughout FSL, on all of our logic
blocks -- with public block manuals that have any SW-relevant
integration parameters clearly itemized.
Why is putting "fsl,p1010-flexcan" an an ARM device any more confusing
than putting it on some PowerPC chip that is not a p1010? Think of it
like a PCI ID, the actual value not being meaningful for much other than
its uniqueness and the ability to find a manual for the hardware.
This has been the recommended practice for quite some time.
> and don't think any reasonable ARM customer of FSL would know to put
> a PPC SOC name in their .dts.
If an ARM device tree comes along that just has
"fsl,some-arm-chip-flexcan", so what? Let the same driver bind against
both, again like PCI IDs. Additional compatibles are mainly a
convenience to give things a chance to work before the driver is updated
(a frequent irritant with PCI IDs and new hardware).
Ideally we would be publishing a sample device tree for our ARM chips
and their peripherals, though. :-P
> I'll ask the HW guys what's going on
> so we can come up with a bit more generic name so we don't have to
> constantly change this. Even if its just:
>
> fsl,ppc-flexcan & fsl,arm-flexcan.
Why is CPU instruction set relevant?
Would a QorIQ customer think to check for an existing compatible in
mpc5xxx, or even mpc83xx or mpc86xx?
-Scott
^ permalink raw reply
* Re: Linux 3.1-rc9
From: Simon Kirby @ 2011-10-25 20:20 UTC (permalink / raw)
To: Thomas Gleixner, David Miller
Cc: Peter Zijlstra, Linus Torvalds, Linux Kernel Mailing List,
Dave Jones, Martin Schwidefsky, Ingo Molnar, Network Development
In-Reply-To: <20111024190203.GA24410@hostway.ca>
On Mon, Oct 24, 2011 at 12:02:03PM -0700, Simon Kirby wrote:
> Ok, hit the hang about 4 more times, but only this morning on a box with
> a serial cable attached. Yay!
Here's lockdep output from another box. This one looks a bit different.
Simon-
[583223.799383] huh, entered softirq 3 NET_RX ffffffff81613740 preempt_count 00000102, exited with 00000103?
[583223.805083] huh, entered softirq 3 NET_RX ffffffff81613740 preempt_count 00000102, exited with 00000103?
[583223.805093]
[583223.805094] =================================
[583223.805096] [ INFO: inconsistent lock state ]
[583223.805098] 3.1.0-rc10-hw-lockdep+ #51
[583223.805100] ---------------------------------
[583223.805102] inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
[583223.805105] swapper/0 [HC0[0]:SC0[0]:HE1:SE1] takes:
[583223.805107] (slock-AF_INET){+.?.-.}, at: [<ffffffff81604540>] sk_clone+0x120/0x420
[583223.805116] {IN-SOFTIRQ-W} state was registered at:
[583223.805117] [<ffffffff81098c7c>] __lock_acquire+0xcbc/0x2180
[583223.805123] [<ffffffff8109a7b9>] lock_acquire+0x109/0x140
[583223.805126] [<ffffffff816f55fc>] _raw_spin_lock+0x3c/0x50
[583223.805131] [<ffffffff8166bd3d>] udp_queue_rcv_skb+0x26d/0x4b0
[583223.805135] [<ffffffff8166c6a3>] __udp4_lib_rcv+0x2f3/0x910
[583223.805139] [<ffffffff8166ccd5>] udp_rcv+0x15/0x20
[583223.805142] [<ffffffff81641960>] ip_local_deliver_finish+0x100/0x2f0
[583223.805146] [<ffffffff81641bdd>] ip_local_deliver+0x8d/0xa0
[583223.805149] [<ffffffff81641203>] ip_rcv_finish+0x1a3/0x510
[583223.805152] [<ffffffff816417e2>] ip_rcv+0x272/0x2f0
[583223.805154] [<ffffffff81610d67>] __netif_receive_skb+0x4d7/0x560
[583223.805158] [<ffffffff81610ec0>] process_backlog+0xd0/0x1e0
[583223.805161] [<ffffffff81613880>] net_rx_action+0x140/0x2c0
[583223.805164] [<ffffffff810640b8>] __do_softirq+0x138/0x250
[583223.805168] [<ffffffff817002bc>] call_softirq+0x1c/0x30
[583223.805172] [<ffffffff810153c5>] do_softirq+0x95/0xd0
[583223.805176] [<ffffffff81063ecd>] local_bh_enable+0xed/0x110
[583223.805179] [<ffffffff81614c48>] dev_queue_xmit+0x1a8/0x8a0
[583223.805181] [<ffffffff8161f1aa>] neigh_resolve_output+0x17a/0x220
[583223.805185] [<ffffffff81647d4c>] ip_finish_output+0x2ec/0x590
[583223.805188] [<ffffffff81648078>] ip_output+0x88/0xe0
[583223.805191] [<ffffffff81646cd8>] ip_local_out+0x28/0x80
[583223.805194] [<ffffffff81646d39>] ip_send_skb+0x9/0x40
[583223.805197] [<ffffffff8166aeb2>] udp_send_skb+0x122/0x390
[583223.805200] [<ffffffff8166db0c>] udp_sendmsg+0x7dc/0x920
[583223.805203] [<ffffffff81675e1f>] inet_sendmsg+0xbf/0x120
[583223.805207] [<ffffffff815ff333>] sock_sendmsg+0xe3/0x110
[583223.805209] [<ffffffff815ffc55>] sys_sendto+0x105/0x140
[583223.805212] [<ffffffff816fe052>] system_call_fastpath+0x16/0x1b
[583223.805217] irq event stamp: 4284605374
[583223.805219] hardirqs last enabled at (4284605372): [<ffffffff816101ad>] net_rps_action_and_irq_enable+0x8d/0xa0
[583223.805222] hardirqs last disabled at (4284605373): [<ffffffff8106412d>] __do_softirq+0x1ad/0x250
[583223.805226] softirqs last enabled at (4284605374): [<ffffffff81064176>] __do_softirq+0x1f6/0x250
[583223.805230] softirqs last disabled at (4284605313): [<ffffffff817002bc>] call_softirq+0x1c/0x30
[583223.805233]
[583223.805233] other info that might help us debug this:
[583223.805235] Possible unsafe locking scenario:
[583223.805236]
[583223.805237] CPU0
[583223.805238] ----
[583223.805239] lock(slock-AF_INET);
[583223.805241] <Interrupt>
[583223.805242] lock(slock-AF_INET);
[583223.805244]
[583223.805245] *** DEADLOCK ***
[583223.805246]
[583223.805248] 1 lock held by swapper/0:
[583223.805249] #0: (slock-AF_INET){+.?.-.}, at: [<ffffffff81604540>] sk_clone+0x120/0x420
[583223.805254]
[583223.805254] stack backtrace:
[583223.805257] Pid: 0, comm: swapper Not tainted 3.1.0-rc10-hw-lockdep+ #51
[583223.805259] Call Trace:
[583223.805264] [<ffffffff81096033>] print_usage_bug+0x243/0x310
[583223.805267] [<ffffffff810965b4>] mark_lock+0x4b4/0x6c0
[583223.805271] [<ffffffff81097400>] ? check_usage_forwards+0x110/0x110
[583223.805275] [<ffffffff81096862>] mark_held_locks+0xa2/0x130
[583223.805278] [<ffffffff816f6334>] ? retint_restore_args+0x13/0x13
[583223.805281] [<ffffffff81096c0d>] trace_hardirqs_on_caller+0x13d/0x1c0
[583223.805286] [<ffffffff813a60ae>] trace_hardirqs_on_thunk+0x3a/0x3f
[583223.805290] [<ffffffff81092b8e>] ? tick_nohz_stop_sched_tick+0x2fe/0x430
[583223.805293] [<ffffffff816f6334>] ? retint_restore_args+0x13/0x13
[583223.805297] [<ffffffff8101b80e>] ? mwait_idle+0x14e/0x170
[583223.805301] [<ffffffff8101b805>] ? mwait_idle+0x145/0x170
[583223.805304] [<ffffffff81013156>] cpu_idle+0x96/0xf0
[583223.805307] [<ffffffff816ca491>] rest_init+0xd1/0xe0
[583223.805310] [<ffffffff816ca3c0>] ? csum_partial_copy_generic+0x170/0x170
[583223.805315] [<ffffffff81adcc55>] start_kernel+0x360/0x3ac
[583223.805318] [<ffffffff81adc2a2>] x86_64_start_reservations+0x82/0x89
[583223.805321] [<ffffffff81adc3b8>] x86_64_start_kernel+0x10f/0x12a
[583223.805325] [<ffffffff81adc140>] ? early_idt_handlers+0x140/0x140
[583226.813848] huh, entered softirq 3 NET_RX ffffffff81613740 preempt_count 00000102, exited with 00000103?
[583232.802948] huh, entered softirq 3 NET_RX ffffffff81613740 preempt_count 00000102, exited with 00000103?
[583244.833571] huh, entered softirq 3 NET_RX ffffffff81613740 preempt_count 00000101, exited with 00000102?
[583253.849631] huh, entered softirq 3 NET_RX ffffffff81613740 preempt_count 00000101, exited with 00000102?
[583268.837126] huh, entered softirq 3 NET_RX ffffffff81613740 preempt_count 00000101, exited with 00000102?
[587843.931805] huh, entered softirq 3 NET_RX ffffffff81613740 preempt_count 00000102, exited with 00000103?
[587846.165584] huh, entered softirq 3 NET_RX ffffffff81613740 preempt_count 00000101, exited with 00000102?
[587850.602316] huh, entered softirq 3 NET_RX ffffffff81613740 preempt_count 00000101, exited with 00000102?
[587859.482841] huh, entered softirq 3 NET_RX ffffffff81613740 preempt_count 00000102, exited with 00000103?
[587873.940136] huh, entered softirq 3 NET_RX ffffffff81613740 preempt_count 00000102, exited with 00000103?
[587877.240624] huh, entered softirq 3 NET_RX ffffffff81613740 preempt_count 00000101, exited with 00000102?
[590476.272022] BUG: soft lockup - CPU#0 stuck for 22s! [swapper:0]
[590476.276002] Modules linked in: ipmi_devintf ipmi_si ipmi_msghandler xt_recent nf_conntrack_ftp xt_state xt_owner nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 bnx2
[590476.276002] irq event stamp: 4284605374
[590476.276002] hardirqs last enabled at (4284605372): [<ffffffff816101ad>] net_rps_action_and_irq_enable+0x8d/0xa0
[590476.276002] hardirqs last disabled at (4284605373): [<ffffffff8106412d>] __do_softirq+0x1ad/0x250
[590476.276002] softirqs last enabled at (4284605374): [<ffffffff81064176>] __do_softirq+0x1f6/0x250
[590476.276002] softirqs last disabled at (4284605313): [<ffffffff817002bc>] call_softirq+0x1c/0x30
[590476.276002] CPU 0
[590476.276002] Modules linked in: ipmi_devintf ipmi_si ipmi_msghandler xt_recent nf_conntrack_ftp xt_state xt_owner nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 bnx2
[590476.276002]
[590476.276002] Pid: 0, comm: swapper Not tainted 3.1.0-rc10-hw-lockdep+ #51 Dell Inc. PowerEdge 1950/0UR033
[590476.276002] RIP: 0010:[<ffffffff813a4ee3>] [<ffffffff813a4ee3>] delay_tsc+0x73/0xd0
[590476.276002] RSP: 0018:ffff88022fc03cf0 EFLAGS: 00000206
[590476.276002] RAX: 00042f884dcdaa24 RBX: ffff88022fc0d3c0 RCX: 000000004dcdaa24
[590476.380029] BUG: soft lockup - CPU#1 stuck for 22s! [php:10828]
[590476.380033] Modules linked in: ipmi_devintf ipmi_si ipmi_msghandler xt_recent nf_conntrack_ftp xt_state xt_owner nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 bnx2
[590476.380044] irq event stamp: 0
[590476.380045] hardirqs last enabled at (0): [< (null)>] (null)
[590476.380048] hardirqs last disabled at (0): [<ffffffff8105aa8b>] copy_process+0x65b/0x1450
[590476.380056] softirqs last enabled at (0): [<ffffffff8105aa8b>] copy_process+0x65b/0x1450
[590476.380060] softirqs last disabled at (0): [< (null)>] (null)
[590476.380063] CPU 1
[590476.380064] Modules linked in: ipmi_devintf ipmi_si ipmi_msghandler xt_recent nf_conntrack_ftp xt_state xt_owner nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 bnx2
[590476.380072]
[590476.380075] Pid: 10828, comm: php Not tainted 3.1.0-rc10-hw-lockdep+ #51 Dell Inc. PowerEdge 1950/0UR033
[590476.380079] RIP: 0010:[<ffffffff8101afa6>] [<ffffffff8101afa6>] native_read_tsc+0x6/0x20
[590476.380086] RSP: 0000:ffff88022fc43ce0 EFLAGS: 00000206
[590476.380088] RAX: 000000005aa56d04 RBX: ffffffff816f6334 RCX: 000000005aa56c92
[590476.380091] RDX: 0000000000042f88 RSI: ffffffff818f9896 RDI: 0000000000000001
[590476.380093] RBP: ffff88022fc43ce0 R08: 000000005aa56c92 R09: 0000000000000000
[590476.380096] R10: ffff88014b9a9f20 R11: 0000000000000000 R12: ffff88022fc43c58
[590476.380098] R13: ffffffff816feb33 R14: ffff88022fc43ce0 R15: 000000000e27878c
[590476.380101] FS: 00007fb61c8fa720(0000) GS:ffff88022fc40000(0000) knlGS:0000000000000000
[590476.380103] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[590476.380106] CR2: 00000000027914a0 CR3: 000000013a070000 CR4: 00000000000006e0
[590476.380108] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[590476.380110] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[590476.380113] Process php (pid: 10828, threadinfo ffff88014a1f2000, task ffff88014b9a9f20)
[590476.380115] Stack:
[590476.380117] ffff88022fc43d30 ffffffff813a4eaf ffff88014a1f2000 000000005aa56c38
[590476.380121] 00000001818f9896 ffff88001db58048 000000000e27878c 0000000076e96800
[590476.380125] 0000000000000001 ffff88014b9a9f20 ffff88022fc43d40 ffffffff813a4f6a
[590476.380129] Call Trace:
[590476.380132] <IRQ>
[590476.380137] [<ffffffff813a4eaf>] delay_tsc+0x3f/0xd0
[590476.380141] [<ffffffff813a4f6a>] __delay+0xa/0x10
[590476.380145] [<ffffffff813ac2ab>] do_raw_spin_lock+0x13b/0x180
[590476.380151] [<ffffffff816f5604>] _raw_spin_lock+0x44/0x50
[590476.380157] [<ffffffff81661823>] ? tcp_keepalive_timer+0x23/0x270
[590476.380161] [<ffffffff81661823>] tcp_keepalive_timer+0x23/0x270
[590476.380166] [<ffffffff8106cd5d>] run_timer_softirq+0x26d/0x410
[590476.380169] [<ffffffff8106cc88>] ? run_timer_softirq+0x198/0x410
[590476.380174] [<ffffffff81661800>] ? tcp_init_xmit_timers+0x20/0x20
[590476.380179] [<ffffffff810640b8>] __do_softirq+0x138/0x250
[590476.380184] [<ffffffff817002bc>] call_softirq+0x1c/0x30
[590476.380188] [<ffffffff810153c5>] do_softirq+0x95/0xd0
[590476.380191] [<ffffffff81063c8d>] irq_exit+0xdd/0x110
[590476.380196] [<ffffffff810310c9>] smp_apic_timer_interrupt+0x69/0xa0
[590476.380200] [<ffffffff816feb33>] apic_timer_interrupt+0x73/0x80
[590476.380203] <EOI>
[590476.380206] [<ffffffff816f6319>] ? retint_swapgs+0x13/0x1b
[590476.380208] Code: 08 ff 15 46 5c a1 00 48 c7 43 08 00 00 00 00 48 89 03 48 83 c4 08 5b c9 c3 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 0f 31
[590476.380227] c1 48 89 d0 48 c1 e0 20 89 ca 48 09 d0 c9 c3 66 2e 0f 1f 84
[590476.380236] Call Trace:
[590476.380237] <IRQ> [<ffffffff813a4eaf>] delay_tsc+0x3f/0xd0
[590476.380242] [<ffffffff813a4f6a>] __delay+0xa/0x10
[590476.380246] [<ffffffff813ac2ab>] do_raw_spin_lock+0x13b/0x180
[590476.380249] [<ffffffff816f5604>] _raw_spin_lock+0x44/0x50
[590476.380252] [<ffffffff81661823>] ? tcp_keepalive_timer+0x23/0x270
[590476.380256] [<ffffffff81661823>] tcp_keepalive_timer+0x23/0x270
[590476.380259] [<ffffffff8106cd5d>] run_timer_softirq+0x26d/0x410
[590476.380262] [<ffffffff8106cc88>] ? run_timer_softirq+0x198/0x410
[590476.380265] [<ffffffff81661800>] ? tcp_init_xmit_timers+0x20/0x20
[590476.380268] [<ffffffff810640b8>] __do_softirq+0x138/0x250
[590476.380271] [<ffffffff817002bc>] call_softirq+0x1c/0x30
[590476.380274] [<ffffffff810153c5>] do_softirq+0x95/0xd0
[590476.380277] [<ffffffff81063c8d>] irq_exit+0xdd/0x110
[590476.380280] [<ffffffff810310c9>] smp_apic_timer_interrupt+0x69/0xa0
[590476.380283] [<ffffffff816feb33>] apic_timer_interrupt+0x73/0x80
[590476.380285] <EOI> [<ffffffff816f6319>] ? retint_swapgs+0x13/0x1b
[590476.484032] BUG: soft lockup - CPU#2 stuck for 23s! [suexec:10831]
...
^ permalink raw reply
* drivers/net/ethernet/apple
From: Geert Uytterhoeven @ 2011-10-25 20:19 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: Benjamin Herrenschmidt, netdev, linux-kernel
Hi Jeff,
drivers/net/ethernet/apple/mac89x0.c is a driver for the Crystal Semiconductor
(Now Cirrus Logic) CS89[02]0, so it belongs in drivers/net/ethernet/cirrus,
next to cs89x0.c.
And according to drivers/net/ethernet/apple/mace.h, "mace" is the
"Am79C940 MACE (Medium Access Control for Ethernet)", so mace and
macmace should be in drivers/net/ethernet/amd/.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] net: make bonding slaves honour master's skb->priority
From: Jay Vosburgh @ 2011-10-25 16:45 UTC (permalink / raw)
To: =?UTF-8?Q?Maciej_=C5=BBenczykowski?=; +Cc: Flavio Leitner, netdev
In-Reply-To: <CANP3RGeMbVFf6oL3+9i8h43q1ycdzcA47rNfzeyLWpi8M8ZV5w@mail.gmail.com>
Maciej Żenczykowski <zenczykowski@gmail.com> wrote:
>> I tripped on it few times and never understood why we
>> were fixing the priority at this point.
>> thanks,
>
>It looks like ancient code, going all the way back to something like
>Linux 2.4.14 (if I recall my git blame session correctly).
>I can't think of a good reason for this...
I believe this line goes back to the beginning, prior to git or
bk. The skb->priority probably meant something different than it does
today.
In any event, I'm fine with the code change. There's still no
actual log message, but if Davem is ok with that I'm ok with it, given
the trivial nature of the change.
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH] net: make bonding slaves honour master's skb->priority
From: Maciej Żenczykowski @ 2011-10-25 16:25 UTC (permalink / raw)
To: Flavio Leitner; +Cc: netdev
In-Reply-To: <20111025110808.27db8487@asterix.rh>
> I tripped on it few times and never understood why we
> were fixing the priority at this point.
> thanks,
It looks like ancient code, going all the way back to something like
Linux 2.4.14 (if I recall my git blame session correctly).
I can't think of a good reason for this...
- Maciej
^ permalink raw reply
* Re: [RFC PATCH 11/17] sh_eth: Don't unnecessarily reset the PHY
From: Moffett, Kyle D @ 2011-10-25 16:00 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
David S. Miller, Nobuhiro Iwamatsu, Kuninori Morimoto
In-Reply-To: <4EA69972.4090004@renesas.com>
On Oct 25, 2011, at 07:11, Yoshihiro Shimoda wrote:
> 2011/10/21 6:00, Kyle Moffett wrote:
>> Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
>> ---
>> drivers/net/sh_eth.c | 19 +------------------
>> 1 files changed, 1 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/net/sh_eth.c b/drivers/net/sh_eth.c
>> index 1c1666e..7ef4378 100644
>> --- a/drivers/net/sh_eth.c
>> +++ b/drivers/net/sh_eth.c
>> @@ -1235,23 +1235,6 @@ static int sh_eth_phy_init(struct net_device *ndev)
>> return 0;
>> }
>>
>> -/* PHY control start function */
>> -static int sh_eth_phy_start(struct net_device *ndev)
>> -{
>> - struct sh_eth_private *mdp = netdev_priv(ndev);
>> - int ret;
>> -
>> - ret = sh_eth_phy_init(ndev);
>> - if (ret)
>> - return ret;
>> -
>> - /* reset phy - this also wakes it from PDOWN */
>> - phy_write(mdp->phydev, MII_BMCR, BMCR_RESET);
>> - phy_start(mdp->phydev);
>
> I think that the driver needs the phy_start().
> So, I removed the phy_write() only. Then, the driver could work correctly.
>
> Therefore, I would to remove the following code only.
> Do you think about this?
>
>> - /* reset phy - this also wakes it from PDOWN */
>> - phy_write(mdp->phydev, MII_BMCR, BMCR_RESET);
You're right, sorry about that. I think I mis-merged this when I rebased
from a much earlier commit. The simple removal of the BMCR_RESET write
should achieve what I was intending.
Cheers,
Kyle Moffett
--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/
^ permalink raw reply
* RE: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address filtering support for passthru mode
From: Rose, Gregory V @ 2011-10-25 15:59 UTC (permalink / raw)
To: Michael S. Tsirkin, Roopa Prabhu
Cc: netdev@vger.kernel.org, sri@us.ibm.com, dragos.tatulea@gmail.com,
arnd@arndb.de, kvm@vger.kernel.org, davem@davemloft.net,
mchan@broadcom.com, dwang2@cisco.com, shemminger@vyatta.com,
eric.dumazet@gmail.com, kaber@trash.net, benve@cisco.com
In-Reply-To: <20111025154617.GB22553@redhat.com>
> -----Original Message-----
> From: Michael S. Tsirkin [mailto:mst@redhat.com]
> Sent: Tuesday, October 25, 2011 8:46 AM
> To: Roopa Prabhu
> Cc: netdev@vger.kernel.org; sri@us.ibm.com; dragos.tatulea@gmail.com;
> arnd@arndb.de; kvm@vger.kernel.org; davem@davemloft.net;
> mchan@broadcom.com; dwang2@cisco.com; shemminger@vyatta.com;
> eric.dumazet@gmail.com; kaber@trash.net; benve@cisco.com; Rose, Gregory V
> Subject: Re: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address
> filtering support for passthru mode
>
> On Mon, Oct 24, 2011 at 11:15:05AM -0700, Roopa Prabhu wrote:
> > >> ... And also I dont know of any hw
> > >> that provides an interface to set hw filters on a per queue basis.
> > >
> > > VMDq hardware would support this, no?
> > >
> > Am not really sure. This patch uses netdev to pass filters to hw. And I
> > don't see any netdev infrastructure that would support per queue
> filters.
>
> Sure. I was only saying that as far as I understand,
> VMDq hardware does support this functionality.
> Right, Greg?
In the case of Intel HW yes. I'll refrain from speaking for other HW vendors although I'm guessing it would be true in their cases also. YMMV, caveat emptor, etc. etc.
- Greg
>
> --
> MST
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address filtering support for passthru mode
From: Michael S. Tsirkin @ 2011-10-25 15:46 UTC (permalink / raw)
To: Roopa Prabhu
Cc: netdev, sri, dragos.tatulea, arnd, kvm, davem, mchan, dwang2,
shemminger, eric.dumazet, kaber, benve, Rose, Gregory V
In-Reply-To: <CACAF939.37AAD%roprabhu@cisco.com>
On Mon, Oct 24, 2011 at 11:15:05AM -0700, Roopa Prabhu wrote:
> >> ... And also I dont know of any hw
> >> that provides an interface to set hw filters on a per queue basis.
> >
> > VMDq hardware would support this, no?
> >
> Am not really sure. This patch uses netdev to pass filters to hw. And I
> don't see any netdev infrastructure that would support per queue filters.
Sure. I was only saying that as far as I understand,
VMDq hardware does support this functionality.
Right, Greg?
--
MST
^ permalink raw reply
* Re: [RFC v2 PATCH 5/4 PATCH] virtio-net: send gratuitous packet when needed
From: Michael S. Tsirkin @ 2011-10-25 15:41 UTC (permalink / raw)
To: Jason Wang
Cc: aliguori, kvm, quintela, jan.kiszka, Rusty Russell, qemu-devel,
blauwirbel, netdev, pbonzini
In-Reply-To: <4EA62401.5000602@redhat.com>
On Tue, Oct 25, 2011 at 10:50:41AM +0800, Jason Wang wrote:
> On 10/24/2011 01:25 PM, Michael S. Tsirkin wrote:
> > On Mon, Oct 24, 2011 at 02:54:59PM +1030, Rusty Russell wrote:
> >> On Sat, 22 Oct 2011 13:43:11 +0800, Jason Wang <jasowang@redhat.com> wrote:
> >>> This make let virtio-net driver can send gratituous packet by a new
> >>> config bit - VIRTIO_NET_S_ANNOUNCE in each config update
> >>> interrupt. When this bit is set by backend, the driver would schedule
> >>> a workqueue to send gratituous packet through NETDEV_NOTIFY_PEERS.
> >>>
> >>> This feature is negotiated through bit VIRTIO_NET_F_GUEST_ANNOUNCE.
> >>>
> >>> Signed-off-by: Jason Wang <jasowang@redhat.com>
> >>
> >> This seems like a huge layering violation. Imagine this in real
> >> hardware, for example.
> >
> > commits 06c4648d46d1b757d6b9591a86810be79818b60c
> > and 99606477a5888b0ead0284fecb13417b1da8e3af
> > document the need for this:
> >
> > NETDEV_NOTIFY_PEERS notifier indicates that a device moved to a
> > different physical link.
> > and
> > In real hardware such notifications are only
> > generated when the device comes up or the address changes.
> >
> > So hypervisor could get the same behaviour by sending link up/down
> > events, this is just an optimization so guest won't do
> > unecessary stuff like try to reconfigure an IP address.
> >
> >
> > Maybe LOCATION_CHANGE would be a better name?
> >
>
> ANNOUNCE_SELF?
It would be nice to formulate what kind of event
are we notifying the guest about.
The announce part of it is really up to the guest, isn't it?
> >
> >> There may be a good reason why virtual devices might want this kind of
> >> reconfiguration cheat, which is unnecessary for normal machines,
> >
> > I think yes, the difference with real hardware is guest can change
> > location without link getting dropped.
> > FWIW, Xen seems to use this capability too.
>
> So does ms netvsc.
>
> >
> >> but
> >> it'd have to be spelled out clearly in the spec to justify it...
> >>
> >> Cheers,
> >> Rusty.
> >
> > Agree, and I'd like to see the spec too. The interface seems
> > to involve the guest clearing the status bit when it detects
> > an event?
>
> I would describe this in spec. The interface need guest to clear the
> status bit, this would let the back-end know it has finished the work as
> we may need to send the gratuitous packets many times.
>
> >
> > Also - how does it interact with the link up event?
> > We probably don't want to schedule this when we detect
> > a link status change or during initialization, as
> > this patch seems to do? What if link goes down
> > while the work is running? Is that OK?
> >
>
> Looks like there's are duplications if guest enable arp_notify vm is
> started,
How hard would it be to avoid these duplicates?
> but we need to handle the situation that resuming a stopped
> virtual machine.
>
> For the link down race, I don't see any real issue, either dropping or
> queued.
For example, you do
unregister_netdev(vi->dev);
cancel_work_sync(&vi->announce);
which looks scary as announce seems to use the netdev.
--
MST
^ permalink raw reply
* [PATCH v2 4/4] SUNRPC: optimize net_ns dereferencing in rpcbind registering calls
From: Stanislav Kinsbursky @ 2011-10-25 14:58 UTC (permalink / raw)
To: Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA
Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA, xemul-bzQdu9zFT3WakBO8gow8eQ,
neilb-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bfields-uC3wQj2KruNg9hUCZPvPmw, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <20111025135637.5286.89632.stgit-bi+AKbBUZKagILUCTcTcHdKyNwTtLsGr@public.gmane.org>
Static rpcbind registering functions can be parametrized by network namespace
pointer, calculated only once, instead of using init_net pointer (or taking it
from current when virtualization will be comleted) in many places.
Signed-off-by: Stanislav Kinsbursky <skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
---
net/sunrpc/rpcb_clnt.c | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
index ef37c55..92ed74f 100644
--- a/net/sunrpc/rpcb_clnt.c
+++ b/net/sunrpc/rpcb_clnt.c
@@ -452,14 +452,14 @@ int rpcb_register(u32 prog, u32 vers, int prot, unsigned short port)
/*
* Fill in AF_INET family-specific arguments to register
*/
-static int rpcb_register_inet4(const struct sockaddr *sap,
+static int rpcb_register_inet4(struct sunrpc_net *sn,
+ const struct sockaddr *sap,
struct rpc_message *msg)
{
const struct sockaddr_in *sin = (const struct sockaddr_in *)sap;
struct rpcbind_args *map = msg->rpc_argp;
unsigned short port = ntohs(sin->sin_port);
int result;
- struct sunrpc_net *sn = net_generic(&init_net, sunrpc_net_id);
map->r_addr = rpc_sockaddr2uaddr(sap);
@@ -480,14 +480,14 @@ static int rpcb_register_inet4(const struct sockaddr *sap,
/*
* Fill in AF_INET6 family-specific arguments to register
*/
-static int rpcb_register_inet6(const struct sockaddr *sap,
+static int rpcb_register_inet6(struct sunrpc_net *sn,
+ const struct sockaddr *sap,
struct rpc_message *msg)
{
const struct sockaddr_in6 *sin6 = (const struct sockaddr_in6 *)sap;
struct rpcbind_args *map = msg->rpc_argp;
unsigned short port = ntohs(sin6->sin6_port);
int result;
- struct sunrpc_net *sn = net_generic(&init_net, sunrpc_net_id);
map->r_addr = rpc_sockaddr2uaddr(sap);
@@ -505,10 +505,10 @@ static int rpcb_register_inet6(const struct sockaddr *sap,
return result;
}
-static int rpcb_unregister_all_protofamilies(struct rpc_message *msg)
+static int rpcb_unregister_all_protofamilies(struct sunrpc_net *sn,
+ struct rpc_message *msg)
{
struct rpcbind_args *map = msg->rpc_argp;
- struct sunrpc_net *sn = net_generic(&init_net, sunrpc_net_id);
dprintk("RPC: unregistering [%u, %u, '%s'] with "
"local rpcbind\n",
@@ -581,13 +581,13 @@ int rpcb_v4_register(const u32 program, const u32 version,
return -EPROTONOSUPPORT;
if (address == NULL)
- return rpcb_unregister_all_protofamilies(&msg);
+ return rpcb_unregister_all_protofamilies(sn, &msg);
switch (address->sa_family) {
case AF_INET:
- return rpcb_register_inet4(address, &msg);
+ return rpcb_register_inet4(sn, address, &msg);
case AF_INET6:
- return rpcb_register_inet6(address, &msg);
+ return rpcb_register_inet6(sn, address, &msg);
}
return -EAFNOSUPPORT;
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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
* [PATCH v2 3/4] SUNRPC: optimize net_ns dereferencing in rpcbind creation calls
From: Stanislav Kinsbursky @ 2011-10-25 14:58 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, bfields, davem,
devel
In-Reply-To: <20111025135637.5286.89632.stgit@localhost6.localdomain6>
Static rpcbind creation functions can be parametrized by network namespace
pointer, calculated only once, instead of using init_net pointer (or taking it
from current when virtualization will be comleted) in many places.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
net/sunrpc/rpcb_clnt.c | 35 +++++++++++++++++++----------------
1 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
index 18eba8e..ef37c55 100644
--- a/net/sunrpc/rpcb_clnt.c
+++ b/net/sunrpc/rpcb_clnt.c
@@ -161,10 +161,10 @@ static void rpcb_map_release(void *data)
kfree(map);
}
-static int rpcb_get_local(void)
+static int rpcb_get_local(struct net *net)
{
int cnt;
- struct sunrpc_net *sn = net_generic(&init_net, sunrpc_net_id);
+ struct sunrpc_net *sn = net_generic(net, sunrpc_net_id);
spin_lock(&sn->rpcb_clnt_lock);
if (sn->rpcb_users)
@@ -202,9 +202,10 @@ void rpcb_put_local(void)
return;
}
-static void rpcb_set_local(struct rpc_clnt *clnt, struct rpc_clnt *clnt4)
+static void rpcb_set_local(struct net *net, struct rpc_clnt *clnt,
+ struct rpc_clnt *clnt4)
{
- struct sunrpc_net *sn = net_generic(&init_net, sunrpc_net_id);
+ struct sunrpc_net *sn = net_generic(net, sunrpc_net_id);
/* Protected by rpcb_create_local_mutex */
sn->rpcb_local_clnt = clnt;
@@ -212,22 +213,23 @@ static void rpcb_set_local(struct rpc_clnt *clnt, struct rpc_clnt *clnt4)
smp_wmb();
sn->rpcb_users = 1;
dprintk("RPC: created new rpcb local clients (rpcb_local_clnt: "
- "%p, rpcb_local_clnt4: %p)\n", sn->rpcb_local_clnt,
- sn->rpcb_local_clnt4);
+ "%p, rpcb_local_clnt4: %p) for net %p%s\n",
+ sn->rpcb_local_clnt, sn->rpcb_local_clnt4,
+ net, (net == &init_net) ? " (init_net)" : "");
}
/*
* Returns zero on success, otherwise a negative errno value
* is returned.
*/
-static int rpcb_create_local_unix(void)
+static int rpcb_create_local_unix(struct net *net)
{
static const struct sockaddr_un rpcb_localaddr_rpcbind = {
.sun_family = AF_LOCAL,
.sun_path = RPCBIND_SOCK_PATHNAME,
};
struct rpc_create_args args = {
- .net = &init_net,
+ .net = net,
.protocol = XPRT_TRANSPORT_LOCAL,
.address = (struct sockaddr *)&rpcb_localaddr_rpcbind,
.addrsize = sizeof(rpcb_localaddr_rpcbind),
@@ -260,7 +262,7 @@ static int rpcb_create_local_unix(void)
clnt4 = NULL;
}
- rpcb_set_local(clnt, clnt4);
+ rpcb_set_local(net, clnt, clnt4);
out:
return result;
@@ -270,7 +272,7 @@ out:
* Returns zero on success, otherwise a negative errno value
* is returned.
*/
-static int rpcb_create_local_net(void)
+static int rpcb_create_local_net(struct net *net)
{
static const struct sockaddr_in rpcb_inaddr_loopback = {
.sin_family = AF_INET,
@@ -278,7 +280,7 @@ static int rpcb_create_local_net(void)
.sin_port = htons(RPCBIND_PORT),
};
struct rpc_create_args args = {
- .net = &init_net,
+ .net = net,
.protocol = XPRT_TRANSPORT_TCP,
.address = (struct sockaddr *)&rpcb_inaddr_loopback,
.addrsize = sizeof(rpcb_inaddr_loopback),
@@ -312,7 +314,7 @@ static int rpcb_create_local_net(void)
clnt4 = NULL;
}
- rpcb_set_local(clnt, clnt4);
+ rpcb_set_local(net, clnt, clnt4);
out:
return result;
@@ -326,16 +328,17 @@ int rpcb_create_local(void)
{
static DEFINE_MUTEX(rpcb_create_local_mutex);
int result = 0;
+ struct net *net = &init_net;
- if (rpcb_get_local())
+ if (rpcb_get_local(net))
return result;
mutex_lock(&rpcb_create_local_mutex);
- if (rpcb_get_local())
+ if (rpcb_get_local(net))
goto out;
- if (rpcb_create_local_unix() != 0)
- result = rpcb_create_local_net();
+ if (rpcb_create_local_unix(net) != 0)
+ result = rpcb_create_local_net(net);
out:
mutex_unlock(&rpcb_create_local_mutex);
^ permalink raw reply related
* [PATCH v2 1/4] SUNRPC: rpcbind clients internals virtualization
From: Stanislav Kinsbursky @ 2011-10-25 14:57 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, bfields, davem,
devel
In-Reply-To: <20111025135637.5286.89632.stgit@localhost6.localdomain6>
This patch moves static rpcbind internals to sunrpc part of network namespace
context. This will allow to create rcpbind clients per network namespace.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
net/sunrpc/netns.h | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/net/sunrpc/netns.h b/net/sunrpc/netns.h
index d013bf2..83eede3 100644
--- a/net/sunrpc/netns.h
+++ b/net/sunrpc/netns.h
@@ -9,6 +9,11 @@ struct cache_detail;
struct sunrpc_net {
struct proc_dir_entry *proc_net_rpc;
struct cache_detail *ip_map_cache;
+
+ struct rpc_clnt *rpcb_local_clnt;
+ struct rpc_clnt *rpcb_local_clnt4;
+ spinlock_t rpcb_clnt_lock;
+ unsigned int rpcb_users;
};
extern int sunrpc_net_id;
^ permalink raw reply related
* [PATCH v2 0/4] Series short description
From: Stanislav Kinsbursky @ 2011-10-25 14:57 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, bfields, davem,
devel
This patch-set was created in context of clone of git branch:
git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git
and rebased on tag "v3.1".
This patch-set virtualizes rpcbind clients per network namespace context. IOW,
each network namespace will have its own pair of rpcbind clients (if the would
be created by request).
Note:
1) this patch-set depends on "SUNRPC: make rpcbind clients allocated and
destroyed dynamically" patch-set which has been send earlier.
2) init_net pointer is still used instead of current->nsproxy->net_ns,
because I'm not sure yet about how to virtualize services.
I.e. NFS callback services will be per netns. NFSd service will be per netns
too from my pow. But Lockd can be per netns or one for all.
And also we have NFSd file system, which is not virtualized yet.
The following series consists of:
---
Stanislav Kinsbursky (4):
SUNRPC: rpcbind clients internals virtualization
SUNRPC: use virtualized rpcbind internals instead of static ones
SUNRPC: optimize net_ns dereferencing in rpcbind creation calls
SUNRPC: optimize net_ns dereferencing in rpcbind registering calls
net/sunrpc/netns.h | 5 ++
net/sunrpc/rpcb_clnt.c | 103 ++++++++++++++++++++++++++----------------------
2 files changed, 61 insertions(+), 47 deletions(-)
--
Signature
^ permalink raw reply
* Re: [PATCH v2 0/4] Series short description
From: Stanislav Kinsbursky @ 2011-10-25 14:20 UTC (permalink / raw)
To: Trond.Myklebust@netapp.com
Cc: linux-nfs@vger.kernel.org, Pavel Emelianov, neilb@suse.de,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
bfields@fieldses.org, davem@davemloft.net, devel@openvz.org
In-Reply-To: <20111025135637.5286.89632.stgit@localhost6.localdomain6>
Sorry for dummy series description.
Here is the right one:
"[PATCH v2 0/4] SUNRPC: rcbind clients virtualization"
--
Best regards,
Stanislav Kinsbursky
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: Eric Dumazet @ 2011-10-25 14:16 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: David Miller, netdev, linux-next, linux-kernel, Linus
In-Reply-To: <20111026005530.a4bd779e1a8182ea57dbf99f@canb.auug.org.au>
Le mercredi 26 octobre 2011 à 00:55 +1100, Stephen Rothwell a écrit :
> Hi all,
>
> After merging the net-next tree, today's linux-next build (powerpc
> pseries_defconfig) failed like this:
>
> drivers/net/ethernet/ibm/ehea/ehea_main.c: In function 'write_swqe2_data':
> drivers/net/ethernet/ibm/ehea/ehea_main.c:1692: error: implicit declaration of function 'frag_size'
>
> Presumably caused by commit 9e903e085262 ("net: add skb frag size
> accessors"). I guess it should have been "skb_frag_size()".
My bad, sorry
[PATCH] ehea: fix skb_frag_size typo
commit 9e903e085262 (net: add skb frag size accessors) introduced a typo
in ehea driver.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
drivers/net/ethernet/ibm/ehea/ehea_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ibm/ehea/ehea_main.c b/drivers/net/ethernet/ibm/ehea/ehea_main.c
index 0d4d4f6..37b70f7 100644
--- a/drivers/net/ethernet/ibm/ehea/ehea_main.c
+++ b/drivers/net/ethernet/ibm/ehea/ehea_main.c
@@ -1689,7 +1689,7 @@ static inline void write_swqe2_data(struct sk_buff *skb, struct net_device *dev,
sgentry = &sg_list[i - sg1entry_contains_frag_data];
sgentry->l_key = lkey;
- sgentry->len = frag_size(frag);
+ sgentry->len = skb_frag_size(frag);
sgentry->vaddr = ehea_map_vaddr(skb_frag_address(frag));
swqe->descriptors++;
}
^ permalink raw reply related
* [PATCH v2 2/4] SUNRPC: use virtualized rpcbind internals instead of static ones
From: Stanislav Kinsbursky @ 2011-10-25 14:58 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, bfields, davem,
devel
In-Reply-To: <20111025135637.5286.89632.stgit@localhost6.localdomain6>
This patch makes rpcbind logic works in network namespace context. IOW each
network namespace will have it's own unique rpcbind internals (clients and
friends) which is required for registering svc services per network namespace.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
net/sunrpc/rpcb_clnt.c | 64 ++++++++++++++++++++++++++----------------------
1 files changed, 35 insertions(+), 29 deletions(-)
diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
index c2054ae..18eba8e 100644
--- a/net/sunrpc/rpcb_clnt.c
+++ b/net/sunrpc/rpcb_clnt.c
@@ -23,12 +23,15 @@
#include <linux/errno.h>
#include <linux/mutex.h>
#include <linux/slab.h>
+#include <linux/nsproxy.h>
#include <net/ipv6.h>
#include <linux/sunrpc/clnt.h>
#include <linux/sunrpc/sched.h>
#include <linux/sunrpc/xprtsock.h>
+#include "netns.h"
+
#ifdef RPC_DEBUG
# define RPCDBG_FACILITY RPCDBG_BIND
#endif
@@ -111,12 +114,6 @@ static void rpcb_getport_done(struct rpc_task *, void *);
static void rpcb_map_release(void *data);
static struct rpc_program rpcb_program;
-static struct rpc_clnt * rpcb_local_clnt;
-static struct rpc_clnt * rpcb_local_clnt4;
-
-DEFINE_SPINLOCK(rpcb_clnt_lock);
-unsigned int rpcb_users;
-
struct rpcbind_args {
struct rpc_xprt * r_xprt;
@@ -167,29 +164,31 @@ static void rpcb_map_release(void *data)
static int rpcb_get_local(void)
{
int cnt;
+ struct sunrpc_net *sn = net_generic(&init_net, sunrpc_net_id);
- spin_lock(&rpcb_clnt_lock);
- if (rpcb_users)
- rpcb_users++;
- cnt = rpcb_users;
- spin_unlock(&rpcb_clnt_lock);
+ spin_lock(&sn->rpcb_clnt_lock);
+ if (sn->rpcb_users)
+ sn->rpcb_users++;
+ cnt = sn->rpcb_users;
+ spin_unlock(&sn->rpcb_clnt_lock);
return cnt;
}
void rpcb_put_local(void)
{
- struct rpc_clnt *clnt = rpcb_local_clnt;
- struct rpc_clnt *clnt4 = rpcb_local_clnt4;
+ struct sunrpc_net *sn = net_generic(&init_net, sunrpc_net_id);
+ struct rpc_clnt *clnt = sn->rpcb_local_clnt;
+ struct rpc_clnt *clnt4 = sn->rpcb_local_clnt4;
int shutdown;
- spin_lock(&rpcb_clnt_lock);
- if (--rpcb_users == 0) {
- rpcb_local_clnt = NULL;
- rpcb_local_clnt4 = NULL;
+ spin_lock(&sn->rpcb_clnt_lock);
+ if (--sn->rpcb_users == 0) {
+ sn->rpcb_local_clnt = NULL;
+ sn->rpcb_local_clnt4 = NULL;
}
- shutdown = !rpcb_users;
- spin_unlock(&rpcb_clnt_lock);
+ shutdown = !sn->rpcb_users;
+ spin_unlock(&sn->rpcb_clnt_lock);
if (shutdown) {
/*
@@ -205,14 +204,16 @@ void rpcb_put_local(void)
static void rpcb_set_local(struct rpc_clnt *clnt, struct rpc_clnt *clnt4)
{
+ struct sunrpc_net *sn = net_generic(&init_net, sunrpc_net_id);
+
/* Protected by rpcb_create_local_mutex */
- rpcb_local_clnt = clnt;
- rpcb_local_clnt4 = clnt4;
+ sn->rpcb_local_clnt = clnt;
+ sn->rpcb_local_clnt4 = clnt4;
smp_wmb();
- rpcb_users = 1;
+ sn->rpcb_users = 1;
dprintk("RPC: created new rpcb local clients (rpcb_local_clnt: "
- "%p, rpcb_local_clnt4: %p)\n", rpcb_local_clnt,
- rpcb_local_clnt4);
+ "%p, rpcb_local_clnt4: %p)\n", sn->rpcb_local_clnt,
+ sn->rpcb_local_clnt4);
}
/*
@@ -432,6 +433,7 @@ int rpcb_register(u32 prog, u32 vers, int prot, unsigned short port)
struct rpc_message msg = {
.rpc_argp = &map,
};
+ struct sunrpc_net *sn = net_generic(&init_net, sunrpc_net_id);
dprintk("RPC: %sregistering (%u, %u, %d, %u) with local "
"rpcbind\n", (port ? "" : "un"),
@@ -441,7 +443,7 @@ int rpcb_register(u32 prog, u32 vers, int prot, unsigned short port)
if (port)
msg.rpc_proc = &rpcb_procedures2[RPCBPROC_SET];
- return rpcb_register_call(rpcb_local_clnt, &msg);
+ return rpcb_register_call(sn->rpcb_local_clnt, &msg);
}
/*
@@ -454,6 +456,7 @@ static int rpcb_register_inet4(const struct sockaddr *sap,
struct rpcbind_args *map = msg->rpc_argp;
unsigned short port = ntohs(sin->sin_port);
int result;
+ struct sunrpc_net *sn = net_generic(&init_net, sunrpc_net_id);
map->r_addr = rpc_sockaddr2uaddr(sap);
@@ -466,7 +469,7 @@ static int rpcb_register_inet4(const struct sockaddr *sap,
if (port)
msg->rpc_proc = &rpcb_procedures4[RPCBPROC_SET];
- result = rpcb_register_call(rpcb_local_clnt4, msg);
+ result = rpcb_register_call(sn->rpcb_local_clnt4, msg);
kfree(map->r_addr);
return result;
}
@@ -481,6 +484,7 @@ static int rpcb_register_inet6(const struct sockaddr *sap,
struct rpcbind_args *map = msg->rpc_argp;
unsigned short port = ntohs(sin6->sin6_port);
int result;
+ struct sunrpc_net *sn = net_generic(&init_net, sunrpc_net_id);
map->r_addr = rpc_sockaddr2uaddr(sap);
@@ -493,7 +497,7 @@ static int rpcb_register_inet6(const struct sockaddr *sap,
if (port)
msg->rpc_proc = &rpcb_procedures4[RPCBPROC_SET];
- result = rpcb_register_call(rpcb_local_clnt4, msg);
+ result = rpcb_register_call(sn->rpcb_local_clnt4, msg);
kfree(map->r_addr);
return result;
}
@@ -501,6 +505,7 @@ static int rpcb_register_inet6(const struct sockaddr *sap,
static int rpcb_unregister_all_protofamilies(struct rpc_message *msg)
{
struct rpcbind_args *map = msg->rpc_argp;
+ struct sunrpc_net *sn = net_generic(&init_net, sunrpc_net_id);
dprintk("RPC: unregistering [%u, %u, '%s'] with "
"local rpcbind\n",
@@ -509,7 +514,7 @@ static int rpcb_unregister_all_protofamilies(struct rpc_message *msg)
map->r_addr = "";
msg->rpc_proc = &rpcb_procedures4[RPCBPROC_UNSET];
- return rpcb_register_call(rpcb_local_clnt4, msg);
+ return rpcb_register_call(sn->rpcb_local_clnt4, msg);
}
/**
@@ -567,8 +572,9 @@ int rpcb_v4_register(const u32 program, const u32 version,
struct rpc_message msg = {
.rpc_argp = &map,
};
+ struct sunrpc_net *sn = net_generic(&init_net, sunrpc_net_id);
- if (rpcb_local_clnt4 == NULL)
+ if (sn->rpcb_local_clnt4 == NULL)
return -EPROTONOSUPPORT;
if (address == NULL)
^ permalink raw reply related
* linux-next: build failure after merge of the net-next tree
From: Stephen Rothwell @ 2011-10-25 13:55 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Eric Dumazet, Linus
[-- Attachment #1: Type: text/plain, Size: 534 bytes --]
Hi all,
After merging the net-next tree, today's linux-next build (powerpc
pseries_defconfig) failed like this:
drivers/net/ethernet/ibm/ehea/ehea_main.c: In function 'write_swqe2_data':
drivers/net/ethernet/ibm/ehea/ehea_main.c:1692: error: implicit declaration of function 'frag_size'
Presumably caused by commit 9e903e085262 ("net: add skb frag size
accessors"). I guess it should have been "skb_frag_size()".
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [patch net-next V5] net: introduce ethernet teaming device
From: Eric Dumazet @ 2011-10-25 13:27 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, bhutchings, shemminger, fubar, andy, tgraf,
ebiederm, mirqus, kaber, greearb, jesse, fbl, benjamin.poirier,
jzupka
In-Reply-To: <1319547821-1045-1-git-send-email-jpirko@redhat.com>
Le mardi 25 octobre 2011 à 15:03 +0200, Jiri Pirko a écrit :
> This patch introduces new network device called team. It supposes to be
> very fast, simple, userspace-driven alternative to existing bonding
> driver.
>
> Userspace library called libteam with couple of demo apps is available
> here:
> https://github.com/jpirko/libteam
> Note it's still in its dipers atm.
>
> team<->libteam use generic netlink for communication. That and rtnl
> suppose to be the only way to configure team device, no sysfs etc.
>
> Python binding basis for libteam was recently introduced (some need
> still need to be done on it though). Daemon providing arpmon/miimon
> active-backup functionality will be introduced shortly.
> All what's necessary is already implemented in kernel team driver.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>
> v4->v5:
> - team_change_mtu() uses team->lock while travesing though port
> list
> - mac address changes are moved completely to jurisdiction of
> userspace daemon. This way the daemon can do FOM1, FOM2 and
> possibly other weird things with mac addresses.
> Only round-robin mode sets up all ports to bond's address then
> enslaved.
> - Extended Kconfig text
Following is not called under rcu, but rtnl or team spinlock held.
Therefore, team_get_port_by_index_rcu() is not the right thing.
+static void __reconstruct_port_hlist(struct team *team, int rm_index)
+{
+ int i;
+ struct team_port *port;
+
+ for (i = rm_index + 1; i < team->port_count; i++) {
+ port = team_get_port_by_index_rcu(team, i);
+ hlist_del_rcu(&port->hlist);
+ port->index--;
+ hlist_add_head_rcu(&port->hlist,
+ team_port_index_hash(team, port->index));
+ }
+}
+
In fact, I claim most of your rcu_read_lock() in management side are
bogus and obfuscate code.
RCU is an exact science, not a commodity.
When RCU is used, rcu_read_lock()/rcu_read_unlock() are used by readers,
not managers :
They should use a spin/mutex(rtnl usually in network land)
and normal reads, no need for rcu_something
Only writes must take care of concurrent readers (aka rcu_assign_pointer())
For example:
team_nl_fill_port_list_get_changed() should not use
list_for_each_entry_rcu(port, &team->port_list, list) {
but a regular
list_for_each_entry(port, &team->port_list, list) {
team_nl_team_get() should not play with RCU either.
It can use __dev_get_by_index() instead of dev_get_by_index_rcu()
Comment in front of team_nl_team_get() is bogus as well :
/*
* Netlink cmd functions should be locked by following two functions.
* To ensure team_uninit would not be called in between, hold rcu_read_lock
* all the time.
*/
How can holding rcu_read_lock() can prevent another cpu doing whatever he wants ?
It seems you believe rcu_read_lock() is a read_lock(), but it isnt.
Using right API is essential to get appropriate LOCKDEP semantic and
code maintainability.
^ permalink raw reply
* [PATCH] net: ucc_geth, increase no. of HW RX descriptors
From: Joakim Tjernlund @ 2011-10-25 13:17 UTC (permalink / raw)
To: Anton Vorontsov, netdev; +Cc: Joakim Tjernlund
In a busy network we see ucc_geth is dropping RX pkgs every now
and then. Increase the first RX queues HW descriptors from
16 to 32 to deal with this.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
drivers/net/ucc_geth.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index fa00935..04e22ff 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -134,7 +134,7 @@ static struct ucc_geth_info ugeth_primary_info = {
TX_BD_RING_LEN},
.bdRingLenRx = {
- RX_BD_RING_LEN,
+ RX_BD_RING_LEN*2,
RX_BD_RING_LEN,
RX_BD_RING_LEN,
RX_BD_RING_LEN,
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH v6 1/8] SUNRPC: introduce helpers for reference counted rpcbind clients
From: Stanislav Kinsbursky @ 2011-10-25 13:25 UTC (permalink / raw)
To: Trond Myklebust
Cc: linux-nfs@vger.kernel.org, Pavel Emelianov, neilb@suse.de,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
bfields@fieldses.org, davem@davemloft.net, devel@openvz.org
In-Reply-To: <1319546750.2716.5.camel@lade.trondhjem.org>
25.10.2011 16:45, Trond Myklebust пишет:
>
> The empty 'return' at the end of a void function: it is 100%
> redundant...
>
O, yes, of course. Sorry.
--
Best regards,
Stanislav Kinsbursky
^ permalink raw reply
* Re: [patch net-next V4] net: introduce ethernet teaming device
From: Flavio Leitner @ 2011-10-25 13:22 UTC (permalink / raw)
To: Michał Mirosław
Cc: Jiri Pirko, netdev, davem, eric.dumazet, bhutchings, shemminger,
fubar, andy, tgraf, ebiederm, kaber, greearb, jesse,
benjamin.poirier, jzupka
In-Reply-To: <CAHXqBFLzuxaCW-q5X066zM3E_t9KHO1uTF6WD3Je2u0EifaSSw@mail.gmail.com>
On Mon, 24 Oct 2011 19:22:36 +0200
Michał Mirosław <mirqus@gmail.com> wrote:
> 2011/10/24 Jiri Pirko <jpirko@redhat.com>:
> > This patch introduces new network device called team. It supposes
> > to be very fast, simple, userspace-driven alternative to existing
> > bonding driver.
> [...]
> > drivers/net/team/team.c | 1573
> > +++++++++++++++++++++++++++++
> > drivers/net/team/team_mode_activebackup.c | 152 +++
> > drivers/net/team/team_mode_roundrobin.c | 107 ++
>
> I think this mode-modularity is overkill. One mode will compile to at
> most a few hundred bytes of code+data, but will use at least 10 times
> that to get loaded and tracked properly. How often/how many more modes
> you anticipate to be introduced? You could just keep the modular
> design but drop the kernel module separation and maybe have modes
> conditionally compiled (for those from the embedded world squeezing
> every byte).
>
Please keep the modes separated. Security and embedded folks will
thank you. If you are concerned with the overhead which still should
be small and doesn't impact performance, you can compile as built-in.
The good thing is that you can choose the best option for you while
doing the opposite doesn't offer that.
Also, if in the future we need to add module parameters, the namespace
is clean.
I would ask to keep it as the work is done already.
fbl
^ 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