Netdev List
 help / color / mirror / Atom feed
* Re: zero length sg in scatterwalk_start.
From: Horia Geanta @ 2012-09-10 21:48 UTC (permalink / raw)
  To: Dave Jones; +Cc: netdev, Fedora Kernel Team, sergei.litvinenko, herbert
In-Reply-To: <20120910191208.GA20865@redhat.com>

On 9/10/2012 10:12 PM, Dave Jones wrote:
> Sergei (Cc'd) just filed this against our 3.6rc4 kernel
>
> It's falling over on the
>
> BUG_ON(!sg->length);
>
> in scatterwalk_start

AFAICT, this is the same issue as the one reported here:
http://lkml.org/lkml/2012/9/9/23

Could you please try the fix proposed:
http://lkml.org/lkml/2012/9/9/97
and hopefully provide your Tested-by ?

Horia

>
> 	Dave
>
> On Mon, Sep 10, 2012 at 06:41:07PM +0000, bugzilla@redhat.com wrote:
>   > https://bugzilla.redhat.com/show_bug.cgi?id=855961
>   >
>   > Description of problem:
>   >
>   > Message with diagnostic and openswan stop to work
>   >
>   > Version-Release number of selected component (if applicable):
>   > kernel-3.6.0-0.rc4.git2.1.fc18.i686
>   > openswan-2.6.38-3.fc18.i686
>   >
>   >
>   > Steps to Reproduce:
>   > 1. Install f18 to KVM
>   > 2. install openswan
>   > 3. prepare configuration on Host and kvm guest:
>   >
>   > conn fedora18
>   > #----------------------------------
>   >         left=10.x.x.100
>   >         leftrsasigkey=0sAQPHXz0 ...
>   > #----------------------------------
>   >         right=10.x.x.18
>   >         rightrsasigkey=0sAQOi...
>   > #----------------------------------
>   >         type=transport
>   >         keyingtries=%forever
>   >         auth=esp
>   >         ike=aes256-sha1-modp1024
>   >         esp=aes256-sha1
>   >         authby=rsasig
>   >         keyexchange=ike
>   >         disablearrivalcheck=yes
>   >         pfs=no
>   >         compress=no
>   >         #-----------------------------
>   >         auto=add
>   >
>   > 4. run from host: ipsec auto --up fedora18
>   >
>   > Actual results:
>   >
>   > Message ... and ipsec service is not accessible any more. Guest do not crash
>   > and stil work (accessible by ssh).
>   >
>   > Expected results:
>   > ipsec start and work
>   >
>   >
>   > [  105.063277] ------------[ cut here ]------------
>   > [  105.063281] kernel BUG at crypto/scatterwalk.c:37!
>   > [  105.063283] invalid opcode: 0000 [#1] SMP
>   > [  105.063286] Modules linked in: authenc rmd160 crypto_null camellia_generic lzo cast6 cast5 deflate zlib_deflate cts gcm ccm serpent_sse2_i586 xts serpent_generic lrw gf128mul glue_helper blowfish_generic blowfish_common twofish_generic twofish_i586 twofish_common xcbc sha512_generic des_generic geode_aes ah6 ah4 esp6 esp4 xfrm4_mode_beet xfrm4_tunnel tunnel4 xfrm4_mode_tunnel xfrm4_mode_transport xfrm6_mode_transport xfrm6_mode_ro xfrm6_mode_beet xfrm6_mode_tunnel ipcomp ipcomp6 xfrm6_tunnel tunnel6 xfrm_ipcomp af_key lockd sunrpc bnep bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ppdev microcode virtio_net i2c_piix4 parport_pc i2c_core parport uinput virtio_blk
>   > [  105.063327] Pid: 995, comm: cryptomgr_test Not tainted 3.6.0-0.rc4.git2.1.fc18.i686 #1 Bochs Bochs
>   > [  105.063329] EIP: 0060:[<c06829e9>] EFLAGS: 00010246 CPU: 0
>   > [  105.063363] EIP is at scatterwalk_start+0x19/0x20
>   > [  105.063365] EAX: f334bbe0 EBX: f286a5d8 ECX: 00000000 EDX: f286a5d8
>   > [  105.063367] ESI: 00000020 EDI: 00000000 EBP: f334bbd0 ESP: f334bbd0
>   > [  105.063368]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
>   > [  105.063372] CR0: 8005003b CR2: 45cb04bc CR3: 00ede000 CR4: 000006d0
>   > [  105.063381] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
>   > [  105.063386] DR6: ffff0ff0 DR7: 00000400
>   > [  105.063388] Process cryptomgr_test (pid: 995, ti=f334a000 task=f26e5640 task.ti=f334a000)
>   > [  105.063389] Stack:
>   > [  105.063390]  f334bbf4 c0682bfa f334bbe0 f286a640 f286a5d8 f80851a3 f286a5a0 f286a5d8
>   > [  105.063395]  f3378a50 f334bc38 f80859db 00000014 00000001 f2bd5000 00000000 87654321
>   > [  105.063400]  00000668 f54cdc80 00000200 00000000 00000000 f286a5d8 00000020 f286a678
>   > [  105.063406] Call Trace:
>   > [  105.063409]  [<c0682bfa>] scatterwalk_map_and_copy+0x2a/0xa0
>   > [  105.063413]  [<f80851a3>] ? crypto_authenc_ahash+0x63/0x80 [authenc]
>   > [  105.063416]  [<f80859db>] crypto_authenc_genicv+0xdb/0x330 [authenc]
>   > [  105.063419]  [<f8085dbc>] crypto_authenc_encrypt+0x8c/0xa0 [authenc]
>   > [  105.063422]  [<c068a48a>] test_aead+0x5aa/0xd40
>   > [  105.063432]  [<c047e685>] ? local_clock+0x65/0x70
>   > [  105.063444]  [<c055d239>] ? deactivate_slab+0x419/0x540
>   > [  105.063449]  [<c04a7f84>] ? trace_hardirqs_on_caller+0xf4/0x180
>   > [  105.063451]  [<c04a801b>] ? trace_hardirqs_on+0xb/0x10
>   > [  105.063455]  [<c068113d>] ? __crypto_alloc_tfm+0x3d/0x150
>   > [  105.063457]  [<c068113d>] ? __crypto_alloc_tfm+0x3d/0x150
>   > [  105.063460]  [<c055e2eb>] ? __kmalloc+0x11b/0x290
>   > [  105.063463]  [<c068121f>] ? __crypto_alloc_tfm+0x11f/0x150
>   > [  105.063466]  [<c0681bcd>] ? crypto_spawn_tfm+0x3d/0x70
>   > [  105.063468]  [<c068f6d2>] ? crypto_cbc_init_tfm+0x22/0x40
>   > [  105.063471]  [<c06811de>] ? __crypto_alloc_tfm+0xde/0x150
>   > [  105.063473]  [<c0681bcd>] ? crypto_spawn_tfm+0x3d/0x70
>   > [  105.063476]  [<c0685022>] ? skcipher_geniv_init+0x22/0x40
>   > [  105.063478]  [<c0685edb>] ? async_chainiv_init+0x7b/0x90
>   > [  105.063481]  [<c06811de>] ? __crypto_alloc_tfm+0xde/0x150
>   > [  105.063484]  [<c068ac68>] alg_test_aead+0x48/0xa0
>   > [  105.063487]  [<c068992e>] ? alg_find_test+0x2e/0x60
>   > [  105.063489]  [<c0689a06>] alg_test+0xa6/0x270
>   > [  105.063511]  [<c09fb836>] ? _raw_spin_unlock_irqrestore+0x36/0x70
>   > [  105.063514]  [<c04a7f84>] ? trace_hardirqs_on_caller+0xf4/0x180
>   > [  105.063517]  [<c04a801b>] ? trace_hardirqs_on+0xb/0x10
>   > [  105.063519]  [<c06886c0>] ? cryptomgr_probe+0xb0/0xb0
>   > [  105.063522]  [<c0688701>] cryptomgr_test+0x41/0x50
>   > [  105.063525]  [<c046640d>] kthread+0x7d/0x90
>   > [  105.063528]  [<c0466390>] ? __init_kthread_worker+0x60/0x60
>   > [  105.063532]  [<c0a03502>] kernel_thread_helper+0x6/0x10
>   > [  105.063533] Code: c3 90 31 f6 83 c4 08 89 f0 5b 5e 5f 5d c3 66 90 66 90 55 89 e5 3e 8d 74 26 00 89 10 8b 4a 0c 85 c9 74 08 8b 52 08 5d 89 50 04 c3 <0f> 0b 90 8d 74 26 00 55 89 e5 53 3e 8d 74 26 00 89 c3 8b 00 81
>   > [  105.063565] EIP: [<c06829e9>] scatterwalk_start+0x19/0x20 SS:ESP 0068:f334bbd0
>   > [  105.063570] ---[ end trace 5057a14544445946 ]---
>   > [  105.063573] BUG: sleeping function called from invalid context at kernel/rwsem.c:20
>   > [  105.063574] in_atomic(): 1, irqs_disabled(): 0, pid: 995, name: cryptomgr_test
>   > [  105.063575] INFO: lockdep is turned off.
>   > [  105.063577] Pid: 995, comm: cryptomgr_test Tainted: G      D      3.6.0-0.rc4.git2.1.fc18.i686 #1
>   > [  105.063578] Call Trace:
>   > [  105.063581]  [<c0475227>] __might_sleep+0x167/0x210
>   > [  105.063584]  [<c09f9230>] down_read+0x20/0x8b
>   > [  105.063587]  [<c046e6ef>] ? __validate_process_creds+0x6f/0xd0
>   > [  105.063590]  [<c0457f6e>] exit_signals+0x1e/0x110
>   > [  105.063595]  [<c0446cef>] do_exit+0x9f/0xa10
>   > [  105.063597]  [<c0443b11>] ? kmsg_dump+0x21/0x210
>   > [  105.063600]  [<c0443c80>] ? kmsg_dump+0x190/0x210
>   > [  105.063602]  [<c0443c94>] ? kmsg_dump+0x1a4/0x210
>   > [  105.063605]  [<c0443b11>] ? kmsg_dump+0x21/0x210
>   > [  105.063607]  [<c09fc92a>] oops_end+0x8a/0xd0
>   > [  105.063611]  [<c04061d4>] die+0x54/0x80
>   > [  105.063613]  [<c09fc366>] do_trap+0x96/0xd0
>   > [  105.063616]  [<c0403b70>] ? do_bounds+0x90/0x90
>   > [  105.063618]  [<c0403c16>] do_invalid_op+0xa6/0xb0
>   > [  105.063620]  [<c06829e9>] ? scatterwalk_start+0x19/0x20
>   > [  105.063623]  [<c068c1ed>] ? hmac_final+0x8d/0xa0
>   > [  105.063625]  [<c0687d67>] ? crypto_shash_final+0x27/0xa0
>   > [  105.063628]  [<c0688173>] ? shash_ahash_finup+0x73/0x80
>   > [  105.063637]  [<c06c8dc8>] ? trace_hardirqs_off_thunk+0xc/0x14
>   > [  105.063640]  [<c09fc0f8>] error_code+0x6c/0x74
>   > [  105.063643]  [<c06800d8>] ? devcgroup_seq_read+0x2a8/0x2f0
>   > [  105.063645]  [<c06829e9>] ? scatterwalk_start+0x19/0x20
>   > [  105.063648]  [<c0682bfa>] scatterwalk_map_and_copy+0x2a/0xa0
>   > [  105.063651]  [<f80851a3>] ? crypto_authenc_ahash+0x63/0x80 [authenc]
>   > [  105.063653]  [<f80859db>] crypto_authenc_genicv+0xdb/0x330 [authenc]
>   > [  105.063656]  [<f8085dbc>] crypto_authenc_encrypt+0x8c/0xa0 [authenc]
>   > [  105.063659]  [<c068a48a>] test_aead+0x5aa/0xd40
>   > [  105.063661]  [<c047e685>] ? local_clock+0x65/0x70
>   > [  105.063664]  [<c055d239>] ? deactivate_slab+0x419/0x540
>   > [  105.063667]  [<c04a7f84>] ? trace_hardirqs_on_caller+0xf4/0x180
>   > [  105.063670]  [<c04a801b>] ? trace_hardirqs_on+0xb/0x10
>   > [  105.063672]  [<c068113d>] ? __crypto_alloc_tfm+0x3d/0x150
>   > [  105.063675]  [<c068113d>] ? __crypto_alloc_tfm+0x3d/0x150
>   > [  105.063678]  [<c055e2eb>] ? __kmalloc+0x11b/0x290
>   > [  105.063681]  [<c068121f>] ? __crypto_alloc_tfm+0x11f/0x150
>   > [  105.063683]  [<c0681bcd>] ? crypto_spawn_tfm+0x3d/0x70
>   > [  105.063685]  [<c068f6d2>] ? crypto_cbc_init_tfm+0x22/0x40
>   > [  105.063688]  [<c06811de>] ? __crypto_alloc_tfm+0xde/0x150
>   > [  105.063690]  [<c0681bcd>] ? crypto_spawn_tfm+0x3d/0x70
>   > [  105.063693]  [<c0685022>] ? skcipher_geniv_init+0x22/0x40
>   > [  105.063695]  [<c0685edb>] ? async_chainiv_init+0x7b/0x90
>   > [  105.063698]  [<c06811de>] ? __crypto_alloc_tfm+0xde/0x150
>   > [  105.063701]  [<c068ac68>] alg_test_aead+0x48/0xa0
>   > [  105.063703]  [<c068992e>] ? alg_find_test+0x2e/0x60
>   > [  105.063706]  [<c0689a06>] alg_test+0xa6/0x270
>   > [  105.063709]  [<c09fb836>] ? _raw_spin_unlock_irqrestore+0x36/0x70
>   > [  105.063711]  [<c04a7f84>] ? trace_hardirqs_on_caller+0xf4/0x180
>   > [  105.063713]  [<c04a801b>] ? trace_hardirqs_on+0xb/0x10
>   > [  105.063716]  [<c06886c0>] ? cryptomgr_probe+0xb0/0xb0
>   > [  105.063718]  [<c0688701>] cryptomgr_test+0x41/0x50
>   > [  105.063721]  [<c046640d>] kthread+0x7d/0x90
>   > [  105.063724]  [<c0466390>] ? __init_kthread_worker+0x60/0x60
>   > [  105.063726]  [<c0a03502>] kernel_thread_helper+0x6/0x10
>   > [  105.063728] note: cryptomgr_test[995] exited with preempt_count 1

^ permalink raw reply

* Re: [PATCH net-next] x86 bpf_jit: support MOD operation
From: David Miller @ 2012-09-10 21:09 UTC (permalink / raw)
  To: eric.dumazet; +Cc: ak, gbakos, netdev
In-Reply-To: <1347310113.13103.8.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 10 Sep 2012 22:48:33 +0200

> From: Eric Dumazet <edumazet@google.com>
> 
> commit b6069a9570 (filter: add MOD operation) added generic
> support for modulus operation in BPF.
> 
> This patch brings JIT support for x86_64
> 
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Applied, thanks Eric.

^ permalink raw reply

* Re: [PATCH 0/5] dev_<level> and dynamic_debug cleanups
From: Jason Baron @ 2012-09-10 20:56 UTC (permalink / raw)
  To: Joe Perches
  Cc: Andrew Morton, netdev, Greg Kroah-Hartman, David S. Miller,
	Jim Cromie, Kay Sievers, linux-kernel
In-Reply-To: <1347069350.13424.28.camel@joe2Laptop>

On Fri, Sep 07, 2012 at 06:55:50PM -0700, Joe Perches wrote:
> On Fri, 2012-09-07 at 11:35 -0400, Jason Baron wrote:
> > If nobody else thinks this patch is better, let's at least add a comment in
> > __dev_printk() and __netdev_printk() to fix dynamic debug, if these are changed.
> 
> Or maybe make dynamic_emit_prefix a public function
> and move the __dynamic_<foo>_printk functions to
> nearby the __<foo>_printk functions so it's easier to
> see that changing one requires the other to change.
> 

ok, that makes sense to me.

Thanks,

-Jason

^ permalink raw reply

* [PATCH net-next] x86 bpf_jit: support MOD operation
From: Eric Dumazet @ 2012-09-10 20:48 UTC (permalink / raw)
  To: David Miller; +Cc: ak, gbakos, netdev
In-Reply-To: <20120910.154537.639794042526369471.davem@davemloft.net>

From: Eric Dumazet <edumazet@google.com>

commit b6069a9570 (filter: add MOD operation) added generic
support for modulus operation in BPF.

This patch brings JIT support for x86_64

Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: George Bakos <gbakos@alpinista.org>
---
 arch/x86/net/bpf_jit_comp.c |   25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index 33643a8..106c578 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -280,6 +280,31 @@ void bpf_jit_compile(struct sk_filter *fp)
 				}
 				EMIT4(0x31, 0xd2, 0xf7, 0xf3); /* xor %edx,%edx; div %ebx */
 				break;
+			case BPF_S_ALU_MOD_X: /* A %= X; */
+				seen |= SEEN_XREG;
+				EMIT2(0x85, 0xdb);	/* test %ebx,%ebx */
+				if (pc_ret0 > 0) {
+					/* addrs[pc_ret0 - 1] is start address of target
+					 * (addrs[i] - 6) is the address following this jmp
+					 * ("xor %edx,%edx; div %ebx;mov %edx,%eax" being 6 bytes long)
+					 */
+					EMIT_COND_JMP(X86_JE, addrs[pc_ret0 - 1] -
+								(addrs[i] - 6));
+				} else {
+					EMIT_COND_JMP(X86_JNE, 2 + 5);
+					CLEAR_A();
+					EMIT1_off32(0xe9, cleanup_addr - (addrs[i] - 6)); /* jmp .+off32 */
+				}
+				EMIT2(0x31, 0xd2);	/* xor %edx,%edx */
+				EMIT2(0xf7, 0xf3);	/* div %ebx */
+				EMIT2(0x89, 0xd0);	/* mov %edx,%eax */
+				break;
+			case BPF_S_ALU_MOD_K: /* A %= K; */
+				EMIT2(0x31, 0xd2);	/* xor %edx,%edx */
+				EMIT1(0xb9);EMIT(K, 4);	/* mov imm32,%ecx */
+				EMIT2(0xf7, 0xf1);	/* div %ecx */
+				EMIT2(0x89, 0xd0);	/* mov %edx,%eax */
+				break;
 			case BPF_S_ALU_DIV_K: /* A = reciprocal_divide(A, K); */
 				EMIT3(0x48, 0x69, 0xc0); /* imul imm32,%rax,%rax */
 				EMIT(K, 4);

^ permalink raw reply related

* Re: [PATCH -next] net: fix net/core/sock.c build error
From: David Miller @ 2012-09-10 20:45 UTC (permalink / raw)
  To: rdunlap; +Cc: sfr, linux-next, linux-kernel, netdev
In-Reply-To: <504E1193.4060809@xenotime.net>

From: Randy Dunlap <rdunlap@xenotime.net>
Date: Mon, 10 Sep 2012 09:13:07 -0700

> From: Randy Dunlap <rdunlap@xenotime.net>
> 
> Fix net/core/sock.c build error when CONFIG_INET is not enabled:
> 
> net/built-in.o: In function `sock_edemux':
> (.text+0xd396): undefined reference to `inet_twsk_put'
> 
> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>

Applied to 'net', thanks Randy.

^ permalink raw reply

* Re: [PATCH 1/1] [PATCH] net: qmi_wwan: fix Gobi device probing for un2430
From: David Miller @ 2012-09-10 20:43 UTC (permalink / raw)
  To: pierre.sauter; +Cc: gregkh, netdev, bjorn
In-Reply-To: <1347296579-15692-1-git-send-email-pierre.sauter@gmail.com>

From: pierre.sauter@gmail.com
Date: Mon, 10 Sep 2012 19:02:59 +0200

> From: Pierre Sauter <pierre.sauter@gmail.com>
> 
> HP un2430 is a Gobi 3000 device. It was mistakenly treated as Gobi 1000
> in patch b9f90eb2740203ff2592efe640409ad48335d1c2.
> 
> I own this device and qmi_wwan works again with this fix.
> 
> Signed-off-by: Pierre Sauter <pierre.sauter@gmail.com>

Bjorn, ACK/NACK?

> ---
>  drivers/net/usb/qmi_wwan.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> index adfab3f..17b8f3e 100644
> --- a/drivers/net/usb/qmi_wwan.c
> +++ b/drivers/net/usb/qmi_wwan.c
> @@ -398,7 +398,6 @@ static const struct usb_device_id products[] = {
>  	/* 4. Gobi 1000 devices */
>  	{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},	/* Acer Gobi Modem Device */
>  	{QMI_GOBI1K_DEVICE(0x03f0, 0x1f1d)},	/* HP un2400 Gobi Modem Device */
> -	{QMI_GOBI1K_DEVICE(0x03f0, 0x371d)},	/* HP un2430 Mobile Broadband Module */
>  	{QMI_GOBI1K_DEVICE(0x04da, 0x250d)},	/* Panasonic Gobi Modem device */
>  	{QMI_GOBI1K_DEVICE(0x413c, 0x8172)},	/* Dell Gobi Modem device */
>  	{QMI_GOBI1K_DEVICE(0x1410, 0xa001)},	/* Novatel Gobi Modem device */
> @@ -440,6 +439,7 @@ static const struct usb_device_id products[] = {
>  	{QMI_GOBI_DEVICE(0x16d8, 0x8002)},	/* CMDTech Gobi 2000 Modem device (VU922) */
>  	{QMI_GOBI_DEVICE(0x05c6, 0x9205)},	/* Gobi 2000 Modem device */
>  	{QMI_GOBI_DEVICE(0x1199, 0x9013)},	/* Sierra Wireless Gobi 3000 Modem device (MC8355) */
> +	{QMI_GOBI_DEVICE(0x03f0, 0x371d)},	/* HP un2430 Mobile Broadband Module */
>  	{QMI_GOBI_DEVICE(0x1199, 0x9015)},	/* Sierra Wireless Gobi 3000 Modem device */
>  	{QMI_GOBI_DEVICE(0x1199, 0x9019)},	/* Sierra Wireless Gobi 3000 Modem device */
>  	{QMI_GOBI_DEVICE(0x1199, 0x901b)},	/* Sierra Wireless MC7770 */
> -- 
> 1.7.10.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply

* Re: [net-next PATCH 0/5] Energy Efficient Ethernet patch series
From: David Miller @ 2012-09-10 20:42 UTC (permalink / raw)
  To: yuvalmin; +Cc: netdev, eilong
In-Reply-To: <1347292268-30348-1-git-send-email-yuvalmin@broadcom.com>

From: "Yuval Mintz" <yuvalmin@broadcom.com>
Date: Mon, 10 Sep 2012 18:51:03 +0300

> This patch series contains various EEE changes, the most significant being
> the addition of EEE support for devices with 4-ports, as well as replacing the
> auto-grEEEn feature with native EEE (802.3az) for boards with 54618SE phys.
> 
> Please consider applying this patch series to 'net-next'.

All applied, thanks.

^ permalink raw reply

* Re: [net PATCH 6/7] bnx2x: fix self-test
From: David Miller @ 2012-09-10 20:38 UTC (permalink / raw)
  To: yuvalmin; +Cc: netdev, eilong, dmitry
In-Reply-To: <1347292135-30250-7-git-send-email-yuvalmin@broadcom.com>

From: "Yuval Mintz" <yuvalmin@broadcom.com>
Date: Mon, 10 Sep 2012 18:48:54 +0300

> From: Dmitry Kravkov <dmitry@broadcom.com>
> 
> Under traffic, there are several registers that when read (e.g., via 
> 'ethtool -t') may cause the chip to stall.
> This patch corrects the registers read in such flows.
> 
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>

You cannot change the size of layout of the register dump without
updating the ethtool register dump version advertised by the
driver.

You're currently the register dump version to zero.

^ permalink raw reply

* Re: [PATCH 3/3] fib6: remove some useless empty lines and comments
From: David Miller @ 2012-09-10 20:33 UTC (permalink / raw)
  To: amwang; +Cc: netdev
In-Reply-To: <1347281326-26890-3-git-send-email-amwang@redhat.com>

From: Cong Wang <amwang@redhat.com>
Date: Mon, 10 Sep 2012 20:48:46 +0800

> There are too many empty lines in this source file,
> remove the useless ones, together with some useless
> comments.
> 
> Signed-off-by: Cong Wang <amwang@redhat.com>

This patch is of zero value, please find something more useful to work
on and contribute, I'm not applying this.

^ permalink raw reply

* Re: [PATCH 2/3] ipv6, route: remove BACKTRACK() macro
From: David Miller @ 2012-09-10 20:32 UTC (permalink / raw)
  To: amwang; +Cc: netdev
In-Reply-To: <1347281326-26890-2-git-send-email-amwang@redhat.com>

From: Cong Wang <amwang@redhat.com>
Date: Mon, 10 Sep 2012 20:48:45 +0800

> It doesn't save any code, nor it helps readability.
> 
> Signed-off-by: Cong Wang <amwang@redhat.com>

I'm not applying this.

Having two copies of the same exact logic means we will accumulate
bugs in the future if someone fixes the problem only in one
copy.

^ permalink raw reply

* Re: [PATCH 1/3] ipv6: remove some useless RCU read lock
From: David Miller @ 2012-09-10 20:31 UTC (permalink / raw)
  To: amwang; +Cc: netdev
In-Reply-To: <1347281326-26890-1-git-send-email-amwang@redhat.com>

From: Cong Wang <amwang@redhat.com>
Date: Mon, 10 Sep 2012 20:48:44 +0800

> After this commit:
> 	commit 97cac0821af4474ec4ba3a9e7a36b98ed9b6db88
> 	Author: David S. Miller <davem@davemloft.net>
> 	Date:   Mon Jul 2 22:43:47 2012 -0700
> 
> 	    ipv6: Store route neighbour in rt6_info struct.
> 
> we no longer use RCU to protect route neighbour.
> 
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>

Applied to net-next, thanks.

^ permalink raw reply

* [PATCH net] net: qmi_wwan: call subdriver with control intf only
From: Bjørn Mork @ 2012-09-10 20:15 UTC (permalink / raw)
  To: netdev-u79uwXL29TY76Z2rM5mHXA
  Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, Bjørn Mork

This fixes a hang on suspend due to calling wdm_suspend on
the unregistered data interface. The hang should have been
a NULL pointer reference had it not been for a logic error
in the cdc_wdm code.

  commit 230718bd net: qmi_wwan: bind to both control and data interface

changed qmi_wwan to use cdc_wdm as a subdriver for devices with
a two-interface QMI/wwan function.  The commit failed to update
qmi_wwan_suspend and qmi_wwan_resume, which were written to handle
either a single combined interface function, or no subdriver at all.

The result was that we called into the subdriver both when the
control interface was suspended and when the data interface was
suspended.  Calling the subdriver suspend function with an
unregistered interface is not supported and will make the
subdriver bug out.

Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
---
 drivers/net/usb/qmi_wwan.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index adfab3f..9d1679f 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -297,7 +297,7 @@ static int qmi_wwan_suspend(struct usb_interface *intf, pm_message_t message)
 	if (ret < 0)
 		goto err;
 
-	if (info->subdriver && info->subdriver->suspend)
+	if (intf == info->control && info->subdriver && info->subdriver->suspend)
 		ret = info->subdriver->suspend(intf, message);
 	if (ret < 0)
 		usbnet_resume(intf);
@@ -311,7 +311,7 @@ static int qmi_wwan_resume(struct usb_interface *intf)
 	struct qmi_wwan_state *info = (void *)&dev->data;
 	int ret = 0;
 
-	if (info->subdriver && info->subdriver->resume)
+	if (intf == info->control && info->subdriver && info->subdriver->resume)
 		ret = info->subdriver->resume(intf);
 	if (ret < 0)
 		goto err;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 net v2] ixp4xx_hss: fix build failure due to missing linux/module.h inclusion
From: David Miller @ 2012-09-10 20:15 UTC (permalink / raw)
  To: florian; +Cc: netdev, khc, joe, stable
In-Reply-To: <1347278818-6913-1-git-send-email-florian@openwrt.org>

From: Florian Fainelli <florian@openwrt.org>
Date: Mon, 10 Sep 2012 14:06:58 +0200

> Commit 36a1211970193ce215de50ed1e4e1272bc814df1 (netprio_cgroup.h:
> dont include module.h from other includes) made the following build
> error on ixp4xx_hss pop up:
> 
>   CC [M]  drivers/net/wan/ixp4xx_hss.o
>  drivers/net/wan/ixp4xx_hss.c:1412:20: error: expected ';', ',' or ')'
>  before string constant
>  drivers/net/wan/ixp4xx_hss.c:1413:25: error: expected ';', ',' or ')'
>  before string constant
>  drivers/net/wan/ixp4xx_hss.c:1414:21: error: expected ';', ',' or ')'
>  before string constant
>  drivers/net/wan/ixp4xx_hss.c:1415:19: error: expected ';', ',' or ')'
>  before string constant
>  make[8]: *** [drivers/net/wan/ixp4xx_hss.o] Error 1
> 
> This was previously hidden because ixp4xx_hss includes linux/hdlc.h which
> includes linux/netdevice.h which includes linux/netprio_cgroup.h which
> used to include linux/module.h. The real issue was actually present since
> the initial commit that added this driver since it uses macros from
> linux/module.h without including this file.
> 
> Signed-off-by: Florian Fainelli <florian@openwrt.org>

Applied and queued up for -stable, thanks.

^ permalink raw reply

* Re: [PATCH] caif: move the dereference below the NULL test
From: David Miller @ 2012-09-10 20:14 UTC (permalink / raw)
  To: weiyj.lk; +Cc: sjur.brandeland, yongjun_wei, netdev
In-Reply-To: <CAPgLHd-MBQnrU9tS0VFw-O7yvs47r3waHqGm1SRS4GA72Pn1hg@mail.gmail.com>

From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Mon, 10 Sep 2012 12:38:27 +0800

> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> 
> The dereference should be moved below the NULL test.
> 
> spatch with a semantic match is used to found this.
> (http://coccinelle.lip6.fr/)
> 
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH net-next] r8169: use unlimited DMA burst for TX
From: David Miller @ 2012-09-10 19:50 UTC (permalink / raw)
  To: mschmidt; +Cc: netdev, romieu, hayeswang, nic_swsd, ivecera
In-Reply-To: <1347234926-5263-1-git-send-email-mschmidt@redhat.com>

From: Michal Schmidt <mschmidt@redhat.com>
Date: Mon, 10 Sep 2012 01:55:26 +0200

> The r8169 driver currently limits the DMA burst for TX to 1024 bytes. I have
> a box where this prevents the interface from using the gigabit line to its full
> potential. This patch solves the problem by setting TX_DMA_BURST to unlimited.
> 
> The box has an ASRock B75M motherboard with on-board RTL8168evl/8111evl
> (XID 0c900880). TSO is enabled.
> 
> I used netperf (TCP_STREAM test) to measure the dependency of TX throughput
> on MTU. I did it for three different values of TX_DMA_BURST ('5'=512, '6'=1024,
> '7'=unlimited). This chart shows the results:
> http://michich.fedorapeople.org/r8169/r8169-effects-of-TX_DMA_BURST.png
> 
> Interesting points:
>  - With the current DMA burst limit (1024):
>    - at the default MTU=1500 I get only 842 Mbit/s.
>    - when going from small MTU, the performance rises monotonically with
>      increasing MTU only up to a peak at MTU=1076 (908 MBit/s). Then there's
>      a sudden drop to 762 MBit/s from which the throughput rises monotonically
>      again with further MTU increases.
>  - With a smaller DMA burst limit (512):
>    - there's a similar peak at MTU=1076 and another one at MTU=564.
>  - With unlimited DMA burst:
>    - at the default MTU=1500 I get nice 940 Mbit/s.
>    - the throughput rises monotonically with increasing MTU with no strange
>      peaks.
> 
> Notice that the peaks occur at MTU sizes that are multiples of the DMA burst
> limit plus 52. Why 52? Because:
>   20 (IP header) + 20 (TCP header) + 12 (TCP options) = 52
> 
> The Realtek-provided r8168 driver (v8.032.00) uses unlimited TX DMA burst too,
> except for CFG_METHOD_1 where the TX DMA burst is set to 512 bytes.
> CFG_METHOD_1 appears to be the oldest MAC version of "RTL8168B/8111B",
> i.e. RTL_GIGA_MAC_VER_11 in r8169. Not sure if this MAC version really needs
> the smaller burst limit, or if any other versions have similar requirements.
> 
> Signed-off-by: Michal Schmidt <mschmidt@redhat.com>

I really need Francois et al. to take a look at this before even thinking
about applying it.

^ permalink raw reply

* Re: [PATCH net-next] etherdevice: introduce help function eth_zero_addr()
From: David Miller @ 2012-09-10 19:50 UTC (permalink / raw)
  To: djduanjiong; +Cc: netdev
In-Reply-To: <504BFFBC.9070209@gmail.com>

From: Duan Jiong <djduanjiong@gmail.com>
Date: Sun, 09 Sep 2012 10:32:28 +0800

> a lot of code has either the memset or an inefficient copy
> from a static array that contains the all-zeros Ethernet address.
> Introduce help function eth_zero_addr() to fill an address with
> all zeros, making the code clearer and allowing us to get rid of
> some constant arrays.
> 
> Signed-off-by: Duan Jiong <djduanjiong@gmail.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH net-next 5/5] cnic: Allocate UIO resources only on devices that support iSCSI.
From: David Miller @ 2012-09-10 19:48 UTC (permalink / raw)
  To: mchan; +Cc: netdev
In-Reply-To: <1347120065-26492-5-git-send-email-mchan@broadcom.com>

From: "Michael Chan" <mchan@broadcom.com>
Date: Sat, 8 Sep 2012 09:01:05 -0700

> Update version to 2.5.13.
> 
> Reviewed-by: Eddie Wai <eddie.wai@broadcom.com>
> Reviewed-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next 4/5] cnic: Allocate kcq resource only on devices that support FCoE.
From: David Miller @ 2012-09-10 19:48 UTC (permalink / raw)
  To: mchan; +Cc: netdev
