* Re: (2) [Bug reporting] kernel panic during handle the dst unreach icmp msg.
From: Eric Dumazet @ 2019-02-15 1:08 UTC (permalink / raw)
To: soukjin.bae, netdev@vger.kernel.org
Cc: 박종언, Steffen Klassert, Herbert Xu
In-Reply-To: <20190214235427epcms1p25712530506811b6279ffbe6c54914e72@epcms1p2>
On 02/14/2019 03:54 PM, 배석진 wrote:
>> I do not believe this patch is needed.
>>
>> You probably hit another more serious bug, but since you do not post the full stack trace
>> it is hard to help.
>>
>> Are you using vti tunnel ?
>
> there's no working logs of vpn/vti/tun on platform or kernel history.
> and callstack has no functions about that.
> it looks like simple ipv4 usage.
>
> attaching full dump info.
> no additional bug or warning on entire kernel history.
> anything about tun or kasan even onther.
>
> thanks.
>
>
> <4>[60392.948306] I[1: ksoftirqd/1: 19] ------------[ cut here ]------------
> <0>[60392.948334] I[1: ksoftirqd/1: 19] kernel BUG at net/ipv4/tcp_ipv4.c:519!
What the code looks like at line 519 of net/ipv4/tcp_ipv4.c ?
This is not a pristine kernel, anything could be wrong, you might have missed some critical backports.
> <2>[60392.948344] I[1: ksoftirqd/1: 19] sec_debug_set_extra_info_fault = BUG / 0xffffff80090351d0
> <0>[60392.948386] I[1: ksoftirqd/1: 19] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> <4>[60392.948395] I[1: ksoftirqd/1: 19] Modules linked in:
> <0>[60392.948408] I[1: ksoftirqd/1: 19] debug-snapshot: core register saved(CPU:1)
> <0>[60392.948416] I[1: ksoftirqd/1: 19] DISR_EL1: 0000000000000000
> <0>[60392.948425] I[1: ksoftirqd/1: 19] DISR_EL1 valid_bit(31) is NOT set (0x0)
> <0>[60392.948433] I[1: ksoftirqd/1: 19] CPU : ERXSTATUS_EL1: 0000000000000000, ERXADDR_EL1: 0000000000000000, ERXMISC0_EL1: 0000000000000000
> <0>[60392.948441] I[1: ksoftirqd/1: 19] ERXSTATUS_EL1 valid_bit(30) is NOT set (0x0)
> <0>[60392.948449] I[1: ksoftirqd/1: 19] DSU : ERXSTATUS_EL1: 0000000000000000, ERXADDR_EL1: 0000000000000000, ERXMISC0_EL1: 0000000000000000
> <0>[60392.948457] I[1: ksoftirqd/1: 19] ERXSTATUS_EL1 valid_bit(30) is NOT set (0x0)
> <0>[60392.948464] I[1: ksoftirqd/1: 19] debug-snapshot: context saved(CPU:1)
> <0>[60392.950562] I[1: ksoftirqd/1: 19] ============ CPU Error Log Info after Cache flush ================
> <0>[60392.950579] I[1: ksoftirqd/1: 19] DISR_EL1: 0000000000000000
> <0>[60392.950588] I[1: ksoftirqd/1: 19] DISR_EL1 valid_bit(31) is NOT set (0x0)
> <0>[60392.950596] I[1: ksoftirqd/1: 19] CPU : ERXSTATUS_EL1: 0000000000000000, ERXADDR_EL1: 0000000000000000, ERXMISC0_EL1: 0000000000000000
> <0>[60392.950604] I[1: ksoftirqd/1: 19] ERXSTATUS_EL1 valid_bit(30) is NOT set (0x0)
> <0>[60392.950611] I[1: ksoftirqd/1: 19] DSU : ERXSTATUS_EL1: 0000000000000000, ERXADDR_EL1: 0000000000000000, ERXMISC0_EL1: 0000000000000000
> <0>[60392.950619] I[1: ksoftirqd/1: 19] ERXSTATUS_EL1 valid_bit(30) is NOT set (0x0)
> <6>[60392.950631] I[1: ksoftirqd/1: 19] debug-snapshot: item - log_kevents is disabled
> <6>[60392.950638] I[1: ksoftirqd/1: 19] TIF_FOREIGN_FPSTATE: 0, FP/SIMD depth 0, cpu: 0
> <4>[60392.950648] I[1: ksoftirqd/1: 19] CPU: 1 PID: 19 Comm: ksoftirqd/1 Tainted: G W 4.14.85-15389299 #1
> <4>[60392.950655] I[1: ksoftirqd/1: 19] Hardware name: Samsung BEYOND2LTE KOR SINGLE 26 board based on EXYNOS9820 (DT)
> <4>[60392.950664] I[1: ksoftirqd/1: 19] task: ffffffc8f0c8c400 task.stack: ffffff800b958000
> <4>[60392.950676] I[1: ksoftirqd/1: 19] PC is at tcp_v4_err+0x4b0/0x4bc
> <4>[60392.950684] I[1: ksoftirqd/1: 19] LR is at tcp_v4_err+0x3ac/0x4bc
> <4>[60392.950692] I[1: ksoftirqd/1: 19] pc : [<ffffff80090351d0>] lr : [<ffffff80090350cc>] pstate: 60c00145
> <4>[60392.950698] I[1: ksoftirqd/1: 19] sp : ffffff800b95b940
> <4>[60392.950705] I[1: ksoftirqd/1: 19] x29: ffffff800b95b990 x28: ffffffc82fe10c2c
> <4>[60392.950714] I[1: ksoftirqd/1: 19] x27: 0000000000000003 x26: 0000000000000001
> <4>[60392.950723] I[1: ksoftirqd/1: 19] x25: ffffffc0051e5e00 x24: ffffff800aaebc80
> <4>[60392.950732] I[1: ksoftirqd/1: 19] x23: ffffffc0051e5f58 x22: 0000000000000000
> <4>[60392.950741] I[1: ksoftirqd/1: 19] x21: 0000000000000071 x20: ffffffc0051e5e88
> <4>[60392.950750] I[1: ksoftirqd/1: 19] x19: ffffffc0051e5e00 x18: 0000000000000001
> <4>[60392.950760] I[1: ksoftirqd/1: 19] x17: 0000000000000400 x16: 0000000000000000
> <4>[60392.950769] I[1: ksoftirqd/1: 19] x15: ffffffffffffffff x14: 0000000000000000
> <4>[60392.950778] I[1: ksoftirqd/1: 19] x13: 0000000000000002 x12: 0000000000000000
> <4>[60392.950787] I[1: ksoftirqd/1: 19] x11: ffffffc0051e5f58 x10: 0000000000007530
> <4>[60392.950796] I[1: ksoftirqd/1: 19] x9 : 0000000000000020 x8 : 0000000000000200
> <4>[60392.950806] I[1: ksoftirqd/1: 19] x7 : 0000000000000000 x6 : 0000000000000010
> <4>[60392.950815] I[1: ksoftirqd/1: 19] x5 : 000000000000808c x4 : 000000000000bb01
> <4>[60392.950825] I[1: ksoftirqd/1: 19] x3 : 00000000831fd9ac x2 : 000000000000808c
> <4>[60392.950834] I[1: ksoftirqd/1: 19] x1 : 000000000200a8c0 x0 : 0000000000000040
> <4>[60392.950844] I[1: ksoftirqd/1: 19]
> <4>[60392.950844] I[1: ksoftirqd/1: 19] PC: 0xffffff80090350d0:
> <4>[60392.950855] I[1: ksoftirqd/1: 19] 50d0 : 92407C08 14000009 AA1303E0 97FFFE97 17FFFFD0 F940CB08 D538D089 9108E108
> <4>[60392.950872] I[1: ksoftirqd/1: 19] 50f0 : 17FFFF78 52801F48 12001D29 F940AE77 9AC92108 D344FD09 528EA60A 9105626B
> <4>[60392.950888] I[1: ksoftirqd/1: 19] 5110 : F11D4D3F 9A8A3108 EB0B02FF B9072268 54000580 B4000577 97C9A4D3 D29EF9EA
> <4>[60392.950903] I[1: ksoftirqd/1: 19] 5130 : F2BC6A6A F9444A68 F2D374AA D343FC09 F2E4188A 9BCA7D29 D344FD29 EB08013F
> <4>[60392.950919] I[1: ksoftirqd/1: 19] 5150 : 54000069 AA0903E8 F9044A69 B94022E9 B9472277 4B090100 97C94F99 CB0002E8
> <4>[60392.950934] I[1: ksoftirqd/1: 19] 5170 : 7100051F 5400022B 320003EA B000A74B 391D4A6A 93407D08 F945416A D344FD0B
> <4>[60392.950951] I[1: ksoftirqd/1: 19] 5190 : 528EA609 F11D4D7F 9A893108 8B080142 911A4261 AA1303E0 F9034662 97FCBBB7
> <4>[60392.950967] I[1: ksoftirqd/1: 19] 51b0 : AA1603E8 17FFFF86 F9455668 AA1303E0 F9402D08 94063788 AA1603E8 17FFFF80
> <4>[60392.950982] I[1: ksoftirqd/1: 19] 51d0 : D4210000 14000000 00BE7BAD F81C0FF7 A90157F6 A9024FF4 A9037BFD 9100C3FD
> <4>[60392.950997] I[1: ksoftirqd/1: 19] 51f0 : AA0003F6 B940AAC8 F9407AC9 7941BECA B9409AD7 2A2803E8 2A0203F4 2A0103F5
> <4>[60392.951012] I[1: ksoftirqd/1: 19] 5210 : 721B051F 8B0A0133 54000201 321F07E3 2A1503E0 2A1403E1 2A1703E2 2A1F03E4
> <4>[60392.951028] I[1: ksoftirqd/1: 19] 5230 : 97D8189D 13804008 0B000108 53107D08 79002268 7941BEC8 321C03E9 790166C9
> <4>[60392.951043] I[1: ksoftirqd/1: 19] 5250 : 790162C8 14000012 79401A68 B940B2C2 AA1303E0 53027D08 121E0D01 97D8177A
> <4>[60392.951058] I[1: ksoftirqd/1: 19] 5270 : 2A0003E4 321F07E3 2A1503E0 2A1403E1 2A1703E2 97D81888 13804008 0B000108
> <4>[60392.951073] I[1: ksoftirqd/1: 19] 5290 : 12800009 4A484128 79002268 A9437BFD A9424FF4 A94157F6 F84407F7 D65F03C0
> <4>[60392.951089] I[1: ksoftirqd/1: 19] 52b0 : 00BE7BAD A9BF7BFD 910003FD B9458008 B9400002 AA0103E0 2A0803E1 97FFFFC4
> <4>[60392.951105] I[1: ksoftirqd/1: 19]
> <4>[60392.951105] I[1: ksoftirqd/1: 19] LR: 0xffffff8009034fcc:
> <4>[60392.951116] I[1: ksoftirqd/1: 19] 4fcc : 39404A69 121F1929 7100093F 540001A1 B4000068 F9407508 B4000148 B9408F28
> <4>[60392.951131] I[1: ksoftirqd/1: 19] 4fec : 35000188 F942A668 AA1303E0 B9022E75 940637FA AA1303E0 97FFAE89 14000006
> <4>[60392.951147] I[1: ksoftirqd/1: 19] 500c : B9408F28 35000068 39568268 37000208 B9023275 AA1403E0 94061649 91020260
> <4>[60392.951162] I[1: ksoftirqd/1: 19] 502c : 97D6FDEE 36000060 AA1303E0 97FCB533 A9457BFD A9444FF4 A94357F6 A9425FF8
> <4>[60392.951177] I[1: ksoftirqd/1: 19] 504c : A94167FA A8C66FFC D65F03C0 F942A668 AA1303E0 B9022E75 940637E0 17FFFFEE
> <4>[60392.951193] I[1: ksoftirqd/1: 19] 506c : D00030CB D37DF34A 9114816B B86A6975 7100075F 54FFFA68 B9400129 6B0902FF
> <4>[60392.951208] I[1: ksoftirqd/1: 19] 508c : 54FFFA01 395D4669 34FFF9C9 B5FFF9A8 395D4E69 34FFF969 B9408F2A 35FFF92A
> <4>[60392.951223] I[1: ksoftirqd/1: 19] 50ac : AA0803F6 B9489A68 51000529 391D4E69 340001C8 B948A669 0B480D20 97C94FC1
> <4>[60392.951238] I[1: ksoftirqd/1: 19] 50cc : 395D4E69 92407C08 14000009 AA1303E0 97FFFE97 17FFFFD0 F940CB08 D538D089
> <4>[60392.951254] I[1: ksoftirqd/1: 19] 50ec : 9108E108 17FFFF78 52801F48 12001D29 F940AE77 9AC92108 D344FD09 528EA60A
> <4>[60392.951269] I[1: ksoftirqd/1: 19] 510c : 9105626B F11D4D3F 9A8A3108 EB0B02FF B9072268 54000580 B4000577 97C9A4D3
> <4>[60392.951283] I[1: ksoftirqd/1: 19] 512c : D29EF9EA F2BC6A6A F9444A68 F2D374AA D343FC09 F2E4188A 9BCA7D29 D344FD29
> <4>[60392.951299] I[1: ksoftirqd/1: 19] 514c : EB08013F 54000069 AA0903E8 F9044A69 B94022E9 B9472277 4B090100 97C94F99
> <4>[60392.951314] I[1: ksoftirqd/1: 19] 516c : CB0002E8 7100051F 5400022B 320003EA B000A74B 391D4A6A 93407D08 F945416A
> <4>[60392.951328] I[1: ksoftirqd/1: 19] 518c : D344FD0B 528EA609 F11D4D7F 9A893108 8B080142 911A4261 AA1303E0 F9034662
> <4>[60392.951344] I[1: ksoftirqd/1: 19] 51ac : 97FCBBB7 AA1603E8 17FFFF86 F9455668 AA1303E0 F9402D08 94063788 AA1603E8
> <4>[60392.951358] I[1: ksoftirqd/1: 19]
> <4>[60392.951358] I[1: ksoftirqd/1: 19] SP: 0xffffff800b95b840:
> <4>[60392.951369] I[1: ksoftirqd/1: 19] b840 : 0B95BA88 FFFFFF80 00002752 00000000 0B95B9A0 FFFFFF80 00000001 00000000
> <4>[60392.951384] I[1: ksoftirqd/1: 19] b860 : 00000001 00000000 051E5E00 FFFFFFC0 0B95B8E0 FFFFFF80 09001E50 FFFFFF80
> <4>[60392.951398] I[1: ksoftirqd/1: 19] b880 : 0B95B8E0 FFFFFF80 EE595D00 B254C55C EF89B000 FFFFFFC8 EE595D00 B254C55C
> <4>[60392.951412] I[1: ksoftirqd/1: 19] b8a0 : 2FE10C24 FFFFFFC8 36B80010 FFFFFFC0 0B2D8880 FFFFFF80 0AAEBC80 FFFFFF80
> <4>[60392.951426] I[1: ksoftirqd/1: 19] b8c0 : 00000010 00000000 00000000 00000000 0B95B930 FFFFFF80 09015704 FFFFFF80
> <4>[60392.951440] I[1: ksoftirqd/1: 19] b8e0 : 00000003 00000000 0906F3D0 FFFFFF80 00000001 00000000 EF89B000 FFFFFFC8
> <4>[60392.951454] I[1: ksoftirqd/1: 19] b900 : 0AAEBC80 FFFFFF80 2FE10C24 FFFFFFC8 00000000 00000000 00000000 FFFFFFC8
> <4>[60392.951468] I[1: ksoftirqd/1: 19] b920 : 00780078 FFFFFFC8 EE595D00 B254C55C 0B95B990 FFFFFF80 09034E40 FFFFFF80
> <4>[60392.951482] I[1: ksoftirqd/1: 19] b940 : 0A5386B0 FFFFFF80 0A540FD0 FFFFFF80 EF89B0A0 FFFFFFC8 EF89B000 FFFFFFC8
> <4>[60392.951496] I[1: ksoftirqd/1: 19] b960 : 00000008 00000000 2FE10C24 FFFFFFC8 00000000 00000000 00000006 00000000
> <4>[60392.951511] I[1: ksoftirqd/1: 19] b980 : 00000000 00000000 1EEBFB80 FFFFFFC8 0B95B9C0 FFFFFF80 0904A990 FFFFFF80
> <4>[60392.951526] I[1: ksoftirqd/1: 19] b9a0 : 0AAEBC80 FFFFFF80 36B82128 FFFFFFC0 2FE10C2C FFFFFFC8 1EEBFB80 FFFFFFC8
> <4>[60392.951541] I[1: ksoftirqd/1: 19] b9c0 : 0B95BA00 FFFFFF80 0904A6D0 FFFFFF80 1EEBFC18 FFFFFFC8 EE595D00 B254C55C
> <4>[60392.951556] I[1: ksoftirqd/1: 19] b9e0 : 0A540578 FFFFFF80 12995900 FFFFFFC0 0AAEBC80 FFFFFF80 1EEBFB80 FFFFFFC8
> <4>[60392.951570] I[1: ksoftirqd/1: 19] ba00 : 0B95BA40 FFFFFF80 0904A3AC FFFFFF80 00000008 00000000 1EEBFC18 FFFFFFC8
> <4>[60392.951586] I[1: ksoftirqd/1: 19] ba20 : 0A540578 FFFFFF80 0964F9E8 FFFFFF80 0AAEBC80 FFFFFF80 1EEBFB80 FFFFFFC8
> <4>[60392.951605] I[1: ksoftirqd/1: 19]
> <4>[60392.951605] I[1: ksoftirqd/1: 19] X7: 0xffffffffffffff00:
> <4>[60392.951616] I[1: ksoftirqd/1: 19] ff00 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.951637] I[1: ksoftirqd/1: 19] ff20 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.951655] I[1: ksoftirqd/1: 19] ff40 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.951671] I[1: ksoftirqd/1: 19] ff60 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.951696] I[1: ksoftirqd/1: 19] ff80 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.951713] I[1: ksoftirqd/1: 19] ffa0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.951730] I[1: ksoftirqd/1: 19] ffc0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.951747] I[1: ksoftirqd/1: 19] ffe0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.951764] I[1: ksoftirqd/1: 19] 0000 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.951780] I[1: ksoftirqd/1: 19] 0020 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.951797] I[1: ksoftirqd/1: 19] 0040 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.951814] I[1: ksoftirqd/1: 19] 0060 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.951831] I[1: ksoftirqd/1: 19] 0080 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.951849] I[1: ksoftirqd/1: 19] 00a0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.951867] I[1: ksoftirqd/1: 19] 00c0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.951884] I[1: ksoftirqd/1: 19] 00e0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.951902] I[1: ksoftirqd/1: 19]
> <4>[60392.951902] I[1: ksoftirqd/1: 19] X11: 0xffffffc0051e5e58:
> <4>[60392.951914] I[1: ksoftirqd/1: 19] 5e58 : 00017031 00000000 00004301 00000000 0000FD75 00000000 EE63F5D0 FFFFFFC8
> <4>[60392.951930] I[1: ksoftirqd/1: 19] 5e78 : FFFFFFFF 00000004 00000003 00000000 00790078 00000000 00000000 00000000
> <4>[60392.951945] I[1: ksoftirqd/1: 19] 5e98 : 051E5E98 FFFFFFC0 051E5E98 FFFFFFC0 00000000 00000001 051E5EB0 FFFFFFC0
> <4>[60392.951961] I[1: ksoftirqd/1: 19] 5eb8 : 051E5EB0 FFFFFFC0 00000000 00000000 051E5EC8 FFFFFFC0 051E5EC8 FFFFFFC0
> <4>[60392.951975] I[1: ksoftirqd/1: 19] 5ed8 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.951990] I[1: ksoftirqd/1: 19] 5ef8 : 00000000 00000000 00000000 00123900 00000000 00000000 00000000 00000000
> <4>[60392.952005] I[1: ksoftirqd/1: 19] 5f18 : 00000000 00000000 00000000 00000000 42FCE000 FFFFFFC8 00000000 00000000
> <4>[60392.952020] I[1: ksoftirqd/1: 19] 5f38 : 00000000 00100000 00000000 00000001 00000000 00000000 00000000 00000000
> <4>[60392.952035] I[1: ksoftirqd/1: 19] 5f58 : 051E5F58 FFFFFFC0 051E5F58 FFFFFFC0 00000000 00000000 FFFFFFFF 00000000
> <4>[60392.952050] I[1: ksoftirqd/1: 19] 5f78 : 00000000 00000000 FFFFFFFF 7FFFFFFF 00000000 00000000 00000000 00000000
> <4>[60392.952065] I[1: ksoftirqd/1: 19] 5f98 : 00000000 00000000 090343B0 FFFFFF80 051E5E00 FFFFFFC0 00000001 FFFFFFFF
> <4>[60392.952079] I[1: ksoftirqd/1: 19] 5fb8 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000C026F
> <4>[60392.952094] I[1: ksoftirqd/1: 19] 5fd8 : 0007C913 FFFFFFFF 00000000 00000000 00000000 00000000 00006000 00000000
> <4>[60392.952109] I[1: ksoftirqd/1: 19] 5ff8 : 00000000 00000000 00000001 00000000 014000C0 43A820B3 00010600 00000001
> <4>[60392.952124] I[1: ksoftirqd/1: 19] 6018 : 00000000 00000000 0AAF9E10 FFFFFF80 00000000 00000000 00000071 00000000
> <4>[60392.952139] I[1: ksoftirqd/1: 19] 6038 : 00000000 00002752 00000000 00000000 00000000 00000000 FFFFFFFF 7FFFFFFF
> <4>[60392.952155] I[1: ksoftirqd/1: 19]
> <4>[60392.952155] I[1: ksoftirqd/1: 19] X12: 0xffffffffffffff00:
> <4>[60392.952166] I[1: ksoftirqd/1: 19] ff00 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952183] I[1: ksoftirqd/1: 19] ff20 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952199] I[1: ksoftirqd/1: 19] ff40 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952216] I[1: ksoftirqd/1: 19] ff60 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952232] I[1: ksoftirqd/1: 19] ff80 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952249] I[1: ksoftirqd/1: 19] ffa0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952266] I[1: ksoftirqd/1: 19] ffc0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952283] I[1: ksoftirqd/1: 19] ffe0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952300] I[1: ksoftirqd/1: 19] 0000 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952317] I[1: ksoftirqd/1: 19] 0020 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952333] I[1: ksoftirqd/1: 19] 0040 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952350] I[1: ksoftirqd/1: 19] 0060 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952366] I[1: ksoftirqd/1: 19] 0080 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952383] I[1: ksoftirqd/1: 19] 00a0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952401] I[1: ksoftirqd/1: 19] 00c0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952417] I[1: ksoftirqd/1: 19] 00e0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952436] I[1: ksoftirqd/1: 19]
> <4>[60392.952436] I[1: ksoftirqd/1: 19] X14: 0xffffffffffffff00:
> <4>[60392.952447] I[1: ksoftirqd/1: 19] ff00 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952467] I[1: ksoftirqd/1: 19] ff20 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952483] I[1: ksoftirqd/1: 19] ff40 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952499] I[1: ksoftirqd/1: 19] ff60 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952516] I[1: ksoftirqd/1: 19] ff80 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952532] I[1: ksoftirqd/1: 19] ffa0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952548] I[1: ksoftirqd/1: 19] ffc0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952563] I[1: ksoftirqd/1: 19] ffe0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952580] I[1: ksoftirqd/1: 19] 0000 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952596] I[1: ksoftirqd/1: 19] 0020 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952612] I[1: ksoftirqd/1: 19] 0040 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952628] I[1: ksoftirqd/1: 19] 0060 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952645] I[1: ksoftirqd/1: 19] 0080 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952661] I[1: ksoftirqd/1: 19] 00a0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952677] I[1: ksoftirqd/1: 19] 00c0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952693] I[1: ksoftirqd/1: 19] 00e0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952710] I[1: ksoftirqd/1: 19]
> <4>[60392.952710] I[1: ksoftirqd/1: 19] X15: 0xfffffffffffffeff:
> <4>[60392.952721] I[1: ksoftirqd/1: 19] fefc : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952737] I[1: ksoftirqd/1: 19] ff1c : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952753] I[1: ksoftirqd/1: 19] ff3c : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952768] I[1: ksoftirqd/1: 19] ff5c : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952784] I[1: ksoftirqd/1: 19] ff7c : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952799] I[1: ksoftirqd/1: 19] ff9c : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952815] I[1: ksoftirqd/1: 19] ffbc : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952830] I[1: ksoftirqd/1: 19] ffdc : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952846] I[1: ksoftirqd/1: 19] fffc : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952861] I[1: ksoftirqd/1: 19] 001c : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952877] I[1: ksoftirqd/1: 19] 003c : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952893] I[1: ksoftirqd/1: 19] 005c : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952910] I[1: ksoftirqd/1: 19] 007c : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952926] I[1: ksoftirqd/1: 19] 009c : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952944] I[1: ksoftirqd/1: 19] 00bc : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952960] I[1: ksoftirqd/1: 19] 00dc : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952976] I[1: ksoftirqd/1: 19] 00fc : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.952993] I[1: ksoftirqd/1: 19]
> <4>[60392.952993] I[1: ksoftirqd/1: 19] X16: 0xffffffffffffff00:
> <4>[60392.953004] I[1: ksoftirqd/1: 19] ff00 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953020] I[1: ksoftirqd/1: 19] ff20 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953036] I[1: ksoftirqd/1: 19] ff40 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953052] I[1: ksoftirqd/1: 19] ff60 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953068] I[1: ksoftirqd/1: 19] ff80 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953084] I[1: ksoftirqd/1: 19] ffa0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953099] I[1: ksoftirqd/1: 19] ffc0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953115] I[1: ksoftirqd/1: 19] ffe0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953130] I[1: ksoftirqd/1: 19] 0000 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953146] I[1: ksoftirqd/1: 19] 0020 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953162] I[1: ksoftirqd/1: 19] 0040 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953178] I[1: ksoftirqd/1: 19] 0060 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953194] I[1: ksoftirqd/1: 19] 0080 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953210] I[1: ksoftirqd/1: 19] 00a0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953226] I[1: ksoftirqd/1: 19] 00c0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953242] I[1: ksoftirqd/1: 19] 00e0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953259] I[1: ksoftirqd/1: 19]
> <4>[60392.953259] I[1: ksoftirqd/1: 19] X19: 0xffffffc0051e5d00:
> <4>[60392.953270] I[1: ksoftirqd/1: 19] 5d00 : 00000000 00000000 00000000 00000000 E745D5E7 496DFBF1 00000000 00000000
> <4>[60392.953285] I[1: ksoftirqd/1: 19] 5d20 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.953300] I[1: ksoftirqd/1: 19] 5d40 : 00000000 00000000 00000000 00000000 00000000 00000000 FFFF0000 0200A8C0
> <4>[60392.953314] I[1: ksoftirqd/1: 19] 5d60 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.953328] I[1: ksoftirqd/1: 19] 5d80 : 00000000 00000000 0081FF80 00000000 00000000 00080000 00000000 00000000
> <4>[60392.953342] I[1: ksoftirqd/1: 19] 5da0 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.953356] I[1: ksoftirqd/1: 19] 5dc0 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.953370] I[1: ksoftirqd/1: 19] 5de0 : 00000000 00000000 051E0BC0 FFFFFFC0 00000085 00000000 3C0ADD53 FCA9C68D
> <4>[60392.953384] I[1: ksoftirqd/1: 19] 5e00 : 831FD9AC 0200A8C0 EEE47EBA 808CBB01 4004000A 00000000 00000000 00000000
> <4>[60392.953398] I[1: ksoftirqd/1: 19] 5e20 : BC8B82B8 FFFFFFC8 0AAF9E10 FFFFFF80 0AAEBC80 FFFFFF80 00000000 00000000
> <4>[60392.953412] I[1: ksoftirqd/1: 19] 5e40 : FFFF0000 831FD9AC 00000000 00000000 FFFF0000 0200A8C0 00017031 00000000
> <4>[60392.953427] I[1: ksoftirqd/1: 19] 5e60 : 00004301 00000000 0000FD75 00000000 EE63F5D0 FFFFFFC8 FFFFFFFF 00000004
> <4>[60392.953441] I[1: ksoftirqd/1: 19] 5e80 : 00000003 00000000 00790078 00000000 00000000 00000000 051E5E98 FFFFFFC0
> <4>[60392.953455] I[1: ksoftirqd/1: 19] 5ea0 : 051E5E98 FFFFFFC0 00000000 00000001 051E5EB0 FFFFFFC0 051E5EB0 FFFFFFC0
> <4>[60392.953469] I[1: ksoftirqd/1: 19] 5ec0 : 00000000 00000000 051E5EC8 FFFFFFC0 051E5EC8 FFFFFFC0 00000000 00000000
> <4>[60392.953483] I[1: ksoftirqd/1: 19] 5ee0 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.953498] I[1: ksoftirqd/1: 19]
> <4>[60392.953498] I[1: ksoftirqd/1: 19] X20: 0xffffffc0051e5d88:
> <4>[60392.953509] I[1: ksoftirqd/1: 19] 5d88 : 0081FF80 00000000 00000000 00080000 00000000 00000000 00000000 00000000
> <4>[60392.953523] I[1: ksoftirqd/1: 19] 5da8 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.953537] I[1: ksoftirqd/1: 19] 5dc8 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.953551] I[1: ksoftirqd/1: 19] 5de8 : 051E0BC0 FFFFFFC0 00000085 00000000 3C0ADD53 FCA9C68D 831FD9AC 0200A8C0
> <4>[60392.953565] I[1: ksoftirqd/1: 19] 5e08 : EEE47EBA 808CBB01 4004000A 00000000 00000000 00000000 BC8B82B8 FFFFFFC8
> <4>[60392.953580] I[1: ksoftirqd/1: 19] 5e28 : 0AAF9E10 FFFFFF80 0AAEBC80 FFFFFF80 00000000 00000000 FFFF0000 831FD9AC
> <4>[60392.953594] I[1: ksoftirqd/1: 19] 5e48 : 00000000 00000000 FFFF0000 0200A8C0 00017031 00000000 00004301 00000000
> <4>[60392.953608] I[1: ksoftirqd/1: 19] 5e68 : 0000FD75 00000000 EE63F5D0 FFFFFFC8 FFFFFFFF 00000004 00000003 00000000
> <4>[60392.953622] I[1: ksoftirqd/1: 19] 5e88 : 00790078 00000000 00000000 00000000 051E5E98 FFFFFFC0 051E5E98 FFFFFFC0
> <4>[60392.953636] I[1: ksoftirqd/1: 19] 5ea8 : 00000000 00000001 051E5EB0 FFFFFFC0 051E5EB0 FFFFFFC0 00000000 00000000
> <4>[60392.953650] I[1: ksoftirqd/1: 19] 5ec8 : 051E5EC8 FFFFFFC0 051E5EC8 FFFFFFC0 00000000 00000000 00000000 00000000
> <4>[60392.953664] I[1: ksoftirqd/1: 19] 5ee8 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00123900
> <4>[60392.953678] I[1: ksoftirqd/1: 19] 5f08 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.953692] I[1: ksoftirqd/1: 19] 5f28 : 42FCE000 FFFFFFC8 00000000 00000000 00000000 00100000 00000000 00000001
> <4>[60392.953706] I[1: ksoftirqd/1: 19] 5f48 : 00000000 00000000 00000000 00000000 051E5F58 FFFFFFC0 051E5F58 FFFFFFC0
> <4>[60392.953720] I[1: ksoftirqd/1: 19] 5f68 : 00000000 00000000 FFFFFFFF 00000000 00000000 00000000 FFFFFFFF 7FFFFFFF
> <4>[60392.953736] I[1: ksoftirqd/1: 19]
> <4>[60392.953736] I[1: ksoftirqd/1: 19] X22: 0xffffffffffffff00:
> <4>[60392.953747] I[1: ksoftirqd/1: 19] ff00 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953764] I[1: ksoftirqd/1: 19] ff20 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953779] I[1: ksoftirqd/1: 19] ff40 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953795] I[1: ksoftirqd/1: 19] ff60 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953813] I[1: ksoftirqd/1: 19] ff80 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953830] I[1: ksoftirqd/1: 19] ffa0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953846] I[1: ksoftirqd/1: 19] ffc0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953862] I[1: ksoftirqd/1: 19] ffe0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953877] I[1: ksoftirqd/1: 19] 0000 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953893] I[1: ksoftirqd/1: 19] 0020 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953909] I[1: ksoftirqd/1: 19] 0040 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953925] I[1: ksoftirqd/1: 19] 0060 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953941] I[1: ksoftirqd/1: 19] 0080 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953957] I[1: ksoftirqd/1: 19] 00a0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953973] I[1: ksoftirqd/1: 19] 00c0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.953989] I[1: ksoftirqd/1: 19] 00e0 : ******** ******** ******** ******** ******** ******** ******** ********
> <4>[60392.954007] I[1: ksoftirqd/1: 19]
> <4>[60392.954007] I[1: ksoftirqd/1: 19] X23: 0xffffffc0051e5e58:
> <4>[60392.954019] I[1: ksoftirqd/1: 19] 5e58 : 00017031 00000000 00004301 00000000 0000FD75 00000000 EE63F5D0 FFFFFFC8
> <4>[60392.954034] I[1: ksoftirqd/1: 19] 5e78 : FFFFFFFF 00000004 00000003 00000000 00790078 00000000 00000000 00000000
> <4>[60392.954048] I[1: ksoftirqd/1: 19] 5e98 : 051E5E98 FFFFFFC0 051E5E98 FFFFFFC0 00000000 00000001 051E5EB0 FFFFFFC0
> <4>[60392.954062] I[1: ksoftirqd/1: 19] 5eb8 : 051E5EB0 FFFFFFC0 00000000 00000000 051E5EC8 FFFFFFC0 051E5EC8 FFFFFFC0
> <4>[60392.954077] I[1: ksoftirqd/1: 19] 5ed8 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.954091] I[1: ksoftirqd/1: 19] 5ef8 : 00000000 00000000 00000000 00123900 00000000 00000000 00000000 00000000
> <4>[60392.954105] I[1: ksoftirqd/1: 19] 5f18 : 00000000 00000000 00000000 00000000 42FCE000 FFFFFFC8 00000000 00000000
> <4>[60392.954119] I[1: ksoftirqd/1: 19] 5f38 : 00000000 00100000 00000000 00000001 00000000 00000000 00000000 00000000
> <4>[60392.954135] I[1: ksoftirqd/1: 19] 5f58 : 051E5F58 FFFFFFC0 051E5F58 FFFFFFC0 00000000 00000000 FFFFFFFF 00000000
> <4>[60392.954149] I[1: ksoftirqd/1: 19] 5f78 : 00000000 00000000 FFFFFFFF 7FFFFFFF 00000000 00000000 00000000 00000000
> <4>[60392.954163] I[1: ksoftirqd/1: 19] 5f98 : 00000000 00000000 090343B0 FFFFFF80 051E5E00 FFFFFFC0 00000001 FFFFFFFF
> <4>[60392.954178] I[1: ksoftirqd/1: 19] 5fb8 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000C026F
> <4>[60392.954192] I[1: ksoftirqd/1: 19] 5fd8 : 0007C913 FFFFFFFF 00000000 00000000 00000000 00000000 00006000 00000000
> <4>[60392.954206] I[1: ksoftirqd/1: 19] 5ff8 : 00000000 00000000 00000001 00000000 014000C0 43A820B3 00010600 00000001
> <4>[60392.954220] I[1: ksoftirqd/1: 19] 6018 : 00000000 00000000 0AAF9E10 FFFFFF80 00000000 00000000 00000071 00000000
> <4>[60392.954234] I[1: ksoftirqd/1: 19] 6038 : 00000000 00002752 00000000 00000000 00000000 00000000 FFFFFFFF 7FFFFFFF
> <4>[60392.954249] I[1: ksoftirqd/1: 19]
> <4>[60392.954249] I[1: ksoftirqd/1: 19] X24: 0xffffff800aaebb80:
> <4>[60392.954261] I[1: ksoftirqd/1: 19] bb80 : 0AAEEB88 FFFFFF80 0AB08710 FFFFFF80 08F65024 FFFFFF80 08F65060 FFFFFF80
> <4>[60392.954275] I[1: ksoftirqd/1: 19] bba0 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.954289] I[1: ksoftirqd/1: 19] bbc0 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.954303] I[1: ksoftirqd/1: 19] bbe0 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.954318] I[1: ksoftirqd/1: 19] bc00 : 00000000 00000000 00000000 00000000 0AAEBC10 FFFFFF80 0AAEBC10 FFFFFF80
> <4>[60392.954333] I[1: ksoftirqd/1: 19] bc20 : 0AAEBC98 FFFFFF80 0AAEBC98 FFFFFF80 00000000 00000000 00000000 00000000
> <4>[60392.954347] I[1: ksoftirqd/1: 19] bc40 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.954361] I[1: ksoftirqd/1: 19] bc60 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.954376] I[1: ksoftirqd/1: 19] bc80 : 00000002 000004F2 00020002 00000000 000174E6 00000000 0AAEBC20 FFFFFF80
> <4>[60392.954391] I[1: ksoftirqd/1: 19] bca0 : 0AAEBC20 FFFFFF80 00000000 00000000 00000000 00000000 0B61BC48 FFFFFF80
> <4>[60392.954405] I[1: ksoftirqd/1: 19] bcc0 : 0B61BC48 FFFFFF80 0A550D80 FFFFFF80 00000000 00000000 9DB59DB5 00000000
> <4>[60392.954419] I[1: ksoftirqd/1: 19] bce0 : 0C000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.954433] I[1: ksoftirqd/1: 19] bd00 : 09644DB0 FFFFFF80 F0000091 00000000 EF839800 FFFFFFC8 EF839900 FFFFFFC8
> <4>[60392.954447] I[1: ksoftirqd/1: 19] bd20 : 0919AB44 FFFFFF80 0A580018 FFFFFF80 00000000 00000001 00000002 00000000
> <4>[60392.954461] I[1: ksoftirqd/1: 19] bd40 : 00000000 00000000 0A580018 FFFFFF80 0AB08478 FFFFFF80 0AAEBD20 FFFFFF80
> <4>[60392.954475] I[1: ksoftirqd/1: 19] bd60 : 00000000 00000000 00000000 00000000 00000000 00000000 EF896858 FFFFFFC8
> <4>[60392.954490] I[1: ksoftirqd/1: 19]
> <4>[60392.954490] I[1: ksoftirqd/1: 19] X25: 0xffffffc0051e5d00:
> <4>[60392.954501] I[1: ksoftirqd/1: 19] 5d00 : 00000000 00000000 00000000 00000000 E745D5E7 496DFBF1 00000000 00000000
> <4>[60392.954516] I[1: ksoftirqd/1: 19] 5d20 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.954530] I[1: ksoftirqd/1: 19] 5d40 : 00000000 00000000 00000000 00000000 00000000 00000000 FFFF0000 0200A8C0
> <4>[60392.954544] I[1: ksoftirqd/1: 19] 5d60 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.954562] I[1: ksoftirqd/1: 19] 5d80 : 00000000 00000000 0081FF80 00000000 00000000 00080000 00000000 00000000
> <4>[60392.954579] I[1: ksoftirqd/1: 19] 5da0 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.954593] I[1: ksoftirqd/1: 19] 5dc0 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.954607] I[1: ksoftirqd/1: 19] 5de0 : 00000000 00000000 051E0BC0 FFFFFFC0 00000085 00000000 3C0ADD53 FCA9C68D
> <4>[60392.954622] I[1: ksoftirqd/1: 19] 5e00 : 831FD9AC 0200A8C0 EEE47EBA 808CBB01 4004000A 00000000 00000000 00000000
> <4>[60392.954640] I[1: ksoftirqd/1: 19] 5e20 : BC8B82B8 FFFFFFC8 0AAF9E10 FFFFFF80 0AAEBC80 FFFFFF80 00000000 00000000
> <4>[60392.954673] I[1: ksoftirqd/1: 19] 5e40 : FFFF0000 831FD9AC 00000000 00000000 FFFF0000 0200A8C0 00017031 00000000
> <4>[60392.954687] I[1: ksoftirqd/1: 19] 5e60 : 00004301 00000000 0000FD75 00000000 EE63F5D0 FFFFFFC8 FFFFFFFF 00000004
> <4>[60392.954702] I[1: ksoftirqd/1: 19] 5e80 : 00000003 00000000 00790078 00000000 00000000 00000000 051E5E98 FFFFFFC0
> <4>[60392.954716] I[1: ksoftirqd/1: 19] 5ea0 : 051E5E98 FFFFFFC0 00000000 00000001 051E5EB0 FFFFFFC0 051E5EB0 FFFFFFC0
> <4>[60392.954730] I[1: ksoftirqd/1: 19] 5ec0 : 00000000 00000000 051E5EC8 FFFFFFC0 051E5EC8 FFFFFFC0 00000000 00000000
> <4>[60392.954745] I[1: ksoftirqd/1: 19] 5ee0 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.954761] I[1: ksoftirqd/1: 19]
> <4>[60392.954761] I[1: ksoftirqd/1: 19] X28: 0xffffffc82fe10b2c:
> <4>[60392.954772] I[1: ksoftirqd/1: 19] 0b2c : 05F02FA5 F6F39767 535F5E0E 0CC4A1B3 04B50A41 DE8744AE 00000040 00000020
> <4>[60392.954787] I[1: ksoftirqd/1: 19] 0b4c : 00000000 00000002 00000000 DB9D6F18 FFFFFFC8 00000000 00000000 00000000
> <4>[60392.954801] I[1: ksoftirqd/1: 19] 0b6c : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.954815] I[1: ksoftirqd/1: 19] 0b8c : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.954830] I[1: ksoftirqd/1: 19] 0bac : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.954844] I[1: ksoftirqd/1: 19] 0bcc : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.954858] I[1: ksoftirqd/1: 19] 0bec : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> <4>[60392.954872] I[1: ksoftirqd/1: 19] 0c0c : 00080000 5000C045 000036D4 62240140 0200A8C0 0200A8C0 ABB50103 00000000
> <4>[60392.954886] I[1: ksoftirqd/1: 19] 0c2c : 34000045 004023E3 99CA0640 0200A8C0 831FD9AC BB018C80 AE46FB9F 537870A5
> <4>[60392.954900] I[1: ksoftirqd/1: 19] 0c4c : 48031180 00002D8D 0A080101 F2556142 DBE9DC24 736D692E 76726573 00656369
> <4>[60392.954914] I[1: ksoftirqd/1: 19] 0c6c : 00390100 00000000 4E000000 554C4C55 00644C4C 00000000 00000000 00000000
> <4>[60392.954928] I[1: ksoftirqd/1: 19] 0c8c : 00000000 00000000 00000000 00000000 00000000 00000000 00000001 00000000
> <4>[60392.954942] I[1: ksoftirqd/1: 19] 0cac : 00000000 00000000 00000000 00000000 00000000 00000001 00000000 00000000
> <4>[60392.954956] I[1: ksoftirqd/1: 19] 0ccc : 00000000 00000000 00000000 00000000 00000000 00100000 00000001 2FE10CF8
> <4>[60392.954970] I[1: ksoftirqd/1: 19] 0cec : FFFFFFC8 00000000 00000000 001B4880 FFFFFFBF 00001000 00000000 00000000
> <4>[60392.954984] I[1: ksoftirqd/1: 19] 0d0c : 00000002 00000001 00000001 00000000 00000000 00000001 00000001 00000000
> <4>[60392.954999] I[1: ksoftirqd/1: 19]
> <4>[60392.954999] I[1: ksoftirqd/1: 19] X29: 0xffffff800b95b890:
> <4>[60392.955010] I[1: ksoftirqd/1: 19] b890 : EF89B000 FFFFFFC8 EE595D00 B254C55C 2FE10C24 FFFFFFC8 36B80010 FFFFFFC0
> <4>[60392.955025] I[1: ksoftirqd/1: 19] b8b0 : 0B2D8880 FFFFFF80 0AAEBC80 FFFFFF80 00000010 00000000 00000000 00000000
> <4>[60392.955039] I[1: ksoftirqd/1: 19] b8d0 : 0B95B930 FFFFFF80 09015704 FFFFFF80 00000003 00000000 0906F3D0 FFFFFF80
> <4>[60392.955053] I[1: ksoftirqd/1: 19] b8f0 : 00000001 00000000 EF89B000 FFFFFFC8 0AAEBC80 FFFFFF80 2FE10C24 FFFFFFC8
> <4>[60392.955067] I[1: ksoftirqd/1: 19] b910 : 00000000 00000000 00000000 FFFFFFC8 00780078 FFFFFFC8 EE595D00 B254C55C
> <4>[60392.955081] I[1: ksoftirqd/1: 19] b930 : 0B95B990 FFFFFF80 09034E40 FFFFFF80 0A5386B0 FFFFFF80 0A540FD0 FFFFFF80
> <4>[60392.955096] I[1: ksoftirqd/1: 19] b950 : EF89B0A0 FFFFFFC8 EF89B000 FFFFFFC8 00000008 00000000 2FE10C24 FFFFFFC8
> <4>[60392.955110] I[1: ksoftirqd/1: 19] b970 : 00000000 00000000 00000006 00000000 00000000 00000000 1EEBFB80 FFFFFFC8
> <4>[60392.955124] I[1: ksoftirqd/1: 19] b990 : 0B95B9C0 FFFFFF80 0904A990 FFFFFF80 0AAEBC80 FFFFFF80 36B82128 FFFFFFC0
> <4>[60392.955138] I[1: ksoftirqd/1: 19] b9b0 : 2FE10C2C FFFFFFC8 1EEBFB80 FFFFFFC8 0B95BA00 FFFFFF80 0904A6D0 FFFFFF80
> <4>[60392.955152] I[1: ksoftirqd/1: 19] b9d0 : 1EEBFC18 FFFFFFC8 EE595D00 B254C55C 0A540578 FFFFFF80 12995900 FFFFFFC0
> <4>[60392.955167] I[1: ksoftirqd/1: 19] b9f0 : 0AAEBC80 FFFFFF80 1EEBFB80 FFFFFFC8 0B95BA40 FFFFFF80 0904A3AC FFFFFF80
> <4>[60392.955181] I[1: ksoftirqd/1: 19] ba10 : 00000008 00000000 1EEBFC18 FFFFFFC8 0A540578 FFFFFF80 0964F9E8 FFFFFF80
> <4>[60392.955195] I[1: ksoftirqd/1: 19] ba30 : 0AAEBC80 FFFFFF80 1EEBFB80 FFFFFFC8 0B95BA70 FFFFFF80 0900B104 FFFFFF80
> <4>[60392.955209] I[1: ksoftirqd/1: 19] ba50 : 2FE10C10 FFFFFFC8 00000001 00000000 0AAEBC80 FFFFFF80 1EEBFB80 FFFFFFC8
> <4>[60392.955223] I[1: ksoftirqd/1: 19] ba70 : 0B95BAE0 FFFFFF80 0900AFD4 FFFFFF80 00000004 00000000 00000001 00000002
> <4>[60392.955238] I[1: ksoftirqd/1: 19]
> <0>[60392.955246] I[1: ksoftirqd/1: 19] Process ksoftirqd/1 (pid: 19, stack limit = 0xffffff800b958000)
> <0>[60392.955253] I[1: ksoftirqd/1: 19] Call trace:
> <4>[60392.955263] I[1: ksoftirqd/1: 19] Exception stack(0xffffff800b95b700 to 0xffffff800b95b840)
> <4>[60392.955272] I[1: ksoftirqd/1: 19] b700: 0000000000000040 000000000200a8c0 000000000000808c 00000000831fd9ac
> <4>[60392.955281] I[1: ksoftirqd/1: 19] b720: 000000000000bb01 000000000000808c 0000000000000010 0000000000000000
> <4>[60392.955290] I[1: ksoftirqd/1: 19] b740: 0000000000000200 0000000000000020 0000000000007530 ffffffc0051e5f58
> <4>[60392.955298] I[1: ksoftirqd/1: 19] b760: 0000000000000000 0000000000000002 0000000000000000 ffffffffffffffff
> <4>[60392.955306] I[1: ksoftirqd/1: 19] b780: 0000000000000000 0000000000000400 0000000000000001 ffffffc0051e5e00
> <4>[60392.955315] I[1: ksoftirqd/1: 19] b7a0: ffffffc0051e5e88 0000000000000071 0000000000000000 ffffffc0051e5f58
> <4>[60392.955323] I[1: ksoftirqd/1: 19] b7c0: ffffff800aaebc80 ffffffc0051e5e00 0000000000000001 0000000000000003
> <4>[60392.955332] I[1: ksoftirqd/1: 19] b7e0: ffffffc82fe10c2c ffffff800b95b990 ffffff80090350cc ffffff800b95b940
> <4>[60392.955341] I[1: ksoftirqd/1: 19] b800: ffffff80090351d0 0000000060c00145 0000000000000001 b254c55cee595d00
> <4>[60392.955349] I[1: ksoftirqd/1: 19] b820: ffffffffffffffff ffffff800b2d7db8 ffffff800b95b990 ffffff80090351d0
> <0>[60392.955362] I[1: ksoftirqd/1: 19] [<ffffff80090351d0>] tcp_v4_err+0x4b0/0x4bc
> <0>[60392.955372] I[1: ksoftirqd/1: 19] [<ffffff800904a990>] icmp_socket_deliver+0x70/0xc0
> <0>[60392.955380] I[1: ksoftirqd/1: 19] [<ffffff800904a6d0>] icmp_unreach+0x1b4/0x1f0
> <0>[60392.955389] I[1: ksoftirqd/1: 19] [<ffffff800904a3ac>] icmp_rcv+0x310/0x348
> <0>[60392.955400] I[1: ksoftirqd/1: 19] [<ffffff800900b104>] ip_local_deliver_finish+0xf8/0x1f0
> <0>[60392.955409] I[1: ksoftirqd/1: 19] [<ffffff800900afd4>] ip_local_deliver+0xc8/0x100
> <0>[60392.955418] I[1: ksoftirqd/1: 19] [<ffffff800900b790>] ip_rcv_finish+0x218/0x2e4
> <0>[60392.955426] I[1: ksoftirqd/1: 19] [<ffffff800900b4c0>] ip_rcv+0x2c4/0x37c
> <0>[60392.955437] I[1: ksoftirqd/1: 19] [<ffffff8008f84f98>] __netif_receive_skb_core+0x8f0/0xa68
> <0>[60392.955446] I[1: ksoftirqd/1: 19] [<ffffff8008f85960>] process_backlog+0x17c/0x290
> <0>[60392.955455] I[1: ksoftirqd/1: 19] [<ffffff8008f85ef0>] net_rx_action+0x224/0x464
> <0>[60392.955465] I[1: ksoftirqd/1: 19] [<ffffff80081b9564>] __do_softirq+0x200/0x39c
> <0>[60392.955475] I[1: ksoftirqd/1: 19] [<ffffff80081f1f04>] run_ksoftirqd+0x34/0x74
> <0>[60392.955485] I[1: ksoftirqd/1: 19] [<ffffff800821ad7c>] smpboot_thread_fn+0x1d0/0x2f8
> <0>[60392.955495] I[1: ksoftirqd/1: 19] [<ffffff8008215c48>] kthread+0x11c/0x130
> <0>[60392.955505] I[1: ksoftirqd/1: 19] [<ffffff80081bdaa0>] ret_from_fork+0x10/0x1c
> <0>[60392.955515] I[1: ksoftirqd/1: 19] Code: f9402d08 94063788 aa1603e8 17ffff80 (d4210000)
> <4>[60392.955524] I[1: ksoftirqd/1: 19] ---[ end trace c1d9b9267f6ef3c2 ]---
>
^ permalink raw reply
* Re: [PATCH v2] kcm: remove any offset before parsing messages
From: Tom Herbert @ 2019-02-15 1:20 UTC (permalink / raw)
To: Dominique Martinet
Cc: David Miller, doronrk, Tom Herbert, Dave Watson,
Linux Kernel Network Developers, LKML
In-Reply-To: <20190215010029.GA10899@nautica>
On Thu, Feb 14, 2019 at 5:00 PM Dominique Martinet
<asmadeus@codewreck.org> wrote:
>
> Dominique Martinet wrote on Wed, Oct 31, 2018:
> > Anyway, that probably explains I have no problem with bigger VM
> > (uselessly more memory available) or without KASAN (I guess there's
> > overhead?), but I'm sending at most 300k of data and the VM has a 1.5GB
> > of ram, so if there's an allocation failure there I think there's a
> > problem ! . . .
> >
> > So, well, I'm not sure on the way forward. Adding a bpf helper and
> > document that kcm users should mind the offset?
>
> bump on this - I had mostly forgotten about it but the nfs-ganesha
> community that could make use of KCM reminded me of my patch that's
> waiting for this.
>
> Summary for people coming back after four months:
> - kcm is great, but the bpf function that's supposed to be called for
> each packet does not automatically adjust the offset so that it can
> assume the skb starts with the packet it needs to look at
>
> - there is some workaround code that is far from obvious and
> undocumented, see the original thread[1]:
> [1] http://lkml.kernel.org/r/20180822183852.jnwlxnz54gbbf6po@davejwatson-mba.dhcp.thefacebook.com
>
> - my patch here tried to automatically pull the corresponding packet to
> the front, but apparently with KASAN can trigger out of memory
> behaviours on "small" VMs, so even if it doesn't seem to impact
> performance much without KASAN I don't think it's really ok to
> potentially hang the connection due to oom under severe conditions.
>
>
> The best alternative I see is adding a proper helper to get
> "kcm_rx_msg(skb)->offset" from bpf and document it so users aren't as
> lost as I have been; I'm not quite sure how/where to add such a helper
> though as I've barely looked at the bpf code until now, but should we go
> for that?
Dominique,
Thanks for looking into this.
I'd rather not complicate the bpf code for this. Can we just always do
an pskb_pull after skb_clone?
Tom
>
>
> (it really feels wrong to me that some random person who just started by
> trying to use kcm has to put this much effort to keep the ball rolling,
> if nobody cares about kcm I'm also open to have it removed completely
> despite the obvious performance gain I benchmarked for ganesha[2] ;
> barely maintained feature is worse than no feature)
>
> [2] https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/421314
>
> Thanks,
> --
> Dominique
^ permalink raw reply
* Re: [PATCH] net: phy: mdio_bus: add missing device_del() in mdiobus_register() error handling
From: Andrew Lunn @ 2019-02-15 1:23 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Florian Fainelli, David S . Miller, netdev, linux-kernel,
Paul Kocialkowski
In-Reply-To: <20190211153159.6b13a687@windsurf>
On Mon, Feb 11, 2019 at 03:31:59PM +0100, Thomas Petazzoni wrote:
> Even if DaveM already merged my simple fix, I had a further look at
> whether we should be using device_unregister(), and in fact we should
> not, but not really for a good reason: because the mdio API is not very
> symmetrical.
>
> The typical flow is:
>
> probe() {
> bus = mdiobus_alloc();
> if (!bus)
> return -ENOMEM;
>
> ret = mdiobus_register(&bus);
> if (ret) {
> mdiobus_free(bus);
>
> ...
> }
>
> remove() {
> mdiobus_unregister();
> mdiobus_free();
> }
>
> mdiobus_alloc() only does memory allocation, i.e it has no side effects
> on the device model data structures.
>
> mdiobus_register() does a device_register(). If it fails, it only
> cleans up with a device_del(), i.e it doesn't do the put_device() that
> it should do to fully "undo" its effect.
>
> mdiobus_unregister() does a device_del(), i.e it also doesn't do the
> opposite of mdiobus_register(), which should be device_del() +
> put_device() (device_unregister() is a shortcut for both).
>
> mdiobus_free() does the put_device()
Hi Thomas
You made some simplifications here. There is a state variable involved
as well. So if you do mdiobus_alloc() ; mdiobus_free(), it will not do
a put_device() but actually call free(). In that case, it is
symmetrical.
>
> So:
>
> * mdiobus_alloc() / mdiobus_free() are not symmetrical in terms of
> their interaction with the device model data structures
>
> * On error, mdiobus_register() leaves a non-zero reference count to the
> bus->dev structure, which will be freed up by mdiobus_free()
>
> * mdiobus_unregister() leaves a non-zero reference count to the
> bus->dev structure, which will be freed up by mdiobus_free()
>
> So, if we were to use device_unregister() in the error path of
> mdiobus_register() and in mdiobus_unregister(), it would break how
> mdiobus_free() works.
I compared mdiobus with alloc_netdev(), register_netdev(),
unregister_netdev() and free_netdev(). The code is actually very
similar, both have a state variable indicating UNITITIALIZED,
UNREGISTERED, REGISTERED, RELEASED, etc. Both have asymmetric
operations.
I think the real issue here is that you cannot destroy the memory
until all references to it are released. So free_netdev() /
mdiobus_free() cannot actual use free() if the device has been
registered so there could be references to it. The free() has to
happen as part of the put_device() once the reference count reaches
zero. If you were to do the put_device() in mdiobus_unregister()
call, by the time you called mdiobus_free(), the structure could of
already been freed, so you cannot look at the state variable to know
if it was ever registered. If it was never registered, you do need to
free it.
So the internals are asymmetric. Which is messy. But the usage of the
API by a driver is symmetric. That i think is more important.
Andrew
^ permalink raw reply
* RE:(2) (2) [Bug reporting] kernel panic during handle the dst unreach icmp msg.
From: 배석진 @ 2019-02-15 1:30 UTC (permalink / raw)
To: Eric Dumazet, 배석진, netdev@vger.kernel.org
Cc: 박종언, Steffen Klassert, Herbert Xu
In-Reply-To: <4989ee5d-0de3-b7a7-494d-f0c133dfc465@gmail.com>
> > <4>[60392.948306] I[1: ksoftirqd/1: 19] ------------[ cut here ]------------
> > <0>[60392.948334] I[1: ksoftirqd/1: 19] kernel BUG at net/ipv4/tcp_ipv4.c:519!
>
> What the code looks like at line 519 of net/ipv4/tcp_ipv4.c ?
>
> This is not a pristine kernel, anything could be wrong, you might have missed some critical backports.
>
I attached that at first mail,
although we added some featre as you said, (about MPTCP)
it looks like clear that the reason for BUG trigger.
> > 370 void tcp_v4_err(struct sk_buff *icmp_skb, u32 info)
> > 371 {
> > ...
> > 516 icsk->icsk_rto = inet_csk_rto_backoff(icsk, TCP_RTO_MAX);
> > 517
> > 518 skb = tcp_write_queue_head(sk);
> > 519 BUG_ON(!skb);
> > 520
> > 521 tcp_mstamp_refresh(tp);
> >
> >
> > we know that the line 519 removed on latest state. instead this will be shown to kernel panic.
^ permalink raw reply
* Re: (2) [Bug reporting] kernel panic during handle the dst unreach icmp msg.
From: Eric Dumazet @ 2019-02-15 1:30 UTC (permalink / raw)
To: soukjin.bae, netdev@vger.kernel.org
Cc: 박종언, Yuchung Cheng
In-Reply-To: <4989ee5d-0de3-b7a7-494d-f0c133dfc465@gmail.com>
On 02/14/2019 05:08 PM, Eric Dumazet wrote:
>
>
> On 02/14/2019 03:54 PM, 배석진 wrote:
>>> I do not believe this patch is needed.
>>>
>>> You probably hit another more serious bug, but since you do not post the full stack trace
>>> it is hard to help.
>>>
>>> Are you using vti tunnel ?
>>
>> there's no working logs of vpn/vti/tun on platform or kernel history.
>> and callstack has no functions about that.
>> it looks like simple ipv4 usage.
>>
>> attaching full dump info.
>> no additional bug or warning on entire kernel history.
>> anything about tun or kasan even onther.
>>
>> thanks.
>>
>>
>> <4>[60392.948306] I[1: ksoftirqd/1: 19] ------------[ cut here ]------------
>> <0>[60392.948334] I[1: ksoftirqd/1: 19] kernel BUG at net/ipv4/tcp_ipv4.c:519!
>
> What the code looks like at line 519 of net/ipv4/tcp_ipv4.c ?
>
> This is not a pristine kernel, anything could be wrong, you might have missed some critical backports.
The current code checks if icsk->icsk_backoff is not zero, so it looks like we have to move
some code like this.
It looks a silly bug to have no packet in write/rtx queues, and a non zero icsk_backoff.
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 2079145a3b7c5f498af429c9a8289342e4421fca..cf3c5095c10e8e7e56621beae2f93c93de184489 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2528,6 +2528,7 @@ void tcp_write_queue_purge(struct sock *sk)
sk_mem_reclaim(sk);
tcp_clear_all_retrans_hints(tcp_sk(sk));
tcp_sk(sk)->packets_out = 0;
+ inet_csk(sk)->icsk_backoff = 0;
}
int tcp_disconnect(struct sock *sk, int flags)
@@ -2576,7 +2577,6 @@ int tcp_disconnect(struct sock *sk, int flags)
tp->write_seq += tp->max_window + 2;
if (tp->write_seq == 0)
tp->write_seq = 1;
- icsk->icsk_backoff = 0;
tp->snd_cwnd = 2;
icsk->icsk_probes_out = 0;
tp->snd_ssthresh = TCP_INFINITE_SSTHRESH;
^ permalink raw reply related
* RE:(2) (2) [Bug reporting] kernel panic during handle the dst unreach icmp msg.
From: 배석진 @ 2019-02-15 1:37 UTC (permalink / raw)
To: Eric Dumazet, 배석진, netdev@vger.kernel.org
Cc: 박종언, Yuchung Cheng
In-Reply-To: <ef47d25c-a37e-8259-ce01-14a8e4c1cd9a@gmail.com>
> The current code checks if icsk->icsk_backoff is not zero, so it looks like we have to move
> some code like this.
>
> It looks a silly bug to have no packet in write/rtx queues, and a non zero icsk_backoff.
>
>
>
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index 2079145a3b7c5f498af429c9a8289342e4421fca..cf3c5095c10e8e7e56621beae2f93c93de184489 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -2528,6 +2528,7 @@ void tcp_write_queue_purge(struct sock *sk)
> sk_mem_reclaim(sk);
> tcp_clear_all_retrans_hints(tcp_sk(sk));
> tcp_sk(sk)->packets_out = 0;
> + inet_csk(sk)->icsk_backoff = 0;
> }
>
> int tcp_disconnect(struct sock *sk, int flags)
> @@ -2576,7 +2577,6 @@ int tcp_disconnect(struct sock *sk, int flags)
> tp->write_seq += tp->max_window + 2;
> if (tp->write_seq == 0)
> tp->write_seq = 1;
> - icsk->icsk_backoff = 0;
> tp->snd_cwnd = 2;
> icsk->icsk_probes_out = 0;
> tp->snd_ssthresh = TCP_INFINITE_SSTHRESH;
>
yes right, queue problems.
I don't know about icsk_backoff :p
this will be work. thanks!
^ permalink raw reply
* Re: (2) (2) [Bug reporting] kernel panic during handle the dst unreach icmp msg.
From: Eric Dumazet @ 2019-02-15 1:41 UTC (permalink / raw)
To: soukjin.bae, netdev@vger.kernel.org
Cc: 박종언, Yuchung Cheng
In-Reply-To: <20190215013753epcms1p4249f1b2b67f8e706618f62cb7bd76412@epcms1p4>
On 02/14/2019 05:37 PM, 배석진 wrote:
>> The current code checks if icsk->icsk_backoff is not zero, so it looks like we have to move
>> some code like this.
>>
>> It looks a silly bug to have no packet in write/rtx queues, and a non zero icsk_backoff.
>>
>>
>>
>> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
>> index 2079145a3b7c5f498af429c9a8289342e4421fca..cf3c5095c10e8e7e56621beae2f93c93de184489 100644
>> --- a/net/ipv4/tcp.c
>> +++ b/net/ipv4/tcp.c
>> @@ -2528,6 +2528,7 @@ void tcp_write_queue_purge(struct sock *sk)
>> sk_mem_reclaim(sk);
>> tcp_clear_all_retrans_hints(tcp_sk(sk));
>> tcp_sk(sk)->packets_out = 0;
>> + inet_csk(sk)->icsk_backoff = 0;
>> }
>>
>> int tcp_disconnect(struct sock *sk, int flags)
>> @@ -2576,7 +2577,6 @@ int tcp_disconnect(struct sock *sk, int flags)
>> tp->write_seq += tp->max_window + 2;
>> if (tp->write_seq == 0)
>> tp->write_seq = 1;
>> - icsk->icsk_backoff = 0;
>> tp->snd_cwnd = 2;
>> icsk->icsk_probes_out = 0;
>> tp->snd_ssthresh = TCP_INFINITE_SSTHRESH;
>>
>
> yes right, queue problems.
> I don't know about icsk_backoff :p
> this will be work. thanks!
>
I am running our packetdrill tests just to be reasonably safe.
^ permalink raw reply
* Re: [PATCH net-next v2] bonding: check slave set command firstly
From: Tonghao Zhang @ 2019-02-15 1:44 UTC (permalink / raw)
To: David Miller; +Cc: Linux Kernel Network Developers
In-Reply-To: <20190214.083651.1886161133830865121.davem@davemloft.net>
On Fri, Feb 15, 2019 at 12:36 AM David Miller <davem@davemloft.net> wrote:
>
> From: xiangxia.m.yue@gmail.com
> Date: Mon, 11 Feb 2019 10:49:48 -0800
>
> > From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> >
> > This patch is a little improvement. If user use the
> > command shown as below, we should print the info [1]
> > instead of [2]. The eth0 exists actually, and it may
> > confuse user.
> >
> > $ echo "eth0" > /sys/class/net/bond4/bonding/slaves
> >
> > [1] "bond4: no command found in slaves file - use +ifname or -ifname"
> > [2] "write error: No such device"
> >
> > Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>
> Applied, but would you please fix the dates on your submissions?
>
> Because the dates in your patch postings are in the past, patchwork
> puts your work at the tail of my patch queue instead of the front.
OK, I format the patch a few days ago, but send it yesterday.
> Thank you.
^ permalink raw reply
* Re: [PATCH bpf-next 1/2] libbpf: Introduce bpf_map__resize
From: Yonghong Song @ 2019-02-15 1:52 UTC (permalink / raw)
To: Andrey Ignatov, netdev@vger.kernel.org
Cc: ast@kernel.org, daniel@iogearbox.net, Kernel Team
In-Reply-To: <36151c3c82144ee3f68780e98ccb29a8c6ac3f75.1550185216.git.rdna@fb.com>
On 2/14/19 3:01 PM, Andrey Ignatov wrote:
> Add bpf_map__resize() to change max_entries for a map.
>
> Quite often necessary map size is unknown at compile time and can be
> calculated only at run time.
>
> Currently the following approach is used to do so:
> * bpf_object__open_buffer() to open Elf file from a buffer;
> * bpf_object__find_map_by_name() to find relevant map;
> * bpf_map__def() to get map attributes and create struct
> bpf_create_map_attr from them;
> * update max_entries in bpf_create_map_attr;
> * bpf_create_map_xattr() to create new map with updated max_entries;
> * bpf_map__reuse_fd() to replace the map in bpf_object with newly
> created one.
>
> And after all this bpf_object can finally be loaded. The map will have
> new size.
>
> It 1) is quite a lot of steps; 2) doesn't take BTF into account.
>
> For "2)" even more steps should be made and some of them require changes
> to libbpf (e.g. to get struct btf * from bpf_object).
>
> Instead the whole problem can be solved by introducing simple
> bpf_map__resize() API that checks the map and sets new max_entries if
> the map is not loaded yet.
>
> So the new steps are:
> * bpf_object__open_buffer() to open Elf file from a buffer;
> * bpf_object__find_map_by_name() to find relevant map;
> * bpf_map__resize() to update max_entries.
>
> That's much simpler and works with BTF.
>
> Signed-off-by: Andrey Ignatov <rdna@fb.com>
Acked-by: Yonghong Song <yhs@fb.com>
^ permalink raw reply
* Re: [PATCH net-next v2] bonding: check slave set command firstly
From: David Miller @ 2019-02-15 1:53 UTC (permalink / raw)
To: xiangxia.m.yue; +Cc: netdev
In-Reply-To: <CAMDZJNUE7WwtotPdBpMV1Q0hfoMKXhErK6nF=sTHXoM6T_8vEA@mail.gmail.com>
From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Date: Fri, 15 Feb 2019 09:44:58 +0800
> OK, I format the patch a few days ago, but send it yesterday.
Just FYI, you can use various options to git such that it composes the
email using the current time rather than the date in the commit
itself.
^ permalink raw reply
* Re: [PATCH bpf-next 2/2] libbpf: Introduce bpf_object__btf
From: Yonghong Song @ 2019-02-15 1:53 UTC (permalink / raw)
To: Andrey Ignatov, netdev@vger.kernel.org
Cc: ast@kernel.org, daniel@iogearbox.net, Kernel Team
In-Reply-To: <e012e835cf644b7d444dcdf60a97b1256075993a.1550185216.git.rdna@fb.com>
On 2/14/19 3:01 PM, Andrey Ignatov wrote:
> Add new accessor for bpf_object to get opaque struct btf * from it.
>
> struct btf * is needed for all operations with BTF and it's present in
> bpf_object. The only thing missing is a way to get it.
>
> Example use-case is to get BTF key_type_id an value_type_id for a map in
nit: an => and
> bpf_object. It can be done with btf__get_map_kv_tids() but that function
> requires struct btf *.
>
> Similar API can be added for struct btf_ext but no use-case for it yet.
>
> Signed-off-by: Andrey Ignatov <rdna@fb.com>
Acked-by: Yonghong Song <yhs@fb.com>
^ permalink raw reply
* Re: [PATCH v2] kcm: remove any offset before parsing messages
From: Dominique Martinet @ 2019-02-15 1:57 UTC (permalink / raw)
To: Tom Herbert
Cc: David Miller, doronrk, Tom Herbert, Dave Watson,
Linux Kernel Network Developers, LKML
In-Reply-To: <CALx6S35HBKgtYkFde_AhCMPRtZfcVYfCYf=mLKjWSLLAfhMHyQ@mail.gmail.com>
Tom Herbert wrote on Thu, Feb 14, 2019:
> > The best alternative I see is adding a proper helper to get
> > "kcm_rx_msg(skb)->offset" from bpf and document it so users aren't as
> > lost as I have been; I'm not quite sure how/where to add such a helper
> > though as I've barely looked at the bpf code until now, but should we go
> > for that?
>
> I'd rather not complicate the bpf code for this. Can we just always do
> an pskb_pull after skb_clone?
Which skb_clone are you thinking of?
If you're referring to the one in strparser, that was my very first
approach here[1], but Dordon shot it down saying that this is not an
strparser bug but a kcm bug since there are ways for users to properly
get the offset and use it -- and the ktls code does it right.
Frankly, my opinion still is that it'd be better in strparser because
there also is some bad use in bpf sockmap (they never look at the offset
either, while kcm uses it for rcv but not for parse), but looking at it
from an optimal performance point of view I agree the user can make
better decision than strparser so I understand where he comes from.
This second patch[2] (the current thread) now does an extra clone if
there is an offset, but the problem really isn't in the clone but the
pull itself that can fail and return NULL when there is memory pressure.
For some reason I hadn't been able to reproduce that behaviour with
strparser doing the pull, but I assume it would also be possible to hit
in extreme situations, I'm not sure...
So anyway, we basically have three choices that I can see:
- push harder on strparser and go back to my first patch ; it's simple
and makes using strparser easier/safer but has a small overhead for
ktls, which uses the current strparser implementation correctly.
I hadn't been able to get this to fail with KASAN last time I tried but
I assume it should still be possible somehow.
- the current patch, that I could only get to fail with KASAN, but does
complexify kcm a bit; this also does not fix bpf sockmap at all.
Would still require to fix the hang, so make strparser retry a few times
if strp->cb.parse_msg failed maybe? Or at least get the error back to
userspace somehow.
- my last suggestion to document the kcm behaviour, and if possible add
a bpf helper to make proper usage easier ; this will make kcm harder to
use on end users but it's better than not being documented and seeing
random unappropriate lengths being parsed.
[1] first strparser patch
http://lkml.kernel.org/r/1534855906-22870-1-git-send-email-asmadeus@codewreck.org
[2] current thread's patch
http://lkml.kernel.org/r/1536657703-27577-1-git-send-email-asmadeus@codewreck.org
Thanks,
--
Dominique
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2019-02-15 2:00 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Fix MAC address setting in mac80211 pmsr code, from Johannes Berg.
2) Probe SFP modules after being attached, from Russell King.
3) Byte ordering bug in SMC rx_curs_confirmed code, from Ursula Braun.
4) Revert some r8169 changes that are causing regressions, from Heiner
Kallweit.
5) Fix spurious connection timeouts in netfilter nat code, from
Florian Westphal.
6) SKB leak in tipc, from Hoang Le.
7) Short packet checkum issue in mlx4, similar to a previous mlx5
change, from Saeed Mahameed. The issue is that whilst padding
bytes are usually zero, it is not guarateed and the hardware
doesn't take the padding bytes into consideration when generating
the checksum.
8) Fix various races in cls_tcindex, from Cong Wang.
9) Need to set stream ext to NULL before freeing in SCTP code, from
Xin Long.
10) Fix locking in phy_is_started, from Heiner Kallweit.
Please pull, thanks a lot!
The following changes since commit 27b4ad621e887ce8e5eb508a0103f13d30f6b38a:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2019-02-08 11:21:54 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
for you to fetch changes up to f9bcc9f3ee4fbbe8f11dfec76745476f5780517e:
net: ethernet: freescale: set FEC ethtool regs version (2019-02-14 12:45:35 -0500)
----------------------------------------------------------------
Andrea Claudi (1):
ipvs: fix dependency on nf_defrag_ipv6
Arthur Kiyanovski (2):
net: ena: fix race between link up and device initalization
net: ena: update driver version from 2.0.2 to 2.0.3
Aviya Erenfeld (1):
nl80211: Fix FTM per burst maximum value
Bert Kenward (1):
sfc: initialise found bitmap in efx_ef10_mtd_probe
Cong Wang (4):
net_sched: fix a race condition in tcindex_destroy()
net_sched: fix a memory leak in cls_tcindex
net_sched: fix two more memory leaks in cls_tcindex
team: avoid complex list operations in team_nl_cmd_options_set()
Dan Carpenter (1):
net: dsa: bcm_sf2: potential array overflow in bcm_sf2_sw_suspend()
David S. Miller (8):
Merge branch 'r8169-revert-two-commits-due-to-a-regression'
Merge git://git.kernel.org/.../pablo/nf
Merge tag 'mac80211-for-davem-2019-02-12' of git://git.kernel.org/.../jberg/mac80211
Merge branch 'ena-races'
Merge branch 'net_sched-some-fixes-for-cls_tcindex'
Merge tag 'mlx5-fixes-2019-02-13' of git://git.kernel.org/.../saeed/linux
Merge git://git.kernel.org/.../pablo/nf
Merge branch 'net-phy-fix-locking-issue'
Deepa Dinamani (1):
selftests: fix timestamping Makefile
Eric Dumazet (4):
vxlan: test dev->flags & IFF_UP before calling netif_rx()
net/x25: do not hold the cpu too long in x25_new_lci()
batman-adv: fix uninit-value in batadv_interface_tx()
net: fix possible overflow in __sk_mem_raise_allocated()
Florian Westphal (1):
netfilter: nat: fix spurious connection timeouts
Francesco Ruggeri (1):
netfilter: compat: initialize all fields in xt_init
Heiner Kallweit (5):
Revert "r8169: remove unneeded mmiowb barriers"
Revert "r8169: make use of xmit_more and __netdev_sent_queue"
net: phy: fix interrupt handling in non-started states
net: phy: don't use locking in phy_is_started
net: phy: fix potential race in the phylib state machine
Hoang Le (1):
tipc: fix skb may be leaky in tipc_link_input
Huang Zijiang (1):
net: hns: Fix object reference leaks in hns_dsaf_roce_reset()
Huy Nguyen (1):
net/mlx5: No command allowed when command interface is not ready
Ilan Peer (1):
mac80211: Fix Tx aggregation session tear down with ITXQs
Jann Horn (2):
netfilter: nf_nat_snmp_basic: add missing length checks in ASN.1 cbs
mm: page_alloc: fix ref bias in page_frag_alloc() for 1-byte allocs
Johannes Berg (5):
cfg80211: pmsr: fix MAC address setting
cfg80211: pmsr: fix abort locking
mac80211: call drv_ibss_join() on restart
cfg80211: pmsr: record netlink port ID
cfg80211: prevent speculation on cfg80211_classify8021d() return
John David Anglin (1):
dsa: mv88e6xxx: Ensure all pending interrupts are handled prior to exit
Jouke Witteveen (1):
Documentation: bring operstate documentation up-to-date
Kal Conley (1):
net/packet: fix 4gb buffer limit due to overflow check
Konstantin Khlebnikov (1):
inet_diag: fix reporting cgroup classid and fallback to priority
Li RongQing (1):
ipv6: propagate genlmsg_reply return code
Lorenzo Bianconi (1):
net: ipv4: use a dedicated counter for icmp_v4 redirect packets
Maria Pasechnik (1):
net/mlx5e: Fix NULL pointer derefernce in set channels error flow
Matteo Croce (1):
geneve: change NET_UDP_TUNNEL dependency to select
Pablo Neira Ayuso (1):
netfilter: nft_compat: use-after-free when deleting targets
Paolo Abeni (1):
vsock: cope with memory allocation failure at socket creation time
Russell King (2):
net: sfp: do not probe SFP module before we're attached
net: phylink: avoid resolving link state too early
Saeed Mahameed (2):
net/mlx4_en: Force CHECKSUM_NONE for short ethernet frames
net/mlx5e: XDP, fix redirect resources availability check
Tariq Toukan (1):
net/mlx5: Fix a compilation warning in events.c
Tuong Lien (1):
tipc: fix link session and re-establish issues
Ursula Braun (1):
net/smc: fix byte_order for rx_curs_confirmed
Vivien Didelot (1):
net: ethernet: freescale: set FEC ethtool regs version
Xin Long (2):
sctp: call gso_reset_checksum when computing checksum in sctp_gso_segment
sctp: set stream ext to NULL after freeing it in sctp_stream_outq_migrate
Zhiqiang Liu (1):
net: fix IPv6 prefix route residue
Documentation/networking/operstates.txt | 14 ++++++++------
drivers/net/Kconfig | 4 ++--
drivers/net/dsa/bcm_sf2.c | 2 +-
drivers/net/dsa/mv88e6xxx/chip.c | 28 ++++++++++++++++++++++------
drivers/net/ethernet/amazon/ena/ena_netdev.c | 10 +++++-----
drivers/net/ethernet/amazon/ena/ena_netdev.h | 2 +-
drivers/net/ethernet/freescale/fec_main.c | 4 ++++
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 2 ++
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 22 ++++++++++++++++++++--
drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 18 ++++++++++++++++++
drivers/net/ethernet/mellanox/mlx5/core/en.h | 1 +
drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c | 6 ++----
drivers/net/ethernet/mellanox/mlx5/core/en/xdp.h | 17 +++++++++++++++++
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c | 7 ++++---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 2 ++
drivers/net/ethernet/mellanox/mlx5/core/events.c | 17 +++++++++--------
drivers/net/ethernet/mellanox/mlx5/core/health.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.h | 1 +
drivers/net/ethernet/realtek/r8169.c | 21 ++++++++++++++-------
drivers/net/ethernet/sfc/ef10.c | 2 +-
drivers/net/phy/phy.c | 16 +++++++---------
drivers/net/phy/phylink.c | 19 +++++++++++++------
drivers/net/phy/sfp-bus.c | 2 ++
drivers/net/phy/sfp.c | 30 +++++++++++++++++++++---------
drivers/net/phy/sfp.h | 2 ++
drivers/net/team/team.c | 27 +++++----------------------
drivers/net/vxlan.c | 14 +++++++++++---
include/linux/phy.h | 15 +--------------
include/net/inetpeer.h | 1 +
include/net/sock.h | 2 +-
include/uapi/linux/inet_diag.h | 16 +++++++++++-----
mm/page_alloc.c | 8 ++++----
net/batman-adv/soft-interface.c | 2 ++
net/core/sock.c | 2 +-
net/ipv4/inet_diag.c | 10 +++++++++-
net/ipv4/inetpeer.c | 1 +
net/ipv4/netfilter/nf_nat_l3proto_ipv4.c | 1 +
net/ipv4/netfilter/nf_nat_snmp_basic_main.c | 7 ++++++-
net/ipv4/route.c | 7 +++++--
net/ipv6/addrconf.c | 3 ++-
net/ipv6/netfilter/nf_nat_l3proto_ipv6.c | 1 +
net/ipv6/seg6.c | 4 +---
net/mac80211/agg-tx.c | 4 +++-
net/mac80211/util.c | 6 +++++-
net/netfilter/ipvs/Kconfig | 1 +
net/netfilter/ipvs/ip_vs_core.c | 10 ++++------
net/netfilter/ipvs/ip_vs_ctl.c | 10 ++++++++++
net/netfilter/nft_compat.c | 3 ++-
net/netfilter/x_tables.c | 2 +-
net/packet/af_packet.c | 2 +-
net/sched/cls_tcindex.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++--------------------------------
net/sched/sch_generic.c | 2 +-
net/sctp/diag.c | 1 +
net/sctp/offload.c | 1 +
net/sctp/stream.c | 4 +++-
net/smc/smc_cdc.c | 4 +---
net/smc/smc_cdc.h | 19 ++++++++++---------
net/tipc/link.c | 17 ++++++++++++++++-
net/tipc/msg.h | 22 ++++++++++++++++++++++
net/tipc/node.c | 11 ++++++-----
net/vmw_vsock/vmci_transport.c | 4 ++++
net/wireless/core.c | 2 ++
net/wireless/nl80211.c | 2 +-
net/wireless/pmsr.c | 26 +++++++++++++++++---------
net/wireless/util.c | 35 ++++++++++++++++++++++++-----------
net/x25/af_x25.c | 6 ++----
tools/testing/selftests/networking/timestamping/Makefile | 3 ---
67 files changed, 429 insertions(+), 220 deletions(-)
^ permalink raw reply
* [PATCH AUTOSEL 4.20 36/77] mac80211: fix miscounting of ttl-dropped frames
From: Sasha Levin @ 2019-02-15 2:08 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Bob Copeland, Bob Copeland, Johannes Berg, Sasha Levin,
linux-wireless, netdev
In-Reply-To: <20190215020855.176727-1-sashal@kernel.org>
From: Bob Copeland <me@bobcopeland.com>
[ Upstream commit a0dc02039a2ee54fb4ae400e0b755ed30e73e58c ]
In ieee80211_rx_h_mesh_fwding, we increment the 'dropped_frames_ttl'
counter when we decrement the ttl to zero. For unicast frames
destined for other hosts, we stop processing the frame at that point.
For multicast frames, we do not rebroadcast it in this case, but we
do pass the frame up the stack to process it on this STA. That
doesn't match the usual definition of "dropped," so don't count
those as such.
With this change, something like `ping6 -i0.2 ff02::1%mesh0` from a
peer in a ttl=1 network no longer increments the counter rapidly.
Signed-off-by: Bob Copeland <bobcopeland@fb.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/rx.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 428f7ad5f9b5..ef215d0e99b0 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2710,7 +2710,9 @@ ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
skb_set_queue_mapping(skb, q);
if (!--mesh_hdr->ttl) {
- IEEE80211_IFSTA_MESH_CTR_INC(ifmsh, dropped_frames_ttl);
+ if (!is_multicast_ether_addr(hdr->addr1))
+ IEEE80211_IFSTA_MESH_CTR_INC(ifmsh,
+ dropped_frames_ttl);
goto out;
}
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 46/65] net: altera_tse: fix connect_local_phy error path
From: Sasha Levin @ 2019-02-15 2:11 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Atsushi Nemoto, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20190215021121.177674-1-sashal@kernel.org>
From: Atsushi Nemoto <atsushi.nemoto@sord.co.jp>
[ Upstream commit 17b42a20d7ca59377788c6a2409e77569570cc10 ]
The connect_local_phy should return NULL (not negative errno) on
error, since its caller expects it.
Signed-off-by: Atsushi Nemoto <atsushi.nemoto@sord.co.jp>
Acked-by: Thor Thayer <thor.thayer@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/altera/altera_tse_main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/altera/altera_tse_main.c b/drivers/net/ethernet/altera/altera_tse_main.c
index baca8f704a45..c3c1195021a2 100644
--- a/drivers/net/ethernet/altera/altera_tse_main.c
+++ b/drivers/net/ethernet/altera/altera_tse_main.c
@@ -714,8 +714,10 @@ static struct phy_device *connect_local_phy(struct net_device *dev)
phydev = phy_connect(dev, phy_id_fmt, &altera_tse_adjust_link,
priv->phy_iface);
- if (IS_ERR(phydev))
+ if (IS_ERR(phydev)) {
netdev_err(dev, "Could not attach to PHY\n");
+ phydev = NULL;
+ }
} else {
int ret;
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 60/65] mac80211: Add attribute aligned(2) to struct 'action'
From: Sasha Levin @ 2019-02-15 2:11 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Mathieu Malaterre, Johannes Berg, Sasha Levin, linux-wireless,
netdev
In-Reply-To: <20190215021121.177674-1-sashal@kernel.org>
From: Mathieu Malaterre <malat@debian.org>
[ Upstream commit 7c53eb5d87bc21464da4268c3c0c47457b6d9c9b ]
During refactor in commit 9e478066eae4 ("mac80211: fix MU-MIMO
follow-MAC mode") a new struct 'action' was declared with packed
attribute as:
struct {
struct ieee80211_hdr_3addr hdr;
u8 category;
u8 action_code;
} __packed action;
But since struct 'ieee80211_hdr_3addr' is declared with an aligned
keyword as:
struct ieee80211_hdr {
__le16 frame_control;
__le16 duration_id;
u8 addr1[ETH_ALEN];
u8 addr2[ETH_ALEN];
u8 addr3[ETH_ALEN];
__le16 seq_ctrl;
u8 addr4[ETH_ALEN];
} __packed __aligned(2);
Solve the ambiguity of placing aligned structure in a packed one by
adding the aligned(2) attribute to struct 'action'.
This removes the following warning (W=1):
net/mac80211/rx.c:234:2: warning: alignment 1 of 'struct <anonymous>' is less than 2 [-Wpacked-not-aligned]
Cc: Johannes Berg <johannes.berg@intel.com>
Suggested-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Mathieu Malaterre <malat@debian.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 77cfa62274f3..a804ef55ec60 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -220,7 +220,7 @@ static void ieee80211_handle_mu_mimo_mon(struct ieee80211_sub_if_data *sdata,
struct ieee80211_hdr_3addr hdr;
u8 category;
u8 action_code;
- } __packed action;
+ } __packed __aligned(2) action;
if (!sdata)
return;
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 33/40] net: usb: asix: ax88772_bind return error when hw_reset fail
From: Sasha Levin @ 2019-02-15 2:13 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Zhang Run, David S . Miller, Sasha Levin, linux-usb, netdev
In-Reply-To: <20190215021313.178476-1-sashal@kernel.org>
From: Zhang Run <zhang.run@zte.com.cn>
[ Upstream commit 6eea3527e68acc22483f4763c8682f223eb90029 ]
The ax88772_bind() should return error code immediately when the PHY
was not reset properly through ax88772a_hw_reset().
Otherwise, The asix_get_phyid() will block when get the PHY
Identifier from the PHYSID1 MII registers through asix_mdio_read()
due to the PHY isn't ready. Furthermore, it will produce a lot of
error message cause system crash.As follows:
asix 1-1:1.0 (unnamed net_device) (uninitialized): Failed to write
reg index 0x0000: -71
asix 1-1:1.0 (unnamed net_device) (uninitialized): Failed to send
software reset: ffffffb9
asix 1-1:1.0 (unnamed net_device) (uninitialized): Failed to write
reg index 0x0000: -71
asix 1-1:1.0 (unnamed net_device) (uninitialized): Failed to enable
software MII access
asix 1-1:1.0 (unnamed net_device) (uninitialized): Failed to read
reg index 0x0000: -71
asix 1-1:1.0 (unnamed net_device) (uninitialized): Failed to write
reg index 0x0000: -71
asix 1-1:1.0 (unnamed net_device) (uninitialized): Failed to enable
software MII access
asix 1-1:1.0 (unnamed net_device) (uninitialized): Failed to read
reg index 0x0000: -71
...
Signed-off-by: Zhang Run <zhang.run@zte.com.cn>
Reviewed-by: Yang Wei <yang.wei9@zte.com.cn>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/usb/asix_devices.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index b1b3d8f7e67d..d0c0ac0c3519 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -731,8 +731,13 @@ static int ax88772_bind(struct usbnet *dev, struct usb_interface *intf)
asix_read_cmd(dev, AX_CMD_STATMNGSTS_REG, 0, 0, 1, &chipcode, 0);
chipcode &= AX_CHIPCODE_MASK;
- (chipcode == AX_AX88772_CHIPCODE) ? ax88772_hw_reset(dev, 0) :
- ax88772a_hw_reset(dev, 0);
+ ret = (chipcode == AX_AX88772_CHIPCODE) ? ax88772_hw_reset(dev, 0) :
+ ax88772a_hw_reset(dev, 0);
+
+ if (ret < 0) {
+ netdev_dbg(dev->net, "Failed to reset AX88772: %d\n", ret);
+ return ret;
+ }
/* Read PHYID register *AFTER* the PHY was reset properly */
phyid = asix_get_phyid(dev);
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 36/40] mac80211: don't initiate TDLS connection if station is not associated to AP
From: Sasha Levin @ 2019-02-15 2:13 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Balaji Pothunoori, Johannes Berg, Sasha Levin, linux-wireless,
netdev
In-Reply-To: <20190215021313.178476-1-sashal@kernel.org>
From: Balaji Pothunoori <bpothuno@codeaurora.org>
[ Upstream commit 7ed5285396c257fd4070b1e29e7b2341aae2a1ce ]
Following call trace is observed while adding TDLS peer entry in driver
during TDLS setup.
Call Trace:
[<c1301476>] dump_stack+0x47/0x61
[<c10537d2>] __warn+0xe2/0x100
[<fa22415f>] ? sta_apply_parameters+0x49f/0x550 [mac80211]
[<c1053895>] warn_slowpath_null+0x25/0x30
[<fa22415f>] sta_apply_parameters+0x49f/0x550 [mac80211]
[<fa20ad42>] ? sta_info_alloc+0x1c2/0x450 [mac80211]
[<fa224623>] ieee80211_add_station+0xe3/0x160 [mac80211]
[<c1876fe3>] nl80211_new_station+0x273/0x420
[<c170f6d9>] genl_rcv_msg+0x219/0x3c0
[<c170f4c0>] ? genl_rcv+0x30/0x30
[<c170ee7e>] netlink_rcv_skb+0x8e/0xb0
[<c170f4ac>] genl_rcv+0x1c/0x30
[<c170e8aa>] netlink_unicast+0x13a/0x1d0
[<c170ec18>] netlink_sendmsg+0x2d8/0x390
[<c16c5acd>] sock_sendmsg+0x2d/0x40
[<c16c6369>] ___sys_sendmsg+0x1d9/0x1e0
Fixing this by allowing TDLS setup request only when we have completed
association.
Signed-off-by: Balaji Pothunoori <bpothuno@codeaurora.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/cfg.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 63558335e41e..2b9af644c0e2 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1462,6 +1462,10 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
if (params->sta_flags_set & BIT(NL80211_STA_FLAG_TDLS_PEER))
sta->sta.tdls = true;
+ if (sta->sta.tdls && sdata->vif.type == NL80211_IFTYPE_STATION &&
+ !sdata->u.mgd.associated)
+ return -EINVAL;
+
err = sta_apply_parameters(local, sta, params);
if (err) {
sta_info_free(local, sta);
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 3.18 13/16] ibmveth: Do not process frames after calling napi_reschedule
From: Sasha Levin @ 2019-02-15 2:15 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Thomas Falcon, David S . Miller, Sasha Levin, linuxppc-dev,
netdev
In-Reply-To: <20190215021546.179605-1-sashal@kernel.org>
From: Thomas Falcon <tlfalcon@linux.ibm.com>
[ Upstream commit e95d22c69b2c130ccce257b84daf283fd82d611e ]
The IBM virtual ethernet driver's polling function continues
to process frames after rescheduling NAPI, resulting in a warning
if it exhausted its budget. Do not restart polling after calling
napi_reschedule. Instead let frames be processed in the following
instance.
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/ibm/ibmveth.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmveth.c b/drivers/net/ethernet/ibm/ibmveth.c
index 427a6674d237..f0301b1ff56c 100644
--- a/drivers/net/ethernet/ibm/ibmveth.c
+++ b/drivers/net/ethernet/ibm/ibmveth.c
@@ -1085,7 +1085,6 @@ static int ibmveth_poll(struct napi_struct *napi, int budget)
int frames_processed = 0;
unsigned long lpar_rc;
-restart_poll:
while (frames_processed < budget) {
if (!ibmveth_rxq_pending_buffer(adapter))
break;
@@ -1154,7 +1153,6 @@ static int ibmveth_poll(struct napi_struct *napi, int budget)
napi_reschedule(napi)) {
lpar_rc = h_vio_signal(adapter->vdev->unit_address,
VIO_IRQ_DISABLE);
- goto restart_poll;
}
}
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 3.18 15/16] cfg80211: extend range deviation for DMG
From: Sasha Levin @ 2019-02-15 2:15 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Chaitanya Tata, Chaitanya Tata, Johannes Berg, Sasha Levin,
linux-wireless, netdev
In-Reply-To: <20190215021546.179605-1-sashal@kernel.org>
From: Chaitanya Tata <chaitanya.tata@bluwirelesstechnology.com>
[ Upstream commit 93183bdbe73bbdd03e9566c8dc37c9d06b0d0db6 ]
Recently, DMG frequency bands have been extended till 71GHz, so extend
the range check till 20GHz (45-71GHZ), else some channels will be marked
as disabled.
Signed-off-by: Chaitanya Tata <Chaitanya.Tata@bluwireless.co.uk>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/wireless/reg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 306464b3acdb..2f1b39577a84 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -688,7 +688,7 @@ static bool reg_does_bw_fit(const struct ieee80211_freq_range *freq_range,
* definitions (the "2.4 GHz band", the "5 GHz band" and the "60GHz band"),
* however it is safe for now to assume that a frequency rule should not be
* part of a frequency's band if the start freq or end freq are off by more
- * than 2 GHz for the 2.4 and 5 GHz bands, and by more than 10 GHz for the
+ * than 2 GHz for the 2.4 and 5 GHz bands, and by more than 20 GHz for the
* 60 GHz band.
* This resolution can be lowered and should be considered as we add
* regulatory rule support for other "bands".
@@ -703,7 +703,7 @@ static bool freq_in_rule_band(const struct ieee80211_freq_range *freq_range,
* with the Channel starting frequency above 45 GHz.
*/
u32 limit = freq_khz > 45 * ONE_GHZ_IN_KHZ ?
- 10 * ONE_GHZ_IN_KHZ : 2 * ONE_GHZ_IN_KHZ;
+ 20 * ONE_GHZ_IN_KHZ : 2 * ONE_GHZ_IN_KHZ;
if (abs(freq_khz - freq_range->start_freq_khz) <= limit)
return true;
if (abs(freq_khz - freq_range->end_freq_khz) <= limit)
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 3.18 12/16] sfc: suppress duplicate nvmem partition types in efx_ef10_mtd_probe
From: Sasha Levin @ 2019-02-15 2:15 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Edward Cree, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20190215021546.179605-1-sashal@kernel.org>
From: Edward Cree <ecree@solarflare.com>
[ Upstream commit 3366463513f544c12c6b88c13da4462ee9e7a1a1 ]
Use a bitmap to keep track of which partition types we've already seen;
for duplicates, return -EEXIST from efx_ef10_mtd_probe_partition() and
thus skip adding that partition.
Duplicate partitions occur because of the A/B backup scheme used by newer
sfc NICs. Prior to this patch they cause sysfs_warn_dup errors because
they have the same name, causing us not to expose any MTDs at all.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/sfc/ef10.c | 29 +++++++++++++++++++++--------
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/sfc/ef10.c b/drivers/net/ethernet/sfc/ef10.c
index 010009d64017..84a17b41313c 100644
--- a/drivers/net/ethernet/sfc/ef10.c
+++ b/drivers/net/ethernet/sfc/ef10.c
@@ -3407,22 +3407,25 @@ static const struct efx_ef10_nvram_type_info efx_ef10_nvram_types[] = {
{ NVRAM_PARTITION_TYPE_LICENSE, 0, 0, "sfc_license" },
{ NVRAM_PARTITION_TYPE_PHY_MIN, 0xff, 0, "sfc_phy_fw" },
};
+#define EF10_NVRAM_PARTITION_COUNT ARRAY_SIZE(efx_ef10_nvram_types)
static int efx_ef10_mtd_probe_partition(struct efx_nic *efx,
struct efx_mcdi_mtd_partition *part,
- unsigned int type)
+ unsigned int type,
+ unsigned long *found)
{
MCDI_DECLARE_BUF(inbuf, MC_CMD_NVRAM_METADATA_IN_LEN);
MCDI_DECLARE_BUF(outbuf, MC_CMD_NVRAM_METADATA_OUT_LENMAX);
const struct efx_ef10_nvram_type_info *info;
size_t size, erase_size, outlen;
+ int type_idx = 0;
bool protected;
int rc;
- for (info = efx_ef10_nvram_types; ; info++) {
- if (info ==
- efx_ef10_nvram_types + ARRAY_SIZE(efx_ef10_nvram_types))
+ for (type_idx = 0; ; type_idx++) {
+ if (type_idx == EF10_NVRAM_PARTITION_COUNT)
return -ENODEV;
+ info = efx_ef10_nvram_types + type_idx;
if ((type & ~info->type_mask) == info->type)
break;
}
@@ -3435,6 +3438,13 @@ static int efx_ef10_mtd_probe_partition(struct efx_nic *efx,
if (protected)
return -ENODEV; /* hide it */
+ /* If we've already exposed a partition of this type, hide this
+ * duplicate. All operations on MTDs are keyed by the type anyway,
+ * so we can't act on the duplicate.
+ */
+ if (__test_and_set_bit(type_idx, found))
+ return -EEXIST;
+
part->nvram_type = type;
MCDI_SET_DWORD(inbuf, NVRAM_METADATA_IN_TYPE, type);
@@ -3463,6 +3473,7 @@ static int efx_ef10_mtd_probe_partition(struct efx_nic *efx,
static int efx_ef10_mtd_probe(struct efx_nic *efx)
{
MCDI_DECLARE_BUF(outbuf, MC_CMD_NVRAM_PARTITIONS_OUT_LENMAX);
+ DECLARE_BITMAP(found, EF10_NVRAM_PARTITION_COUNT);
struct efx_mcdi_mtd_partition *parts;
size_t outlen, n_parts_total, i, n_parts;
unsigned int type;
@@ -3491,11 +3502,13 @@ static int efx_ef10_mtd_probe(struct efx_nic *efx)
for (i = 0; i < n_parts_total; i++) {
type = MCDI_ARRAY_DWORD(outbuf, NVRAM_PARTITIONS_OUT_TYPE_ID,
i);
- rc = efx_ef10_mtd_probe_partition(efx, &parts[n_parts], type);
- if (rc == 0)
- n_parts++;
- else if (rc != -ENODEV)
+ rc = efx_ef10_mtd_probe_partition(efx, &parts[n_parts], type,
+ found);
+ if (rc == -EEXIST || rc == -ENODEV)
+ continue;
+ if (rc)
goto fail;
+ n_parts++;
}
rc = efx_mtd_add(efx, &parts[0].common, n_parts, sizeof(*parts));
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 3.18 14/16] mac80211: don't initiate TDLS connection if station is not associated to AP
From: Sasha Levin @ 2019-02-15 2:15 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Balaji Pothunoori, Johannes Berg, Sasha Levin, linux-wireless,
netdev
In-Reply-To: <20190215021546.179605-1-sashal@kernel.org>
From: Balaji Pothunoori <bpothuno@codeaurora.org>
[ Upstream commit 7ed5285396c257fd4070b1e29e7b2341aae2a1ce ]
Following call trace is observed while adding TDLS peer entry in driver
during TDLS setup.
Call Trace:
[<c1301476>] dump_stack+0x47/0x61
[<c10537d2>] __warn+0xe2/0x100
[<fa22415f>] ? sta_apply_parameters+0x49f/0x550 [mac80211]
[<c1053895>] warn_slowpath_null+0x25/0x30
[<fa22415f>] sta_apply_parameters+0x49f/0x550 [mac80211]
[<fa20ad42>] ? sta_info_alloc+0x1c2/0x450 [mac80211]
[<fa224623>] ieee80211_add_station+0xe3/0x160 [mac80211]
[<c1876fe3>] nl80211_new_station+0x273/0x420
[<c170f6d9>] genl_rcv_msg+0x219/0x3c0
[<c170f4c0>] ? genl_rcv+0x30/0x30
[<c170ee7e>] netlink_rcv_skb+0x8e/0xb0
[<c170f4ac>] genl_rcv+0x1c/0x30
[<c170e8aa>] netlink_unicast+0x13a/0x1d0
[<c170ec18>] netlink_sendmsg+0x2d8/0x390
[<c16c5acd>] sock_sendmsg+0x2d/0x40
[<c16c6369>] ___sys_sendmsg+0x1d9/0x1e0
Fixing this by allowing TDLS setup request only when we have completed
association.
Signed-off-by: Balaji Pothunoori <bpothuno@codeaurora.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/cfg.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 6ba5240dd61d..ffe319309d03 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1194,6 +1194,10 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
sta->sta.tdls = true;
}
+ if (sta->sta.tdls && sdata->vif.type == NL80211_IFTYPE_STATION &&
+ !sdata->u.mgd.associated)
+ return -EINVAL;
+
err = sta_apply_parameters(local, sta, params);
if (err) {
sta_info_free(local, sta);
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 3.18 11/16] net: altera_tse: fix connect_local_phy error path
From: Sasha Levin @ 2019-02-15 2:15 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Atsushi Nemoto, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20190215021546.179605-1-sashal@kernel.org>
From: Atsushi Nemoto <atsushi.nemoto@sord.co.jp>
[ Upstream commit 17b42a20d7ca59377788c6a2409e77569570cc10 ]
The connect_local_phy should return NULL (not negative errno) on
error, since its caller expects it.
Signed-off-by: Atsushi Nemoto <atsushi.nemoto@sord.co.jp>
Acked-by: Thor Thayer <thor.thayer@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/altera/altera_tse_main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/altera/altera_tse_main.c b/drivers/net/ethernet/altera/altera_tse_main.c
index 2eb6404755b1..c1b599c52195 100644
--- a/drivers/net/ethernet/altera/altera_tse_main.c
+++ b/drivers/net/ethernet/altera/altera_tse_main.c
@@ -706,8 +706,10 @@ static struct phy_device *connect_local_phy(struct net_device *dev)
phydev = phy_connect(dev, phy_id_fmt, &altera_tse_adjust_link,
priv->phy_iface);
- if (IS_ERR(phydev))
+ if (IS_ERR(phydev)) {
netdev_err(dev, "Could not attach to PHY\n");
+ phydev = NULL;
+ }
} else {
int ret;
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 3.18 08/16] libceph: avoid KEEPALIVE_PENDING races in ceph_con_keepalive()
From: Sasha Levin @ 2019-02-15 2:15 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Ilya Dryomov, Sasha Levin, ceph-devel, netdev
In-Reply-To: <20190215021546.179605-1-sashal@kernel.org>
From: Ilya Dryomov <idryomov@gmail.com>
[ Upstream commit 4aac9228d16458cedcfd90c7fb37211cf3653ac3 ]
con_fault() can transition the connection into STANDBY right after
ceph_con_keepalive() clears STANDBY in clear_standby():
libceph user thread ceph-msgr worker
ceph_con_keepalive()
mutex_lock(&con->mutex)
clear_standby(con)
mutex_unlock(&con->mutex)
mutex_lock(&con->mutex)
con_fault()
...
if KEEPALIVE_PENDING isn't set
set state to STANDBY
...
mutex_unlock(&con->mutex)
set KEEPALIVE_PENDING
set WRITE_PENDING
This triggers warnings in clear_standby() when either ceph_con_send()
or ceph_con_keepalive() get to clearing STANDBY next time.
I don't see a reason to condition queue_con() call on the previous
value of KEEPALIVE_PENDING, so move the setting of KEEPALIVE_PENDING
into the critical section -- unlike WRITE_PENDING, KEEPALIVE_PENDING
could have been a non-atomic flag.
Reported-by: syzbot+acdeb633f6211ccdf886@syzkaller.appspotmail.com
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Tested-by: Myungho Jung <mhjungk@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/ceph/messenger.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/ceph/messenger.c b/net/ceph/messenger.c
index 2dc4e064bea3..45bd78f3e28f 100644
--- a/net/ceph/messenger.c
+++ b/net/ceph/messenger.c
@@ -3068,9 +3068,10 @@ void ceph_con_keepalive(struct ceph_connection *con)
dout("con_keepalive %p\n", con);
mutex_lock(&con->mutex);
clear_standby(con);
+ con_flag_set(con, CON_FLAG_KEEPALIVE_PENDING);
mutex_unlock(&con->mutex);
- if (con_flag_test_and_set(con, CON_FLAG_KEEPALIVE_PENDING) == 0 &&
- con_flag_test_and_set(con, CON_FLAG_WRITE_PENDING) == 0)
+
+ if (con_flag_test_and_set(con, CON_FLAG_WRITE_PENDING) == 0)
queue_con(con);
}
EXPORT_SYMBOL(ceph_con_keepalive);
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 3.18 07/16] mac80211: fix miscounting of ttl-dropped frames
From: Sasha Levin @ 2019-02-15 2:15 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Bob Copeland, Bob Copeland, Johannes Berg, Sasha Levin,
linux-wireless, netdev
In-Reply-To: <20190215021546.179605-1-sashal@kernel.org>
From: Bob Copeland <me@bobcopeland.com>
[ Upstream commit a0dc02039a2ee54fb4ae400e0b755ed30e73e58c ]
In ieee80211_rx_h_mesh_fwding, we increment the 'dropped_frames_ttl'
counter when we decrement the ttl to zero. For unicast frames
destined for other hosts, we stop processing the frame at that point.
For multicast frames, we do not rebroadcast it in this case, but we
do pass the frame up the stack to process it on this STA. That
doesn't match the usual definition of "dropped," so don't count
those as such.
With this change, something like `ping6 -i0.2 ff02::1%mesh0` from a
peer in a ttl=1 network no longer increments the counter rapidly.
Signed-off-by: Bob Copeland <bobcopeland@fb.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/rx.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index ea3b13987521..ccb822aa6225 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2179,7 +2179,9 @@ ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
skb_set_queue_mapping(skb, q);
if (!--mesh_hdr->ttl) {
- IEEE80211_IFSTA_MESH_CTR_INC(ifmsh, dropped_frames_ttl);
+ if (!is_multicast_ether_addr(hdr->addr1))
+ IEEE80211_IFSTA_MESH_CTR_INC(ifmsh,
+ dropped_frames_ttl);
goto out;
}
--
2.19.1
^ permalink raw reply related
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