Fixed a minor typo in Documentation/rbtree.c #59
+1
−1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
alexandrebelloni
pushed a commit
to alexandrebelloni/linux
that referenced
this pull request
Nov 30, 2013
If the system had a few memory groups and all of them were destroyed, memcg_limited_groups_array_size has non-zero value, but all new caches are created without memcg_params, because memcg_kmem_enabled() returns false. We try to enumirate child caches in a few places and all of them are potentially dangerous. For example my kernel is compiled with CONFIG_SLAB and it crashed when I tryed to mount a NFS share after a few experiments with kmemcg. BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: [<ffffffff8118166a>] do_tune_cpucache+0x8a/0xd0 PGD b942a067 PUD b999f067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: fscache(+) ip6table_filter ip6_tables iptable_filter ip_tables i2c_piix4 pcspkr virtio_net virtio_balloon i2c_core floppy CPU: 0 PID: 357 Comm: modprobe Not tainted 3.11.0-rc7+ torvalds#59 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 task: ffff8800b9f98240 ti: ffff8800ba32e000 task.ti: ffff8800ba32e000 RIP: 0010:[<ffffffff8118166a>] [<ffffffff8118166a>] do_tune_cpucache+0x8a/0xd0 RSP: 0018:ffff8800ba32fb70 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000000 RSI: ffff8800b9f98910 RDI: 0000000000000246 RBP: ffff8800ba32fba0 R08: 0000000000000002 R09: 0000000000000004 R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000010 R13: 0000000000000008 R14: 00000000000000d0 R15: ffff8800375d0200 FS: 00007f55f1378740(0000) GS:ffff8800bfa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007f24feba57a0 CR3: 0000000037b51000 CR4: 00000000000006f0 Call Trace: enable_cpucache+0x49/0x100 setup_cpu_cache+0x215/0x280 __kmem_cache_create+0x2fa/0x450 kmem_cache_create_memcg+0x214/0x350 kmem_cache_create+0x2b/0x30 fscache_init+0x19b/0x230 [fscache] do_one_initcall+0xfa/0x1b0 load_module+0x1c41/0x26d0 SyS_finit_module+0x86/0xb0 system_call_fastpath+0x16/0x1b Signed-off-by: Andrey Vagin <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: Glauber Costa <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
alexandrebelloni
pushed a commit
to alexandrebelloni/linux
that referenced
this pull request
Nov 30, 2013
As the new x86 CPU bootup printout format code maintainer, I am taking immediate action to improve and clean (and thus indulge my OCD) the reporting of the cores when coming up online. Fix padding to a right-hand alignment, cleanup code and bind reporting width to the max number of supported CPUs on the system, like this: [ 0.074509] smpboot: Booting Node 0, Processors: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 OK [ 0.644008] smpboot: Booting Node 1, Processors: torvalds#8 torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 OK [ 1.245006] smpboot: Booting Node 2, Processors: torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 OK [ 1.864005] smpboot: Booting Node 3, Processors: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 OK [ 2.489005] smpboot: Booting Node 4, Processors: torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 OK [ 3.093005] smpboot: Booting Node 5, Processors: torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 OK [ 3.698005] smpboot: Booting Node 6, Processors: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 OK [ 4.304005] smpboot: Booting Node 7, Processors: torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 OK [ 4.961413] Brought up 64 CPUs and this: [ 0.072367] smpboot: Booting Node 0, Processors: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 OK [ 0.686329] Brought up 8 CPUs Signed-off-by: Borislav Petkov <[email protected]> Cc: Libin <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
alexandrebelloni
pushed a commit
to alexandrebelloni/linux
that referenced
this pull request
Nov 30, 2013
Turn it into (for example): [ 0.073380] x86: Booting SMP configuration: [ 0.074005] .... node #0, CPUs: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 [ 0.603005] .... node #1, CPUs: torvalds#8 torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 [ 1.200005] .... node #2, CPUs: torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 [ 1.796005] .... node #3, CPUs: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 [ 2.393005] .... node #4, CPUs: torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 [ 2.996005] .... node #5, CPUs: torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 [ 3.600005] .... node torvalds#6, CPUs: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 [ 4.202005] .... node torvalds#7, CPUs: torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 [ 4.811005] .... node torvalds#8, CPUs: torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71 [ 5.421006] .... node torvalds#9, CPUs: torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 [ 6.032005] .... node torvalds#10, CPUs: torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 [ 6.648006] .... node torvalds#11, CPUs: torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95 [ 7.262005] .... node torvalds#12, CPUs: torvalds#96 torvalds#97 torvalds#98 torvalds#99 torvalds#100 torvalds#101 torvalds#102 torvalds#103 [ 7.865005] .... node torvalds#13, CPUs: torvalds#104 torvalds#105 torvalds#106 torvalds#107 torvalds#108 torvalds#109 torvalds#110 torvalds#111 [ 8.466005] .... node torvalds#14, CPUs: torvalds#112 torvalds#113 torvalds#114 torvalds#115 torvalds#116 torvalds#117 torvalds#118 torvalds#119 [ 9.073006] .... node torvalds#15, CPUs: torvalds#120 torvalds#121 torvalds#122 torvalds#123 torvalds#124 torvalds#125 torvalds#126 torvalds#127 [ 9.679901] x86: Booted up 16 nodes, 128 CPUs and drop useless elements. Change num_digits() to hpa's division-avoiding, cell-phone-typed version which he went at great lengths and pains to submit on a Saturday evening. Signed-off-by: Borislav Petkov <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: Linus Torvalds <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
ystk
pushed a commit
to ystk/linux-ltsi-work
that referenced
this pull request
Dec 16, 2013
commit 6f6b895 upstream. If the system had a few memory groups and all of them were destroyed, memcg_limited_groups_array_size has non-zero value, but all new caches are created without memcg_params, because memcg_kmem_enabled() returns false. We try to enumirate child caches in a few places and all of them are potentially dangerous. For example my kernel is compiled with CONFIG_SLAB and it crashed when I tryed to mount a NFS share after a few experiments with kmemcg. BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: [<ffffffff8118166a>] do_tune_cpucache+0x8a/0xd0 PGD b942a067 PUD b999f067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: fscache(+) ip6table_filter ip6_tables iptable_filter ip_tables i2c_piix4 pcspkr virtio_net virtio_balloon i2c_core floppy CPU: 0 PID: 357 Comm: modprobe Not tainted 3.11.0-rc7+ torvalds#59 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 task: ffff8800b9f98240 ti: ffff8800ba32e000 task.ti: ffff8800ba32e000 RIP: 0010:[<ffffffff8118166a>] [<ffffffff8118166a>] do_tune_cpucache+0x8a/0xd0 RSP: 0018:ffff8800ba32fb70 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000000 RSI: ffff8800b9f98910 RDI: 0000000000000246 RBP: ffff8800ba32fba0 R08: 0000000000000002 R09: 0000000000000004 R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000010 R13: 0000000000000008 R14: 00000000000000d0 R15: ffff8800375d0200 FS: 00007f55f1378740(0000) GS:ffff8800bfa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007f24feba57a0 CR3: 0000000037b51000 CR4: 00000000000006f0 Call Trace: enable_cpucache+0x49/0x100 setup_cpu_cache+0x215/0x280 __kmem_cache_create+0x2fa/0x450 kmem_cache_create_memcg+0x214/0x350 kmem_cache_create+0x2b/0x30 fscache_init+0x19b/0x230 [fscache] do_one_initcall+0xfa/0x1b0 load_module+0x1c41/0x26d0 SyS_finit_module+0x86/0xb0 system_call_fastpath+0x16/0x1b Signed-off-by: Andrey Vagin <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: Glauber Costa <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Johannes Weiner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
zeitgeist87
pushed a commit
to zeitgeist87/linux
that referenced
this pull request
Mar 14, 2014
The iommu_count field in si_domain(static identity domain) is initialized to zero and never increases. It will underflow when tearing down iommu unit in function free_dmar_iommu() and leak memory. So refine code to correctly manage si_domain->iommu_count. Warning message caused by si_domain memory leak: [ 14.609681] IOMMU: Setting RMRR: [ 14.613496] Ignoring identity map for HW passthrough device 0000:00:1a.0 [0xbdcfd000 - 0xbdd1dfff] [ 14.623809] Ignoring identity map for HW passthrough device 0000:00:1d.0 [0xbdcfd000 - 0xbdd1dfff] [ 14.634162] IOMMU: Prepare 0-16MiB unity mapping for LPC [ 14.640329] Ignoring identity map for HW passthrough device 0000:00:1f.0 [0x0 - 0xffffff] [ 14.673360] IOMMU: dmar init failed [ 14.678157] kmem_cache_destroy iommu_devinfo: Slab cache still has objects [ 14.686076] CPU: 12 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-gerry+ torvalds#59 [ 14.694176] Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012 [ 14.707412] 0000000000000000 ffff88042dd33db0 ffffffff8156223d ffff880c2cc37c00 [ 14.716407] ffff88042dd33dc8 ffffffff811790b1 ffff880c2d3533b8 ffff88042dd33e00 [ 14.725468] ffffffff81dc7a6a ffffffff81b1e8e0 ffffffff81f84058 ffffffff81d8a711 [ 14.734464] Call Trace: [ 14.737453] [<ffffffff8156223d>] dump_stack+0x4d/0x66 [ 14.743430] [<ffffffff811790b1>] kmem_cache_destroy+0xf1/0x100 [ 14.750279] [<ffffffff81dc7a6a>] intel_iommu_init+0x122/0x56a [ 14.757035] [<ffffffff81d8a711>] ? iommu_setup+0x27d/0x27d [ 14.763491] [<ffffffff81d8a739>] pci_iommu_init+0x28/0x52 [ 14.769846] [<ffffffff81000342>] do_one_initcall+0x122/0x180 [ 14.776506] [<ffffffff81077738>] ? parse_args+0x1e8/0x320 [ 14.782866] [<ffffffff81d850e8>] kernel_init_freeable+0x1e1/0x26c [ 14.789994] [<ffffffff81d84833>] ? do_early_param+0x88/0x88 [ 14.796556] [<ffffffff8154ffc0>] ? rest_init+0xd0/0xd0 [ 14.802626] [<ffffffff8154ffce>] kernel_init+0xe/0x130 [ 14.808698] [<ffffffff815756ac>] ret_from_fork+0x7c/0xb0 [ 14.814963] [<ffffffff8154ffc0>] ? rest_init+0xd0/0xd0 [ 14.821640] kmem_cache_destroy iommu_domain: Slab cache still has objects [ 14.829456] CPU: 12 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-gerry+ torvalds#59 [ 14.837562] Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012 [ 14.850803] 0000000000000000 ffff88042dd33db0 ffffffff8156223d ffff88102c1ee3c0 [ 14.861222] ffff88042dd33dc8 ffffffff811790b1 ffff880c2d3533b8 ffff88042dd33e00 [ 14.870284] ffffffff81dc7a76 ffffffff81b1e8e0 ffffffff81f84058 ffffffff81d8a711 [ 14.879271] Call Trace: [ 14.882227] [<ffffffff8156223d>] dump_stack+0x4d/0x66 [ 14.888197] [<ffffffff811790b1>] kmem_cache_destroy+0xf1/0x100 [ 14.895034] [<ffffffff81dc7a76>] intel_iommu_init+0x12e/0x56a [ 14.901781] [<ffffffff81d8a711>] ? iommu_setup+0x27d/0x27d [ 14.908238] [<ffffffff81d8a739>] pci_iommu_init+0x28/0x52 [ 14.914594] [<ffffffff81000342>] do_one_initcall+0x122/0x180 [ 14.921244] [<ffffffff81077738>] ? parse_args+0x1e8/0x320 [ 14.927598] [<ffffffff81d850e8>] kernel_init_freeable+0x1e1/0x26c [ 14.934738] [<ffffffff81d84833>] ? do_early_param+0x88/0x88 [ 14.941309] [<ffffffff8154ffc0>] ? rest_init+0xd0/0xd0 [ 14.947380] [<ffffffff8154ffce>] kernel_init+0xe/0x130 [ 14.953430] [<ffffffff815756ac>] ret_from_fork+0x7c/0xb0 [ 14.959689] [<ffffffff8154ffc0>] ? rest_init+0xd0/0xd0 [ 14.966299] kmem_cache_destroy iommu_iova: Slab cache still has objects [ 14.973923] CPU: 12 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-gerry+ torvalds#59 [ 14.982020] Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012 [ 14.995263] 0000000000000000 ffff88042dd33db0 ffffffff8156223d ffff88042cb5c980 [ 15.004265] ffff88042dd33dc8 ffffffff811790b1 ffff880c2d3533b8 ffff88042dd33e00 [ 15.013322] ffffffff81dc7a82 ffffffff81b1e8e0 ffffffff81f84058 ffffffff81d8a711 [ 15.022318] Call Trace: [ 15.025238] [<ffffffff8156223d>] dump_stack+0x4d/0x66 [ 15.031202] [<ffffffff811790b1>] kmem_cache_destroy+0xf1/0x100 [ 15.038038] [<ffffffff81dc7a82>] intel_iommu_init+0x13a/0x56a [ 15.044786] [<ffffffff81d8a711>] ? iommu_setup+0x27d/0x27d [ 15.051242] [<ffffffff81d8a739>] pci_iommu_init+0x28/0x52 [ 15.057601] [<ffffffff81000342>] do_one_initcall+0x122/0x180 [ 15.064254] [<ffffffff81077738>] ? parse_args+0x1e8/0x320 [ 15.070608] [<ffffffff81d850e8>] kernel_init_freeable+0x1e1/0x26c [ 15.077747] [<ffffffff81d84833>] ? do_early_param+0x88/0x88 [ 15.084300] [<ffffffff8154ffc0>] ? rest_init+0xd0/0xd0 [ 15.090362] [<ffffffff8154ffce>] kernel_init+0xe/0x130 [ 15.096431] [<ffffffff815756ac>] ret_from_fork+0x7c/0xb0 [ 15.102693] [<ffffffff8154ffc0>] ? rest_init+0xd0/0xd0 [ 15.189273] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) Signed-off-by: Jiang Liu <[email protected]> Cc: Alex Williamson <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
zeitgeist87
pushed a commit
to zeitgeist87/linux
that referenced
this pull request
Mar 14, 2014
…loop-during-umount-checkpatch-fixes ERROR: code indent should use tabs where possible torvalds#56: FILE: fs/ocfs2/dlm/dlmmaster.c:3087: + if (tmp->type == DLM_MLE_MASTER) {$ WARNING: please, no spaces at the start of a line torvalds#56: FILE: fs/ocfs2/dlm/dlmmaster.c:3087: + if (tmp->type == DLM_MLE_MASTER) {$ WARNING: suspect code indent for conditional statements (23, 31) torvalds#56: FILE: fs/ocfs2/dlm/dlmmaster.c:3087: + if (tmp->type == DLM_MLE_MASTER) { + ret = DLM_MIGRATE_RESPONSE_MASTERY_REF; ERROR: code indent should use tabs where possible torvalds#57: FILE: fs/ocfs2/dlm/dlmmaster.c:3088: + ret = DLM_MIGRATE_RESPONSE_MASTERY_REF;$ WARNING: please, no spaces at the start of a line torvalds#57: FILE: fs/ocfs2/dlm/dlmmaster.c:3088: + ret = DLM_MIGRATE_RESPONSE_MASTERY_REF;$ ERROR: code indent should use tabs where possible #58: FILE: fs/ocfs2/dlm/dlmmaster.c:3089: + mlog(0, "%s:%.*s: master=%u, newmaster=%u, "$ WARNING: please, no spaces at the start of a line #58: FILE: fs/ocfs2/dlm/dlmmaster.c:3089: + mlog(0, "%s:%.*s: master=%u, newmaster=%u, "$ WARNING: quoted string split across lines torvalds#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090: + mlog(0, "%s:%.*s: master=%u, newmaster=%u, " + "telling master to get ref " ERROR: code indent should use tabs where possible torvalds#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090: + "telling master to get ref "$ WARNING: please, no spaces at the start of a line torvalds#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090: + "telling master to get ref "$ WARNING: quoted string split across lines torvalds#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091: + "telling master to get ref " + "for cleared out mle during " ERROR: code indent should use tabs where possible torvalds#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091: + "for cleared out mle during "$ WARNING: please, no spaces at the start of a line torvalds#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091: + "for cleared out mle during "$ WARNING: quoted string split across lines torvalds#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092: + "for cleared out mle during " + "migration\n", dlm->name, ERROR: code indent should use tabs where possible torvalds#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092: + "migration\n", dlm->name,$ WARNING: please, no spaces at the start of a line torvalds#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092: + "migration\n", dlm->name,$ ERROR: code indent should use tabs where possible torvalds#62: FILE: fs/ocfs2/dlm/dlmmaster.c:3093: + namelen, name, master,$ WARNING: please, no spaces at the start of a line torvalds#62: FILE: fs/ocfs2/dlm/dlmmaster.c:3093: + namelen, name, master,$ ERROR: code indent should use tabs where possible torvalds#63: FILE: fs/ocfs2/dlm/dlmmaster.c:3094: + new_master);$ WARNING: please, no spaces at the start of a line torvalds#63: FILE: fs/ocfs2/dlm/dlmmaster.c:3094: + new_master);$ ERROR: code indent should use tabs where possible torvalds#64: FILE: fs/ocfs2/dlm/dlmmaster.c:3095: + }$ WARNING: please, no spaces at the start of a line torvalds#64: FILE: fs/ocfs2/dlm/dlmmaster.c:3095: + }$ total: 9 errors, 13 warnings, 20 lines checked NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or scripts/cleanfile ./patches/ocfs2-do-not-return-dlm_migrate_response_mastery_ref-to-avoid-endlessloop-during-umount.patch has style problems, please review. If any of these errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Joel Becker <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Xue jiufei <[email protected]> Cc: jiangyiwen <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
swarren
pushed a commit
to swarren/linux-tegra
that referenced
this pull request
Mar 19, 2014
…loop-during-umount-checkpatch-fixes ERROR: code indent should use tabs where possible torvalds#56: FILE: fs/ocfs2/dlm/dlmmaster.c:3087: + if (tmp->type == DLM_MLE_MASTER) {$ WARNING: please, no spaces at the start of a line torvalds#56: FILE: fs/ocfs2/dlm/dlmmaster.c:3087: + if (tmp->type == DLM_MLE_MASTER) {$ WARNING: suspect code indent for conditional statements (23, 31) torvalds#56: FILE: fs/ocfs2/dlm/dlmmaster.c:3087: + if (tmp->type == DLM_MLE_MASTER) { + ret = DLM_MIGRATE_RESPONSE_MASTERY_REF; ERROR: code indent should use tabs where possible torvalds#57: FILE: fs/ocfs2/dlm/dlmmaster.c:3088: + ret = DLM_MIGRATE_RESPONSE_MASTERY_REF;$ WARNING: please, no spaces at the start of a line torvalds#57: FILE: fs/ocfs2/dlm/dlmmaster.c:3088: + ret = DLM_MIGRATE_RESPONSE_MASTERY_REF;$ ERROR: code indent should use tabs where possible #58: FILE: fs/ocfs2/dlm/dlmmaster.c:3089: + mlog(0, "%s:%.*s: master=%u, newmaster=%u, "$ WARNING: please, no spaces at the start of a line #58: FILE: fs/ocfs2/dlm/dlmmaster.c:3089: + mlog(0, "%s:%.*s: master=%u, newmaster=%u, "$ WARNING: quoted string split across lines torvalds#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090: + mlog(0, "%s:%.*s: master=%u, newmaster=%u, " + "telling master to get ref " ERROR: code indent should use tabs where possible torvalds#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090: + "telling master to get ref "$ WARNING: please, no spaces at the start of a line torvalds#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090: + "telling master to get ref "$ WARNING: quoted string split across lines torvalds#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091: + "telling master to get ref " + "for cleared out mle during " ERROR: code indent should use tabs where possible torvalds#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091: + "for cleared out mle during "$ WARNING: please, no spaces at the start of a line torvalds#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091: + "for cleared out mle during "$ WARNING: quoted string split across lines torvalds#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092: + "for cleared out mle during " + "migration\n", dlm->name, ERROR: code indent should use tabs where possible torvalds#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092: + "migration\n", dlm->name,$ WARNING: please, no spaces at the start of a line torvalds#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092: + "migration\n", dlm->name,$ ERROR: code indent should use tabs where possible torvalds#62: FILE: fs/ocfs2/dlm/dlmmaster.c:3093: + namelen, name, master,$ WARNING: please, no spaces at the start of a line torvalds#62: FILE: fs/ocfs2/dlm/dlmmaster.c:3093: + namelen, name, master,$ ERROR: code indent should use tabs where possible torvalds#63: FILE: fs/ocfs2/dlm/dlmmaster.c:3094: + new_master);$ WARNING: please, no spaces at the start of a line torvalds#63: FILE: fs/ocfs2/dlm/dlmmaster.c:3094: + new_master);$ ERROR: code indent should use tabs where possible torvalds#64: FILE: fs/ocfs2/dlm/dlmmaster.c:3095: + }$ WARNING: please, no spaces at the start of a line torvalds#64: FILE: fs/ocfs2/dlm/dlmmaster.c:3095: + }$ total: 9 errors, 13 warnings, 20 lines checked NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or scripts/cleanfile ./patches/ocfs2-do-not-return-dlm_migrate_response_mastery_ref-to-avoid-endlessloop-during-umount.patch has style problems, please review. If any of these errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Joel Becker <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Xue jiufei <[email protected]> Cc: jiangyiwen <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
ddstreet
referenced
this pull request
in ddstreet/linux
Apr 8, 2014
GIT 3b55c3c0ec2eb3f163f15559f3962df717f53ccb commit 8dec067dc9c59f9fdcaf4357c22994cde3647eb8 Author: Tomasz Figa <[email protected]> Date: Fri Mar 21 02:59:30 2014 +0900 ARM: EXYNOS: Fix compilation error in cpuidle.c The big series refactoring Exynos suspend to RAM handling missed the cpuidle driver that is disabled in exynos_defconfig, leaving it including old mach/pm_core.h header and using old s3c_cpu_resume symbol instead of new exynos_cpu_resume, resulting in compilation failures with CONFIG_ARCH_EXYNOS and CONFIG_CPU_IDLE enabled. This patch fixes that silly mistake and performs necessary modification to arhc/arm/exynos/cpuidle.c to make it compile again. Signed-off-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 58f37b0d47e9839fc8ef90d712594ed55cfcb2c7 Author: Tomasz Figa <[email protected]> Date: Fri Mar 21 03:22:33 2014 +0900 ARM: S5P64X0: Explicitly include linux/serial_s3c.h in mach/pm-core.h This patch fixes compilation failure due to missing explicit inclusion of linux/serial_s3c.h in mach/pm-core.h, which contains definitions required for further code in this header. Signed-off-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit b2cde2cc71f2382e4a4bfaaacd5263bd93f1e0d2 Author: Florian Fainelli <[email protected]> Date: Thu Mar 20 10:53:23 2014 -0700 net: bcmgenet: manipulate netdev_queue directly Instead of always invoking netdev_get_tx_queue() in bcmgenet_xmit() and bcmgenet_tx_reclaim(), just get the corresponding netdev_queue pointer once and for all and manipulate it throughout bcmgenet_xmit() and bcmgenet_tx_reclaim(). Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit d5c76f628d399f06785b0ee910c431770a01b807 Author: Florian Fainelli <[email protected]> Date: Thu Mar 20 10:53:22 2014 -0700 net: bcmgenet: remove bogus tx queue checks netdev_pick_tx already takes care of making sure that a given skb->queue_mapping value will remain within the number of advertised hardware queue number, there is no need to re-do this again in the driver. Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit d03825fba459d0d58e4fe162439babfc5f5eabc4 Author: Florian Fainelli <[email protected]> Date: Thu Mar 20 10:53:21 2014 -0700 net: bcmgenet: add skb_tx_timestamp call The BCMGENET driver was not TX timestamping the SKBs it queued for transmission, do this in bcmgenet_xmit() right before kicking the Transmit DMA engine. Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 9460c936794fbcf82623e263926b17334ca5887a Author: Florian Fainelli <[email protected]> Date: Thu Mar 20 10:53:20 2014 -0700 net: bcmgenet: remove unused spinlock member The spinlock cookie in bcmgenet_priv is never used, get rid of it. Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit f738a13d8365b0f824f3f20450b413f55374f175 Author: Laurent Pinchart <[email protected]> Date: Thu Mar 20 15:00:35 2014 +0100 sh_eth: Remove goto statements that jump straight to a return "goto" is well accepted for error paths in the kernel but should not be used unnecessarily. Return the correct value directly instead of using a goto when possible. Signed-off-by: Laurent Pinchart <[email protected]> Acked-by: Geert Uytterhoeven <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit daacf03f0bbfefee3df107c3f7659d22e22538a7 Author: Laurent Pinchart <[email protected]> Date: Thu Mar 20 15:00:34 2014 +0100 sh_eth: Register MDIO bus before registering the network device Network API functions that rely on the MDIO bus can be called as soon as the driver calls register_netdev(). Register the MDIO bus before the network device to avoid race conditions. Signed-off-by: Laurent Pinchart <[email protected]> Acked-by: Geert Uytterhoeven <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit bd920ff553ba17f19372501a14e432d9d92b102b Author: Laurent Pinchart <[email protected]> Date: Thu Mar 20 15:00:33 2014 +0100 sh_eth: Simplify MDIO bus initialization and release The network device passed to the sh_mdio_init and sh_mdio_release functions is only used to access the sh_eth_private instance. Pass it directly to those functions. Signed-off-by: Laurent Pinchart <[email protected]> Acked-by: Geert Uytterhoeven <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit a5bd60608936fbb84471a80592401ce29a68de71 Author: Laurent Pinchart <[email protected]> Date: Thu Mar 20 15:00:32 2014 +0100 sh_eth: Use the platform device as the MDIO bus parent The MDIO bus parent is set to the network device. Beside not reflecting the hardware topology, this prevents registering the MDIO bus before initializing the network device. Fix it by setting the MDIO bus parent to the platform device. Signed-off-by: Laurent Pinchart <[email protected]> Acked-by: Geert Uytterhoeven <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit aa8d422510969b705656e49fc0166d862aca9246 Author: Laurent Pinchart <[email protected]> Date: Thu Mar 20 15:00:31 2014 +0100 sh_eth: Use the platform device for memory allocation Memory allocated for the MDIO bus with the devm_kzalloc() API is associated with the network device. While this will cause memory to be freed at the right time, it doesn't allow allocating memory before the network device is initialized. Replace the network device with the parent platform device for memory allocation to remove that dependency. This also improves consistency with the other devm_* calls in the driver that all use the platform device. Signed-off-by: Laurent Pinchart <[email protected]> Acked-by: Geert Uytterhoeven <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 54af36e7136b5e111734ca5b06c6b4390d663cac Author: Alexander Aring <[email protected]> Date: Thu Mar 20 14:57:03 2014 +0100 ieee802154: dgram: cleanup set of broadcast panid This patch is only a cleanup to use the right define for a panid field. The broadcast address and panid broadcast is still the same value. Signed-off-by: Alexander Aring <[email protected]> Cc: Phoebe Buckheister <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 06324f2f7c21e3ba3529546063a3ebf7da806ed0 Author: Alexander Aring <[email protected]> Date: Thu Mar 20 14:57:02 2014 +0100 af_ieee802154: fix check on broadcast address This patch fixes an issue which was introduced by commit b70ab2e87f17176d18f67ef331064441a032b5f3 ("ieee802154: enforce consistent endianness in the 802.15.4 stack"). The correct behaviour should be a check on the broadcast address field which is 0xffff. Signed-off-by: Alexander Aring <[email protected]> Reported-by: Jan Luebbe <[email protected]> Cc: Phoebe Buckheister <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 3c6f5592203e8126b70717f040c6c59f953068b3 Author: Jason Gunthorpe <[email protected]> Date: Wed Mar 19 16:15:24 2014 -0600 of_mdio: Allow the DT to specify the phy ID and avoid autoprobing This makes the generic of_mdiobus_register parse the DT compatible string for the pattern ethernet-phy-idAAAA.BBBB. If present it should be a value that matches the phy-id register normally readable through MDIO. When the ID is given the phy autoprobing is defeated and the phy is created directly. This is necessary to support phy's that cannot be autoprobed when of_mdiobus_register is called. Specifically, my case has the phy in reset at of_mdiobus_register, the reset is only released once the ethernet driver starts, before it attaches to the phy. Tested on ARM Kirkwood with phy id 0x01410e90 (Marvell 88E1318) Signed-off-by: Jason Gunthorpe <[email protected]> Acked-by: Florian Fainelli <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit f00e756ed12d3204583764c93e41b89e1ae7ee44 Author: Jason Gunthorpe <[email protected]> Date: Wed Mar 19 16:15:23 2014 -0600 dt: Document a compatible entry for MDIO ethernet Phys This describes a compatible entry of the form: ethernet-phy-idAAAA,BBBB Which is modelled after the PCI structured compatible entry (pciVVVV,DDDD.SSSS.ssss.RR) If present the OF core will be able to use this information to directly create the correct phy without auto probing the bus. Signed-off-by: Jason Gunthorpe <[email protected]> Acked-by: Rob Herring <[email protected]> Acked-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 259fef033ffe4e70bf7f358c53400a09f1b5384e Author: Ben Chan <[email protected]> Date: Wed Mar 19 14:00:06 2014 -0700 net: cdc_ncm: respect operator preferred MTU reported by MBIM According to "Universal Serial Bus Communications Class Subclass Specification for Mobile Broadband Interface Model, Revision 1.0, Errata-1" published by USB-IF, the wMTU field of the MBIM extended functional descriptor indicates the operator preferred MTU for IP data streams. This patch modifies cdc_ncm_setup to ensure that the MTU value set on the usbnet device does not exceed the operator preferred MTU indicated by wMTU if the MBIM device exposes a MBIM extended functional descriptor. Signed-off-by: Ben Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit bfe9b3f8c5229e5de4fd18e941866bc410d16334 Author: Ben Chan <[email protected]> Date: Wed Mar 19 14:00:05 2014 -0700 USB: cdc: add MBIM extended functional descriptor structure This patch adds the MBIM extended functional descriptor structure defined in "Universal Serial Bus Communications Class Subclass Specification for Mobile Broadband Interface Model, Revision 1.0, Errata-1" published by USB-IF. Signed-off-by: Ben Chan <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit f518338b16038beeb73e155e60d0f70beb9379f4 Author: Nicolas Dichtel <[email protected]> Date: Wed Mar 19 17:47:51 2014 +0100 ip6mr: fix mfc notification flags Commit 812e44dd1829 ("ip6mr: advertise new mfc entries via rtnl") reuses the function ip6mr_fill_mroute() to notify mfc events. But this function was used only for dump and thus was always setting the flag NLM_F_MULTI, which is wrong in case of a single notification. Libraries like libnl will wait forever for NLMSG_DONE. CC: Thomas Graf <[email protected]> Signed-off-by: Nicolas Dichtel <[email protected]> Acked-by: Thomas Graf <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 65886f439ab0fdc2dff20d1fa87afb98c6717472 Author: Nicolas Dichtel <[email protected]> Date: Wed Mar 19 17:47:50 2014 +0100 ipmr: fix mfc notification flags Commit 8cd3ac9f9b7b ("ipmr: advertise new mfc entries via rtnl") reuses the function ipmr_fill_mroute() to notify mfc events. But this function was used only for dump and thus was always setting the flag NLM_F_MULTI, which is wrong in case of a single notification. Libraries like libnl will wait forever for NLMSG_DONE. CC: Thomas Graf <[email protected]> Signed-off-by: Nicolas Dichtel <[email protected]> Acked-by: Thomas Graf <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 1c104a6bebf3c16b6248408b84f91d09ac8a26b6 Author: Nicolas Dichtel <[email protected]> Date: Wed Mar 19 17:47:49 2014 +0100 rtnetlink: fix fdb notification flags Commit 3ff661c38c84 ("net: rtnetlink notify events for FDB NTF_SELF adds and deletes") reuses the function nlmsg_populate_fdb_fill() to notify fdb events. But this function was used only for dump and thus was always setting the flag NLM_F_MULTI, which is wrong in case of a single notification. Libraries like libnl will wait forever for NLMSG_DONE. CC: Thomas Graf <[email protected]> Signed-off-by: Nicolas Dichtel <[email protected]> Acked-by: Thomas Graf <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 632623153196bf183a69686ed9c07eee98ff1bf8 Author: Eric Dumazet <[email protected]> Date: Wed Mar 19 21:02:21 2014 -0700 tcp: syncookies: do not use getnstimeofday() While it is true that getnstimeofday() uses about 40 cycles if TSC is available, it can use 1600 cycles if hpet is the clocksource. Switch to get_jiffies_64(), as this is more than enough, and go back to 60 seconds periods. Fixes: 8c27bd75f04f ("tcp: syncookies: reduce cookie lifetime to 128 seconds") Signed-off-by: Eric Dumazet <[email protected]> Cc: Florian Westphal <[email protected]> Acked-by: Florian Westphal <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit dd41cc3bb90efd455df514899a5d3cf245182eb1 Author: Matan Barak <[email protected]> Date: Wed Mar 19 18:11:53 2014 +0200 net/mlx4: Adapt num_vfs/probed_vf params for single port VF A new syntax is added for the module parameters num_vfs and probe_vf. num_vfs=p1,p2,p1+p2 probe_bf=p1,p2,p1+p2 Where p1(2) is the number of VFs on / probed VFs for physical port1(2) and p1+p2 is the number of dual port VFs. Single port VFs are currently supported only when the link type for both ports of the device is Ethernet. Signed-off-by: Matan Barak <[email protected]> Signed-off-by: Or Gerlitz <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 449fc48866f7d84b0d9a19201de18a4dd4d3488c Author: Matan Barak <[email protected]> Date: Wed Mar 19 18:11:52 2014 +0200 net/mlx4: Adapt code for N-Port VF Adds support for N-Port VFs, this includes: 1. Adding support in the wrapped FW command In wrapped commands, we need to verify and convert the slave's port into the real physical port. Furthermore, when sending the response back to the slave, a reverse conversion should be made. 2. Adjusting sqpn for QP1 para-virtualization The slave assumes that sqpn is used for QP1 communication. If the slave is assigned to a port != (first port), we need to adjust the sqpn that will direct its QP1 packets into the correct endpoint. 3. Adjusting gid[5] to modify the port for raw ethernet In B0 steering, gid[5] contains the port. It needs to be adjusted into the physical port. 4. Adjusting number of ports in the query / ports caps in the FW commands When a slave queries the hardware, it needs to view only the physical ports it's assigned to. 5. Adjusting the sched_qp according to the port number The QP port is encoded in the sched_qp, thus in modify_qp we need to encode the correct port in sched_qp. Signed-off-by: Matan Barak <[email protected]> Signed-off-by: Or Gerlitz <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit f74462acf8f390528c8b7937f227c6c90d017f3b Author: Matan Barak <[email protected]> Date: Wed Mar 19 18:11:51 2014 +0200 net/mlx4: Add utils for N-Port VFs This patch adds the following utils: 1. Convert slave_id -> VF 2. Get the active ports by slave_id 3. Convert slave's port to real port 4. Get the slave's port from real port 5. Get all slaves that uses the i'th real port 6. Get all slaves that uses the i'th real port exclusively Signed-off-by: Matan Barak <[email protected]> Signed-off-by: Or Gerlitz <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 1ab95d37bcc3ff2d69e3871e4f056bab7aed0b85 Author: Matan Barak <[email protected]> Date: Wed Mar 19 18:11:50 2014 +0200 net/mlx4: Add data structures to support N-Ports per VF Adds the required data structures to support VFs with N (1 or 2) ports instead of always using the number of physical ports. Signed-off-by: Matan Barak <[email protected]> Signed-off-by: Or Gerlitz <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 82373701be26b893eaf7372db0af84235a51998a Author: Matan Barak <[email protected]> Date: Wed Mar 19 18:11:49 2014 +0200 IB/mlx4_ib: Adapt code to use caps.num_ports instead of a constant Some code in the mlx4 IB driver stack assumed MLX4_MAX_PORTS ports. Instead, we should only loop until the number of actual ports in i the device, which is stored in dev->caps.num_ports. Signed-off-by: Matan Barak <[email protected]> Signed-off-by: Or Gerlitz <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 8798998c2cdbc0df3c64e8845c1502ed93ef1ebd Author: Fabio Estevam <[email protected]> Date: Wed Mar 19 11:22:06 2014 -0300 smsc911x: Change clock warning message to debug level Since passing the clock is not mandatory, change the warning message to debug, so that we avoid getting the following clock failure message on every boot: smsc911x: Driver version 2008-10-21 smsc911x smsc911x (unregistered net_device): couldn't get clock -2 libphy: smsc911x-mdio: probed Signed-off-by: Fabio Estevam <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit e35bad5d876dc7b0bfd794a3ba328a442bd970e0 Author: Daniel Baluta <[email protected]> Date: Wed Mar 19 15:58:25 2014 +0200 net: remove empty lines from tcp_syn_flood_action Signed-off-by: Daniel Baluta <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 1aa9c483d1be13831bc4e516ce4848d32ac3e944 Author: Sachin Kamat <[email protected]> Date: Fri Mar 21 04:49:03 2014 +0900 ARM: EXYNOS: Remove hardware.h file This is a dummy placeholder file. Delete it. Signed-off-by: Sachin Kamat <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 2bb1ad17d66da3549eb4d23e264786a98f9ab17b Author: Sachin Kamat <[email protected]> Date: Fri Mar 21 04:48:59 2014 +0900 ARM: SAMSUNG: Remove hardware.h inclusion The contents of this header file are not referenced anywhere in the included .c files except in devs.c. Remove its inclusion. For devs.c, explicitly include sizes.h header for SZ_* macros. Signed-off-by: Sachin Kamat <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 144bf7b0a96e28266c6b2f47a6e04c7a4e4b3aa4 Author: Sachin Kamat <[email protected]> Date: Fri Mar 21 04:48:07 2014 +0900 ARM: S3C24XX: Remove invalid code from hardware.h Remove the code that is not referenced anywhere. While at it also remove incorrect file path. Signed-off-by: Sachin Kamat <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 676141e48af7463717896352e69c10f945ac22dd Author: Jens Axboe <[email protected]> Date: Thu Mar 20 13:29:18 2014 -0600 blk-mq: don't dump CPU -> hw queue map on driver load Now that we are out of initial debug/bringup mode, remove the verbose dump of the mapping table. Provide the mapping table in sysfs, under the hardware queue directory, in the cpu_list file. Signed-off-by: Jens Axboe <[email protected]> commit 602408e3de70d132c115670a366f4c5ae657080c Author: Tushar Behera <[email protected]> Date: Fri Mar 21 04:31:30 2014 +0900 dt-bindings: clock: Move exynos-audss-clk.h to dt-bindings/clock Most of the clock related dt-binding header files are located in dt-bindings/clock folder. It would be good to keep all the similar header files at a single location. Signed-off-by: Tushar Behera <[email protected]> Reviewed-by: Sachin Kamat <[email protected]> Acked-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 55ace6b285d7350d5b562ba065656c8242629a32 Author: Tushar Behera <[email protected]> Date: Fri Mar 21 04:26:40 2014 +0900 ARM: dts: Keep some essential LDOs enabled for arndale-octa board LDO3 and LDO23 need to be enabled in order for soft-reset to work. Additionally LDO9 needs to be enabled for USB operations. Signed-off-by: Tushar Behera <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 3da355c03a44bc45f3688bb68b51eefa738d1857 Author: Tushar Behera <[email protected]> Date: Fri Mar 21 04:26:40 2014 +0900 ARM: dts: Disable MDMA1 node for arndale-octa board MDMA1 can support both secure and non-secure AXI transactions. When this is enabled in the kernel for boards that run in secure mode, we get imprecise external aborts causing the kernel to oops. Unhandled fault: imprecise external abort (0x1406) at 0x00000000 Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000007 Suggested-by: Javi Merino <[email protected]> Signed-off-by: Tushar Behera <[email protected]> Tested-by: Javi Merino <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit e1a9d00c689a5da2d1baf273891507c5fb063f4c Author: Mark Brown <[email protected]> Date: Fri Mar 21 02:57:18 2014 +0900 ARM: S3C64XX: Fix build for implicit serial_s3c.h inclusion Some very recent change appears to have removed an implicit inclusion of serial_s3c.h causing build failures due to references to UART registers in the serial port restore code in next-20140318. Include it explicitly to fix the build. Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit cf559ab94e058df65c841b4afc8d5346fdda19b3 Author: Mark Brown <[email protected]> Date: Fri Mar 21 02:55:11 2014 +0900 serial: s3c: Fix build of header without serial_core.h preinclusion serial_s3c.h uses upf_t which is defined in serial_core.h but does not include that itself meaning that users which include serial_s3c.h by itself don't build. Signed-off-by: Mark Brown <[email protected]> [t.figa: Moved inclusion under #ifndef __ASSEMBLY__ to fix mach-exynos] Signed-off-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit dd8ac696b20c1be5ca4728045df10e882e01e91d Author: Tomasz Figa <[email protected]> Date: Tue Mar 18 07:28:30 2014 +0900 ARM: EXYNOS: Allow wake-up using GIC interrupts This patch restores the ability to receive wake-up events from internal GIC interrupts, e.g. RTC tick or alarm interrupts. Signed-off-by: Tomasz Figa <[email protected]> Acked-by: Kyungmin Park <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit d710aa31874e2ff6e656dbd4807f4bd8d659eb93 Author: Tomasz Figa <[email protected]> Date: Tue Mar 18 07:28:27 2014 +0900 ARM: EXYNOS: Stop using legacy Samsung PM code Since Exynos SoCs does not follow most of the semantics of older SoCs when configuring the system to enter sleep, there is no reason to rely on the legacy Samsung PM core anymore. This patch adds local Exynos suspend ops and removes all the code left unnecessary. As a side effect, suspend support on Exynos becomes multiplatform-friendly. Signed-off-by: Tomasz Figa <[email protected]> Acked-by: Kyungmin Park <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 559ba237999d723ccba5b4a75cf6b280bac1ab21 Author: Tomasz Figa <[email protected]> Date: Tue Mar 18 07:28:22 2014 +0900 ARM: EXYNOS: Remove PM initcalls and useless indirection This patch simplifies Exynos PM initialization and makes it multiplatform friendly by replacing initcalls used originally to invoke all the initialization code with explicit function calls. In addition, an useless subsys_interface is removed, as all its .add_dev callback did was setting two function pointers. Signed-off-by: Tomasz Figa <[email protected]> Acked-by: Kyungmin Park <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit dbc5ca163dc46153a8e5249da627af571ae47c10 Author: Tomasz Figa <[email protected]> Date: Tue Mar 18 07:28:10 2014 +0900 ARM: EXYNOS: Fix abuse of CONFIG_PM CONFIG_PM means that at least one of CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME is enabled, while multiple entries in mach-exynos/Kconfig abused it to enable sleep- and runtime-specific functionality. This patch fixes this abuse by replacing dependencies on CONFIG_PM with appropriate dependencies on either CONFIG_PM_SLEEP or CONFIG_PM_RUNTIME, whichever is appropriate. Signed-off-by: Tomasz Figa <[email protected]> Acked-by: Kyungmin Park <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit f682426630c620a2b8ae488a4f0d85ec6c272d66 Author: Tomasz Figa <[email protected]> Date: Tue Mar 18 07:28:10 2014 +0900 ARM: SAMSUNG: Move s3c_pm_check_* prototypes to plat/pm-common.h To allow using Samsung PM memory check helpers on platforms that do not use the legacy Samsung PM core, this patch moves prototypes of relevant functions to plat/pm-common.h header. Signed-off-by: Tomasz Figa <[email protected]> Acked-by: Kyungmin Park <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit b27899178c53226a5ff780a17657c84eb5e32338 Author: Tomasz Figa <[email protected]> Date: Tue Mar 18 07:28:10 2014 +0900 ARM: SAMSUNG: Move common save/restore helpers to separate file To separate legacy PM code from generic helpers, this patch moves the generic register save/restore helpers to a new file called pm-common.c that is compiled always when CONFIG_PM_SLEEP is enabled, to allow platforms that do not want to use the legacy PM code use the generic helpers. Signed-off-by: Tomasz Figa <[email protected]> Acked-by: Kyungmin Park <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 72551f6cf13e2f3a1d273b7007b5d7d7fd69c554 Author: Tomasz Figa <[email protected]> Date: Tue Mar 18 07:28:09 2014 +0900 ARM: SAMSUNG: Move Samsung PM debug code into separate file Not all Samsung SoC platforms are going to use the legacy Samsung PM code enabled by CONFIG_SAMSUNG_PM_DEBUG. To allow using Samsung PM debug helpers on such platforms, related code is moved to separate file and a plat/pm-common.h header is added to separate legacy and generic code. Signed-off-by: Tomasz Figa <[email protected]> Acked-by: Kyungmin Park <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit d38688a69fd88269eae3c7c66ec34fb02fb04fd1 Author: Tomasz Figa <[email protected]> Date: Tue Mar 18 07:28:09 2014 +0900 ARM: SAMSUNG: Consolidate PM debug functions This patch removes one-line functions that was used just to pass constant arguments to lower level functions. After previous patches the need for those constants has been eliminated, so the main functions can be called directly. Signed-off-by: Tomasz Figa <[email protected]> Acked-by: Kyungmin Park <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 99b2fc2b8b40256538332769f11f2fe6ee942f6c Author: Tomasz Figa <[email protected]> Date: Tue Mar 18 07:28:09 2014 +0900 ARM: SAMSUNG: Use debug_ll_addr() to get UART base address This patch modifies Samsung PM debug helpers to use a multiplatform friendly way of getting base address of debug UART port, so instead of using a per-mach static macro, a generic debug_ll_addr() helper is used. Signed-off-by: Tomasz Figa <[email protected]> Acked-by: Kyungmin Park <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit de7fe0807c08553b88028d039861a4b8ad04fc62 Author: Tomasz Figa <[email protected]> Date: Tue Mar 18 07:28:09 2014 +0900 ARM: SAMSUNG: Save UART DIVSLOT register based on SoC type The only SoC that does not have DIVSLOT register is S3C2410, so instead of exporting a variable for platforms to set if DIVSLOT register should be preserved, it's enough to simply check whether we are running on a S3C2410 instead. Signed-off-by: Tomasz Figa <[email protected]> Acked-by: Kyungmin Park <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 04241069617d4f0bfd9f4a3aeefae13e1e5b55e1 Author: Tomasz Figa <[email protected]> Date: Tue Mar 18 07:28:09 2014 +0900 ARM: SAMSUNG: Add soc_is_s3c2410() helper Due to the S3C2410 SoC being quite different from other S3C24xx SoCs in some aspects, such as availability of DIVSLOT register in its UART blocks, there is a need sometimes to check whether we are running on this SoC, not just the S3C24xx series. This patch adds soc_is_s3c2410() helper function for this purpose. Signed-off-by: Tomasz Figa <[email protected]> Acked-by: Kyungmin Park <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 61557b8bac9c80a5c14d237d420c246703e5c2e2 Author: Tomasz Figa <[email protected]> Date: Tue Mar 18 07:28:09 2014 +0900 ARM: EXYNOS: Do not resume l2x0 if not enabled before suspend Trying to resume l2x0 if it was not enabled before suspend leads to system crash. This patch prevents this by checking if l2x0_regs_phys is a valid pointer to l2x0 context data saved on initialization. Signed-off-by: Tomasz Figa <[email protected]> Acked-by: Kyungmin Park <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 56981fbc1b044cb140f70279deb736b6ae8664fb Author: Mike Snitzer <[email protected]> Date: Thu Mar 20 10:11:15 2014 -0400 dm cache: prevent corruption caused by discard_block_size > cache_block_size If the discard block size is larger than the cache block size we will not properly quiesce IO to a region that is about to be discarded. This results in a race between a cache migration where no copy is needed, and a write to an adjacent cache block that's within the same large discard block. Workaround this by limiting the discard_block_size to cache_block_size. Also limit the max_discard_sectors to cache_block_size. A more comprehensive fix that introduces range locking support in the bio_prison and proper quiescing of a discard range that spans multiple cache blocks is already in development. Reported-by: Morgan Mears <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Acked-by: Joe Thornber <[email protected]> Acked-by: Heinz Mauelshagen <[email protected]> Cc: [email protected] commit 88050049e7111f074e8887ba5a4cefc9f8fa8d41 Author: stephen hemminger <[email protected]> Date: Wed Mar 19 21:54:20 2014 -0700 netlink: fix setsockopt in mmap examples in documentation The documentation for how to use netlink mmap interface is incorrect. The calls to setsockopt() require an additional argument. Signed-off-by: Stephen Hemminger <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit f9b8c4c8baded129535d82d74df8e87a7a369f54 Author: Ben Pfaff <[email protected]> Date: Thu Mar 20 10:45:21 2014 -0700 openvswitch: Correctly report flow used times for first 5 minutes after boot. The kernel starts out its "jiffies" timer as 5 minutes below zero, as shown in include/linux/jiffies.h: /* * Have the 32 bit jiffies value wrap 5 minutes after boot * so jiffies wrap bugs show up earlier. */ #define INITIAL_JIFFIES ((unsigned long)(unsigned int) (-300*HZ)) The loop in ovs_flow_stats_get() starts out with 'used' set to 0, then takes any "later" time. This means that for the first five minutes after boot, flows will always be reported as never used, since 0 is greater than any time already seen. Signed-off-by: Ben Pfaff <[email protected]> Acked-by: Pravin B Shelar <[email protected]> Signed-off-by: Jesse Gross <[email protected]> commit 494314c415e2d3b308f57c9245ae6525166c70b8 Author: Trond Myklebust <[email protected]> Date: Thu Mar 20 12:59:09 2014 -0400 SUNRPC: rpc_restart_call/rpc_restart_call_prepare should clear task->tk_status When restarting an rpc call, we should not be carrying over data from the previous call. Signed-off-by: Trond Myklebust <[email protected]> commit 6bd144160a5554e4af052c153a094c4851a4c6aa Author: Trond Myklebust <[email protected]> Date: Thu Mar 20 12:53:54 2014 -0400 SUNRPC: Don't let rpc_delay() clobber non-timeout errors Signed-off-by: Trond Myklebust <[email protected]> commit d614f6d0bed7fa5a795708a6dc334370e1ca7951 Author: Yan Burman <[email protected]> Date: Tue Mar 11 14:41:47 2014 +0200 IB/mad: Check and handle potential DMA mapping errors Running with DMA_API_DEBUG enabled and not checking for DMA mapping errors triggers a kernel stack trace with "DMA-API: device driver failed to check map error" message. Add these checks to the MAD module, both to be be more robust and also eliminate these false-positive stack traces. Signed-off-by: Yan Burman <[email protected]> Signed-off-by: Or Gerlitz <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit 76cf9cbb68f3234f54c0a12bde6372911157c650 Author: Selvin Xavier <[email protected]> Date: Tue Mar 18 14:54:56 2014 +0530 RDMA/ocrdma: Unregister inet notifier when unloading ocrdma Unregister the inet notifier during ocrdma unload to avoid a panic after driver unload. Signed-off-by: Selvin Xavier <[email protected]> Signed-off-by: Devesh Sharma <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit 186f8ba062f796221d51077342f3ba5202838e9f Author: Dan Carpenter <[email protected]> Date: Thu Jan 30 15:12:31 2014 +0300 IB/qib: Cleanup qib_register_observer() Returning directly is easier to read than do-nothing gotos. Remove the duplicative check on "olp" and pull the code in one indent level. Signed-off-by: Dan Carpenter <[email protected]> Acked-by: Mike Marciniszyn <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit 49c0e2414b20d868cf006addf14152570aef2605 Author: CQ Tang <[email protected]> Date: Thu Jan 30 17:36:00 2014 -0500 IB/qib: Change SDMA progression mode depending on single- or multi-rail Improve performance by changing the behavour of the driver when all SDMA descriptors are in use, and the processes adding new descriptors are single- or multi-rail. For single-rail processes, the driver will block the call and finish posting all SDMA descriptors onto the hardware queue before returning back to PSM. Repeated kernel calls are slower than blocking. For multi-rail processes, the driver will return to PSM as quick as possible so PSM can feed packets to other rail. If all hardware queues are full, PSM will buffer the remaining SDMA descriptors until notified by interrupt that space is available. This patch builds a red-black tree to track the number rails opened by a particular PID. If the number is more than one, it is a multi-rail PSM process, otherwise, it is a single-rail process. Reviewed-by: Dean Luick <[email protected]> Reviewed-by: John A Gregor <[email protected]> Reviewed-by: Mitko Haralanov <[email protected]> Signed-off-by: CQ Tang <[email protected]> Signed-off-by: Mike Marciniszyn <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit 8307281a5bceaaaa1566897dc0b57cdb62413ae8 Author: Roland Dreier <[email protected]> Date: Mon Mar 17 23:14:17 2014 -0700 RDMA/ocrdma: Fix warnings about pointer <-> integer casts We should cast pointers to and from unsigned long to turn them into ints. Signed-off-by: Roland Dreier <[email protected]> commit 0d3a1e7e317b06d87b92011c62a5061f299820b9 Author: Devesh Sharma <[email protected]> Date: Tue Feb 4 11:57:10 2014 +0530 RDMA/ocrdma: Code clean-up Clean up code. Also modifying GSI QP to error during ocrdma_close is fixed. Signed-off-by: Devesh Sharma <[email protected]> Signed-off-by: Selvin Xavier <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit 9a31758308df672713ea0db9a9eff7c3cb348bc2 Author: Selvin Xavier <[email protected]> Date: Tue Feb 4 11:57:09 2014 +0530 RDMA/ocrdma: Display FW version Adding a sysfs file for getting the FW version. Signed-off-by: Selvin Xavier <[email protected]> Signed-off-by: Devesh Sharma <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit babe6b9ce0bdf964624435382a67c09f668bcab0 Author: Selvin Xavier <[email protected]> Date: Tue Feb 4 11:57:07 2014 +0530 RDMA/ocrdma: Query controller information Issue mailbox commands to query ocrdma controller information and phy information and print them while adding ocrdma device. Signed-off-by: Selvin Xavier <[email protected]> Signed-off-by: Devesh Sharma <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit 8bdb31b4d1931a32264fbe4651e607eb72941ff0 Author: Sachin Kamat <[email protected]> Date: Fri Mar 21 02:17:22 2014 +0900 ARM: dts: Update Exynos DT files with generic compatible strings Add generic compatible strings to the respective board DT files. Signed-off-by: Sachin Kamat <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 4868123ceb6ef0d4fa04e3211a0f4cd948f418f9 Author: Sachin Kamat <[email protected]> Date: Fri Mar 21 02:14:59 2014 +0900 ARM: EXYNOS: Add generic compatible strings Add generic compatible strings for Exynos4 and 5 platforms so that future SoCs can use them if there is nothing extra/specific to be differentiated. Signed-off-by: Sachin Kamat <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit cbf08b9ebdfc75bb13ef80ad3b8e3bea46d8c43a Author: Sachin Kamat <[email protected]> Date: Fri Mar 21 02:14:30 2014 +0900 ARM: EXYNOS: Consolidate exynos4 and exynos5 machine files Since there is very little difference between these two files, they can be easily combined into one with necessary SoC checks. While at it also merge the common.c file into this as it does not have any other users. Signed-off-by: Sachin Kamat <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 6eb84669cf7e94214593f162d4c1cf20424dd906 Author: Sachin Kamat <[email protected]> Date: Fri Mar 21 02:09:39 2014 +0900 ARM: EXYNOS: Consolidate CPU init code cpu_table was used to distinguish between different Exynos4 and 5 SoCs and based on the type do the initialization and io mapping. exynos_init is dummy and no longer needed as we do a DT based booting. By having a common io mapping function we can get rid of the whole table and avoid populating it for every SoC. Tested on Exynos4210, 5250 and 5420 based boards. Signed-off-by: Sachin Kamat <[email protected]> Tested-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 7bd03c0ebe54db94f20cd7577b875d9d27e539a9 Author: Selvin Xavier <[email protected]> Date: Tue Feb 4 11:57:06 2014 +0530 RDMA/ocrdma: Support non-embedded mailbox commands Added a routine to issue non-embedded mailbox commands for handling large mailbox request/response data. Signed-off-by: Selvin Xavier <[email protected]> Signed-off-by: Devesh Sharma <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit a1b8aff87d5f27022e6c14c43bf43226e75d2745 Author: Selvin Xavier <[email protected]> Date: Tue Feb 4 11:57:05 2014 +0530 RDMA/ocrdma: Handle CQ overrun error Signed-off-by: Selvin Xavier <[email protected]> Signed-off-by: Devesh Sharma <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit 23631e15a7f3c01a1ebb34f2c176f658c27eb949 Author: Selvin Xavier <[email protected]> Date: Tue Feb 4 11:57:04 2014 +0530 RDMA/ocrdma: Display proper value for max_mw Signed-off-by: Selvin Xavier <[email protected]> Signed-off-by: Devesh Sharma <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit c0e19755d56142b026b07b8020273301c8ed42bb Author: Selvin Xavier <[email protected]> Date: Tue Feb 4 11:57:03 2014 +0530 RDMA/ocrdma: Use non-zero tag in SRQ posting As part of SRQ receive buffers posting we populate a non-zero tag which will be returned in SRQ receive completions. Signed-off-by: Selvin Xavier <[email protected]> Signed-off-by: Devesh Sharma <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit def4eb8e5eacdfbc4788a6cb1bc0a3f118b5b349 Author: Selvin Xavier <[email protected]> Date: Tue Feb 4 11:57:02 2014 +0530 RDMA/ocrdma: Memory leak fix in ocrdma_dereg_mr() Signed-off-by: Selvin Xavier <[email protected]> Signed-off-by: Devesh Sharma <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit 0f4d45e0845e63e54aeaf5a7444b8ef4b77e4895 Author: [email protected] <[email protected]> Date: Tue Feb 4 11:57:01 2014 +0530 RDMA/ocrdma: Increment abi version count Increment the ABI version count for driver/library interface. Signed-off-by: Devesh Sharma <[email protected]> Signed-off-by: Selvin Xavier <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit 5b5eb9421408080b46ce14210ca717714859dee4 Author: [email protected] <[email protected]> Date: Tue Feb 4 11:57:00 2014 +0530 RDMA/ocrdma: Update version string Update the driver vrsion string and node description string Signed-off-by: Devesh Sharma <[email protected]> Signed-off-by: Selvin Xavier <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit 91b3140a692e87733367521efdd24f9a3532889a Author: [email protected] <[email protected]> Date: Tue Feb 4 11:56:59 2014 +0530 be2net: Add abi version between be2net and ocrdma This patch adds abi versioning between be2net and ocrdma driver modules to catch functional incompatibilities in the two drivers. Signed-off-by: Devesh Sharma <[email protected]> Signed-off-by: Selvin Xavier <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit 973ce6ce272d2c79f7eb1094ec26c25d1d8b4b32 Author: [email protected] <[email protected]> Date: Tue Feb 4 11:56:58 2014 +0530 RDMA/ocrdma: ABI versioning between ocrdma and be2net While loading RoCE driver be2net driver should check for ABI version to catch functional incompatibilities. Signed-off-by: Devesh Sharma <[email protected]> Signed-off-by: Selvin Xavier <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit db84035babf25f81be2a548f9332553b3a62865f Author: [email protected] <[email protected]> Date: Tue Feb 4 11:56:57 2014 +0530 RDMA/ocrdma: Allow DPP QP creation Allow creating DPP QP even if inline-data is not requested. This is an optimization to lower latency. Signed-off-by: Devesh Sharma <[email protected]> Signed-off-by: Selvin Xavier <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit d64c9414a4cc7c768d117ae035bf45cce760aeb5 Author: [email protected] <[email protected]> Date: Tue Feb 4 11:56:56 2014 +0530 RDMA/ocrdma: Read ASIC_ID register to select asic_gen ocrdma driver selects execution path based on sli_family and asic generation number. This introduces code to read the asic gen number from pci register instead of obtaining it from the Emulex NIC driver. Signed-off-by: Devesh Sharma <[email protected]> Signed-off-by: Selvin Xavier <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit da7d0e7699e6c5e3b076ba68680afe679e7379f0 Author: Devesh Sharma <[email protected]> Date: Tue Feb 4 11:56:55 2014 +0530 RDMA/ocrdma: SQ and RQ doorbell offset clean up Introducing new macros to define SQ and RQ doorbell offset. Signed-off-by: Devesh Sharma <[email protected]> Signed-off-by: Selvin Xavier <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit 1dbf741320af98620593c9a1d7481dd8b37f53fe Author: [email protected] <[email protected]> Date: Tue Feb 4 11:56:54 2014 +0530 RDMA/ocrdma: EQ full catastrophe avoidance Stale entries in the CQ being destroyed causes hardware to generate EQEs indefinitely for a given CQ. Thus causing uncontrolled execution of irq_handler. This patch fixes this using following sementics: * irq_handler will ring EQ doorbell atleast once and implement budgeting scheme. * cq_destroy will count number of valid entires during destroy and ring cq-db so that hardware does not generate uncontrolled EQE. * cq_destroy will synchronize with last running irq_handler instance. * arm_cq will always defer arming CQ till poll_cq, except for the first arm_cq call. * poll_cq will always ring cq-db with arm=SET if arm_cq was called prior to enter poll_cq. * poll_cq will always ring cq-db with arm=UNSET if arm_cq was not called prior to enter poll_cq. Signed-off-by: Devesh Sharma <[email protected]> Signed-off-by: Selvin Xavier <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit eda6d1d1b7932f90d55583f8f3835dd7d6b32543 Author: Steve Wise <[email protected]> Date: Wed Mar 19 17:44:45 2014 +0530 RDMA/cxgb4: Save the correct map length for fast_reg_page_lists We cannot save the mapped length using the rdma max_page_list_len field of the ib_fast_reg_page_list struct because the core code uses it. This results in an incorrect unmap of the page list in c4iw_free_fastreg_pbl(). I found this with dma mapping debugging enabled in the kernel. The fix is to save the length in the c4iw_fr_page_list struct. Signed-off-by: Steve Wise <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit df2d5130ece9118591c2f3fbf0ee4a79183b4ccc Author: Steve Wise <[email protected]> Date: Wed Mar 19 17:44:44 2014 +0530 RDMA/cxgb4: Default peer2peer mode to 1 Signed-off-by: Steve Wise <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit ba32de9d8d8173a1d6dd1ed608c519d5d0a623bb Author: Steve Wise <[email protected]> Date: Wed Mar 19 17:44:43 2014 +0530 RDMA/cxgb4: Mind the sq_sig_all/sq_sig_type QP attributes Signed-off-by: Steve Wise <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit 8a9c399eeee8c2d99e22b975f6023001a1fde88f Author: Steve Wise <[email protected]> Date: Wed Mar 19 17:44:42 2014 +0530 RDMA/cxgb4: Fix incorrect BUG_ON conditions Based on original work from Jay Hernandez <[email protected]> Signed-off-by: Steve Wise <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit 58553078c1feb40e0a02d7c72ae41dd6b923f231 Author: Sachin Kamat <[email protected]> Date: Fri Mar 21 02:00:21 2014 +0900 ARM: SAMSUNG: Introduce generic Exynos4 and 5 helpers Add helpers to check for Exynos4 and 5 family of SoCs. This will eliminate comparing long list of SoCs and make code simpler. Signed-off-by: Sachin Kamat <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 7ed30015007c32c006783526dc54a2a88bd5e13b Author: Sachin Kamat <[email protected]> Date: Fri Mar 21 01:52:56 2014 +0900 ARM: EXYNOS: Add support to reserve memory for MFC-v7 Reserve memory for MFC-v7 IP. Signed-off-by: Sachin Kamat <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit 8b3e8bbd132279be544a6f4dc22c22d244c98c23 Author: Tushar Behera <[email protected]> Date: Fri Mar 21 01:49:24 2014 +0900 ARM: SAMSUNG: Reorganize calls to reserve memory for MFC Reorganize code so that "plat/mfc.h" is no more referred from mach-exynos directory. Signed-off-by: Tushar Behera <[email protected]> Signed-off-by: Kukjin Kim <[email protected]> commit ebf00060c33b9d0946384fa6f440df7ea35a569e Author: Steve Wise <[email protected]> Date: Wed Mar 19 17:44:40 2014 +0530 RDMA/cxgb4: Always release neigh entry Always release the neigh entry in rx_pkt(). Based on original work by Santosh Rastapur <[email protected]>. Signed-off-by: Steve Wise <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit f8e819081f797df355cffbdedb9301ea50ae76b2 Author: Steve Wise <[email protected]> Date: Wed Mar 19 17:44:39 2014 +0530 RDMA/cxgb4: Allow loopback connections find_route() must treat loopback as a valid egress interface. Signed-off-by: Steve Wise <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit ffd435924c86de055d33fe59941841819eef9f6a Author: Steve Wise <[email protected]> Date: Wed Mar 19 17:44:38 2014 +0530 RDMA/cxgb4: Cap CQ size at T4_MAX_IQ_SIZE Signed-off-by: Steve Wise <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit e24a72a3302a638d4c6e77f0b40c45cc61c3f089 Author: Dan Carpenter <[email protected]> Date: Sat Oct 19 12:14:35 2013 +0300 RDMA/cxgb4: Fix four byte info leak in c4iw_create_cq() There is a four byte hole at the end of the "uresp" struct after the ->qid_mask member. Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit ff1706f4feb8e0e1a2e56a8dd57e17a4b45649b5 Author: Dan Carpenter <[email protected]> Date: Sat Oct 19 12:14:12 2013 +0300 RDMA/cxgb4: Fix underflows in c4iw_create_qp() These sizes should be unsigned so we don't allow negative values and have underflow bugs. These can come from the user so there may be security implications, but I have not tested this. Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Roland Dreier <[email protected]> commit 4726e0b045b80c514377da35ca01467ef6a4de53 Author: Sagar Kamble <[email protected]> Date: Mon Mar 10 17:06:23 2014 +0530 drm/i915: Enabling 128x128 and 256x256 ARGB Cursor Support With this patch we allow larger cursor planes of sizes 128x128 and 256x256. v2: Added more precise check on size while setting cursor plane. v3: Changes related to restructuring cursor size restrictions and DRM_DEBUG usage. v4: Indentation related changes for setting cursor control and implementing DRM_CAP_CURSOR_WIDTH and DRM_CAP_CURSOR_HEIGHT Testcase: igt/kms_cursor_crc Cc: Daniel Vetter <[email protected]> Cc: Jani Nikula <[email protected]> Cc: David Airlie <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: G, Pallavi <[email protected]> Signed-off-by: Sagar Kamble <[email protected]> Reviewed-by: Imre Deak <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> commit 61b1a7fbda6f761ebe16a62124578ca0779d9365 Author: Johan Hedberg <[email protected]> Date: Thu Mar 20 12:54:16 2014 +0200 Bluetooth: Fix address value for early disconnection events We need to ensure that we do not send events to user space with the identity address if we have not yet notified user space of the IRK. The code was previously trying to handle this for the mgmt_pair_device response (which worked well enough) but this is not the only connection related event that might be sent to user space before pairing is successful: another important event is Device Disconnected. The issue can actually be solved more simply than the solution previously used for mgmt_pair_device. Since we do have the identity address tracked as part of the remote IRK struct we can just copy it over from there to the hci_conn struct once we've for real sent the mgmt event for the new IRK. Signed-off-by: Johan Hedberg <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> commit 204747c970c0d568721c76ab8a57dde0e5dcf0d5 Author: Guenter Roeck <[email protected]> Date: Thu Mar 20 08:12:28 2014 -0700 mfd: kempld-core: Fix potential hang-up during boot On PXT and COMe-cPC2 boards it is observed that the hardware mutex is acquired but not being released during initialization. This can result in a hang-up during boot if the driver is built into the kernel. Releasing the mutex twice if it was acquired fixes the problem. Subsequent request/release cycles work as expected, so the fix is only needed during initialization. Cc: <[email protected]> Reviewed-by: Michael Brunner <[email protected]> Tested-by: Michael Brunner <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit 5a78401623740c892868d5929b33f5cda8fe819e Author: Krzysztof Kozlowski <[email protected]> Date: Tue Mar 18 14:11:26 2014 +0100 mfd: sec-core: Fix uninitialized 'regmap_rtc' on S2MPA01 Initialize the 'regmap_rtc' on S2MPA01 to some sane value. Sane at least for S5M87X chipsets, not S2MPS/S2MPA but it won't be used because rtc-s5m driver does not support S2MPA01. This fixes following error: drivers/mfd/sec-core.c:342:45: warning: ‘regmap_rtc’ may be used uninitialized in this function [-Wuninitialized] Signed-off-by: Krzysztof Kozlowski <[email protected]> Acked-by: Sachin Kamat <[email protected]> Signed-off-by: Lee Jones <[email protected]> commit 67b3bd4e65f0854aca70e0134d59b1daede49504 Author: Arend van Spriel <[email protected]> Date: Thu Mar 20 10:18:03 2014 +0100 brcmfmac: fallback to mimo_bw_cap for older firmwares In order to support the driver behaviour introduced by: commit d0575a5a703978c43e25128421158c78534ba100 Author: Daniel Kim <[email protected]> Date: Wed Mar 12 18:12:14 2014 -0700 brcmfmac: Enable 40MHz bandwidth in 2GHz band and OBSS scanning in devices that do not support bwcap firmware command a fallback is added. Reviewed-by: Daniel (Deognyoun) Kim <[email protected]> Reviewed-by: Pieter-Paul Giesberts <[email protected]> Signed-off-by: Arend van Spriel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 4d1a4f16c96d3f4cf6afd92ca3ffb4d2c24875e1 Author: Arend van Spriel <[email protected]> Date: Thu Mar 20 10:18:02 2014 +0100 brcmfmac: only show error message when brcmf_sdiod_regrw_helper() fails In the function brcmf_sdiod_request_data() an error message is logged, but the calling function retries it. This patch will only log an error message when retry limit is reached. The low-level error is still logged by a SDIO debug message. Reviewed-by: Daniel (Deognyoun) Kim <[email protected]> Reviewed-by: Pieter-Paul Giesberts <[email protected]> Signed-off-by: Arend van Spriel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 58e9df462fd70a1862378beb46b312f1f6bca94f Author: Arend van Spriel <[email protected]> Date: Thu Mar 20 10:18:01 2014 +0100 brcmfmac: reinit watchdog completion after handling watchdog The watchdog thread waits on completion that is set from a timer. As the completion is count based this could mean that on a busy system the watchdog is handled multiple times with a very short interval. This is not the intended behaviour. After handling the watchdog it should wait for the next timer expiry. This is accomplished by reinitializing the completion. Reviewed-by: Hante Meuleman <[email protected]> Reviewed-by: Pieter-Paul Giesberts <[email protected]> Signed-off-by: Arend van Spriel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit d23536796011cbeeb93fc866446800c52deb5603 Author: Daniel Kim <[email protected]> Date: Thu Mar 20 10:18:00 2014 +0100 brcmfmac: Enable 40MHz bandwidth in 2GHz band and OBSS scanning operations This patch enables 40MHz bandwidth in 2GHz band after checking whether cfg80211 allows it or not, and enables OBSS scanning operations to to support 20/40 BSS coexistence. Reviewed-by: Arend Van Spriel <[email protected]> Reviewed-by: Hante Meuleman <[email protected]> Reviewed-by: Pieter-Paul Giesberts <[email protected]> Signed-off-by: Daniel Kim <[email protected]> Signed-off-by: Arend van Spriel <[email protected]> Signed-off-by: John W. Linville <[email protected]> commit 1fa3e2eb9db07f30a605c66d1a2fdde4b24e74d5 Author: Steve Dickson <[email protected]> Date: Thu Mar 20 11:23:03 2014 -0400 SUNRPC: Ensure call_connect_status() deals correctly with SOFTCONN tasks Don't schedule an rpc_delay before checking to see if the task is a SOFTCONN because the tk_callback from the delay (__rpc_atrun) clears the task status before the rpc_exit_task can be run. Signed-off-by: Steve Dickson <[email protected]> Fixes: 561ec1603171c (SUNRPC: call_connect_status should recheck...) Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Trond Myklebust <[email protected]> commit f5b972e9fbd2e99a2abc3221783d089799b69394 Author: Heiko Carstens <[email protected]> Date: Thu Mar 20 15:30:14 2014 +0100 compat: include linux/unistd.h within linux/compat.h linux/compat.h does not include linux/unistd.h but the compat.h header file contains various conditional #ifdef __ARCH_WANT_COMPAT_... asmlinkage long compat...() #endif compat system call function declarations. If linux/unistd.h isn't included it depends on previous includes if those __ARCH_WANT_COMPAT_... defines are defined or not. So add an additional linux/unistd.h include. Should fix this compile error on tile: include/uapi/asm-generic/unistd.h:195:1: error: 'compat_sys_getdents64' undeclared make[3]: *** [arch/tile/kernel/compat.o] Error 1 Reported-by: Geert Uytterhoeven <[email protected]> Acked-by: Geert Uytterhoeven <[email protected]> Acked-by: Chris Metcalf <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> commit e1b2dc176f2d5be7952c47a4e4e8f3b06a90db1c Author: Tejun Heo <[email protected]> Date: Thu Mar 20 11:10:15 2014 -0400 cgroup: break kernfs active_ref protection in cgroup directory operations cgroup_tree_mutex should nest above the kernfs active_ref protection; however, cgroup_create() and cgroup_rename() were grabbing cgroup_tree_mutex while under kernfs active_ref protection. This has actualy possibility to lead to deadlocks in case these operations race against cgroup_rmdir() which invokes kernfs_remove() on directory kernfs_node while holding cgroup_tree_mutex. Neither cgroup_create() or cgroup_rename() requires active_ref protection. The former already has enough synchronization through cgroup_lock_live_group() and the latter doesn't care, so this can be fixed by updating both functions to break all active_ref protections before grabbing cgroup_tree_mutex. While this patch fixes the immediate issue, it probably needs further work in the long term - kernfs directories should enable lockdep annotations and maybe the better way to handle this is marking directory nodes as not needing active_ref protection rather than breaking it in each operation. Signed-off-by: Tejun Heo <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> commit 80e0b6e8a001361316a2d62b748fe677ec46b860 Author: Richard Guy Briggs <[email protected]> Date: Sun Mar 16 14:00:19 2014 -0400 sched: declare pid_alive as inline We accidentally declared pid_alive without any extern/inline connotation. Some platforms were fine with this, some like ia64 and mips were very angry. If the function is inline, the prototype should be inline! on ia64: include/linux/sched.h:1718: warning: 'pid_alive' declared inline after being called Signed-off-by: Richard Guy Briggs <[email protected]> Signed-off-by: Eric Paris <[email protected]> commit 579ec9e1ab0bdca2dbc3c942aa1a530a6ec8c349 Author: Eric Paris <[email protected]> Date: Tue Mar 11 12:55:42 2014 -0400 audit: use uapi/linux/audit.h for AUDIT_ARCH declarations The syscall.h headers were including linux/audit.h but really only needed the uapi/linux/audit.h to get the requisite defines. Switch to the uapi headers. Signed-off-by: Eric Paris <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] commit 5e937a9ae9137899c6641d718bd3820861099a09 Author: Eric Paris <[email protected]> Date: Tue Mar 11 12:48:43 2014 -0400 syscall_get_arch: remove useless function arguments Every caller of syscall_get_arch() uses current for the task and no implementors of the function need args. So just get rid of both of those things. Admittedly, since these are inline functions we aren't wasting stack space, but it just makes the prototypes better. Signed-off-by: Eric Paris <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] commit b7550787fe8b5beffb5f56fa11a87712d699d085 Author: Joe Perches <jo…
pstglia
pushed a commit
to pstglia/linux
that referenced
this pull request
Oct 6, 2014
The iommu_count field in si_domain(static identity domain) is initialized to zero and never increases. It will underflow when tearing down iommu unit in function free_dmar_iommu() and leak memory. So refine code to correctly manage si_domain->iommu_count. Warning message caused by si_domain memory leak: [ 14.609681] IOMMU: Setting RMRR: [ 14.613496] Ignoring identity map for HW passthrough device 0000:00:1a.0 [0xbdcfd000 - 0xbdd1dfff] [ 14.623809] Ignoring identity map for HW passthrough device 0000:00:1d.0 [0xbdcfd000 - 0xbdd1dfff] [ 14.634162] IOMMU: Prepare 0-16MiB unity mapping for LPC [ 14.640329] Ignoring identity map for HW passthrough device 0000:00:1f.0 [0x0 - 0xffffff] [ 14.673360] IOMMU: dmar init failed [ 14.678157] kmem_cache_destroy iommu_devinfo: Slab cache still has objects [ 14.686076] CPU: 12 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-gerry+ torvalds#59 [ 14.694176] Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012 [ 14.707412] 0000000000000000 ffff88042dd33db0 ffffffff8156223d ffff880c2cc37c00 [ 14.716407] ffff88042dd33dc8 ffffffff811790b1 ffff880c2d3533b8 ffff88042dd33e00 [ 14.725468] ffffffff81dc7a6a ffffffff81b1e8e0 ffffffff81f84058 ffffffff81d8a711 [ 14.734464] Call Trace: [ 14.737453] [<ffffffff8156223d>] dump_stack+0x4d/0x66 [ 14.743430] [<ffffffff811790b1>] kmem_cache_destroy+0xf1/0x100 [ 14.750279] [<ffffffff81dc7a6a>] intel_iommu_init+0x122/0x56a [ 14.757035] [<ffffffff81d8a711>] ? iommu_setup+0x27d/0x27d [ 14.763491] [<ffffffff81d8a739>] pci_iommu_init+0x28/0x52 [ 14.769846] [<ffffffff81000342>] do_one_initcall+0x122/0x180 [ 14.776506] [<ffffffff81077738>] ? parse_args+0x1e8/0x320 [ 14.782866] [<ffffffff81d850e8>] kernel_init_freeable+0x1e1/0x26c [ 14.789994] [<ffffffff81d84833>] ? do_early_param+0x88/0x88 [ 14.796556] [<ffffffff8154ffc0>] ? rest_init+0xd0/0xd0 [ 14.802626] [<ffffffff8154ffce>] kernel_init+0xe/0x130 [ 14.808698] [<ffffffff815756ac>] ret_from_fork+0x7c/0xb0 [ 14.814963] [<ffffffff8154ffc0>] ? rest_init+0xd0/0xd0 [ 14.821640] kmem_cache_destroy iommu_domain: Slab cache still has objects [ 14.829456] CPU: 12 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-gerry+ torvalds#59 [ 14.837562] Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012 [ 14.850803] 0000000000000000 ffff88042dd33db0 ffffffff8156223d ffff88102c1ee3c0 [ 14.861222] ffff88042dd33dc8 ffffffff811790b1 ffff880c2d3533b8 ffff88042dd33e00 [ 14.870284] ffffffff81dc7a76 ffffffff81b1e8e0 ffffffff81f84058 ffffffff81d8a711 [ 14.879271] Call Trace: [ 14.882227] [<ffffffff8156223d>] dump_stack+0x4d/0x66 [ 14.888197] [<ffffffff811790b1>] kmem_cache_destroy+0xf1/0x100 [ 14.895034] [<ffffffff81dc7a76>] intel_iommu_init+0x12e/0x56a [ 14.901781] [<ffffffff81d8a711>] ? iommu_setup+0x27d/0x27d [ 14.908238] [<ffffffff81d8a739>] pci_iommu_init+0x28/0x52 [ 14.914594] [<ffffffff81000342>] do_one_initcall+0x122/0x180 [ 14.921244] [<ffffffff81077738>] ? parse_args+0x1e8/0x320 [ 14.927598] [<ffffffff81d850e8>] kernel_init_freeable+0x1e1/0x26c [ 14.934738] [<ffffffff81d84833>] ? do_early_param+0x88/0x88 [ 14.941309] [<ffffffff8154ffc0>] ? rest_init+0xd0/0xd0 [ 14.947380] [<ffffffff8154ffce>] kernel_init+0xe/0x130 [ 14.953430] [<ffffffff815756ac>] ret_from_fork+0x7c/0xb0 [ 14.959689] [<ffffffff8154ffc0>] ? rest_init+0xd0/0xd0 [ 14.966299] kmem_cache_destroy iommu_iova: Slab cache still has objects [ 14.973923] CPU: 12 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-gerry+ torvalds#59 [ 14.982020] Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012 [ 14.995263] 0000000000000000 ffff88042dd33db0 ffffffff8156223d ffff88042cb5c980 [ 15.004265] ffff88042dd33dc8 ffffffff811790b1 ffff880c2d3533b8 ffff88042dd33e00 [ 15.013322] ffffffff81dc7a82 ffffffff81b1e8e0 ffffffff81f84058 ffffffff81d8a711 [ 15.022318] Call Trace: [ 15.025238] [<ffffffff8156223d>] dump_stack+0x4d/0x66 [ 15.031202] [<ffffffff811790b1>] kmem_cache_destroy+0xf1/0x100 [ 15.038038] [<ffffffff81dc7a82>] intel_iommu_init+0x13a/0x56a [ 15.044786] [<ffffffff81d8a711>] ? iommu_setup+0x27d/0x27d [ 15.051242] [<ffffffff81d8a739>] pci_iommu_init+0x28/0x52 [ 15.057601] [<ffffffff81000342>] do_one_initcall+0x122/0x180 [ 15.064254] [<ffffffff81077738>] ? parse_args+0x1e8/0x320 [ 15.070608] [<ffffffff81d850e8>] kernel_init_freeable+0x1e1/0x26c [ 15.077747] [<ffffffff81d84833>] ? do_early_param+0x88/0x88 [ 15.084300] [<ffffffff8154ffc0>] ? rest_init+0xd0/0xd0 [ 15.090362] [<ffffffff8154ffce>] kernel_init+0xe/0x130 [ 15.096431] [<ffffffff815756ac>] ret_from_fork+0x7c/0xb0 [ 15.102693] [<ffffffff8154ffc0>] ? rest_init+0xd0/0xd0 [ 15.189273] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) Signed-off-by: Jiang Liu <[email protected]> Cc: Alex Williamson <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
laodzu
pushed a commit
to laodzu/linux
that referenced
this pull request
May 22, 2015
If the system had a few memory groups and all of them were destroyed, memcg_limited_groups_array_size has non-zero value, but all new caches are created without memcg_params, because memcg_kmem_enabled() returns false. We try to enumirate child caches in a few places and all of them are potentially dangerous. For example my kernel is compiled with CONFIG_SLAB and it crashed when I tryed to mount a NFS share after a few experiments with kmemcg. BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: [<ffffffff8118166a>] do_tune_cpucache+0x8a/0xd0 PGD b942a067 PUD b999f067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: fscache(+) ip6table_filter ip6_tables iptable_filter ip_tables i2c_piix4 pcspkr virtio_net virtio_balloon i2c_core floppy CPU: 0 PID: 357 Comm: modprobe Not tainted 3.11.0-rc7+ torvalds#59 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 task: ffff8800b9f98240 ti: ffff8800ba32e000 task.ti: ffff8800ba32e000 RIP: 0010:[<ffffffff8118166a>] [<ffffffff8118166a>] do_tune_cpucache+0x8a/0xd0 RSP: 0018:ffff8800ba32fb70 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000000 RSI: ffff8800b9f98910 RDI: 0000000000000246 RBP: ffff8800ba32fba0 R08: 0000000000000002 R09: 0000000000000004 R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000010 R13: 0000000000000008 R14: 00000000000000d0 R15: ffff8800375d0200 FS: 00007f55f1378740(0000) GS:ffff8800bfa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007f24feba57a0 CR3: 0000000037b51000 CR4: 00000000000006f0 Call Trace: enable_cpucache+0x49/0x100 setup_cpu_cache+0x215/0x280 __kmem_cache_create+0x2fa/0x450 kmem_cache_create_memcg+0x214/0x350 kmem_cache_create+0x2b/0x30 fscache_init+0x19b/0x230 [fscache] do_one_initcall+0xfa/0x1b0 load_module+0x1c41/0x26d0 SyS_finit_module+0x86/0xb0 system_call_fastpath+0x16/0x1b Signed-off-by: Andrey Vagin <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: Glauber Costa <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
aejsmith
pushed a commit
to aejsmith/linux
that referenced
this pull request
Jul 29, 2015
Fix power off code
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Nov 5, 2015
dev_opp_list_lock is used everywhere to protect device and OPP lists,
but dev_pm_opp_set_sharing_cpus() is missed somehow. And instead we used
rcu-lock, which wouldn't help here as we are adding a new list_dev.
This also fixes a problem where we have called kzalloc(..., GFP_KERNEL)
from within rcu-lock, which isn't allowed as kzalloc can sleep when
called with GFP_KERNEL.
With CONFIG_DEBUG_ATOMIC_SLEEP set, we get following lockdep-splat:
include/linux/rcupdate.h:578 Illegal context switch in RCU read-side critical section!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
5 locks held by swapper/0/1:
#0: (&dev->mutex){......}, at: [<c02f68f4>] __driver_attach+0x48/0x98
#1: (&dev->mutex){......}, at: [<c02f6904>] __driver_attach+0x58/0x98
#2: (cpu_hotplug.lock){++++++}, at: [<c00249d0>] get_online_cpus+0x40/0xb0
#3: (subsys mutex#5){+.+.+.}, at: [<c02f4f8c>] subsys_interface_register+0x44/0xdc
#4: (rcu_read_lock){......}, at: [<c0305c80>] dev_pm_opp_set_sharing_cpus+0x0/0x1e4
stack backtrace:
CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.3.0-rc7-00047-g81f5932958a8 torvalds#59
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[<c0016874>] (unwind_backtrace) from [<c001355c>] (show_stack+0x10/0x14)
[<c001355c>] (show_stack) from [<c022553c>] (dump_stack+0x94/0xbc)
[<c022553c>] (dump_stack) from [<c004904c>] (___might_sleep+0x24c/0x298)
[<c004904c>] (___might_sleep) from [<c00f07e4>] (kmem_cache_alloc+0xe8/0x164)
[<c00f07e4>] (kmem_cache_alloc) from [<c0305354>] (_add_list_dev+0x30/0x58)
[<c0305354>] (_add_list_dev) from [<c0305d50>] (dev_pm_opp_set_sharing_cpus+0xd0/0x1e4)
[<c0305d50>] (dev_pm_opp_set_sharing_cpus) from [<c040eda4>] (cpufreq_init+0x4cc/0x62c)
[<c040eda4>] (cpufreq_init) from [<c040a964>] (cpufreq_online+0xbc/0x73c)
[<c040a964>] (cpufreq_online) from [<c02f4fe0>] (subsys_interface_register+0x98/0xdc)
[<c02f4fe0>] (subsys_interface_register) from [<c040a640>] (cpufreq_register_driver+0x110/0x17c)
[<c040a640>] (cpufreq_register_driver) from [<c040ef64>] (dt_cpufreq_probe+0x60/0x8c)
[<c040ef64>] (dt_cpufreq_probe) from [<c02f8084>] (platform_drv_probe+0x44/0xa4)
[<c02f8084>] (platform_drv_probe) from [<c02f67c0>] (driver_probe_device+0x208/0x2f4)
[<c02f67c0>] (driver_probe_device) from [<c02f6940>] (__driver_attach+0x94/0x98)
[<c02f6940>] (__driver_attach) from [<c02f4c1c>] (bus_for_each_dev+0x68/0x9c)
Cc: 4.3 <[email protected]> # 4.3
Reported-by: Michael Turquette <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Nov 7, 2015
dev_opp_list_lock is used everywhere to protect device and OPP lists,
but dev_pm_opp_set_sharing_cpus() is missed somehow. And instead we used
rcu-lock, which wouldn't help here as we are adding a new list_dev.
This also fixes a problem where we have called kzalloc(..., GFP_KERNEL)
from within rcu-lock, which isn't allowed as kzalloc can sleep when
called with GFP_KERNEL.
With CONFIG_DEBUG_ATOMIC_SLEEP set, we get following lockdep-splat:
include/linux/rcupdate.h:578 Illegal context switch in RCU read-side critical section!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
5 locks held by swapper/0/1:
#0: (&dev->mutex){......}, at: [<c02f68f4>] __driver_attach+0x48/0x98
#1: (&dev->mutex){......}, at: [<c02f6904>] __driver_attach+0x58/0x98
#2: (cpu_hotplug.lock){++++++}, at: [<c00249d0>] get_online_cpus+0x40/0xb0
#3: (subsys mutex#5){+.+.+.}, at: [<c02f4f8c>] subsys_interface_register+0x44/0xdc
#4: (rcu_read_lock){......}, at: [<c0305c80>] dev_pm_opp_set_sharing_cpus+0x0/0x1e4
stack backtrace:
CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.3.0-rc7-00047-g81f5932958a8 torvalds#59
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[<c0016874>] (unwind_backtrace) from [<c001355c>] (show_stack+0x10/0x14)
[<c001355c>] (show_stack) from [<c022553c>] (dump_stack+0x94/0xbc)
[<c022553c>] (dump_stack) from [<c004904c>] (___might_sleep+0x24c/0x298)
[<c004904c>] (___might_sleep) from [<c00f07e4>] (kmem_cache_alloc+0xe8/0x164)
[<c00f07e4>] (kmem_cache_alloc) from [<c0305354>] (_add_list_dev+0x30/0x58)
[<c0305354>] (_add_list_dev) from [<c0305d50>] (dev_pm_opp_set_sharing_cpus+0xd0/0x1e4)
[<c0305d50>] (dev_pm_opp_set_sharing_cpus) from [<c040eda4>] (cpufreq_init+0x4cc/0x62c)
[<c040eda4>] (cpufreq_init) from [<c040a964>] (cpufreq_online+0xbc/0x73c)
[<c040a964>] (cpufreq_online) from [<c02f4fe0>] (subsys_interface_register+0x98/0xdc)
[<c02f4fe0>] (subsys_interface_register) from [<c040a640>] (cpufreq_register_driver+0x110/0x17c)
[<c040a640>] (cpufreq_register_driver) from [<c040ef64>] (dt_cpufreq_probe+0x60/0x8c)
[<c040ef64>] (dt_cpufreq_probe) from [<c02f8084>] (platform_drv_probe+0x44/0xa4)
[<c02f8084>] (platform_drv_probe) from [<c02f67c0>] (driver_probe_device+0x208/0x2f4)
[<c02f67c0>] (driver_probe_device) from [<c02f6940>] (__driver_attach+0x94/0x98)
[<c02f6940>] (__driver_attach) from [<c02f4c1c>] (bus_for_each_dev+0x68/0x9c)
Reported-by: Michael Turquette <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Cc: 4.3 <[email protected]> # 4.3
Signed-off-by: Rafael J. Wysocki <[email protected]>
diaevd
referenced
this pull request
in diaevd/zen-kernel
Dec 30, 2015
exfat_upcase.c: mark uni_upcase table as "const".
sashalevin
pushed a commit
to sashalevin/linux-stable-security
that referenced
this pull request
Apr 29, 2016
commit 6f6b895 upstream. If the system had a few memory groups and all of them were destroyed, memcg_limited_groups_array_size has non-zero value, but all new caches are created without memcg_params, because memcg_kmem_enabled() returns false. We try to enumirate child caches in a few places and all of them are potentially dangerous. For example my kernel is compiled with CONFIG_SLAB and it crashed when I tryed to mount a NFS share after a few experiments with kmemcg. BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: [<ffffffff8118166a>] do_tune_cpucache+0x8a/0xd0 PGD b942a067 PUD b999f067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: fscache(+) ip6table_filter ip6_tables iptable_filter ip_tables i2c_piix4 pcspkr virtio_net virtio_balloon i2c_core floppy CPU: 0 PID: 357 Comm: modprobe Not tainted 3.11.0-rc7+ torvalds#59 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 task: ffff8800b9f98240 ti: ffff8800ba32e000 task.ti: ffff8800ba32e000 RIP: 0010:[<ffffffff8118166a>] [<ffffffff8118166a>] do_tune_cpucache+0x8a/0xd0 RSP: 0018:ffff8800ba32fb70 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000000 RSI: ffff8800b9f98910 RDI: 0000000000000246 RBP: ffff8800ba32fba0 R08: 0000000000000002 R09: 0000000000000004 R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000010 R13: 0000000000000008 R14: 00000000000000d0 R15: ffff8800375d0200 FS: 00007f55f1378740(0000) GS:ffff8800bfa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007f24feba57a0 CR3: 0000000037b51000 CR4: 00000000000006f0 Call Trace: enable_cpucache+0x49/0x100 setup_cpu_cache+0x215/0x280 __kmem_cache_create+0x2fa/0x450 kmem_cache_create_memcg+0x214/0x350 kmem_cache_create+0x2b/0x30 fscache_init+0x19b/0x230 [fscache] do_one_initcall+0xfa/0x1b0 load_module+0x1c41/0x26d0 SyS_finit_module+0x86/0xb0 system_call_fastpath+0x16/0x1b Signed-off-by: Andrey Vagin <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: Glauber Costa <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Johannes Weiner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jun 13, 2016
Move dma channel allocations to pcmops open and close functions. Reason to do this is that, lpass_platform_pcm_free() accesses snd_soc_pcm_runtime via substream->private data, However By this time runtimes are already freed as part of soc_cleanup_card_resources() sequence. This patch moves the channel allocations/deallocations to pcmops open() and close() respectively, where the code has valid snd_soc_pcm_runtime. Without this patch unloading lpass sound card module would result in below crash: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = ffff800038f0d000 [00000000] *pgd=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: snd_soc_apq8016_sbc(-) snd_soc_lpass_apq8016 snd_soc_lpass_cpu snd_soc_lpass_platform CPU: 0 PID: 1573 Comm: rmmod Not tainted 4.7.0-rc2-next-20160609+ torvalds#59 Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) task: ffff800038cd0000 ti: ffff80003929c000 task.ti: ffff80003929c000 PC is at lpass_platform_pcm_free+0xc4/0x1c0 [snd_soc_lpass_platform] LR is at lpass_platform_pcm_free+0xb8/0x1c0 [snd_soc_lpass_platform] pc : [<ffff000000b20b64>] lr : [<ffff000000b20b58>] pstate: 60000145 sp : ffff80003929fa90 x29: ffff80003929fa90 x28: ffff000000b22438 x27: ffff000000b22450 x26: ffff000000b22468 x25: ffff000000b22488 x24: ffff000000b223f0 x23: ffff000000b22418 x22: ffff800038f428c0 x21: ffff8000392ae280 x20: 0000000000000001 x19: ffff000000b22118 x18: 0000ffffdc331600 x17: 0000ffffb78036c0 x16: ffff0000081c16e8 x15: 0000ffffb77f0588 x14: 3d4d554e51455300 x13: ffffffffffff0000 x12: 0000000000000028 x11: 0000000000000044 x10: ffff80003929f822 x9 : ffff80003929f823 x8 : 0000000000000000 x7 : 0000000000000004 x6 : ffff000008864890 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff80003efac228 x1 : ffff000000b22118 x0 : ffff000000b22450 Process rmmod (pid: 1573, stack limit = 0xffff80003929c020) Stack: (0xffff80003929fa90 to 0xffff8000392a0000) fa80: ffff80003929fb40 ffff0000086d1f8c faa0: ffff000008ca5408 ffff800038f42200 ffff000008ca5420 000000000000000b fac0: ffff80003929fd70 0000000000000015 0000000000000120 000000000000006a fae0: ffff0000087f2000 ffff80003929c000 ffff80003929fb40 ffff8000392ae358 fb00: ffff8000392af900 0000000000000000 ffff8000392afa48 000000000000000b fb20: ffff80003929fd70 0000000000000015 ffff80003929fb80 ffff0000086cc070 fb40: ffff80003929fb70 ffff0000086d21d4 ffff800038f7fa00 ffff8000392801a0 fb60: ffff800038cf2000 0000000000000015 ffff80003929fb80 ffff0000086cc064 fb80: ffff80003929fba0 ffff0000086cc1f4 ffff800038f70600 000000000000000b fba0: ffff80003929fbc0 ffff0000086c68a8 ffff800039280000 ffff800039280540 fbc0: ffff80003929fbe0 ffff0000084a7438 ffff800039280540 ffff800039280550 fbe0: ffff80003929fc10 ffff000008355ddc ffff800039280550 ffff000008c64718 fc00: ffff800038f61d00 ffff000008ca5190 ffff80003929fc40 ffff000008355e5c fc20: ffff800039280550 ffff800039280000 ffff80003847b618 ffff800039280000 fc40: ffff80003929fc60 ffff0000084a77d8 0000000000000000 0000000000000015 fc60: ffff80003929fc70 ffff0000086c6e58 ffff80003929fc90 ffff0000086c6fbc fc80: ffff80003929fcb0 ffff800039280000 ffff80003929fcd0 ffff0000086e3e50 fca0: ffff80003847b050 ffff80003847b728 ffff800000000000 ffff000000000000 fcc0: ffff80003929fcc0 ffff80003929fcc0 ffff80003929fd00 ffff0000086e4c8c fce0: ffff80003847b618 ffff800038f61100 ffff8000399ddf90 000000000000000b fd00: ffff80003929fd20 ffff0000086f0684 ffff800038f61000 ffff0000080d51c0 fd20: ffff80003929fd30 ffff0000084af904 ffff80003929fd80 ffff0000084afcf8 fd40: ffff8000399ddf90 ffff000000b3c028 ffff8000399ddff0 ffff000008cc8000 fd60: 0000000080000000 ffff0000084ac090 ffff800038f94600 ffff800038f61000 fd80: ffff80003929fda0 ffff0000084ac0b0 ffff8000399ddf90 ffff000000b3c028 fda0: ffff80003929fdc0 ffff0000084ac234 ffff8000399ddf90 ffff000000b3c028 fdc0: ffff80003929fdf0 ffff0000084ab3d4 ffff000000b3c028 ffff000008c64000 fde0: ffff000008c64818 ffff000000000001 ffff80003929fe20 ffff0000084ac8ac fe00: ffff000000b3c028 ffff000000b3c100 fffffffffffffff5 0000000000000000 fe20: ffff80003929fe40 ffff0000084ad998 ffff000008c2d000 0000000000000015 fe40: ffff80003929fe50 ffff000000b3a460 ffff80003929fe60 ffff000008120fe4 fe60: 0000000000000000 ffff000008084e70 0000000000000000 0000000000000000 fe80: ffffffffffffffff 0000ffff954cca48 0000000000000004 5f636f735f646e73 fea0: 5f36313038717061 0000000000636273 0000000000000000 ffff000008084d64 fec0: 0000000000000000 0000000000000000 0000aaaabc814340 0000000000000800 fee0: 4fdc43dac03e2300 0000000000002002 0000ffff95548e58 0000ffffd9f89fb9 ff00: 0000000000000000 0000000000000000 000000000000006a 1999999999999999 ff20: 00000000ffffffff 0000000000000000 0000000000000005 ffffffffffffffff ff40: 0000ffff95402a94 0000ffff9554a588 0000ffff954cca40 0000aaaaaf8d22d0 ff60: 0000ffffd9f8ad70 0000aaaabc8142e0 0000000000000000 0000000000000000 ff80: 0000ffffd9f8be7c 0000000000000000 0000ffffd9f8b0e0 0000ffffd9f8b2b8 ffa0: 0000aaaabc8142e0 0000aaaabc813010 0000000000000000 0000ffffd9f8b010 ffc0: 0000aaaaaf8b5ad4 0000ffffd9f8b010 0000ffff954cca48 0000000080000000 ffe0: 0000aaaabc814340 000000000000006a 0000060000000000 00000000fffefcaf Call trace: Exception stack(0xffff80003929f8d0 to 0xffff80003929f9f0) f8c0: ffff000000b22118 00000000000001 f8e0: ffff80003929fa90 ffff000000b20b64 ffff80003929f910 ffff000008a12f40 f900: ffff000008c15b78 0000000100000001 ffff80003929f9b0 ffff0000080f66e0 f920: ffff000000b22118 0000000000000001 ffff8000392ae280 ffff800038f428c0 f940: ffff000000b22418 ffff000000b223f0 ffff000000b22488 ffff000000b22468 f960: ffff000000b22450 ffff000000b22438 ffff000000b22450 ffff000000b22118 f980: ffff80003efac228 0000000000000000 0000000000000000 0000000000000000 f9a0: ffff000008864890 0000000000000004 0000000000000000 ffff80003929f823 f9c0: ffff80003929f822 0000000000000044 0000000000000028 ffffffffffff0000 f9e0: 3d4d554e51455300 0000ffffb77f0588 [<ffff000000b20b64>] lpass_platform_pcm_free+0xc4/0x1c0 [snd_soc_lpass_platform] [<ffff0000086d1f8c>] snd_pcm_free+0x30/0xa0 [<ffff0000086d21d4>] snd_pcm_dev_free+0x10/0x18 [<ffff0000086cc064>] __snd_device_free+0x58/0xa0 [<ffff0000086cc1f4>] snd_device_free_all+0x2c/0x48 [<ffff0000086c68a8>] release_card_device+0x1c/0x74 [<ffff0000084a7438>] device_release+0x34/0x90 [<ffff000008355ddc>] kobject_release+0x44/0x84 [<ffff000008355e5c>] kobject_put+0x40/0x68 [<ffff0000084a77d8>] put_device+0x14/0x1c [<ffff0000086c6e58>] snd_card_free_when_closed+0x24/0x34 [<ffff0000086c6fbc>] snd_card_free+0x40/0x60 [<ffff0000086e3e50>] soc_cleanup_card_resources+0x80/0x94 [<ffff0000086e4c8c>] snd_soc_unregister_card+0x28/0x38 [<ffff0000086f0684>] devm_card_release+0x10/0x18 [<ffff0000084af904>] release_nodes+0x124/0x208 [<ffff0000084afcf8>] devres_release_all+0x34/0x54 [<ffff0000084ac0b0>] __device_release_driver+0x84/0xfc [<ffff0000084ac234>] driver_detach+0xbc/0xc0 [<ffff0000084ab3d4>] bus_remove_driver+0x58/0xac [<ffff0000084ac8ac>] driver_unregister+0x2c/0x4c [<ffff0000084ad998>] platform_driver_unregister+0x10/0x18 [<ffff000000b3a460>] apq8016_sbc_platform_driver_exit+0x10/0xbb0 [snd_soc_apq8016_sbc] [<ffff000008120fe4>] SyS_delete_module+0x1b8/0x1fc [<ffff000008084e70>] el0_svc_naked+0x24/0x28 Signed-off-by: Srinivas Kandagatla <[email protected]>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jun 14, 2016
Move dma channel allocations to pcmops open and close functions. Reason to do this is that, lpass_platform_pcm_free() accesses snd_soc_pcm_runtime via substream->private data, However By this time runtimes are already freed as part of soc_cleanup_card_resources() sequence. This patch moves the channel allocations/deallocations to pcmops open() and close() respectively, where the code has valid snd_soc_pcm_runtime. Without this patch unloading lpass sound card module would result in below crash: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = ffff800038f0d000 [00000000] *pgd=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: snd_soc_apq8016_sbc(-) snd_soc_lpass_apq8016 snd_soc_lpass_cpu snd_soc_lpass_platform CPU: 0 PID: 1573 Comm: rmmod Not tainted 4.7.0-rc2-next-20160609+ torvalds#59 Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) task: ffff800038cd0000 ti: ffff80003929c000 task.ti: ffff80003929c000 PC is at lpass_platform_pcm_free+0xc4/0x1c0 [snd_soc_lpass_platform] LR is at lpass_platform_pcm_free+0xb8/0x1c0 [snd_soc_lpass_platform] pc : [<ffff000000b20b64>] lr : [<ffff000000b20b58>] pstate: 60000145 sp : ffff80003929fa90 x29: ffff80003929fa90 x28: ffff000000b22438 x27: ffff000000b22450 x26: ffff000000b22468 x25: ffff000000b22488 x24: ffff000000b223f0 x23: ffff000000b22418 x22: ffff800038f428c0 x21: ffff8000392ae280 x20: 0000000000000001 x19: ffff000000b22118 x18: 0000ffffdc331600 x17: 0000ffffb78036c0 x16: ffff0000081c16e8 x15: 0000ffffb77f0588 x14: 3d4d554e51455300 x13: ffffffffffff0000 x12: 0000000000000028 x11: 0000000000000044 x10: ffff80003929f822 x9 : ffff80003929f823 x8 : 0000000000000000 x7 : 0000000000000004 x6 : ffff000008864890 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff80003efac228 x1 : ffff000000b22118 x0 : ffff000000b22450 Process rmmod (pid: 1573, stack limit = 0xffff80003929c020) Stack: (0xffff80003929fa90 to 0xffff8000392a0000) fa80: ffff80003929fb40 ffff0000086d1f8c faa0: ffff000008ca5408 ffff800038f42200 ffff000008ca5420 000000000000000b fac0: ffff80003929fd70 0000000000000015 0000000000000120 000000000000006a fae0: ffff0000087f2000 ffff80003929c000 ffff80003929fb40 ffff8000392ae358 fb00: ffff8000392af900 0000000000000000 ffff8000392afa48 000000000000000b fb20: ffff80003929fd70 0000000000000015 ffff80003929fb80 ffff0000086cc070 fb40: ffff80003929fb70 ffff0000086d21d4 ffff800038f7fa00 ffff8000392801a0 fb60: ffff800038cf2000 0000000000000015 ffff80003929fb80 ffff0000086cc064 fb80: ffff80003929fba0 ffff0000086cc1f4 ffff800038f70600 000000000000000b fba0: ffff80003929fbc0 ffff0000086c68a8 ffff800039280000 ffff800039280540 fbc0: ffff80003929fbe0 ffff0000084a7438 ffff800039280540 ffff800039280550 fbe0: ffff80003929fc10 ffff000008355ddc ffff800039280550 ffff000008c64718 fc00: ffff800038f61d00 ffff000008ca5190 ffff80003929fc40 ffff000008355e5c fc20: ffff800039280550 ffff800039280000 ffff80003847b618 ffff800039280000 fc40: ffff80003929fc60 ffff0000084a77d8 0000000000000000 0000000000000015 fc60: ffff80003929fc70 ffff0000086c6e58 ffff80003929fc90 ffff0000086c6fbc fc80: ffff80003929fcb0 ffff800039280000 ffff80003929fcd0 ffff0000086e3e50 fca0: ffff80003847b050 ffff80003847b728 ffff800000000000 ffff000000000000 fcc0: ffff80003929fcc0 ffff80003929fcc0 ffff80003929fd00 ffff0000086e4c8c fce0: ffff80003847b618 ffff800038f61100 ffff8000399ddf90 000000000000000b fd00: ffff80003929fd20 ffff0000086f0684 ffff800038f61000 ffff0000080d51c0 fd20: ffff80003929fd30 ffff0000084af904 ffff80003929fd80 ffff0000084afcf8 fd40: ffff8000399ddf90 ffff000000b3c028 ffff8000399ddff0 ffff000008cc8000 fd60: 0000000080000000 ffff0000084ac090 ffff800038f94600 ffff800038f61000 fd80: ffff80003929fda0 ffff0000084ac0b0 ffff8000399ddf90 ffff000000b3c028 fda0: ffff80003929fdc0 ffff0000084ac234 ffff8000399ddf90 ffff000000b3c028 fdc0: ffff80003929fdf0 ffff0000084ab3d4 ffff000000b3c028 ffff000008c64000 fde0: ffff000008c64818 ffff000000000001 ffff80003929fe20 ffff0000084ac8ac fe00: ffff000000b3c028 ffff000000b3c100 fffffffffffffff5 0000000000000000 fe20: ffff80003929fe40 ffff0000084ad998 ffff000008c2d000 0000000000000015 fe40: ffff80003929fe50 ffff000000b3a460 ffff80003929fe60 ffff000008120fe4 fe60: 0000000000000000 ffff000008084e70 0000000000000000 0000000000000000 fe80: ffffffffffffffff 0000ffff954cca48 0000000000000004 5f636f735f646e73 fea0: 5f36313038717061 0000000000636273 0000000000000000 ffff000008084d64 fec0: 0000000000000000 0000000000000000 0000aaaabc814340 0000000000000800 fee0: 4fdc43dac03e2300 0000000000002002 0000ffff95548e58 0000ffffd9f89fb9 ff00: 0000000000000000 0000000000000000 000000000000006a 1999999999999999 ff20: 00000000ffffffff 0000000000000000 0000000000000005 ffffffffffffffff ff40: 0000ffff95402a94 0000ffff9554a588 0000ffff954cca40 0000aaaaaf8d22d0 ff60: 0000ffffd9f8ad70 0000aaaabc8142e0 0000000000000000 0000000000000000 ff80: 0000ffffd9f8be7c 0000000000000000 0000ffffd9f8b0e0 0000ffffd9f8b2b8 ffa0: 0000aaaabc8142e0 0000aaaabc813010 0000000000000000 0000ffffd9f8b010 ffc0: 0000aaaaaf8b5ad4 0000ffffd9f8b010 0000ffff954cca48 0000000080000000 ffe0: 0000aaaabc814340 000000000000006a 0000060000000000 00000000fffefcaf Call trace: Exception stack(0xffff80003929f8d0 to 0xffff80003929f9f0) f8c0: ffff000000b22118 00000000000001 f8e0: ffff80003929fa90 ffff000000b20b64 ffff80003929f910 ffff000008a12f40 f900: ffff000008c15b78 0000000100000001 ffff80003929f9b0 ffff0000080f66e0 f920: ffff000000b22118 0000000000000001 ffff8000392ae280 ffff800038f428c0 f940: ffff000000b22418 ffff000000b223f0 ffff000000b22488 ffff000000b22468 f960: ffff000000b22450 ffff000000b22438 ffff000000b22450 ffff000000b22118 f980: ffff80003efac228 0000000000000000 0000000000000000 0000000000000000 f9a0: ffff000008864890 0000000000000004 0000000000000000 ffff80003929f823 f9c0: ffff80003929f822 0000000000000044 0000000000000028 ffffffffffff0000 f9e0: 3d4d554e51455300 0000ffffb77f0588 [<ffff000000b20b64>] lpass_platform_pcm_free+0xc4/0x1c0 [snd_soc_lpass_platform] [<ffff0000086d1f8c>] snd_pcm_free+0x30/0xa0 [<ffff0000086d21d4>] snd_pcm_dev_free+0x10/0x18 [<ffff0000086cc064>] __snd_device_free+0x58/0xa0 [<ffff0000086cc1f4>] snd_device_free_all+0x2c/0x48 [<ffff0000086c68a8>] release_card_device+0x1c/0x74 [<ffff0000084a7438>] device_release+0x34/0x90 [<ffff000008355ddc>] kobject_release+0x44/0x84 [<ffff000008355e5c>] kobject_put+0x40/0x68 [<ffff0000084a77d8>] put_device+0x14/0x1c [<ffff0000086c6e58>] snd_card_free_when_closed+0x24/0x34 [<ffff0000086c6fbc>] snd_card_free+0x40/0x60 [<ffff0000086e3e50>] soc_cleanup_card_resources+0x80/0x94 [<ffff0000086e4c8c>] snd_soc_unregister_card+0x28/0x38 [<ffff0000086f0684>] devm_card_release+0x10/0x18 [<ffff0000084af904>] release_nodes+0x124/0x208 [<ffff0000084afcf8>] devres_release_all+0x34/0x54 [<ffff0000084ac0b0>] __device_release_driver+0x84/0xfc [<ffff0000084ac234>] driver_detach+0xbc/0xc0 [<ffff0000084ab3d4>] bus_remove_driver+0x58/0xac [<ffff0000084ac8ac>] driver_unregister+0x2c/0x4c [<ffff0000084ad998>] platform_driver_unregister+0x10/0x18 [<ffff000000b3a460>] apq8016_sbc_platform_driver_exit+0x10/0xbb0 [snd_soc_apq8016_sbc] [<ffff000008120fe4>] SyS_delete_module+0x1b8/0x1fc [<ffff000008084e70>] el0_svc_naked+0x24/0x28 Signed-off-by: Srinivas Kandagatla <[email protected]>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jul 4, 2016
Move dma channel allocations to pcmops open and close functions. Reason to do this is that, lpass_platform_pcm_free() accesses snd_soc_pcm_runtime via substream->private data, However By this time runtimes are already freed as part of soc_cleanup_card_resources() sequence. This patch moves the channel allocations/deallocations to pcmops open() and close() respectively, where the code has valid snd_soc_pcm_runtime. Without this patch unloading lpass sound card module would result in below crash: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = ffff800038f0d000 [00000000] *pgd=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: snd_soc_apq8016_sbc(-) snd_soc_lpass_apq8016 snd_soc_lpass_cpu snd_soc_lpass_platform CPU: 0 PID: 1573 Comm: rmmod Not tainted 4.7.0-rc2-next-20160609+ torvalds#59 Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) task: ffff800038cd0000 ti: ffff80003929c000 task.ti: ffff80003929c000 PC is at lpass_platform_pcm_free+0xc4/0x1c0 [snd_soc_lpass_platform] LR is at lpass_platform_pcm_free+0xb8/0x1c0 [snd_soc_lpass_platform] pc : [<ffff000000b20b64>] lr : [<ffff000000b20b58>] pstate: 60000145 sp : ffff80003929fa90 x29: ffff80003929fa90 x28: ffff000000b22438 x27: ffff000000b22450 x26: ffff000000b22468 x25: ffff000000b22488 x24: ffff000000b223f0 x23: ffff000000b22418 x22: ffff800038f428c0 x21: ffff8000392ae280 x20: 0000000000000001 x19: ffff000000b22118 x18: 0000ffffdc331600 x17: 0000ffffb78036c0 x16: ffff0000081c16e8 x15: 0000ffffb77f0588 x14: 3d4d554e51455300 x13: ffffffffffff0000 x12: 0000000000000028 x11: 0000000000000044 x10: ffff80003929f822 x9 : ffff80003929f823 x8 : 0000000000000000 x7 : 0000000000000004 x6 : ffff000008864890 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff80003efac228 x1 : ffff000000b22118 x0 : ffff000000b22450 Process rmmod (pid: 1573, stack limit = 0xffff80003929c020) Stack: (0xffff80003929fa90 to 0xffff8000392a0000) fa80: ffff80003929fb40 ffff0000086d1f8c faa0: ffff000008ca5408 ffff800038f42200 ffff000008ca5420 000000000000000b fac0: ffff80003929fd70 0000000000000015 0000000000000120 000000000000006a fae0: ffff0000087f2000 ffff80003929c000 ffff80003929fb40 ffff8000392ae358 fb00: ffff8000392af900 0000000000000000 ffff8000392afa48 000000000000000b fb20: ffff80003929fd70 0000000000000015 ffff80003929fb80 ffff0000086cc070 fb40: ffff80003929fb70 ffff0000086d21d4 ffff800038f7fa00 ffff8000392801a0 fb60: ffff800038cf2000 0000000000000015 ffff80003929fb80 ffff0000086cc064 fb80: ffff80003929fba0 ffff0000086cc1f4 ffff800038f70600 000000000000000b fba0: ffff80003929fbc0 ffff0000086c68a8 ffff800039280000 ffff800039280540 fbc0: ffff80003929fbe0 ffff0000084a7438 ffff800039280540 ffff800039280550 fbe0: ffff80003929fc10 ffff000008355ddc ffff800039280550 ffff000008c64718 fc00: ffff800038f61d00 ffff000008ca5190 ffff80003929fc40 ffff000008355e5c fc20: ffff800039280550 ffff800039280000 ffff80003847b618 ffff800039280000 fc40: ffff80003929fc60 ffff0000084a77d8 0000000000000000 0000000000000015 fc60: ffff80003929fc70 ffff0000086c6e58 ffff80003929fc90 ffff0000086c6fbc fc80: ffff80003929fcb0 ffff800039280000 ffff80003929fcd0 ffff0000086e3e50 fca0: ffff80003847b050 ffff80003847b728 ffff800000000000 ffff000000000000 fcc0: ffff80003929fcc0 ffff80003929fcc0 ffff80003929fd00 ffff0000086e4c8c fce0: ffff80003847b618 ffff800038f61100 ffff8000399ddf90 000000000000000b fd00: ffff80003929fd20 ffff0000086f0684 ffff800038f61000 ffff0000080d51c0 fd20: ffff80003929fd30 ffff0000084af904 ffff80003929fd80 ffff0000084afcf8 fd40: ffff8000399ddf90 ffff000000b3c028 ffff8000399ddff0 ffff000008cc8000 fd60: 0000000080000000 ffff0000084ac090 ffff800038f94600 ffff800038f61000 fd80: ffff80003929fda0 ffff0000084ac0b0 ffff8000399ddf90 ffff000000b3c028 fda0: ffff80003929fdc0 ffff0000084ac234 ffff8000399ddf90 ffff000000b3c028 fdc0: ffff80003929fdf0 ffff0000084ab3d4 ffff000000b3c028 ffff000008c64000 fde0: ffff000008c64818 ffff000000000001 ffff80003929fe20 ffff0000084ac8ac fe00: ffff000000b3c028 ffff000000b3c100 fffffffffffffff5 0000000000000000 fe20: ffff80003929fe40 ffff0000084ad998 ffff000008c2d000 0000000000000015 fe40: ffff80003929fe50 ffff000000b3a460 ffff80003929fe60 ffff000008120fe4 fe60: 0000000000000000 ffff000008084e70 0000000000000000 0000000000000000 fe80: ffffffffffffffff 0000ffff954cca48 0000000000000004 5f636f735f646e73 fea0: 5f36313038717061 0000000000636273 0000000000000000 ffff000008084d64 fec0: 0000000000000000 0000000000000000 0000aaaabc814340 0000000000000800 fee0: 4fdc43dac03e2300 0000000000002002 0000ffff95548e58 0000ffffd9f89fb9 ff00: 0000000000000000 0000000000000000 000000000000006a 1999999999999999 ff20: 00000000ffffffff 0000000000000000 0000000000000005 ffffffffffffffff ff40: 0000ffff95402a94 0000ffff9554a588 0000ffff954cca40 0000aaaaaf8d22d0 ff60: 0000ffffd9f8ad70 0000aaaabc8142e0 0000000000000000 0000000000000000 ff80: 0000ffffd9f8be7c 0000000000000000 0000ffffd9f8b0e0 0000ffffd9f8b2b8 ffa0: 0000aaaabc8142e0 0000aaaabc813010 0000000000000000 0000ffffd9f8b010 ffc0: 0000aaaaaf8b5ad4 0000ffffd9f8b010 0000ffff954cca48 0000000080000000 ffe0: 0000aaaabc814340 000000000000006a 0000060000000000 00000000fffefcaf Call trace: Exception stack(0xffff80003929f8d0 to 0xffff80003929f9f0) f8c0: ffff000000b22118 00000000000001 f8e0: ffff80003929fa90 ffff000000b20b64 ffff80003929f910 ffff000008a12f40 f900: ffff000008c15b78 0000000100000001 ffff80003929f9b0 ffff0000080f66e0 f920: ffff000000b22118 0000000000000001 ffff8000392ae280 ffff800038f428c0 f940: ffff000000b22418 ffff000000b223f0 ffff000000b22488 ffff000000b22468 f960: ffff000000b22450 ffff000000b22438 ffff000000b22450 ffff000000b22118 f980: ffff80003efac228 0000000000000000 0000000000000000 0000000000000000 f9a0: ffff000008864890 0000000000000004 0000000000000000 ffff80003929f823 f9c0: ffff80003929f822 0000000000000044 0000000000000028 ffffffffffff0000 f9e0: 3d4d554e51455300 0000ffffb77f0588 [<ffff000000b20b64>] lpass_platform_pcm_free+0xc4/0x1c0 [snd_soc_lpass_platform] [<ffff0000086d1f8c>] snd_pcm_free+0x30/0xa0 [<ffff0000086d21d4>] snd_pcm_dev_free+0x10/0x18 [<ffff0000086cc064>] __snd_device_free+0x58/0xa0 [<ffff0000086cc1f4>] snd_device_free_all+0x2c/0x48 [<ffff0000086c68a8>] release_card_device+0x1c/0x74 [<ffff0000084a7438>] device_release+0x34/0x90 [<ffff000008355ddc>] kobject_release+0x44/0x84 [<ffff000008355e5c>] kobject_put+0x40/0x68 [<ffff0000084a77d8>] put_device+0x14/0x1c [<ffff0000086c6e58>] snd_card_free_when_closed+0x24/0x34 [<ffff0000086c6fbc>] snd_card_free+0x40/0x60 [<ffff0000086e3e50>] soc_cleanup_card_resources+0x80/0x94 [<ffff0000086e4c8c>] snd_soc_unregister_card+0x28/0x38 [<ffff0000086f0684>] devm_card_release+0x10/0x18 [<ffff0000084af904>] release_nodes+0x124/0x208 [<ffff0000084afcf8>] devres_release_all+0x34/0x54 [<ffff0000084ac0b0>] __device_release_driver+0x84/0xfc [<ffff0000084ac234>] driver_detach+0xbc/0xc0 [<ffff0000084ab3d4>] bus_remove_driver+0x58/0xac [<ffff0000084ac8ac>] driver_unregister+0x2c/0x4c [<ffff0000084ad998>] platform_driver_unregister+0x10/0x18 [<ffff000000b3a460>] apq8016_sbc_platform_driver_exit+0x10/0xbb0 [snd_soc_apq8016_sbc] [<ffff000008120fe4>] SyS_delete_module+0x1b8/0x1fc [<ffff000008084e70>] el0_svc_naked+0x24/0x28 Signed-off-by: Srinivas Kandagatla <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Oct 31, 2016
…ckpatch-fixes WARNING: line over 80 characters torvalds#59: FILE: mm/mempolicy.c:1686: + * __GFP_THISNODE shouldn't even be used with the bind policy because WARNING: line over 80 characters torvalds#60: FILE: mm/mempolicy.c:1687: + * we might easily break the expectation to stay on the requested node WARNING: line over 80 characters torvalds#69: FILE: mm/mempolicy.c:1690: + WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE)); total: 0 errors, 3 warnings, 33 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/mm-mempolicy-clean-up-__gfp_thisnode-confusion-in-policy_zonelist.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Nov 8, 2016
…ckpatch-fixes WARNING: line over 80 characters torvalds#59: FILE: mm/mempolicy.c:1686: + * __GFP_THISNODE shouldn't even be used with the bind policy because WARNING: line over 80 characters torvalds#60: FILE: mm/mempolicy.c:1687: + * we might easily break the expectation to stay on the requested node WARNING: line over 80 characters torvalds#69: FILE: mm/mempolicy.c:1690: + WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE)); total: 0 errors, 3 warnings, 33 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/mm-mempolicy-clean-up-__gfp_thisnode-confusion-in-policy_zonelist.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Nov 9, 2016
…ckpatch-fixes WARNING: line over 80 characters torvalds#59: FILE: mm/mempolicy.c:1686: + * __GFP_THISNODE shouldn't even be used with the bind policy because WARNING: line over 80 characters torvalds#60: FILE: mm/mempolicy.c:1687: + * we might easily break the expectation to stay on the requested node WARNING: line over 80 characters torvalds#69: FILE: mm/mempolicy.c:1690: + WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE)); total: 0 errors, 3 warnings, 33 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/mm-mempolicy-clean-up-__gfp_thisnode-confusion-in-policy_zonelist.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Nov 9, 2016
…ckpatch-fixes WARNING: line over 80 characters torvalds#59: FILE: mm/mempolicy.c:1686: + * __GFP_THISNODE shouldn't even be used with the bind policy because WARNING: line over 80 characters torvalds#60: FILE: mm/mempolicy.c:1687: + * we might easily break the expectation to stay on the requested node WARNING: line over 80 characters torvalds#69: FILE: mm/mempolicy.c:1690: + WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE)); total: 0 errors, 3 warnings, 33 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/mm-mempolicy-clean-up-__gfp_thisnode-confusion-in-policy_zonelist.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Nov 25, 2016
…ckpatch-fixes WARNING: line over 80 characters torvalds#59: FILE: mm/mempolicy.c:1686: + * __GFP_THISNODE shouldn't even be used with the bind policy because WARNING: line over 80 characters torvalds#60: FILE: mm/mempolicy.c:1687: + * we might easily break the expectation to stay on the requested node WARNING: line over 80 characters torvalds#69: FILE: mm/mempolicy.c:1690: + WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE)); total: 0 errors, 3 warnings, 33 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/mm-mempolicy-clean-up-__gfp_thisnode-confusion-in-policy_zonelist.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Nov 30, 2016
When removing and adding cpu 0 on a system with GHES NMI the following stack trace is seen when re-adding the cpu: WARNING: CPU: 0 PID: 0 at arch/x86/kernel/apic/apic.c:1349 setup_local_APIC+ Modules linked in: nfsv3 rpcsec_gss_krb5 nfsv4 nfs fscache coretemp intel_ra CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-rc5+ torvalds#59 Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.01.00.0 ffffffff81c03e78 ffffffff81337905 0000000000000000 0000000000000000 ffffffff81c03eb8 ffffffff8107d9c1 00000545810aac4a 0000000000000000 00000000000000f0 0000000000000000 000081cb6440f1d0 0000000000000001 Call Trace: [<ffffffff81337905>] dump_stack+0x63/0x8e [<ffffffff8107d9c1>] __warn+0xd1/0xf0 [<ffffffff8107daad>] warn_slowpath_null+0x1d/0x20 [<ffffffff810522b5>] setup_local_APIC+0x275/0x370 [<ffffffff810523be>] apic_ap_setup+0xe/0x20 [<ffffffff8104f5a8>] start_secondary+0x48/0x180 [<ffffffff81d89aa0>] ? set_init_arg+0x55/0x55 [<ffffffff81d89120>] ? early_idt_handler_array+0x120/0x120 [<ffffffff81d895d6>] ? x86_64_start_reservations+0x2a/0x2c [<ffffffff81d89715>] ? x86_64_start_kernel+0x13d/0x14c ---[ end trace 7b6555b6343ef9ee ]--- During the cpu bringup, wakeup_cpu_via_init_nmi() is called and issues an NMI on CPU 0. The GHES NMI handler, ghes_notify_nmi() runs the ghes_proc_irq_work work queue which ends up setting IRQ_WORK_VECTOR (0xf6). The "faulty" IR line set at arch/x86/kernel/apic/apic.c:1349 is also 0xf6 (specifically APIC IRR for irqs 255 to 224 is 0x400000) which confirms that something has set the IRQ_WORK_VECTOR line prior to the APIC being initialized. Commit 2383844 ("GHES: Elliminate double-loop in the NMI handler") incorrectly modified the behavior such that the handler returns NMI_HANDLED only if an error was processed, and incorrectly runs the ghes work queue for every NMI. This patch modifies the ghes_proc_irq_work() to run as it did prior to 2383844 ("GHES: Elliminate double-loop in the NMI handler") by properly returning NMI_HANDLED and only calling the work queue if NMI_HANDLED has been set. Fixes: 2383844 ("GHES: Elliminate double-loop in the NMI handler") Signed-off-by: Prarit Bhargava <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Cc: Len Brown <[email protected]> Cc: Paul Gortmaker <[email protected]> Cc: Tyler Baicar <[email protected]> Cc: Punit Agrawal <[email protected]> Cc: Don Zickus <[email protected]> Cc: [email protected]
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Dec 2, 2016
…ckpatch-fixes WARNING: line over 80 characters torvalds#59: FILE: mm/mempolicy.c:1686: + * __GFP_THISNODE shouldn't even be used with the bind policy because WARNING: line over 80 characters torvalds#60: FILE: mm/mempolicy.c:1687: + * we might easily break the expectation to stay on the requested node WARNING: line over 80 characters torvalds#69: FILE: mm/mempolicy.c:1690: + WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE)); total: 0 errors, 3 warnings, 33 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/mm-mempolicy-clean-up-__gfp_thisnode-confusion-in-policy_zonelist.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Dec 8, 2016
…ckpatch-fixes WARNING: line over 80 characters torvalds#59: FILE: mm/mempolicy.c:1686: + * __GFP_THISNODE shouldn't even be used with the bind policy because WARNING: line over 80 characters torvalds#60: FILE: mm/mempolicy.c:1687: + * we might easily break the expectation to stay on the requested node WARNING: line over 80 characters torvalds#69: FILE: mm/mempolicy.c:1690: + WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE)); total: 0 errors, 3 warnings, 33 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/mm-mempolicy-clean-up-__gfp_thisnode-confusion-in-policy_zonelist.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Dec 10, 2016
…ckpatch-fixes WARNING: line over 80 characters torvalds#59: FILE: mm/mempolicy.c:1686: + * __GFP_THISNODE shouldn't even be used with the bind policy because WARNING: line over 80 characters torvalds#60: FILE: mm/mempolicy.c:1687: + * we might easily break the expectation to stay on the requested node WARNING: line over 80 characters torvalds#69: FILE: mm/mempolicy.c:1690: + WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE)); total: 0 errors, 3 warnings, 33 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/mm-mempolicy-clean-up-__gfp_thisnode-confusion-in-policy_zonelist.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Oct 26, 2023
The following commands: tc qdisc add dev eth1 handle 2: root htb offload tc class add dev eth1 parent 2: classid 2:1 htb rate 5mbit burst 15k yeld to a WARN in the HTB qdisc: WARNING: CPU: 2 PID: 1583 at net/sched/sch_htb.c:1959 CPU: 2 PID: 1583 Comm: tc Kdump: loaded 6.6.0-rc2.mptcp_7895773e5235+ torvalds#59 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc37 04/01/2014 RIP: 0010:htb_change_class+0x25c4/0x2e30 [sch_htb] Code: 24 58 48 b8 00 00 00 00 00 fc ff df 48 89 ca 48 c1 ea 03 80 3c 02 00 0f 85 92 01 00 00 49 89 8c 24 b0 01 00 00 e9 77 fc ff ff <0f> 0b e9 15 ec ff ff 80 3d f8 35 00 00 00 0f 85 d4 f9 ff ff ba 32 RSP: 0018:ffffc900015df240 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88811b4ca000 RCX: ffff88811db42800 RDX: 1ffff11023b68502 RSI: ffffffffaf2e6a00 RDI: ffff88811db42810 RBP: ffff88811db45000 R08: 0000000000000001 R09: fffffbfff664bbc9 R10: ffffffffb325de4f R11: ffffffffb2d33748 R12: 0000000000000000 R13: ffff88811db43000 R14: ffff88811b4caaac R15: ffff8881252c0030 FS: 00007f6c1f126740(0000) GS:ffff88815aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055dca8e5b4a8 CR3: 000000011bc7a006 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tc_ctl_tclass+0x394/0xeb0 rtnetlink_rcv_msg+0x2f5/0xaa0 netlink_rcv_skb+0x12e/0x3a0 netlink_unicast+0x421/0x730 netlink_sendmsg+0x79e/0xc60 ____sys_sendmsg+0x95a/0xc20 ___sys_sendmsg+0xee/0x170 __sys_sendmsg+0xc6/0x170 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 The first command creates per TX queue pfifo qdiscs in tc_modify_qdisc() -> htb_init() and grafts the pfifo to each dev_queue via tc_modify_qdisc() -> qdisc_graft() -> htb_attach(). When the command completes, the qdisc_sleeping for each dev_queue is a pfifo one. The next class creation will trigger the reported splat. Address the issue taking care of old non-builtin qdisc in htb_change_class(). Fixes: d03b195 ("sch_htb: Hierarchical QoS hardware offload") Signed-off-by: Paolo Abeni <[email protected]>
logic10492
pushed a commit
to logic10492/linux-amd-zen2
that referenced
this pull request
Jan 18, 2024
Update and refactor scheduler build system
gyroninja
added a commit
to gyroninja/linux
that referenced
this pull request
Jan 28, 2024
KSAN calls into rcu code which then triggers a write that reenters into KSAN getting the system stuck doing infinite recursion. #0 kmsan_get_context () at mm/kmsan/kmsan.h:106 #1 __msan_get_context_state () at mm/kmsan/instrumentation.c:331 #2 0xffffffff81495671 in get_current () at ./arch/x86/include/asm/current.h:42 #3 rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 #4 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 #5 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#6 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#7 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#8 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#9 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#10 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#11 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#12 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#13 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#14 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#15 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#16 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#17 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#18 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#19 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#20 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#21 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#22 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#23 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#24 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#25 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#26 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#27 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#28 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#29 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#30 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#31 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#32 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#33 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#34 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#35 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#36 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#37 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#38 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#39 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#40 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#41 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#42 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#43 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#44 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#45 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#46 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#47 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#48 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#49 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#50 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#51 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 #52 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 #53 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#54 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#55 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#56 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#57 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 #58 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#59 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#60 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#61 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#62 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#63 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#64 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#65 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#66 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#67 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#68 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#69 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 #70 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#71 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#72 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#73 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#74 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#75 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#76 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#77 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff86203c90) at ./arch/x86/include/asm/kmsan.h:82 torvalds#78 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff86203c90) at mm/kmsan/shadow.c:75 torvalds#79 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff86203c90, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#80 kmsan_get_shadow_origin_ptr (address=0xffffffff86203c90, size=8, store=false) at mm/kmsan/shadow.c:97 torvalds#81 0xffffffff81b1dc72 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=8, store=false) at mm/kmsan/instrumentation.c:36 torvalds#82 __msan_metadata_ptr_for_load_8 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:92 torvalds#83 0xffffffff814fdb9e in filter_irq_stacks (entries=<optimized out>, nr_entries=4) at kernel/stacktrace.c:397 torvalds#84 0xffffffff829520e8 in stack_depot_save_flags (entries=0xffffffff8620d974 <init_task+1012>, nr_entries=4, alloc_flags=0, depot_flags=0) at lib/stackdepot.c:500 torvalds#85 0xffffffff81b1e560 in __msan_poison_alloca (address=0xffffffff86203da0, size=24, descr=<optimized out>) at mm/kmsan/instrumentation.c:285 torvalds#86 0xffffffff8562821c in _printk (fmt=0xffffffff85f191a5 "\0016Attempting lock1") at kernel/printk/printk.c:2324 torvalds#87 0xffffffff81942aa2 in kmem_cache_create_usercopy (name=0xffffffff85f18903 "mm_struct", size=1296, align=0, flags=270336, useroffset=<optimized out>, usersize=<optimized out>, ctor=0x0 <fixed_percpu_data>) at mm/slab_common.c:296 torvalds#88 0xffffffff86f337a0 in mm_cache_init () at kernel/fork.c:3262 torvalds#89 0xffffffff86eacb8e in start_kernel () at init/main.c:932 torvalds#90 0xffffffff86ecdf94 in x86_64_start_reservations (real_mode_data=0x140e0 <exception_stacks+28896> <error: Cannot access memory at address 0x140e0>) at arch/x86/kernel/head64.c:555 torvalds#91 0xffffffff86ecde9b in x86_64_start_kernel (real_mode_data=0x140e0 <exception_stacks+28896> <error: Cannot access memory at address 0x140e0>) at arch/x86/kernel/head64.c:536 torvalds#92 0xffffffff810001d3 in secondary_startup_64 () at /pool/workspace/linux/arch/x86/kernel/head_64.S:461 torvalds#93 0x0000000000000000 in ??
gyroninja
added a commit
to gyroninja/linux
that referenced
this pull request
Jan 28, 2024
As of 5ec8e8e(mm/sparsemem: fix race in accessing memory_section->usage) KMSAN now calls into RCU tree code during kmsan_get_metadata. This will trigger a write that will reenter into KMSAN getting the system stuck doing infinite recursion. #0 kmsan_get_context () at mm/kmsan/kmsan.h:106 #1 __msan_get_context_state () at mm/kmsan/instrumentation.c:331 #2 0xffffffff81495671 in get_current () at ./arch/x86/include/asm/current.h:42 #3 rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 #4 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 #5 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#6 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#7 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#8 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#9 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#10 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#11 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#12 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#13 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#14 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#15 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#16 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#17 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#18 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#19 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#20 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#21 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#22 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#23 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#24 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#25 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#26 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#27 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#28 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#29 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#30 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#31 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#32 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#33 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#34 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#35 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#36 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#37 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#38 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#39 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#40 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#41 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#42 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#43 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#44 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#45 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#46 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#47 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#48 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#49 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#50 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#51 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 #52 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 #53 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#54 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#55 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#56 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#57 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 #58 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#59 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#60 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#61 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#62 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#63 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#64 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#65 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#66 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#67 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#68 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#69 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 #70 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#71 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#72 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#73 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#74 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#75 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#76 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#77 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff86203c90) at ./arch/x86/include/asm/kmsan.h:82 torvalds#78 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff86203c90) at mm/kmsan/shadow.c:75 torvalds#79 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff86203c90, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#80 kmsan_get_shadow_origin_ptr (address=0xffffffff86203c90, size=8, store=false) at mm/kmsan/shadow.c:97 torvalds#81 0xffffffff81b1dc72 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=8, store=false) at mm/kmsan/instrumentation.c:36 torvalds#82 __msan_metadata_ptr_for_load_8 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:92 torvalds#83 0xffffffff814fdb9e in filter_irq_stacks (entries=<optimized out>, nr_entries=4) at kernel/stacktrace.c:397 torvalds#84 0xffffffff829520e8 in stack_depot_save_flags (entries=0xffffffff8620d974 <init_task+1012>, nr_entries=4, alloc_flags=0, depot_flags=0) at lib/stackdepot.c:500 torvalds#85 0xffffffff81b1e560 in __msan_poison_alloca (address=0xffffffff86203da0, size=24, descr=<optimized out>) at mm/kmsan/instrumentation.c:285 torvalds#86 0xffffffff8562821c in _printk (fmt=0xffffffff85f191a5 "\0016Attempting lock1") at kernel/printk/printk.c:2324 torvalds#87 0xffffffff81942aa2 in kmem_cache_create_usercopy (name=0xffffffff85f18903 "mm_struct", size=1296, align=0, flags=270336, useroffset=<optimized out>, usersize=<optimized out>, ctor=0x0 <fixed_percpu_data>) at mm/slab_common.c:296 torvalds#88 0xffffffff86f337a0 in mm_cache_init () at kernel/fork.c:3262 torvalds#89 0xffffffff86eacb8e in start_kernel () at init/main.c:932 torvalds#90 0xffffffff86ecdf94 in x86_64_start_reservations (real_mode_data=0x140e0 <exception_stacks+28896> <error: Cannot access memory at address 0x140e0>) at arch/x86/kernel/head64.c:555 torvalds#91 0xffffffff86ecde9b in x86_64_start_kernel (real_mode_data=0x140e0 <exception_stacks+28896> <error: Cannot access memory at address 0x140e0>) at arch/x86/kernel/head64.c:536 torvalds#92 0xffffffff810001d3 in secondary_startup_64 () at /pool/workspace/linux/arch/x86/kernel/head_64.S:461 torvalds#93 0x0000000000000000 in ??
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Apr 20, 2024
Christoph reported a splat hinting at a corrupted snd_una: WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 process_scheduled_works kernel/workqueue.c:3335 [inline] worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK> When fallback to TCP happens early on a client socket, snd_nxt is not yet initialized and any incoming ack will copy such value into snd_una. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values. We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice. Instead address the issue always initializing snd_nxt (and write_seq, for consistency) at connect time. Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect") Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#485 Tested-by: Christoph Paasch <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Apr 24, 2024
Christoph reported a splat hinting at a corrupted snd_una: WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 process_scheduled_works kernel/workqueue.c:3335 [inline] worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK> When fallback to TCP happens early on a client socket, snd_nxt is not yet initialized and any incoming ack will copy such value into snd_una. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values. We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice. Instead address the issue always initializing snd_nxt (and write_seq, for consistency) at connect time. Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect") Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#485 Tested-by: Christoph Paasch <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 29, 2024
Christoph reported a splat hinting at a corrupted snd_una: WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 process_scheduled_works kernel/workqueue.c:3335 [inline] worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK> When fallback to TCP happens early on a client socket, snd_nxt is not yet initialized and any incoming ack will copy such value into snd_una. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values. We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice. Instead address the issue always initializing snd_nxt (and write_seq, for consistency) at connect time. Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect") Cc: [email protected] Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#485 Tested-by: Christoph Paasch <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 30, 2024
Christoph reported a splat hinting at a corrupted snd_una: WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 process_scheduled_works kernel/workqueue.c:3335 [inline] worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK> When fallback to TCP happens early on a client socket, snd_nxt is not yet initialized and any incoming ack will copy such value into snd_una. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values. We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice. Instead address the issue always initializing snd_nxt (and write_seq, for consistency) at connect time. Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect") Cc: [email protected] Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#485 Tested-by: Christoph Paasch <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 30, 2024
Christoph reported a splat hinting at a corrupted snd_una: WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 process_scheduled_works kernel/workqueue.c:3335 [inline] worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK> When fallback to TCP happens early on a client socket, snd_nxt is not yet initialized and any incoming ack will copy such value into snd_una. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values. We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice. Instead address the issue always initializing snd_nxt (and write_seq, for consistency) at connect time. Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect") Cc: [email protected] Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#485 Tested-by: Christoph Paasch <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: NipaLocal <nipa@local>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Apr 30, 2024
Christoph reported a splat hinting at a corrupted snd_una: WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 process_scheduled_works kernel/workqueue.c:3335 [inline] worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK> When fallback to TCP happens early on a client socket, snd_nxt is not yet initialized and any incoming ack will copy such value into snd_una. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values. We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice. Instead address the issue always initializing snd_nxt (and write_seq, for consistency) at connect time. Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect") Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#485 Tested-by: Christoph Paasch <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 30, 2024
Christoph reported a splat hinting at a corrupted snd_una: WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 process_scheduled_works kernel/workqueue.c:3335 [inline] worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK> When fallback to TCP happens early on a client socket, snd_nxt is not yet initialized and any incoming ack will copy such value into snd_una. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values. We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice. Instead address the issue always initializing snd_nxt (and write_seq, for consistency) at connect time. Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect") Cc: [email protected] Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#485 Tested-by: Christoph Paasch <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 30, 2024
Christoph reported a splat hinting at a corrupted snd_una: WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 process_scheduled_works kernel/workqueue.c:3335 [inline] worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK> When fallback to TCP happens early on a client socket, snd_nxt is not yet initialized and any incoming ack will copy such value into snd_una. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values. We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice. Instead address the issue always initializing snd_nxt (and write_seq, for consistency) at connect time. Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect") Cc: [email protected] Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#485 Tested-by: Christoph Paasch <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 30, 2024
Christoph reported a splat hinting at a corrupted snd_una: WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 process_scheduled_works kernel/workqueue.c:3335 [inline] worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK> When fallback to TCP happens early on a client socket, snd_nxt is not yet initialized and any incoming ack will copy such value into snd_una. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values. We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice. Instead address the issue always initializing snd_nxt (and write_seq, for consistency) at connect time. Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect") Cc: [email protected] Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#485 Tested-by: Christoph Paasch <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 30, 2024
Christoph reported a splat hinting at a corrupted snd_una: WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 process_scheduled_works kernel/workqueue.c:3335 [inline] worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK> When fallback to TCP happens early on a client socket, snd_nxt is not yet initialized and any incoming ack will copy such value into snd_una. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values. We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice. Instead address the issue always initializing snd_nxt (and write_seq, for consistency) at connect time. Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect") Cc: [email protected] Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#485 Tested-by: Christoph Paasch <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 30, 2024
Christoph reported a splat hinting at a corrupted snd_una: WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 process_scheduled_works kernel/workqueue.c:3335 [inline] worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK> When fallback to TCP happens early on a client socket, snd_nxt is not yet initialized and any incoming ack will copy such value into snd_una. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values. We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice. Instead address the issue always initializing snd_nxt (and write_seq, for consistency) at connect time. Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect") Cc: [email protected] Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#485 Tested-by: Christoph Paasch <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 30, 2024
Christoph reported a splat hinting at a corrupted snd_una: WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 process_scheduled_works kernel/workqueue.c:3335 [inline] worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK> When fallback to TCP happens early on a client socket, snd_nxt is not yet initialized and any incoming ack will copy such value into snd_una. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values. We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice. Instead address the issue always initializing snd_nxt (and write_seq, for consistency) at connect time. Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect") Cc: [email protected] Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#485 Tested-by: Christoph Paasch <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
May 1, 2024
Christoph reported a splat hinting at a corrupted snd_una: WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 process_scheduled_works kernel/workqueue.c:3335 [inline] worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK> When fallback to TCP happens early on a client socket, snd_nxt is not yet initialized and any incoming ack will copy such value into snd_una. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values. We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice. Instead address the issue always initializing snd_nxt (and write_seq, for consistency) at connect time. Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect") Cc: [email protected] Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#485 Tested-by: Christoph Paasch <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
May 1, 2024
Christoph reported a splat hinting at a corrupted snd_una: WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 process_scheduled_works kernel/workqueue.c:3335 [inline] worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK> When fallback to TCP happens early on a client socket, snd_nxt is not yet initialized and any incoming ack will copy such value into snd_una. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values. We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice. Instead address the issue always initializing snd_nxt (and write_seq, for consistency) at connect time. Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect") Cc: [email protected] Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#485 Tested-by: Christoph Paasch <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://lore.kernel.org/r/20240429-upstream-net-20240429-mptcp-snd_nxt-init-connect-v1-1-59ceac0a7dcb@kernel.org Signed-off-by: Jakub Kicinski <[email protected]>
ptr1337
pushed a commit
to CachyOS/linux
that referenced
this pull request
May 17, 2024
commit fb7a0d3 upstream. Christoph reported a splat hinting at a corrupted snd_una: WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 process_scheduled_works kernel/workqueue.c:3335 [inline] worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK> When fallback to TCP happens early on a client socket, snd_nxt is not yet initialized and any incoming ack will copy such value into snd_una. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values. We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice. Instead address the issue always initializing snd_nxt (and write_seq, for consistency) at connect time. Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect") Cc: [email protected] Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#485 Tested-by: Christoph Paasch <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://lore.kernel.org/r/20240429-upstream-net-20240429-mptcp-snd_nxt-init-connect-v1-1-59ceac0a7dcb@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
1054009064
pushed a commit
to 1054009064/linux
that referenced
this pull request
May 17, 2024
commit fb7a0d3 upstream. Christoph reported a splat hinting at a corrupted snd_una: WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 process_scheduled_works kernel/workqueue.c:3335 [inline] worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK> When fallback to TCP happens early on a client socket, snd_nxt is not yet initialized and any incoming ack will copy such value into snd_una. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values. We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice. Instead address the issue always initializing snd_nxt (and write_seq, for consistency) at connect time. Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect") Cc: [email protected] Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#485 Tested-by: Christoph Paasch <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://lore.kernel.org/r/20240429-upstream-net-20240429-mptcp-snd_nxt-init-connect-v1-1-59ceac0a7dcb@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
1054009064
pushed a commit
to 1054009064/linux
that referenced
this pull request
May 17, 2024
commit fb7a0d3 upstream. Christoph reported a splat hinting at a corrupted snd_una: WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 process_scheduled_works kernel/workqueue.c:3335 [inline] worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK> When fallback to TCP happens early on a client socket, snd_nxt is not yet initialized and any incoming ack will copy such value into snd_una. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values. We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice. Instead address the issue always initializing snd_nxt (and write_seq, for consistency) at connect time. Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect") Cc: [email protected] Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#485 Tested-by: Christoph Paasch <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://lore.kernel.org/r/20240429-upstream-net-20240429-mptcp-snd_nxt-init-connect-v1-1-59ceac0a7dcb@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
1054009064
pushed a commit
to 1054009064/linux
that referenced
this pull request
May 17, 2024
commit fb7a0d3 upstream. Christoph reported a splat hinting at a corrupted snd_una: WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 process_scheduled_works kernel/workqueue.c:3335 [inline] worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK> When fallback to TCP happens early on a client socket, snd_nxt is not yet initialized and any incoming ack will copy such value into snd_una. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values. We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice. Instead address the issue always initializing snd_nxt (and write_seq, for consistency) at connect time. Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect") Cc: [email protected] Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#485 Tested-by: Christoph Paasch <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://lore.kernel.org/r/20240429-upstream-net-20240429-mptcp-snd_nxt-init-connect-v1-1-59ceac0a7dcb@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
1054009064
pushed a commit
to 1054009064/linux
that referenced
this pull request
May 25, 2024
commit fb7a0d3 upstream. Christoph reported a splat hinting at a corrupted snd_una: WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 process_scheduled_works kernel/workqueue.c:3335 [inline] worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK> When fallback to TCP happens early on a client socket, snd_nxt is not yet initialized and any incoming ack will copy such value into snd_una. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values. We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice. Instead address the issue always initializing snd_nxt (and write_seq, for consistency) at connect time. Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect") Cc: [email protected] Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#485 Tested-by: Christoph Paasch <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://lore.kernel.org/r/20240429-upstream-net-20240429-mptcp-snd_nxt-init-connect-v1-1-59ceac0a7dcb@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> [ snd_nxt field is not available in v5.10.y: before, only write_seq was used, see commit eaa2ffa ("mptcp: introduce MPTCP snd_nxt") for more details about that. ] Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Jun 25, 2024
Originally there was a race where removing a psock from the sock map while it was also receiving an skb and calling sk_psock_data_ready(). It was possible the removal code would NULL/set the data_ready callback while concurrently calling the hook from receive path. The fix was to wrap the access in sk_callback_lock to ensure the saved_data_ready pointer didn't change under us. There was some discussion around doing a larger change to ensure we could use READ_ONCE/WRITE_ONCE over the callback, but that was for *next kernels not stable fixes. But, we unfortunately introduced a regression with the fix because there is another path into this code (that didn't have a test case) through the stream parser. The stream parser runs with the lower lock which means we get the following splat and lock up. ============================================ WARNING: possible recursive locking detected 6.10.0-rc2 torvalds#59 Not tainted -------------------------------------------- test_sockmap/342 is trying to acquire lock: ffff888007a87228 (clock-AF_INET){++--}-{2:2}, at: sk_psock_skb_ingress_enqueue (./include/linux/skmsg.h:467 net/core/skmsg.c:555) but task is already holding lock: ffff888007a87228 (clock-AF_INET){++--}-{2:2}, at: sk_psock_strp_data_ready (net/core/skmsg.c:1120) To fix ensure we do not grap lock when we reach this code through the strparser. Fixes: 6648e61 ("bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue") Reported-by: Vincent Whitchurch <[email protected]> Signed-off-by: John Fastabend <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Aug 26, 2024
Fix WARN_ON: [ 22.869352][ T1885] clk_spi0 already unprepared [ 22.869379][ T1885] WARNING: CPU: 3 PID: 1885 at drivers/clk/clk.c:813 clk_core_unprepare+0xbc4 [ 22.869380][ T1885] Modules linked in: bcmdhd dhd_static_buf [ 22.869391][ T1885] CPU: 3 PID: 1885 Comm: Binder:355_2 Tainted: G W 5.10.66 torvalds#59 [ 22.869393][ T1885] Hardware name: Rockchip RK3588 EVB1 LP4 V10 Board (DT) [ 22.869397][ T1885] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 22.869401][ T1885] pc : clk_core_unprepare+0xbc/0x214 [ 22.869404][ T1885] lr : clk_core_unprepare+0xbc/0x214 Fixes: ("spi: rockchip: Suspend and resume the bus during NOIRQ_SYSTEM_SLEEP_PM ops") Signed-off-by: Jon Lin <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Aug 26, 2024
Fix WARN_ON: [ 22.869352][ T1885] clk_spi0 already unprepared [ 22.869379][ T1885] WARNING: CPU: 3 PID: 1885 at drivers/clk/clk.c:813 clk_core_unprepare+0xbc4 [ 22.869380][ T1885] Modules linked in: bcmdhd dhd_static_buf [ 22.869391][ T1885] CPU: 3 PID: 1885 Comm: Binder:355_2 Tainted: G W 5.10.66 torvalds#59 [ 22.869393][ T1885] Hardware name: Rockchip RK3588 EVB1 LP4 V10 Board (DT) [ 22.869397][ T1885] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 22.869401][ T1885] pc : clk_core_unprepare+0xbc/0x214 [ 22.869404][ T1885] lr : clk_core_unprepare+0xbc/0x214 Fixes: ("spi: rockchip: Suspend and resume the bus during NOIRQ_SYSTEM_SLEEP_PM ops") Signed-off-by: Jon Lin <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Aug 26, 2024
Fix WARN_ON: [ 22.869352][ T1885] clk_spi0 already unprepared [ 22.869379][ T1885] WARNING: CPU: 3 PID: 1885 at drivers/clk/clk.c:813 clk_core_unprepare+0xbc4 [ 22.869380][ T1885] Modules linked in: bcmdhd dhd_static_buf [ 22.869391][ T1885] CPU: 3 PID: 1885 Comm: Binder:355_2 Tainted: G W 5.10.66 torvalds#59 [ 22.869393][ T1885] Hardware name: Rockchip RK3588 EVB1 LP4 V10 Board (DT) [ 22.869397][ T1885] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 22.869401][ T1885] pc : clk_core_unprepare+0xbc/0x214 [ 22.869404][ T1885] lr : clk_core_unprepare+0xbc/0x214 Fixes: ("spi: rockchip: Suspend and resume the bus during NOIRQ_SYSTEM_SLEEP_PM ops") Signed-off-by: Jon Lin <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Sep 5, 2024
commit 25216af ("PCI: Add managed pcim_intx()") moved the allocation step for pci_intx()'s device resource from pcim_enable_device() to pcim_intx(). As before, pcim_enable_device() sets pci_dev.is_managed to true; and it is never set to false again. Due to the lifecycle of a struct pci_dev, it can happen that a second driver obtains the same pci_dev after a first driver ran. If one driver uses pcim_enable_device() and the other doesn't, this causes the other driver to run into managed pcim_intx(), which will try to allocate when called for the first time. Allocations might sleep, so calling pci_intx() while holding spinlocks becomes then invalid, which causes lockdep warnings and could cause deadlocks: ======================================================== WARNING: possible irq lock inversion dependency detected 6.11.0-rc6+ torvalds#59 Tainted: G W -------------------------------------------------------- CPU 0/KVM/1537 just changed the state of lock: ffffa0f0cff965f0 (&vdev->irqlock){-...}-{2:2}, at: vfio_intx_handler+0x21/0xd0 [vfio_pci_core] but this lock took another, HARDIRQ-unsafe lock in the past: (fs_reclaim){+.+.}-{0:0} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); local_irq_disable(); lock(&vdev->irqlock); lock(fs_reclaim); <Interrupt> lock(&vdev->irqlock); *** DEADLOCK *** Have pcim_enable_device()'s release function, pcim_disable_device(), set pci_dev.is_managed to false so that subsequent drivers using the same struct pci_dev do implicitly run into managed code. Fixes: 25216af ("PCI: Add managed pcim_intx()") Reported-by: Alex Williamson <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Suggested-by: Alex Williamson <[email protected]> Signed-off-by: Philipp Stanner <[email protected]> Tested-by: Alex Williamson <[email protected]>
roxell
pushed a commit
to roxell/linux
that referenced
this pull request
Sep 12, 2024
25216af ("PCI: Add managed pcim_intx()") moved the allocation step for pci_intx()'s device resource from pcim_enable_device() to pcim_intx(). As before, pcim_enable_device() sets pci_dev.is_managed to true; and it is never set to false again. Due to the lifecycle of a struct pci_dev, it can happen that a second driver obtains the same pci_dev after a first driver ran. If one driver uses pcim_enable_device() and the other doesn't, this causes the other driver to run into managed pcim_intx(), which will try to allocate when called for the first time. Allocations might sleep, so calling pci_intx() while holding spinlocks becomes then invalid, which causes lockdep warnings and could cause deadlocks: ======================================================== WARNING: possible irq lock inversion dependency detected 6.11.0-rc6+ torvalds#59 Tainted: G W -------------------------------------------------------- CPU 0/KVM/1537 just changed the state of lock: ffffa0f0cff965f0 (&vdev->irqlock){-...}-{2:2}, at: vfio_intx_handler+0x21/0xd0 [vfio_pci_core] but this lock took another, HARDIRQ-unsafe lock in the past: (fs_reclaim){+.+.}-{0:0} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); local_irq_disable(); lock(&vdev->irqlock); lock(fs_reclaim); <Interrupt> lock(&vdev->irqlock); *** DEADLOCK *** Have pcim_enable_device()'s release function, pcim_disable_device(), set pci_dev.is_managed to false so that subsequent drivers using the same struct pci_dev do implicitly run into managed code. Link: https://lore.kernel.org/r/[email protected] Fixes: 25216af ("PCI: Add managed pcim_intx()") Reported-by: Alex Williamson <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Suggested-by: Alex Williamson <[email protected]> Signed-off-by: Philipp Stanner <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Tested-by: Alex Williamson <[email protected]> Reviewed-by: Damien Le Moal <[email protected]>
roxell
pushed a commit
to roxell/linux
that referenced
this pull request
Sep 13, 2024
25216af ("PCI: Add managed pcim_intx()") moved the allocation step for pci_intx()'s device resource from pcim_enable_device() to pcim_intx(). As before, pcim_enable_device() sets pci_dev.is_managed to true; and it is never set to false again. Due to the lifecycle of a struct pci_dev, it can happen that a second driver obtains the same pci_dev after a first driver ran. If one driver uses pcim_enable_device() and the other doesn't, this causes the other driver to run into managed pcim_intx(), which will try to allocate when called for the first time. Allocations might sleep, so calling pci_intx() while holding spinlocks becomes then invalid, which causes lockdep warnings and could cause deadlocks: ======================================================== WARNING: possible irq lock inversion dependency detected 6.11.0-rc6+ torvalds#59 Tainted: G W -------------------------------------------------------- CPU 0/KVM/1537 just changed the state of lock: ffffa0f0cff965f0 (&vdev->irqlock){-...}-{2:2}, at: vfio_intx_handler+0x21/0xd0 [vfio_pci_core] but this lock took another, HARDIRQ-unsafe lock in the past: (fs_reclaim){+.+.}-{0:0} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); local_irq_disable(); lock(&vdev->irqlock); lock(fs_reclaim); <Interrupt> lock(&vdev->irqlock); *** DEADLOCK *** Have pcim_enable_device()'s release function, pcim_disable_device(), set pci_dev.is_managed to false so that subsequent drivers using the same struct pci_dev do not implicitly run into managed code. Link: https://lore.kernel.org/r/[email protected] Fixes: 25216af ("PCI: Add managed pcim_intx()") Reported-by: Alex Williamson <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Suggested-by: Alex Williamson <[email protected]> Signed-off-by: Philipp Stanner <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Tested-by: Alex Williamson <[email protected]> Reviewed-by: Damien Le Moal <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changed linus/rbtree.h to linux/rbtree.h