In-Reply-To: <1347120065-26492-4-git-send-email-mchan@broadcom.com>

From: "Michael Chan" <mchan@broadcom.com>
Date: Sat, 8 Sep 2012 09:01:04 -0700

> To save memory and to exit IRQ loop quicker on devices that don't support
> FCoE.
> 
> Reviewed-by: Eddie Wai <eddie.wai@broadcom.com>
> Reviewed-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next 3/5] cnic: Add function pointers to arm IRQ for different devices.
From: David Miller @ 2012-09-10 19:48 UTC (permalink / raw)
  To: mchan; +Cc: netdev
In-Reply-To: <1347120065-26492-3-git-send-email-mchan@broadcom.com>

From: "Michael Chan" <mchan@broadcom.com>
Date: Sat, 8 Sep 2012 09:01:03 -0700

> This will make it easier to exit IRQ loop and re-arm IRQ on devices that
> don't support FCoE.
> 
> Reviewed-by: Eddie Wai <eddie.wai@broadcom.com>
> Reviewed-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next 2/5] cnic: Free UIO rings when the device is closed.
From: David Miller @ 2012-09-10 19:48 UTC (permalink / raw)
  To: mchan; +Cc: netdev
In-Reply-To: <1347120065-26492-2-git-send-email-mchan@broadcom.com>

