* net: stmmac: Meson GXBB: attempting to execute userspace memory
From: Heinrich Schuchardt @ 2016-11-26 7:53 UTC (permalink / raw)
To: Carlo Caione, Kevin Hilman
Cc: Giuseppe Cavallaro, Alexandre Torgue, netdev, linux-arm-kernel,
linux-amlogic, lkml
For Odroid C2 I have compiled kernel
4.9.0-rc6-next-20161124-00001-gbf7e142
with one additional patch
https://github.com/xypron/kernel-odroid-c2/blob/master/patch/0001-stmmac-RTL8211F-Meson-GXBB-TX-throughput-problems.patch
I repeatedly see faults like the one below:
[ 2557.400796] Unhandled fault: synchronous external abort (0x92000010)
at 0x000040001e8ee4b0
[ 2557.952413] CPU: 0 PID: 22837 Comm: cc1 Tainted: G D
4.9.0-rc6-next-20161124-00001-gbf7e142 #1
[ 2557.962062] Hardware name: Hardkernel ODROID-C2 (DT)
[ 2557.966980] task: ffff80006ddb7080 task.stack: ffff80006dd9c000
[ 2557.972846] PC is at 0x6a0d98
[ 2557.975776] LR is at 0x6a0e54
[ 2557.978709] pc : [<00000000006a0d98>] lr : [<00000000006a0e54>]
pstate: 80000000
[ 2557.986040] sp : 0000fffff3ee5f80
[ 2557.989318] x29: 0000fffff3ee5f80 x28: 000040000b3f1240
[ 2557.994578] x27: 00000000012a7000 x26: 000040000b3f1288
[ 2557.999840] x25: 0000000000f58f88 x24: 000040000b3f1240
[ 2558.005101] x23: 0000000000000000 x22: 0000000000000001
[ 2558.010362] x21: 0000000000000001 x20: 000040000b3f1250
[ 2558.015623] x19: 0000000000000054 x18: 0000000000000001
[ 2558.020885] x17: 0000400008acaa10 x16: 0000000001285050
[ 2558.026146] x15: 000040000ad96dc8 x14: 000000000000001f
[ 2558.031407] x13: 000040000b3f1270 x12: 000040000b3f1258
[ 2558.036668] x11: 0000000001347000 x10: 0000000000000661
[ 2558.041930] x9 : 0000000000000005 x8 : 0000000000000003
[ 2558.047191] x7 : 000040000b3f1240 x6 : 0000000020020033
[ 2558.052452] x5 : 000040000b402020 x4 : 000040000b3e1aa0
[ 2558.057713] x3 : 000000000000000c x2 : 0000000000000020
[ 2558.062974] x1 : 0000000000f45000 x0 : 0000000000000065
[ 2558.068235]
[ 2558.069712] Internal error: Attempting to execute userspace memory:
8600000f [#7] PREEMPT SMP
[ 2558.078155] Modules linked in: meson_rng rng_core meson_gxbb_wdt
ip_tables x_tables ipv6 dwmac_generic realtek dwmac_meson8b
stmmac_platform stmmac
[ 2558.091267] CPU: 0 PID: 22837 Comm: cc1 Tainted: G D
4.9.0-rc6-next-20161124-00001-gbf7e142 #1
[ 2558.100925] Hardware name: Hardkernel ODROID-C2 (DT)
[ 2558.105841] task: ffff80006ddb7080 task.stack: ffff80006dd9c000
[ 2558.111706] PC is at 0x6a0e54
[ 2558.114638] LR is at 0x6a0e54
[ 2558.117571] pc : [<00000000006a0e54>] lr : [<00000000006a0e54>]
pstate: 600003c5
[ 2558.124902] sp : ffff80006dd9fec0
[ 2558.128179] x29: 0000000000000000 x28: ffff80006ddb7080
[ 2558.133441] x27: 00000000012a7000 x26: 000040000b3f1288
[ 2558.138702] x25: 0000000000f58f88 x24: 000040000b3f1240
[ 2558.143963] x23: 0000000080000000 x22: 00000000006a0d98
[ 2558.149225] x21: ffffffffffffffff x20: 000080006e223000
[ 2558.154486] x19: 0000000000000000 x18: 0000000000000010
[ 2558.159747] x17: 0000400008acaa10 x16: 0000000001285050
[ 2558.165008] x15: ffff000088e91f07 x14: 0000000000000006
[ 2558.170270] x13: ffff000008e91f15 x12: 000000000000000f
[ 2558.175531] x11: 0000000000000002 x10: 00000000000002ea
[ 2558.180792] x9 : ffff80006dd9fb40 x8 : 0000000000010a8b
[ 2558.186053] x7 : 0000000000000000 x6 : 000000000000020e
[ 2558.191315] x5 : 00000000020f020e x4 : 0000000000000000
[ 2558.196576] x3 : 0000000000000000 x2 : 000000000000020f
[ 2558.201837] x1 : ffff80006ddb7080 x0 : 0000000000000000
[ 2558.207098]
[ 2558.208565] Process cc1 (pid: 22837, stack limit = 0xffff80006dd9c000)
[ 2558.215035] Stack: (0xffff80006dd9fec0 to 0xffff80006dda0000)
[ 2558.220728] fec0: 0000000000000065 0000000000f45000 0000000000000020
000000000000000c
[ 2558.228490] fee0: 000040000b3e1aa0 000040000b402020 0000000020020033
000040000b3f1240
[ 2558.236253] ff00: 0000000000000003 0000000000000005 0000000000000661
0000000001347000
[ 2558.244015] ff20: 000040000b3f1258 000040000b3f1270 000000000000001f
000040000ad96dc8
[ 2558.251778] ff40: 0000000001285050 0000400008acaa10 0000000000000001
0000000000000054
[ 2558.259540] ff60: 000040000b3f1250 0000000000000001 0000000000000001
0000000000000000
[ 2558.267303] ff80: 000040000b3f1240 0000000000f58f88 000040000b3f1288
00000000012a7000
[ 2558.275065] ffa0: 000040000b3f1240 0000fffff3ee5f80 00000000006a0e54
0000fffff3ee5f80
[ 2558.282828] ffc0: 00000000006a0d98 0000000080000000 0000000000000003
ffffffffffffffff
[ 2558.290590] ffe0: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
[ 2558.298351] Call trace:
[ 2558.300769] Exception stack(0xffff80006dd9fcf0 to 0xffff80006dd9fe20)
[ 2558.307149] fce0: 0000000000000000
0001000000000000
[ 2558.314913] fd00: ffff80006dd9fec0 00000000006a0e54 ffff800073acf500
0000000000000004
[ 2558.322675] fd20: 0000000000000000 ffff000008dbbc18 ffff80006ddb7080
000000006dd9fdd0
[ 2558.330438] fd40: ffff80006dd9fd90 ffff0000080ca878 ffff80006dd9fe40
ffff80006ddb7080
[ 2558.338200] fd60: 0000000000000004 00000000000003c0 ffff80006dd9fe40
000040000b3f1240
[ 2558.345963] fd80: 0000000000f58f88 000040000b3f1288 0000000000000000
ffff80006ddb7080
[ 2558.353725] fda0: 000000000000020f 0000000000000000 0000000000000000
00000000020f020e
[ 2558.361487] fdc0: 000000000000020e 0000000000000000 0000000000010a8b
ffff80006dd9fb40
[ 2558.369250] fde0: 00000000000002ea 0000000000000002 000000000000000f
ffff000008e91f15
[ 2558.377012] fe00: 0000000000000006 ffff000088e91f07 0000000001285050
0000400008acaa10
[ 2558.384775] [<00000000006a0e54>] 0x6a0e54
[ 2558.388743] Code: d503201f f9400280 2a1703e1 97ffff0a (aa0003f3)
[ 2558.395241] ---[ end trace 7d280955c14d4ff1 ]---
[ 2558.584022] Bad mode in Error handler detected on CPU0, code
0xbf000000 -- SError
[ 2558.585871] CPU: 0 PID: 22867 Comm: cc1 Tainted: G D
4.9.0-rc6-next-20161124-00001-gbf7e142 #1
[ 2558.595527] Hardware name: Hardkernel ODROID-C2 (DT)
[ 2558.600444] task: ffff80007454d780 task.stack: ffff8000660bc000
[ 2558.606310] PC is at 0x631928
[ 2558.609240] LR is at 0xb59ce0
[ 2558.612172] pc : [<0000000000631928>] lr : [<0000000000b59ce0>]
pstate: 80000000
[ 2558.619503] sp : 0000ffffed764d90
[ 2558.622782] x29: 0000ffffed764d90 x28: 0000000000000028
[ 2558.628042] x27: 000000001a1062f0 x26: 0000000001299198
[ 2558.633303] x25: 0000000000000001 x24: 0000000000000000
[ 2558.638564] x23: 0000000000000004 x22: 00000000013513c8
[ 2558.643825] x21: 0000400039d43488 x20: 0000000000000000
[ 2558.649086] x19: 0000400039d2d730 x18: 0000000000000000
[ 2558.654348] x17: 0000400039a7c378 x16: 0000000001285138
[ 2558.659609] x15: 0000000000000001 x14: 0000000000000000
[ 2558.664870] x13: ffffff0000000000 x12: 0000000000000000
[ 2558.670131] x11: 0000000000000028 x10: 000000000129b2b8
[ 2558.675393] x9 : 0000000000000041 x8 : 0000000000000003
[ 2558.680654] x7 : 0000000000000050 x6 : 000000000003d2c8
[ 2558.685915] x5 : 0000000000000002 x4 : 0000000000000004
[ 2558.691176] x3 : 0000000000000003 x2 : 0000000001349000
[ 2558.696438] x1 : 000000000003cb90 x0 : 0000400039d45050
[ 2558.701699]
[ 2558.703177] Internal error: Attempting to execute userspace memory:
8600000f [#8] PREEMPT SMP
[ 2558.711618] Modules linked in: meson_rng rng_core meson_gxbb_wdt
ip_tables x_tables ipv6 dwmac_generic realtek dwmac_meson8b
stmmac_platform stmmac
[ 2558.724731] CPU: 0 PID: 22867 Comm: cc1 Tainted: G D
4.9.0-rc6-next-20161124-00001-gbf7e142 #1
[ 2558.734388] Hardware name: Hardkernel ODROID-C2 (DT)
[ 2558.739304] task: ffff80007454d780 task.stack: ffff8000660bc000
[ 2558.745169] PC is at 0xb59ce0
[ 2558.748102] LR is at 0xb59ce0
[ 2558.751035] pc : [<0000000000b59ce0>] lr : [<0000000000b59ce0>]
pstate: 600003c5
[ 2558.758365] sp : ffff8000660bfec0
[ 2558.761643] x29: 0000000000000000 x28: ffff80007454d780
[ 2558.766904] x27: 000000001a1062f0 x26: 0000000001299198
[ 2558.772165] x25: 0000000000000001 x24: 0000000000000000
[ 2558.777426] x23: 0000000080000000 x22: 0000000000631928
[ 2558.782688] x21: ffffffffffffffff x20: 000080006e223000
[ 2558.787949] x19: 0000000000000000 x18: 0000000000000010
[ 2558.793210] x17: 0000400039a7c378 x16: 0000000001285138
[ 2558.798471] x15: ffff000088e91f07 x14: 0000000000000006
[ 2558.803733] x13: ffff000008e91f15 x12: 000000000000000f
[ 2558.808994] x11: 0000000000000002 x10: 0000000000000336
[ 2558.814255] x9 : ffff8000660bfb40 x8 : 00000000000ab503
[ 2558.819516] x7 : 0000000000000000 x6 : 00000000000000dd
[ 2558.824778] x5 : 0000000000de00dd x4 : 0000000000000000
[ 2558.830039] x3 : 0000000000000000 x2 : 00000000000000de
[ 2558.835300] x1 : ffff80007454d780 x0 : 0000000000000000
[ 2558.840561]
[ 2558.842029] Process cc1 (pid: 22867, stack limit = 0xffff8000660bc000)
[ 2558.848498] Stack: (0xffff8000660bfec0 to 0xffff8000660c0000)
[ 2558.854191] fec0: 0000400039d45050 000000000003cb90 0000000001349000
0000000000000003
[ 2558.861953] fee0: 0000000000000004 0000000000000002 000000000003d2c8
0000000000000050
[ 2558.869716] ff00: 0000000000000003 0000000000000041 000000000129b2b8
0000000000000028
[ 2558.877478] ff20: 0000000000000000 ffffff0000000000 0000000000000000
0000000000000001
[ 2558.885241] ff40: 0000000001285138 0000400039a7c378 0000000000000000
0000400039d2d730
[ 2558.893003] ff60: 0000000000000000 0000400039d43488 00000000013513c8
0000000000000004
[ 2558.900766] ff80: 0000000000000000 0000000000000001 0000000001299198
000000001a1062f0
[ 2558.908529] ffa0: 0000000000000028 0000ffffed764d90 0000000000b59ce0
0000ffffed764d90
[ 2558.916291] ffc0: 0000000000631928 0000000080000000 000000001a18c000
ffffffffffffffff
[ 2558.924053] ffe0: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
[ 2558.931814] Call trace:
[ 2558.934232] Exception stack(0xffff8000660bfcf0 to 0xffff8000660bfe20)
[ 2558.940613] fce0: 0000000000000000
0001000000000000
[ 2558.948376] fd00: ffff8000660bfec0 0000000000b59ce0 ffff800073acf640
0000000000000004
[ 2558.956138] fd20: 0000000000000000 ffff000008dbbc18 ffff80007454d780
00000000660bfdd0
[ 2558.963901] fd40: ffff8000660bfd90 ffff0000080ca878 ffff8000660bfe40
ffff80007454d780
[ 2558.971663] fd60: 0000000000000004 00000000000003c0 ffff8000660bfe40
0000000000000000
[ 2558.979426] fd80: 0000000000000001 0000000001299198 0000000000000000
ffff80007454d780
[ 2558.987188] fda0: 00000000000000de 0000000000000000 0000000000000000
0000000000de00dd
[ 2558.994951] fdc0: 00000000000000dd 0000000000000000 00000000000ab503
ffff8000660bfb40
[ 2559.002713] fde0: 0000000000000336 0000000000000002 000000000000000f
ffff000008e91f15
[ 2559.010476] fe00: 0000000000000006 ffff000088e91f07 0000000001285138
0000400039a7c378
[ 2559.018238] [<0000000000b59ce0>] 0xb59ce0
[ 2559.022207] Code: d2800001 d2800002 d2800500 97eb5e9d (a9007c1f)
[ 2559.028376] ---[ end trace 7d280955c14d4ff2 ]---
[ 2559.034397] Bad mode in Error handler detected on CPU2, code
0xbf000000 -- SError
[ 2559.040235] CPU: 2 PID: 22866 Comm: gcc Tainted: G D
4.9.0-rc6-next-20161124-00001-gbf7e142 #1
[ 2559.049892] Hardware name: Hardkernel ODROID-C2 (DT)
[ 2559.054808] task: ffff80007454e400 task.stack: ffff80006de9c000
[ 2559.060674] PC is at 0x40003c0400d8
[ 2559.064122] LR is at 0x46d4e0
[ 2559.067055] pc : [<000040003c0400d8>] lr : [<000000000046d4e0>]
pstate: 80000000
[ 2559.074385] sp : 0000ffffe6387270
[ 2559.077664] x29: 0000ffffe6387270 x28: 0000000016c0ff90
[ 2559.082924] x27: 0000000000000002 x26: 0000000000000001
[ 2559.088185] x25: 0000ffffe63873f4 x24: 0000ffffe63873f8
[ 2559.093447] x23: 0000ffffe63873f4 x22: 0000ffffe63873f8
[ 2559.098708] x21: 0000000016c104e0 x20: 0000000000005953
[ 2559.103969] x19: 0000000000000000 [ 2559.107102] Unhandled fault:
synchronous external abort (0x96000010) at 0xffff800000c1e000
[ 2559.107108] Internal error: : 96000010 [#9] PREEMPT SMP
[ 2559.107110] Modules linked in:
[ 2559.107113] meson_rng rng_core meson_gxbb_wdt ip_tables x_tables
ipv6 dwmac_generic realtek dwmac_meson8b stmmac_platform stmmac[
2559.107131] CPU: 0 PID: 1124 Comm: mmcqd/1 Tainted: G D 1
[ 2559.107132] Hardware name: Hardkernel ODROID-C2 (DT)
[ 2559.107135] task: ffff8000704abe80 task.stack: ffff8000734d0000
[ 2559.107147] PC is at __memcpy+0x100/0x180
[ 2559.107152] LR is at sg_copy_buffer+0xb0/0x110
[ 2559.107155] pc : [<ffff00000837ee00>] lr : [<ffff00000838e928>]
pstate: 200001c5
[ 2559.107155] sp : ffff8000734d3bb0
[ 2559.107157] x29: ffff8000734d3bb0
[ 2559.107158] x28: ffff800073a14800 x27: ffff800073a14b68
[ 2559.107162] x26: 0000000000000000 x25: 0000000000000140
[ 2559.107165] x24: 0000000000000001 x23: 0000000000001000
[ 2559.107168] x22: ffff8000746a2000 x21: 0000000000001000
[ 2559.107170] x20: 0000000000000000 x19: 0000000000001000
[ 2559.107172] x18: 0000000000000000 x17: ffffffffffffffff
[ 2559.107175] x16: 00000000000006be x15: ffff000008c34000
[ 2559.107178] x14: 747962342e090a34 x13: 3278302038323162
[ 2559.107181] x12: 656c752e090a3864 x11: ffff800073866800
[ 2559.107183] x10: ffff80006bf68eb0 x9 : 0000000000000000
[ 2559.107186] x8 : ffff800073a94920 x7 : 0000000000000000
[ 2559.107188] x6 : ffff8000746a2000 x5 : 0000820000000000
[ 2559.107191] x4 : 0000000000000000 x3 : 0000000000000000
[ 2559.107193] x2 : 0000000000000f80 x1 : ffff800000c1e000
[ 2559.107196] x0 : ffff8000746a2000
[ 2559.107199] Process mmcqd/1 (pid: 1124, stack limit = 0xffff8000734d0000)
[ 2559.107202] Stack: (0xffff8000734d3bb0 to 0xffff8000734d4000)
[ 2559.107205] 3ba0: ffff8000734d3c50
ffff00000838e9bc
[ 2559.107208] 3bc0: ffff800073a14000 ffff800073a14a30 ffff80006bf68eb0
ffff800073a14a28
[ 2559.107212] 3be0: ffff800073a14818 ffff800073a14800 0000000000000000
ffff00000838e1c4
[ 2559.107215] 3c00: ffff800073a94900 ffff7e0000030780 ffff800000c1e000
0000000000001000
[ 2559.107218] 3c20: 0000000000001000 ffff800073ad0a00 0000000100000000
0000000000000001
[ 2559.107221] 3c40: 0000100000000000 0000000000000005 ffff8000734d3c60
ffff00000874c1bc
[ 2559.107224] 3c60: ffff8000734d3c70 ffff000008748010 ffff8000734d3cd0
ffff000008749908
[ 2559.107228] 3c80: ffff80006bf68eb0 ffff800073a14000 ffff8000734c8000
ffff800073a14818
[ 2559.107231] 3ca0: ffff800073a14800 ffff800073a14800 ffff80006bf68eb0
ffff800073a14a28
[ 2559.107234] 3cc0: ffff80006bf68eb0 ffff000008749bc8 ffff8000734d3d70
ffff00000874b298
[ 2559.107237] 3ce0: ffff800073a14000 ffff800073a14818 ffff8000734c8000
0000000000000000
[ 2559.107240] 3d00: ffff800073a14800 ffff800073a14800 ffff800073a13800
0000000000000000
[ 2559.107243] 3d20: ffff80006bf68eb0 0000000000000000 00000000012853f0
ffff000008c0fcb8
[ 2559.107246] 3d40: 0000000000000000 000000000835bf14 ffff000008a05f58
ffff800000000000
[ 2559.107249] 3d60: ffff8000734c8000 0000000000000001 ffff8000734d3de0
ffff00000874b6f4
[ 2559.107252] 3d80: ffff800073a14818 ffff80006bf68eb0 ffff8000734c8000
0000000000000001
[ 2559.107255] 3da0: ffff800073a14828 0000000000000000 0000000000000000
0000000000000000
[ 2559.107258] 3dc0: 0000000000000000 0000000000000000 ffff800073a14818
ffff00000874b6c4
[ 2559.107261] 3de0: ffff8000734d3e20 ffff0000080daa84 ffff800073a94980
ffff000008e8eb08
[ 2559.107264] 3e00: ffff000008b75b50 ffff800073a14818 ffff00000874b658
0000000000000000
[ 2559.107267] 3e20: 0000000000000000 ffff000008082ec0 ffff0000080da9b8
ffff800073a94980
[ 2559.107270] 3e40: 0000000000000000 0000000000000000 0000000000000000
000003ff01893600
[ 2559.107273] 3e60: ffff8000734d3ea0 0000000000000000 ffff0000080da9b8
ffff800073a14818
[ 2559.107276] 3e80: 0000000000000000 0000000000000000 ffff8000734d3e90
ffff8000734d3e90
[ 2559.107279] 3ea0: 0000000000000000 ffff000000000000 ffff8000734d3eb0
ffff8000734d3eb0
[ 2559.107281] 3ec0: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
[ 2559.107284] 3ee0: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
[ 2559.107287] 3f00: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
[ 2559.107290] 3f20: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
[ 2559.107293] 3f40: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
[ 2559.107295] 3f60: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
[ 2559.107298] 3f80: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
[ 2559.107300] 3fa0: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
[ 2559.107303] 3fc0: 0000000000000000 0000000000000005 0000000000000000
0000000000000000
[ 2559.107306] 3fe0: 0000000000000000 0000000000000000 0000001800002cba
26000000a01b3800
[ 2559.107308] Call trace:
[ 2559.107312] Exception stack(0xffff8000734d39e0 to 0xffff8000734d3b10)
[ 2559.107315] 39e0: 0000000000001000 0001000000000000 ffff8000734d3bb0
ffff00000837ee00
[ 2559.107318] 3a00: 0000000000000007 ffff800000000000 ffff800000c1e000
0000000100100010
[ 2559.107321] 3a20: ffff8000734d3ac0 ffff000008748d88 ffff8000734d3b8c
0000000000000001
[ 2559.107324] 3a40: ffff8000734d3b40 ffff0000081c9dac ffff800074401d00
ffff0000081745d8
[ 2559.107327] 3a60: ffff7e0001b72f80 ffff80006dcbe300 00000000031fda40
0000000000000000
[ 2559.107330] 3a80: ffff8000746a2000 ffff800000c1e000 0000000000000f80
0000000000000000
[ 2559.107333] 3aa0: 0000000000000000 0000820000000000 ffff8000746a2000
0000000000000000
[ 2559.107336] 3ac0: ffff800073a94920 0000000000000000 ffff80006bf68eb0
ffff800073866800
[ 2559.107339] 3ae0: 656c752e090a3864 3278302038323162 747962342e090a34
ffff000008c34000
[ 2559.107341] 3b00: 00000000000006be ffffffffffffffff
[ 2559.107346] [<ffff00000837ee00>] __memcpy+0x100/0x180
[ 2559.107349] [<ffff00000838e9bc>] sg_copy_to_buffer+0x14/0x20
[ 2559.107357] [<ffff00000874c1bc>] mmc_queue_bounce_pre+0x34/0x40
[ 2559.107362] [<ffff000008748010>] mmc_blk_rw_rq_prep+0x288/0x3a0
[ 2559.107365] [<ffff000008749908>] mmc_blk_issue_rw_rq+0x3c0/0x998
[ 2559.107368] [<ffff00000874b298>] mmc_blk_issue_rq+0x150/0x510
[ 2559.107371] [<ffff00000874b6f4>] mmc_queue_thread+0x9c/0x140
[ 2559.107377] [<ffff0000080daa84>] kthread+0xcc/0xe0
[ 2559.107383] [<ffff000008082ec0>] ret_from_fork+0x10/0x50
[ 2559.107387] Code: d503201f d503201f d503201f d503201f (a8c12027)
[ 2559.107409] ---[ end trace 7d280955c14d4ff3 ]---
[ 2559.107417] note: mmcqd/1[1124] exited with preempt_count 1
[ 2559.688313] x18: 0000000000040900 x17: 0000000000590578 x16:
000040003c0400a8
[ 2559.695471] x15: 000000000000065c x14: 0000000000000000
[ 2559.700733] x13: 002f362f756e672d x12: 78756e696c2d3436
[ 2559.705994] x11: 0000000000000001 x10: 0101010101010101
[ 2559.711255] x9 : 0000000000000001 x8 : 0000000000000104
[ 2559.716516] x7 : 000000000046d448 x6 : 0000ffffe63873f4
[ 2559.721778] x5 : 0000ffffe63873f8 x4 : 0000000000000000
[ 2559.727039] x3 : 0000000000000000 x2 : 0000000000000000
[ 2559.732300] x1 : 0000000016c104e0 x0 : 0000000000005953
[ 2559.737561]
[ 2559.739036] Internal error: Attempting to execute userspace memory:
8600000f [#10] PREEMPT SMP
[ 2559.747566] Modules linked in: meson_rng rng_core meson_gxbb_wdt
ip_tables x_tables ipv6 dwmac_generic realtek dwmac_meson8b
stmmac_platform stmmac
[ 2559.760678] CPU: 2 PID: 22866 Comm: gcc Tainted: G D
4.9.0-rc6-next-20161124-00001-gbf7e142 #1
[ 2559.770337] Hardware name: Hardkernel ODROID-C2 (DT)
[ 2559.775254] task: ffff80007454e400 task.stack: ffff80006de9c000
[ 2559.781118] PC is at 0x46d4e0
[ 2559.784051] LR is at 0x46d4e0
[ 2559.786983] pc : [<000000000046d4e0>] lr : [<000000000046d4e0>]
pstate: 600003c5
[ 2559.794314] sp : ffff80006de9fec0
[ 2559.797591] x29: 0000000000000000 x28: ffff80007454e400
[ 2559.802853] x27: 0000000000000002 x26: 0000000000000001
[ 2559.808114] x25: 0000ffffe63873f4 x24: 0000ffffe63873f8
[ 2559.813375] x23: 0000000080000000 x22: 000040003c0400d8
[ 2559.818636] x21: ffffffffffffffff x20: 000080006e24d000
[ 2559.823898] x19: 0000000000000000 x18: 0000000000000010
[ 2559.829159] x17: 0000000000590578 x16: 000040003c0400a8
[ 2559.834420] x15: ffff000088e91f07 x14: 0000000000000006
[ 2559.839682] x13: ffff000008e91f15 x12: 000000000000000f
[ 2559.844943] x11: 0000000000000002 x10: 00000000000003f4
[ 2559.850204] x9 : ffff80006de9fb40 x8 : 00000000000b4119
[ 2559.855465] x7 : 0000000000000000 x6 : 000000000000019d
[ 2559.860726] x5 : 00000000019e019d x4 : 0000000000000000
[ 2559.865988] x3 : 0000000000000002 x2 : 000000000000019e
[ 2559.871249] x1 : ffff80007454e400 x0 : 0000000000000000
[ 2559.876510]
[ 2559.877977] Process gcc (pid: 22866, stack limit = 0xffff80006de9c000)
[ 2559.884446] Stack: (0xffff80006de9fec0 to 0xffff80006dea0000)
[ 2559.890140] fec0: 0000000000005953 0000000016c104e0 0000000000000000
0000000000000000
[ 2559.897902] fee0: 0000000000000000 0000ffffe63873f8 0000ffffe63873f4
000000000046d448
[ 2559.905664] ff00: 0000000000000104 0000000000000001 0101010101010101
0000000000000001
[ 2559.913427] ff20: 78756e696c2d3436 002f362f756e672d 0000000000000000
000000000000065c
[ 2559.921190] ff40: 000040003c0400a8 0000000000590578 0000000000040900
0000000000000000
[ 2559.928952] ff60: 0000000000005953 0000000016c104e0 0000ffffe63873f8
0000ffffe63873f4
[ 2559.936714] ff80: 0000ffffe63873f8 0000ffffe63873f4 0000000000000001
0000000000000002
[ 2559.944477] ffa0: 0000000016c0ff90 0000ffffe6387270 000000000046d4e0
0000ffffe6387270
[ 2559.952240] ffc0: 000040003c0400d8 0000000080000000 0000000000005953
ffffffffffffffff
[ 2559.960002] ffe0: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
[ 2559.967762] Call trace:
[ 2559.970179] Exception stack(0xffff80006de9fcf0 to 0xffff80006de9fe20)
[ 2559.976561] fce0: 0000000000000000
0001000000000000
[ 2559.984324] fd00: ffff80006de9fec0 000000000046d4e0 ffff80007366f8c0
0000000000000004
[ 2559.992087] fd20: 0000000000000000 ffff000008dbbc18 ffff80007454e400
000000006de9fdd0
[ 2559.999850] fd40: ffff80006de9fd90 ffff0000080ca878 ffff80006de9fe40
ffff80007454e400
[ 2560.007612] fd60: 0000000000000004 00000000000003c0 ffff80006de9fe40
0000ffffe63873f8
[ 2560.015374] fd80: 0000ffffe63873f4 0000000000000001 0000000000000000
ffff80007454e400
[ 2560.023137] fda0: 000000000000019e 0000000000000002 0000000000000000
00000000019e019d
[ 2560.030899] fdc0: 000000000000019d 0000000000000000 00000000000b4119
ffff80006de9fb40
[ 2560.038662] fde0: 00000000000003f4 0000000000000002 000000000000000f
ffff000008e91f15
[ 2560.046425] fe00: 0000000000000006 ffff000088e91f07 000040003c0400a8
0000000000590578
[ 2560.054186] [<000000000046d4e0>] 0x46d4e0
[ 2560.058155] Code: aa1503e1 2a1403e0 52800002 97fe895d (2a0003e1)
[ 2560.064244] ---[ end trace 7d280955c14d4ff4 ]---
^ permalink raw reply
* [PATCH net-next] cgroup, bpf: remove unnecessary #include
From: Alexei Starovoitov @ 2016-11-26 7:23 UTC (permalink / raw)
To: David S . Miller; +Cc: Daniel Borkmann, Daniel Mack, Tejun Heo, netdev
this #include is unnecessary and brings whole set of
other headers into cgroup-defs.h. Remove it.
Fixes: 3007098494be ("cgroup: add support for eBPF programs")
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
---
include/linux/bpf-cgroup.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/bpf-cgroup.h b/include/linux/bpf-cgroup.h
index ec80d0c0953e..0cf1adfadd2d 100644
--- a/include/linux/bpf-cgroup.h
+++ b/include/linux/bpf-cgroup.h
@@ -1,7 +1,6 @@
#ifndef _BPF_CGROUP_H
#define _BPF_CGROUP_H
-#include <linux/bpf.h>
#include <linux/jump_label.h>
#include <uapi/linux/bpf.h>
--
2.8.0
^ permalink raw reply related
* Xmas Offer
From: Mrs Julie Leach @ 2016-11-26 7:02 UTC (permalink / raw)
To: Recipients
You are a recipient to Mrs Julie Leach Donation of $3 million USD. Contact ( julieleach93@gmail.com ) for claims.
^ permalink raw reply
* Re: [Patch net-next] net_sched: move the empty tp check from ->destroy() to ->delete()
From: Cong Wang @ 2016-11-26 6:46 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Roi Dayan, Linux Kernel Network Developers, Jiri Pirko,
John Fastabend
In-Reply-To: <58370558.9070004@iogearbox.net>
On Thu, Nov 24, 2016 at 7:20 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> Ok, strange, qdisc_destroy() calls into ops->destroy(), where ingress
> drops its entire chain via tcf_destroy_chain(), so that will be NULL
> eventually. The tps are freed by call_rcu() as well as qdisc itself
> later on via qdisc_rcu_free(), where it frees per-cpu bstats as well.
> Outstanding readers should either bail out due to if (!cl) or can still
> process the chain until read section ends, but during that time, cl->q
> resp. bstats should be good. Do you happen to know what's at address
> ffff880a68b04028? I was wondering wrt call_rcu() vs call_rcu_bh(), but
> at least on ingress (netif_receive_skb_internal()) we hold rcu_read_lock()
> here. The KASAN report is reliably happening at this location, right?
I am confused as well, I don't see how it could be related to my patch yet.
I will take a deep look in the weekend.
Thanks!
^ permalink raw reply
* Re: Crash due to mutex genl_lock called from RCU context
From: subashab @ 2016-11-26 5:59 UTC (permalink / raw)
To: Eric Dumazet; +Cc: tgraf, netdev, netdev-owner
In-Reply-To: <1480136078.8455.589.camel@edumazet-glaptop3.roam.corp.google.com>
> Oh well, this wont work, since sk->sk_destruct will be called from RCU
> callback.
>
> Grabbing the mutex should not be done from netlink_sock_destruct() but
> from netlink_release()
>
> Maybe this patch would be better :
>
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index 62bea4591054..cce10e3c9b68 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -324,16 +324,6 @@ static void netlink_skb_set_owner_r(struct
> sk_buff *skb, struct sock *sk)
>
> static void netlink_sock_destruct(struct sock *sk)
> {
> - struct netlink_sock *nlk = nlk_sk(sk);
> -
> - if (nlk->cb_running) {
> - if (nlk->cb.done)
> - nlk->cb.done(&nlk->cb);
> -
> - module_put(nlk->cb.module);
> - kfree_skb(nlk->cb.skb);
> - }
> -
> skb_queue_purge(&sk->sk_receive_queue);
>
> if (!sock_flag(sk, SOCK_DEAD)) {
> @@ -456,8 +446,9 @@ static struct sock *netlink_lookup(struct net
> *net, int protocol, u32 portid)
>
> rcu_read_lock();
> sk = __netlink_lookup(table, portid, net);
> - if (sk)
> - sock_hold(sk);
> + if (sk && !atomic_inc_not_zero(&sk->sk_refcnt))
> + sk = NULL;
> +
> rcu_read_unlock();
>
> return sk;
> @@ -581,6 +572,7 @@ static int __netlink_create(struct net *net,
> struct socket *sock,
> }
> init_waitqueue_head(&nlk->wait);
>
> + sock_set_flag(sk, SOCK_RCU_FREE);
> sk->sk_destruct = netlink_sock_destruct;
> sk->sk_protocol = protocol;
> return 0;
> @@ -645,13 +637,6 @@ static int netlink_create(struct net *net, struct
> socket *sock, int protocol,
> goto out;
> }
>
> -static void deferred_put_nlk_sk(struct rcu_head *head)
> -{
> - struct netlink_sock *nlk = container_of(head, struct netlink_sock,
> rcu);
> -
> - sock_put(&nlk->sk);
> -}
> -
> static int netlink_release(struct socket *sock)
> {
> struct sock *sk = sock->sk;
> @@ -724,7 +709,19 @@ static int netlink_release(struct socket *sock)
> local_bh_disable();
> sock_prot_inuse_add(sock_net(sk), &netlink_proto, -1);
> local_bh_enable();
> - call_rcu(&nlk->rcu, deferred_put_nlk_sk);
> + if (nlk->cb_running) {
> + mutex_lock(nlk->cb_mutex);
> + if (nlk->cb_running) {
> + if (nlk->cb.done)
> + nlk->cb.done(&nlk->cb);
> +
> + module_put(nlk->cb.module);
> + kfree_skb(nlk->cb.skb);
> + nlk->cb_running = false;
> + }
> + mutex_unlock(nlk->cb_mutex);
> + }
> + sock_put(sk);
> return 0;
> }
>
> diff --git a/net/netlink/af_netlink.h b/net/netlink/af_netlink.h
> index 3cfd6cc60504..5dc08a7b0a2b 100644
> --- a/net/netlink/af_netlink.h
> +++ b/net/netlink/af_netlink.h
> @@ -32,7 +32,6 @@ struct netlink_sock {
> struct module *module;
>
> struct rhash_head node;
> - struct rcu_head rcu;
> };
>
> static inline struct netlink_sock *nlk_sk(struct sock *sk)
Thanks Eric! I'll try this and get back with results over this weekend.
^ permalink raw reply
* Re: Crash due to mutex genl_lock called from RCU context
From: Eric Dumazet @ 2016-11-26 4:54 UTC (permalink / raw)
To: subashab; +Cc: tgraf, netdev
In-Reply-To: <1480133493.8455.584.camel@edumazet-glaptop3.roam.corp.google.com>
On Fri, 2016-11-25 at 20:11 -0800, Eric Dumazet wrote:
> On Fri, 2016-11-25 at 19:15 -0700, subashab@codeaurora.org wrote:
> > We are seeing a crash due to gen_lock mutex being acquired in RCU
> > context.
> > Crash is seen on a 4.4 based kernel ARM64 device. This occurred in a
> > regression rack, so unfortunately I don't have steps for a reproducer.
> >
> > It looks like freeing socket in RCU was brought in through commit
> > 21e4902aea80ef35afc00ee8d2abdea4f519b7f7 ("netlink: Lockless lookup with
> > RCU grace period in socket release").
> > I am not very familiar with generic netlink sockets so I am not sure
> > if there is any other way to fix this apart from reverting this patch.
> >
> > Any pointers to debug this would be appreciated.
> >
> > Here is the call stack -
> >
> > BUG: sleeping function called from invalid context
> > kernel/locking/mutex.c:98
> > in_atomic(): 1, irqs_disabled(): 0, pid: 16400, name: busybox
> > [<ffffff80080cad20>] ___might_sleep+0x134/0x144
> > [<ffffff80080cadac>] __might_sleep+0x7c/0x8c
> > [<ffffff8008ef09a8>] mutex_lock+0x2c/0x4c
> > [<ffffff8008d307f0>] genl_lock+0x1c/0x24
> > [<ffffff8008d30848>] genl_lock_done+0x2c/0x50
> > [<ffffff8008d2ccac>] netlink_sock_destruct+0x30/0x94
> > [<ffffff8008cdef44>] sk_destruct+0x2c/0x150
> > [<ffffff8008cdf104>] __sk_free+0x9c/0xc4
> > [<ffffff8008cdf16c>] sk_free+0x40/0x4c
> > [<ffffff8008d2c7fc>] deferred_put_nlk_sk+0x40/0x4c
> > [<ffffff800810b104>] rcu_process_callbacks+0x4d4/0x644
> > [<ffffff80080a6598>] __do_softirq+0x1b8/0x3c4
> > [<ffffff80080a6a60>] irq_exit+0x80/0xd4
> > [<ffffff800808e554>] handle_IPI+0x1c0/0x364
> > [<ffffff80080817f8>] gic_handle_irq+0x154/0x1a4
>
> Right, Thomas commit looks buggy.
>
> Unfortunately the proper infra was added later in commit
> a4298e4522d687a79af8 ("net: add SOCK_RCU_FREE socket flag")
>
> I guess we should backport it, then apply following (untested) fix
>
> Could you test this solution ? Thanks !
>
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index 62bea4591054..fe0d43314198 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -456,8 +456,9 @@ static struct sock *netlink_lookup(struct net *net, int protocol, u32 portid)
>
> rcu_read_lock();
> sk = __netlink_lookup(table, portid, net);
> - if (sk)
> - sock_hold(sk);
> + if (sk && !atomic_inc_not_zero(&sk->sk_refcnt))
> + sk = NULL;
> +
> rcu_read_unlock();
>
> return sk;
> @@ -581,6 +582,7 @@ static int __netlink_create(struct net *net, struct socket *sock,
> }
> init_waitqueue_head(&nlk->wait);
>
> + sock_set_flag(sk, SOCK_RCU_FREE);
> sk->sk_destruct = netlink_sock_destruct;
> sk->sk_protocol = protocol;
Oh well, this wont work, since sk->sk_destruct will be called from RCU
callback.
Grabbing the mutex should not be done from netlink_sock_destruct() but
from netlink_release()
Maybe this patch would be better :
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 62bea4591054..cce10e3c9b68 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -324,16 +324,6 @@ static void netlink_skb_set_owner_r(struct sk_buff *skb, struct sock *sk)
static void netlink_sock_destruct(struct sock *sk)
{
- struct netlink_sock *nlk = nlk_sk(sk);
-
- if (nlk->cb_running) {
- if (nlk->cb.done)
- nlk->cb.done(&nlk->cb);
-
- module_put(nlk->cb.module);
- kfree_skb(nlk->cb.skb);
- }
-
skb_queue_purge(&sk->sk_receive_queue);
if (!sock_flag(sk, SOCK_DEAD)) {
@@ -456,8 +446,9 @@ static struct sock *netlink_lookup(struct net *net, int protocol, u32 portid)
rcu_read_lock();
sk = __netlink_lookup(table, portid, net);
- if (sk)
- sock_hold(sk);
+ if (sk && !atomic_inc_not_zero(&sk->sk_refcnt))
+ sk = NULL;
+
rcu_read_unlock();
return sk;
@@ -581,6 +572,7 @@ static int __netlink_create(struct net *net, struct socket *sock,
}
init_waitqueue_head(&nlk->wait);
+ sock_set_flag(sk, SOCK_RCU_FREE);
sk->sk_destruct = netlink_sock_destruct;
sk->sk_protocol = protocol;
return 0;
@@ -645,13 +637,6 @@ static int netlink_create(struct net *net, struct socket *sock, int protocol,
goto out;
}
-static void deferred_put_nlk_sk(struct rcu_head *head)
-{
- struct netlink_sock *nlk = container_of(head, struct netlink_sock, rcu);
-
- sock_put(&nlk->sk);
-}
-
static int netlink_release(struct socket *sock)
{
struct sock *sk = sock->sk;
@@ -724,7 +709,19 @@ static int netlink_release(struct socket *sock)
local_bh_disable();
sock_prot_inuse_add(sock_net(sk), &netlink_proto, -1);
local_bh_enable();
- call_rcu(&nlk->rcu, deferred_put_nlk_sk);
+ if (nlk->cb_running) {
+ mutex_lock(nlk->cb_mutex);
+ if (nlk->cb_running) {
+ if (nlk->cb.done)
+ nlk->cb.done(&nlk->cb);
+
+ module_put(nlk->cb.module);
+ kfree_skb(nlk->cb.skb);
+ nlk->cb_running = false;
+ }
+ mutex_unlock(nlk->cb_mutex);
+ }
+ sock_put(sk);
return 0;
}
diff --git a/net/netlink/af_netlink.h b/net/netlink/af_netlink.h
index 3cfd6cc60504..5dc08a7b0a2b 100644
--- a/net/netlink/af_netlink.h
+++ b/net/netlink/af_netlink.h
@@ -32,7 +32,6 @@ struct netlink_sock {
struct module *module;
struct rhash_head node;
- struct rcu_head rcu;
};
static inline struct netlink_sock *nlk_sk(struct sock *sk)
^ permalink raw reply related
* Re: Crash due to mutex genl_lock called from RCU context
From: Eric Dumazet @ 2016-11-26 4:11 UTC (permalink / raw)
To: subashab; +Cc: tgraf, netdev
In-Reply-To: <c669cd06c3e50febd95b5ed4aaa78532@codeaurora.org>
On Fri, 2016-11-25 at 19:15 -0700, subashab@codeaurora.org wrote:
> We are seeing a crash due to gen_lock mutex being acquired in RCU
> context.
> Crash is seen on a 4.4 based kernel ARM64 device. This occurred in a
> regression rack, so unfortunately I don't have steps for a reproducer.
>
> It looks like freeing socket in RCU was brought in through commit
> 21e4902aea80ef35afc00ee8d2abdea4f519b7f7 ("netlink: Lockless lookup with
> RCU grace period in socket release").
> I am not very familiar with generic netlink sockets so I am not sure
> if there is any other way to fix this apart from reverting this patch.
>
> Any pointers to debug this would be appreciated.
>
> Here is the call stack -
>
> BUG: sleeping function called from invalid context
> kernel/locking/mutex.c:98
> in_atomic(): 1, irqs_disabled(): 0, pid: 16400, name: busybox
> [<ffffff80080cad20>] ___might_sleep+0x134/0x144
> [<ffffff80080cadac>] __might_sleep+0x7c/0x8c
> [<ffffff8008ef09a8>] mutex_lock+0x2c/0x4c
> [<ffffff8008d307f0>] genl_lock+0x1c/0x24
> [<ffffff8008d30848>] genl_lock_done+0x2c/0x50
> [<ffffff8008d2ccac>] netlink_sock_destruct+0x30/0x94
> [<ffffff8008cdef44>] sk_destruct+0x2c/0x150
> [<ffffff8008cdf104>] __sk_free+0x9c/0xc4
> [<ffffff8008cdf16c>] sk_free+0x40/0x4c
> [<ffffff8008d2c7fc>] deferred_put_nlk_sk+0x40/0x4c
> [<ffffff800810b104>] rcu_process_callbacks+0x4d4/0x644
> [<ffffff80080a6598>] __do_softirq+0x1b8/0x3c4
> [<ffffff80080a6a60>] irq_exit+0x80/0xd4
> [<ffffff800808e554>] handle_IPI+0x1c0/0x364
> [<ffffff80080817f8>] gic_handle_irq+0x154/0x1a4
Right, Thomas commit looks buggy.
Unfortunately the proper infra was added later in commit
a4298e4522d687a79af8 ("net: add SOCK_RCU_FREE socket flag")
I guess we should backport it, then apply following (untested) fix
Could you test this solution ? Thanks !
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 62bea4591054..fe0d43314198 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -456,8 +456,9 @@ static struct sock *netlink_lookup(struct net *net, int protocol, u32 portid)
rcu_read_lock();
sk = __netlink_lookup(table, portid, net);
- if (sk)
- sock_hold(sk);
+ if (sk && !atomic_inc_not_zero(&sk->sk_refcnt))
+ sk = NULL;
+
rcu_read_unlock();
return sk;
@@ -581,6 +582,7 @@ static int __netlink_create(struct net *net, struct socket *sock,
}
init_waitqueue_head(&nlk->wait);
+ sock_set_flag(sk, SOCK_RCU_FREE);
sk->sk_destruct = netlink_sock_destruct;
sk->sk_protocol = protocol;
return 0;
@@ -645,13 +647,6 @@ static int netlink_create(struct net *net, struct socket *sock, int protocol,
goto out;
}
-static void deferred_put_nlk_sk(struct rcu_head *head)
-{
- struct netlink_sock *nlk = container_of(head, struct netlink_sock, rcu);
-
- sock_put(&nlk->sk);
-}
-
static int netlink_release(struct socket *sock)
{
struct sock *sk = sock->sk;
@@ -724,7 +719,7 @@ static int netlink_release(struct socket *sock)
local_bh_disable();
sock_prot_inuse_add(sock_net(sk), &netlink_proto, -1);
local_bh_enable();
- call_rcu(&nlk->rcu, deferred_put_nlk_sk);
+ sock_put(sk);
return 0;
}
diff --git a/net/netlink/af_netlink.h b/net/netlink/af_netlink.h
index 3cfd6cc60504..5dc08a7b0a2b 100644
--- a/net/netlink/af_netlink.h
+++ b/net/netlink/af_netlink.h
@@ -32,7 +32,6 @@ struct netlink_sock {
struct module *module;
struct rhash_head node;
- struct rcu_head rcu;
};
static inline struct netlink_sock *nlk_sk(struct sock *sk)
^ permalink raw reply related
* Xmas Offer
From: Mrs Julie Leach @ 2016-11-26 3:05 UTC (permalink / raw)
To: Recipients
You are a recipient to Mrs Julie Leach Donation of $3 million USD. Contact ( julieleach93@gmail.com ) for claims.
^ permalink raw reply
* Re: [PATCH net 1/1] tipc: resolve connection flow control compatibility problem
From: David Miller @ 2016-11-26 2:38 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, parthasarathy.bhuvaragan, ying.xue, maloy,
tipc-discussion
In-Reply-To: <1480031227-14836-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Thu, 24 Nov 2016 18:47:07 -0500
> In commit 10724cc7bb78 ("tipc: redesign connection-level flow control")
> we replaced the previous message based flow control with one based on
> 1k blocks. In order to ensure backwards compatibility the mechanism
> falls back to using message as base unit when it senses that the peer
> doesn't support the new algorithm. The default flow control window,
> i.e., how many units can be sent before the sender blocks and waits
> for an acknowledge (aka advertisement) is 512. This was tested against
> the previous version, which uses an acknowledge frequency of on ack per
> 256 received message, and found to work fine.
>
> However, we missed the fact that versions older than Linux 3.15 use an
> acknowledge frequency of 512, which is exactly the limit where a 4.6+
> sender will stop and wait for acknowledge. This would also work fine if
> it weren't for the fact that if the first sent message on a 4.6+ server
> side is an empty SYNACK, this one is also is counted as a sent message,
> while it is not counted as a received message on a legacy 3.15-receiver.
> This leads to the sender always being one step ahead of the receiver, a
> scenario causing the sender to block after 512 sent messages, while the
> receiver only has registered 511 read messages. Hence, the legacy
> receiver is not trigged to send an acknowledge, with a permanently
> blocked sender as result.
>
> We solve this deadlock by simply allowing the sender to send one more
> message before it blocks, i.e., by a making minimal change to the
> condition used for determining connection congestion.
>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied, thanks Jon.
^ permalink raw reply
* Re: [patch net-next 00/19] mlxsw: traps, trap groups and policers
From: David Miller @ 2016-11-26 2:22 UTC (permalink / raw)
To: jiri; +Cc: netdev, nogahf, idosch, eladr, yotamg, arkadis, ogerlitz
In-Reply-To: <1480066427-3961-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 25 Nov 2016 10:33:28 +0100
> From: Jiri Pirko <jiri@mellanox.com>
>
> Nogah says:
>
> For a packet to be sent from the HW to the cpu, it needs to be trapped.
> For a trap to be activate it should be assigned to a trap group.
> Those trap groups can have policers, to limit the packet rate (the max
> number of packets that can be sent to the cpu in a time slot, the rest
> will be discarded) or the data rate (the same, but the count is not by the
> number of packets but by their total length in bytes).
>
> This patchset rearrange the trap setting API, re-write the traps and the
> trap groups list in spectrum and assign them policers.
Series applied, thanks.
^ permalink raw reply
* Crash due to mutex genl_lock called from RCU context
From: subashab @ 2016-11-26 2:15 UTC (permalink / raw)
To: tgraf, netdev; +Cc: eric.dumazet
We are seeing a crash due to gen_lock mutex being acquired in RCU
context.
Crash is seen on a 4.4 based kernel ARM64 device. This occurred in a
regression rack, so unfortunately I don't have steps for a reproducer.
It looks like freeing socket in RCU was brought in through commit
21e4902aea80ef35afc00ee8d2abdea4f519b7f7 ("netlink: Lockless lookup with
RCU grace period in socket release").
I am not very familiar with generic netlink sockets so I am not sure
if there is any other way to fix this apart from reverting this patch.
Any pointers to debug this would be appreciated.
Here is the call stack -
BUG: sleeping function called from invalid context
kernel/locking/mutex.c:98
in_atomic(): 1, irqs_disabled(): 0, pid: 16400, name: busybox
[<ffffff80080cad20>] ___might_sleep+0x134/0x144
[<ffffff80080cadac>] __might_sleep+0x7c/0x8c
[<ffffff8008ef09a8>] mutex_lock+0x2c/0x4c
[<ffffff8008d307f0>] genl_lock+0x1c/0x24
[<ffffff8008d30848>] genl_lock_done+0x2c/0x50
[<ffffff8008d2ccac>] netlink_sock_destruct+0x30/0x94
[<ffffff8008cdef44>] sk_destruct+0x2c/0x150
[<ffffff8008cdf104>] __sk_free+0x9c/0xc4
[<ffffff8008cdf16c>] sk_free+0x40/0x4c
[<ffffff8008d2c7fc>] deferred_put_nlk_sk+0x40/0x4c
[<ffffff800810b104>] rcu_process_callbacks+0x4d4/0x644
[<ffffff80080a6598>] __do_softirq+0x1b8/0x3c4
[<ffffff80080a6a60>] irq_exit+0x80/0xd4
[<ffffff800808e554>] handle_IPI+0x1c0/0x364
[<ffffff80080817f8>] gic_handle_irq+0x154/0x1a4
^ permalink raw reply
* Re: [PATCH net] mvpp2: use correct size for memset
From: David Miller @ 2016-11-26 1:57 UTC (permalink / raw)
To: arnd; +Cc: jszhang, mw, tremyfr, netdev, linux-kernel
In-Reply-To: <20161124162843.3849988-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Thu, 24 Nov 2016 17:28:12 +0100
> gcc-7 detects a short memset in mvpp2, introduced in the original
> merge of the driver:
>
> drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_cls_init':
> drivers/net/ethernet/marvell/mvpp2.c:3296:2: error: 'memset' used with length equal to number of elements without multiplication by element size [-Werror=memset-elt-size]
>
> The result seems to be that we write uninitialized data into the
> flow table registers, although we did not get any warning about
> that uninitialized data usage.
>
> Using sizeof() lets us initialize then entire array instead.
>
> Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] irda: fix overly long udelay()
From: David Miller @ 2016-11-26 1:56 UTC (permalink / raw)
To: arnd; +Cc: samuel, netdev, linux-kernel
In-Reply-To: <20161124162630.3802535-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Thu, 24 Nov 2016 17:26:22 +0100
> irda_get_mtt() returns a hardcoded '10000' in some cases,
> and with gcc-7, we get a build error because this triggers a
> compile-time check in udelay():
>
> drivers/net/irda/w83977af_ir.o: In function `w83977af_hard_xmit':
> w83977af_ir.c:(.text.w83977af_hard_xmit+0x14c): undefined reference to `__bad_udelay'
>
> Older compilers did not run into this because they either did not
> completely inline the irda_get_mtt() or did not consider the
> 10000 value a constant expression.
>
> The code has been wrong since the start of git history.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
...
> @@ -518,7 +518,9 @@ static netdev_tx_t w83977af_hard_xmit(struct sk_buff *skb,
>
> mtt = irda_get_mtt(skb);
> pr_debug("%s(%ld), mtt=%d\n", __func__ , jiffies, mtt);
> - if (mtt)
> + if (mtt > 1000)
> + mdelay(mtt/1000);
> + else if (mtt)
> udelay(mtt);
I know this isn't caused by you, but wow what is going on with the
indentation here?!?!?
^ permalink raw reply
* Re: [PATCH V3 net-next 05/15] smc: CLC handshake (incl. preparation steps)
From: David Miller @ 2016-11-26 1:53 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, utz.bacher
In-Reply-To: <20161124150645.90881-6-ubraun@linux.vnet.ibm.com>
From: Ursula Braun <ubraun@linux.vnet.ibm.com>
Date: Thu, 24 Nov 2016 16:06:35 +0100
> +struct smc_clc_msg_hdr { /* header1 of clc messages */
> + u8 eyecatcher[4]; /* eye catcher */
> + u8 type; /* proposal / accept / confirm / decline */
> + __be16 length;
> +#if defined(__BIG_ENDIAN_BITFIELD)
> + u8 version : 4,
> + flag : 1,
> + rsvd : 3;
> +#elif defined(__LITTLE_ENDIAN_BITFIELD)
> + u8 rsvd : 3,
> + flag : 1,
> + version : 4;
> +#endif
> +} __packed;
Please get rid of all of these __packed attributes. They are likely
completely unnecessary and the code generated for this construct on
certain architectures is amazingly inefficient.
Describe the on-wire datastructures properly with fixed sized types
and any padding or overlapping, as needed.
^ permalink raw reply
* Re: [PATCH V3 net-next 03/15] smc: establish pnet table management
From: David Miller @ 2016-11-26 1:51 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, utz.bacher
In-Reply-To: <20161124150645.90881-4-ubraun@linux.vnet.ibm.com>
From: Ursula Braun <ubraun@linux.vnet.ibm.com>
Date: Thu, 24 Nov 2016 16:06:33 +0100
> Connection creation with SMC-R starts through an internal
> TCP-connection. The Ethernet interface for this TCP-connection is not
> restricted to the Ethernet interface of a RoCE device. Any existing
> Ethernet interface belonging to the same physical net can be used, as
> long as there is a defined relation between the Ethernet interface and
> some RoCE devices. This relation is defined with the help of an
> identification string called "Physical Net ID" or short "pnet ID".
> Information about defined pnet IDs and their related Ethernet
> interfaces and RoCE devices is stored in the SMC-R pnet table.
>
> This patch adds pnet table configuration support as a set of
> sysfs files listed under /sys/kernel/smc. Attribute files
> exist to add and delete pnet IDs and to map RoCE devices and
> ethernet interfaces to an individual pnet ID.
>
> There is no cross check if ethernet interfaces or infiniband
> devices really exist in the system. This enables the configuration of
> the pnet table after module load even if interfaces or devices might
> not yet be available.
>
> Signed-off-by: Thomas Richter <tmricht@linux.vnet.ibm.com>
> Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
Please do not use sysfs to configure your subsystems IB and eth
mappings.
Instead use a properly formed genetlink interface that will properly
integrate with other subsystems, and also allow for proper event
monitoring.
I also fundamentally disagree with allowing references to devices that
do not even exist yet. It implies a string --> device conversion in
places where that cost should be avoided.
^ permalink raw reply
* Re: [PATCH V3 net-next 02/15] smc: establish new socket family
From: David Miller @ 2016-11-26 1:47 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, utz.bacher
In-Reply-To: <20161124150645.90881-3-ubraun@linux.vnet.ibm.com>
From: Ursula Braun <ubraun@linux.vnet.ibm.com>
Date: Thu, 24 Nov 2016 16:06:32 +0100
> +static struct sock *smc_sock_alloc(struct net *net, struct socket *sock)
> +{
> + struct smc_sock *smc;
> + struct sock *sk;
> +
> + sk = sk_alloc(net, PF_SMC, GFP_KERNEL, &smc_proto, 0);
> + if (!sk)
> + return NULL;
> +
> + sock_init_data(sock, sk); /* sets sk_refcnt to 1 */
> + sk->sk_state = SMC_INIT;
> + sk->sk_destruct = smc_destruct;
> + sk->sk_protocol = SMCPROTO_SMC;
> + sk_refcnt_debug_inc(sk);
> +
> + smc = smc_sk(sk);
> + smc->clcsock = NULL;
> + smc->use_fallback = 0;
This is unnecessary, sk_alloc() clears out the memory for you.
> +static int smc_bind(struct socket *sock, struct sockaddr *uaddr,
> + int addr_len)
> +{
...
> + smc->clcsock->sk->sk_reuse = sk->sk_reuse;
> + rc = kernel_bind(smc->clcsock, uaddr, addr_len);
Is it valid to assume smc->clcsock is not NULL right here?
> +struct smc_sock { /* smc sock container */
> + struct sock sk;
> + struct socket *clcsock; /* internal tcp socket */
> + u8 use_fallback : 1; /* fallback to tcp */
> +};
Please use 'bool' and true/false for 'use_fallback'.
^ permalink raw reply
* Re: [PATCH V3 net-next 01/15] net: introduce keepalive function in struct proto
From: David Miller @ 2016-11-26 1:41 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, utz.bacher
In-Reply-To: <20161124150645.90881-2-ubraun@linux.vnet.ibm.com>
From: Ursula Braun <ubraun@linux.vnet.ibm.com>
Date: Thu, 24 Nov 2016 16:06:31 +0100
> diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
> index 3ea1cf8..9b1602a 100644
> --- a/net/ipv4/tcp_timer.c
> +++ b/net/ipv4/tcp_timer.c
> @@ -617,6 +617,7 @@ void tcp_set_keepalive(struct sock *sk, int val)
> else if (!val)
> inet_csk_delete_keepalive_timer(sk);
> }
> +EXPORT_SYMBOL(tcp_set_keepalive);
Please use EXPORT_SYMBOL_GPL().
^ permalink raw reply
* Re: [PATCH] net/mlx5: drop duplicate header delay.h
From: David Miller @ 2016-11-26 1:33 UTC (permalink / raw)
To: geliangtang; +Cc: saeedm, matanb, leonro, netdev, linux-rdma, linux-kernel
In-Reply-To: <03d5a2a0f03458cdb4f2b139cfabc11b5c334f95.1479990943.git.geliangtang@gmail.com>
From: Geliang Tang <geliangtang@gmail.com>
Date: Thu, 24 Nov 2016 21:58:33 +0800
> Drop duplicate header delay.h from mlx5/core/main.c.
>
> Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: ieee802154: drop duplicate header delay.h
From: David Miller @ 2016-11-26 1:33 UTC (permalink / raw)
To: geliangtang; +Cc: michael.hennerich, aar, linux-wpan, netdev, linux-kernel
In-Reply-To: <f64943b9c1da12b6199ba745ba04cb477a05a5a3.1479991128.git.geliangtang@gmail.com>
From: Geliang Tang <geliangtang@gmail.com>
Date: Thu, 24 Nov 2016 21:58:32 +0800
> Drop duplicate header delay.h from adf7242.c.
>
> Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ibmvnic: drop duplicate header seq_file.h
From: David Miller @ 2016-11-26 1:32 UTC (permalink / raw)
To: geliangtang
Cc: tlfalcon, jallen, benh, paulus, mpe, netdev, linuxppc-dev,
linux-kernel
In-Reply-To: <9f2baee4e0a81ba8b5089a2b5a42f67678de4b06.1479989017.git.geliangtang@gmail.com>
From: Geliang Tang <geliangtang@gmail.com>
Date: Thu, 24 Nov 2016 21:58:29 +0800
> Drop duplicate header seq_file.h from ibmvnic.c.
>
> Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Applied.
^ permalink raw reply
* Re: [patch] fsl/fman: fix a leak in tgec_free()
From: David Miller @ 2016-11-26 1:30 UTC (permalink / raw)
To: dan.carpenter; +Cc: madalin.bucur, igal.liberman, netdev, kernel-janitors
In-Reply-To: <20161124111931.GK17225@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 24 Nov 2016 14:20:43 +0300
> We set "tgec->cfg" to NULL before passing it to kfree(). There is no
> need to set it to NULL at all. Let's just delete it.
>
> Fixes: 57ba4c9b56d8 ("fsl/fman: Add FMan MAC support")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [patch] net/mlx5: remove a duplicate condition
From: David Miller @ 2016-11-26 1:30 UTC (permalink / raw)
To: dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA
Cc: saeedm-VPRAkNaXOzVWk0Htik3J/w, matanb-VPRAkNaXOzVWk0Htik3J/w,
leonro-VPRAkNaXOzVWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161124110345.GC17225@mwanda>
From: Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Date: Thu, 24 Nov 2016 14:03:45 +0300
> We verified that MLX5_FLOW_CONTEXT_ACTION_COUNT was set on the first
> line of the function so we don't need to check again here.
>
> Signed-off-by: Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: ethtool: don't require CAP_NET_ADMIN for ETHTOOL_GLINKSETTINGS
From: David Miller @ 2016-11-26 1:23 UTC (permalink / raw)
To: mlichvar; +Cc: netdev, decot
In-Reply-To: <20161124095506.25791-1-mlichvar@redhat.com>
From: Miroslav Lichvar <mlichvar@redhat.com>
Date: Thu, 24 Nov 2016 10:55:06 +0100
> The ETHTOOL_GLINKSETTINGS command is deprecating the ETHTOOL_GSET
> command and likewise it shouldn't require the CAP_NET_ADMIN capability.
>
> Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
Good catch, applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/4] net: thunderx: Support for 80xx, RED, PFC e.t.c
From: David Miller @ 2016-11-26 1:21 UTC (permalink / raw)
To: sunil.kovvuri; +Cc: netdev, linux-kernel, linux-arm-kernel, sgoutham
In-Reply-To: <1479979083-15963-1-git-send-email-sunil.kovvuri@gmail.com>
From: sunil.kovvuri@gmail.com
Date: Thu, 24 Nov 2016 14:47:59 +0530
> This patch series adds support for SLM modules present on 80xx
> silicon, enables ramdom early discard, backpressure generation,
> PFC and some ethtool changes to display supported link modes e.t.c.
Series applied to net-next.
^ permalink raw reply
* Re: [net-next] neigh: fix the loop index error in neigh dump
From: David Miller @ 2016-11-26 1:17 UTC (permalink / raw)
To: zhangshengju; +Cc: netdev, dsa
In-Reply-To: <1479965109-14607-1-git-send-email-zhangshengju@cmss.chinamobile.com>
From: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
Date: Thu, 24 Nov 2016 13:25:09 +0800
> Loop index in neigh dump function is not updated correctly under some
> circumstances, this patch will fix it.
>
> Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
If this bug is also in the 'net' tree you should target this patch
there.
Also, you must provide an appropriate "Fixes: " tag identifying
the commit which introduced this bug.
^ 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