From: "Michael Chan" <mchan@broadcom.com>
Date: Sat, 8 Sep 2012 09:01:02 -0700

> This will free up unneeded memory.
> 
> Reviewed-by: Eddie Wai <eddie.wai@broadcom.com>
> Reviewed-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next 1/5] cnic: Add functions to allocate and free UIO rings
From: David Miller @ 2012-09-10 19:48 UTC (permalink / raw)
  To: mchan; +Cc: netdev
In-Reply-To: <1347120065-26492-1-git-send-email-mchan@broadcom.com>

From: "Michael Chan" <mchan@broadcom.com>
Date: Sat, 8 Sep 2012 09:01:01 -0700

> These functions are needed to free up memory when the rings are no longer
> needed.
> 
> Reviewed-by: Eddie Wai <eddie.wai@broadcom.com>
> Reviewed-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next] filter: add MOD operation
From: David Miller @ 2012-09-10 19:45 UTC (permalink / raw)
  To: eric.dumazet; +Cc: ak, gbakos, jschlst, netdev
In-Reply-To: <1347091415.1234.317.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 08 Sep 2012 10:03:35 +0200

> From: Eric Dumazet <edumazet@google.com>
 ...
> [PATCH net-next] filter: add MOD operation
> 
> Add a new ALU opcode, to compute a modulus.
> 
> Commit ffe06c17afbbb used an ancillary to implement XOR_X,
> but here we reserve one of the available ALU opcode to implement both
> MOD_X and MOD_K
> 
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Suggested-by: George Bakos <gbakos@alpinista.org>
> Cc: Jay Schulist <jschlst@samba.org>
> Cc: Jiri Pirko <jpirko@redhat.com>
> Cc: Andi Kleen <ak@linux.intel.com>

Applied to net-next, thanks.

^ permalink raw reply

* Re: [PATCH] staging: r8712u: fix bug in r8712_recv_indicatepkt()
From: Larry Finger @ 2012-09-10 19:40 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Greg Kroah-Hartman, netdev, Dave Jones
In-Reply-To: <1347304931.1234.2017.camel@edumazet-glaptop>

On 09/10/2012 02:22 PM, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> 64bit arches have a buggy r8712u driver, let's fix it.
>
> skb->tail must be set properly or network stack behavior is undefined.
>
> Addresses https://bugzilla.redhat.com/show_bug.cgi?id=847525
> Addresses https://bugzilla.kernel.org/show_bug.cgi?id=45071
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Dave Jones <davej@redhat.com>
> Cc: stable@vger.kernel.org [2.6.37+]

Acked-by: Larry Finger <Larry.Finger@lwfinger.net>

Larry

> ---
>   drivers/staging/rtl8712/recv_linux.c |    7 +------
>   1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/staging/rtl8712/recv_linux.c b/drivers/staging/rtl8712/recv_linux.c
> index 0e26d5f..495ee12 100644
> --- a/drivers/staging/rtl8712/recv_linux.c
> +++ b/drivers/staging/rtl8712/recv_linux.c
> @@ -117,13 +117,8 @@ void r8712_recv_indicatepkt(struct _adapter *padapter,
>   	if (skb == NULL)
>   		goto _recv_indicatepkt_drop;
>   	skb->data = precv_frame->u.hdr.rx_data;
> -#ifdef NET_SKBUFF_DATA_USES_OFFSET
> -	skb->tail = (sk_buff_data_t)(precv_frame->u.hdr.rx_tail -
> -		     precv_frame->u.hdr.rx_head);
> -#else
> -	skb->tail = (sk_buff_data_t)precv_frame->u.hdr.rx_tail;
> -#endif
>   	skb->len = precv_frame->u.hdr.len;
> +	skb_set_tail_pointer(skb, skb->len);
>   	if ((pattrib->tcpchk_valid == 1) && (pattrib->tcp_chkrpt == 1))
>   		skb->ip_summed = CHECKSUM_UNNECESSARY;
>   	else
>
>
>

^ permalink raw reply

* Re: [PATCH] xfrm: Report user triggered expirations against the users socket
From: David Miller @ 2012-09-10 19:34 UTC (permalink / raw)
  To: jhs; +Cc: ebiederm, netdev, hadi
In-Reply-To: <504B307E.2030607@mojatatu.com>

From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Sat, 08 Sep 2012 07:48:14 -0400

> On 12-09-08 03:17 AM, Eric W. Biederman wrote:
>> When a policy expiration is triggered from user space the request
>> travles through km_policy_expired and ultimately into
>> xfrm_exp_policy_notify which calls build_polexpire.  build_polexpire
>> uses the netlink port passed to km_policy_expired as the source port
>> for
>> the netlink message it builds.
>>
>> When a state expiration is triggered from user space the request
>> travles
>> through km_state_expired and ultimately into xfrm_exp_state_notify
>> which
>> calls build_expire.  build_expire uses the netlink port passed to
>> km_state_expired as the source port for the netlink message it builds.
>>
>> Pass nlh->nlmsg_pid from the user generated netlink message that
>> requested the expiration to km_policy_expired and km_state_expired
>> instead of current->pid which is not a netlink port number.
>>
>> Cc: Jamal Hadi Salim <hadi@cyberus.ca>
>> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>>
> 
> I suppose.
> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>

Applied to net-next, thanks.

^ permalink raw reply

* Re: [PATCH] netlink: Rename pid to portid to avoid confusion
From: David Miller @ 2012-09-10 19:31 UTC (permalink / raw)
  To: shemminger; +Cc: ebiederm, netdev
In-Reply-To: <20120908095441.359df1d1@s6510.linuxnetplumber.net>

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Sat, 8 Sep 2012 09:54:41 -0700

> On Fri, 07 Sep 2012 23:12:54 -0700
> ebiederm@xmission.com (Eric W. Biederman) wrote:
> 
>> It is a frequent mistake to confuse the netlink port identifier with a
>> process identifier.  Try to reduce this confusion by renaming fields
>> that hold port identifiers portid instead of pid.
>> 
>> I have carefully avoided changing the structures exported to
>> userspace to avoid changing the userspace API.
>> 
>> I have successfully built an allyesconfig kernel with this change.
>> 
>> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>> ---
> 
> Ok. I validated that no header file used by iproute2 is affected.
> 
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>

Applied to net-next, thanks.

^ 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