-
Notifications
You must be signed in to change notification settings - Fork 54.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ignore diagonals for iMON PAD in keyboard mode #102
Open
ikus060
wants to merge
1
commit into
torvalds:master
Choose a base branch
from
ikus060:master
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
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
For user with an iMON PAD Remote control, the keyboard mode is very touchy and almost useless with XBMC. Event with stabilized() algorithm the behaviour is unexpected. To make it less touchy, I make it ignore any value too close to the diagonals.
hubcapsc
pushed a commit
to hubcapsc/linux
that referenced
this pull request
Jul 2, 2014
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 <bp@suse.de> Cc: huawei.libin@huawei.com Cc: wangyijing@huawei.com Cc: fenghua.yu@intel.com Cc: guohanjun@huawei.com Cc: paul.gortmaker@windriver.com Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20130930095624.GB16383@pd.tnic Signed-off-by: Ingo Molnar <mingo@kernel.org>
hubcapsc
pushed a commit
to hubcapsc/linux
that referenced
this pull request
Jul 2, 2014
These mappings are in fact special and require special handling in privcmd, which already exists. Failure to mark the PTE as special on arm64 causes all sorts of bad PTE fun. e.g. e.g.: BUG: Bad page map in process xl pte:e0004077b33f53 pmd:4079575003 page:ffffffbce1a2f328 count:1 mapcount:-1 mapping: (null) index:0x0 page flags: 0x4000000000000014(referenced|dirty) addr:0000007fb5259000 vm_flags:040644fa anon_vma: (null) mapping:ffffffc03a6fda58 index:0 vma->vm_ops->fault: privcmd_fault+0x0/0x38 vma->vm_file->f_op->mmap: privcmd_mmap+0x0/0x2c CPU: 0 PID: 2657 Comm: xl Not tainted 3.12.0+ torvalds#102 Call trace: [<ffffffc0000880f8>] dump_backtrace+0x0/0x12c [<ffffffc000088238>] show_stack+0x14/0x1c [<ffffffc0004b67e0>] dump_stack+0x70/0x90 [<ffffffc000125690>] print_bad_pte+0x12c/0x1bc [<ffffffc0001268f4>] unmap_single_vma+0x4cc/0x700 [<ffffffc0001273b4>] unmap_vmas+0x68/0xb4 [<ffffffc00012c050>] unmap_region+0xcc/0x1d4 [<ffffffc00012df20>] do_munmap+0x218/0x314 [<ffffffc00012e060>] vm_munmap+0x44/0x64 [<ffffffc00012ed78>] SyS_munmap+0x24/0x34 Where unmap_single_vma contains inlined -> unmap_page_range -> zap_pud_range -> zap_pmd_range -> zap_pte_range -> print_bad_pte. Or: BUG: Bad page state in process xl pfn:4077b4d page:ffffffbce1a2f8d8 count:0 mapcount:-1 mapping: (null) index:0x0 page flags: 0x4000000000000014(referenced|dirty) Modules linked in: CPU: 0 PID: 2657 Comm: xl Tainted: G B 3.12.0+ torvalds#102 Call trace: [<ffffffc0000880f8>] dump_backtrace+0x0/0x12c [<ffffffc000088238>] show_stack+0x14/0x1c [<ffffffc0004b67e0>] dump_stack+0x70/0x90 [<ffffffc00010f798>] bad_page+0xc4/0x110 [<ffffffc00010f8b4>] free_pages_prepare+0xd0/0xd8 [<ffffffc000110e94>] free_hot_cold_page+0x28/0x178 [<ffffffc000111460>] free_hot_cold_page_list+0x38/0x60 [<ffffffc000114cf0>] release_pages+0x190/0x1dc [<ffffffc00012c0e0>] unmap_region+0x15c/0x1d4 [<ffffffc00012df20>] do_munmap+0x218/0x314 [<ffffffc00012e060>] vm_munmap+0x44/0x64 [<ffffffc00012ed78>] SyS_munmap+0x24/0x34 x86 already gets this correct. 32-bit arm gets away with this because there is not PTE_SPECIAL bit in the PTE there and the vm_normal_page fallback path does the right thing. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
pstglia
pushed a commit
to pstglia/linux
that referenced
this pull request
Oct 6, 2014
During the EEH hotplug event, iommu_add_device() will be invoked three times and two of them will trigger warning or error. The three times to invoke the iommu_add_device() are: pci_device_add ... set_iommu_table_base_and_group <- 1st time, fail device_add ... tce_iommu_bus_notifier <- 2nd time, succees pcibios_add_pci_devices ... pcibios_setup_bus_devices <- 3rd time, re-attach The first time fails, since the dev->kobj->sd is not initialized. The dev->kobj->sd is initialized in device_add(). The third time's warning is triggered by the re-attach of the iommu_group. After applying this patch, the error iommu_tce: 0003:05:00.0 has not been added, ret=-14 and the warning [ 204.123609] ------------[ cut here ]------------ [ 204.123645] WARNING: at arch/powerpc/kernel/iommu.c:1125 [ 204.123680] Modules linked in: xt_CHECKSUM nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6t_REJECT bnep bluetooth 6lowpan_iphc rfkill xt_conntrack ebtable_nat ebtable_broute bridge stp llc mlx4_ib ib_sa ib_mad ib_core ib_addr ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw bnx2x tg3 mlx4_core nfsd ptp mdio ses libcrc32c nfs_acl enclosure be2net pps_core shpchp lockd kvm uinput sunrpc binfmt_misc lpfc scsi_transport_fc ipr scsi_tgt [ 204.124356] CPU: 18 PID: 650 Comm: eehd Not tainted 3.14.0-rc5yw+ torvalds#102 [ 204.124400] task: c0000027ed485670 ti: c0000027ed50c000 task.ti: c0000027ed50c000 [ 204.124453] NIP: c00000000003cf80 LR: c00000000006c648 CTR: c00000000006c5c0 [ 204.124506] REGS: c0000027ed50f440 TRAP: 0700 Not tainted (3.14.0-rc5yw+) [ 204.124558] MSR: 9000000000029032 <SF,HV,EE,ME,IR,DR,RI> CR: 88008084 XER: 20000000 [ 204.124682] CFAR: c00000000006c644 SOFTE: 1 GPR00: c00000000006c648 c0000027ed50f6c0 c000000001398380 c0000027ec260300 GPR04: c0000027ea92c000 c00000000006ad00 c0000000016e41b0 0000000000000110 GPR08: c0000000012cd4c0 0000000000000001 c0000027ec2602ff 0000000000000062 GPR12: 0000000028008084 c00000000fdca200 c0000000000d1d90 c0000027ec281a80 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001 GPR24: 000000005342697b 0000000000002906 c000001fe6ac9800 c000001fe6ac9800 GPR28: 0000000000000000 c0000000016e3a80 c0000027ea92c090 c0000027ea92c000 [ 204.125353] NIP [c00000000003cf80] .iommu_add_device+0x30/0x1f0 [ 204.125399] LR [c00000000006c648] .pnv_pci_ioda_dma_dev_setup+0x88/0xb0 [ 204.125443] Call Trace: [ 204.125464] [c0000027ed50f6c0] [c0000027ed50f750] 0xc0000027ed50f750 (unreliable) [ 204.125526] [c0000027ed50f750] [c00000000006c648] .pnv_pci_ioda_dma_dev_setup+0x88/0xb0 [ 204.125588] [c0000027ed50f7d0] [c000000000069cc8] .pnv_pci_dma_dev_setup+0x78/0x340 [ 204.125650] [c0000027ed50f870] [c000000000044408] .pcibios_setup_device+0x88/0x2f0 [ 204.125712] [c0000027ed50f940] [c000000000046040] .pcibios_setup_bus_devices+0x60/0xd0 [ 204.125774] [c0000027ed50f9c0] [c000000000043acc] .pcibios_add_pci_devices+0xdc/0x1c0 [ 204.125837] [c0000027ed50fa50] [c00000000086f970] .eeh_reset_device+0x36c/0x4f0 [ 204.125939] [c0000027ed50fb20] [c00000000003a2d8] .eeh_handle_normal_event+0x448/0x480 [ 204.126068] [c0000027ed50fbc0] [c00000000003a35c] .eeh_handle_event+0x4c/0x340 [ 204.126192] [c0000027ed50fc80] [c00000000003a74c] .eeh_event_handler+0xfc/0x1b0 [ 204.126319] [c0000027ed50fd30] [c0000000000d1ea0] .kthread+0x110/0x130 [ 204.126430] [c0000027ed50fe30] [c00000000000a460] .ret_from_kernel_thread+0x5c/0x7c [ 204.126556] Instruction dump: [ 204.126610] 7c0802a6 fba1ffe8 fbc1fff0 fbe1fff8 f8010010 f821ff71 7c7e1b78 60000000 [ 204.126787] 60000000 e87e0298 3143ffff 7d2a1910 <0b090000> 2fa90000 40de00c8 ebfe0218 [ 204.126966] ---[ end trace 6e7aefd80add2973 ]--- are cleared. This patch removes iommu_add_device() in pnv_pci_ioda_dma_dev_setup(), which revert part of the change in commit d905c5d(PPC: POWERNV: move iommu_add_device earlier). Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
apxii
pushed a commit
to apxii/linux
that referenced
this pull request
May 6, 2015
I2C kernel module removal fix
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Oct 18, 2015
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Oct 21, 2015
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Oct 22, 2015
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
nhoriguchi
pushed a commit
to nhoriguchi/linux
that referenced
this pull request
Oct 30, 2015
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Nov 11, 2015
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Nov 12, 2015
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Nov 19, 2015
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Nov 26, 2015
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Dec 4, 2015
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Dec 7, 2015
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Dec 9, 2015
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ddstreet
pushed a commit
to ddstreet/linux
that referenced
this pull request
Dec 10, 2015
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Dec 10, 2015
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Dec 11, 2015
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ddstreet
pushed a commit
to ddstreet/linux
that referenced
this pull request
Dec 11, 2015
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Dec 18, 2015
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 1, 2016
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 6, 2016
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 13, 2016
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 14, 2016
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 15, 2016
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 21, 2016
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 22, 2016
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 28, 2016
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Feb 1, 2016
This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 27, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 27, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 27, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 27, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 27, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 27, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 27, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 27, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 27, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 27, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 27, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 27, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 27, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 27, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 27, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 27, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 27, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 27, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 27, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 27, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 27, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 29, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 29, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 29, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 29, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 29, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jun 29, 2022
[ Upstream commit 56961c6 ] Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
larsclausen
pushed a commit
to larsclausen/linux
that referenced
this pull request
Jul 18, 2022
Commit a7259df ("memblock: make memblock_find_in_range method private") changed the API using which memory is reserved for the pKVM hypervisor. However, memblock_phys_alloc() differs from the original API in terms of kmemleak semantics -- the old one didn't report the reserved regions to kmemleak while the new one does. Unfortunately, when protected KVM is enabled, all kernel accesses to pKVM-private memory result in a fatal exception, which can now happen because of kmemleak scans: $ echo scan > /sys/kernel/debug/kmemleak [ 34.991354] kvm [304]: nVHE hyp BUG at: [<ffff800008fa3750>] __kvm_nvhe_handle_host_mem_abort+0x270/0x290! [ 34.991580] kvm [304]: Hyp Offset: 0xfffe8be807e00000 [ 34.991813] Kernel panic - not syncing: HYP panic: [ 34.991813] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 34.991813] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 34.991813] VCPU:0000000000000000 [ 34.993660] CPU: 0 PID: 304 Comm: bash Not tainted 5.19.0-rc2 torvalds#102 [ 34.994059] Hardware name: linux,dummy-virt (DT) [ 34.994452] Call trace: [ 34.994641] dump_backtrace.part.0+0xcc/0xe0 [ 34.994932] show_stack+0x18/0x6c [ 34.995094] dump_stack_lvl+0x68/0x84 [ 34.995276] dump_stack+0x18/0x34 [ 34.995484] panic+0x16c/0x354 [ 34.995673] __hyp_pgtable_total_pages+0x0/0x60 [ 34.995933] scan_block+0x74/0x12c [ 34.996129] scan_gray_list+0xd8/0x19c [ 34.996332] kmemleak_scan+0x2c8/0x580 [ 34.996535] kmemleak_write+0x340/0x4a0 [ 34.996744] full_proxy_write+0x60/0xbc [ 34.996967] vfs_write+0xc4/0x2b0 [ 34.997136] ksys_write+0x68/0xf4 [ 34.997311] __arm64_sys_write+0x20/0x2c [ 34.997532] invoke_syscall+0x48/0x114 [ 34.997779] el0_svc_common.constprop.0+0x44/0xec [ 34.998029] do_el0_svc+0x2c/0xc0 [ 34.998205] el0_svc+0x2c/0x84 [ 34.998421] el0t_64_sync_handler+0xf4/0x100 [ 34.998653] el0t_64_sync+0x18c/0x190 [ 34.999252] SMP: stopping secondary CPUs [ 35.000034] Kernel Offset: disabled [ 35.000261] CPU features: 0x800,00007831,00001086 [ 35.000642] Memory Limit: none [ 35.001329] ---[ end Kernel panic - not syncing: HYP panic: [ 35.001329] PS:600003c9 PC:0000f418011a3750 ESR:00000000f2000800 [ 35.001329] FAR:ffff000439200000 HPFAR:0000000004792000 PAR:0000000000000000 [ 35.001329] VCPU:0000000000000000 ]--- Fix this by explicitly excluding the hypervisor's memory pool from kmemleak like we already do for the hyp BSS. Cc: Mike Rapoport <rppt@kernel.org> Fixes: a7259df ("memblock: make memblock_find_in_range method private") Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220616161135.3997786-1-qperret@google.com
akiernan
pushed a commit
to zuma-array/linux
that referenced
this pull request
Nov 3, 2022
PD#150097: driver defect clean up: torvalds#35 torvalds#39 torvalds#54 torvalds#55 torvalds#83 torvalds#94 torvalds#96 torvalds#102 torvalds#649 torvalds#690 torvalds#695 Change-Id: I1b9a9384100f4e39da246c5242de8e506671454d Signed-off-by: Evoke Zhang <evoke.zhang@amlogic.com>
akiernan
pushed a commit
to zuma-array/linux
that referenced
this pull request
Nov 4, 2022
PD#150097: driver defect clean up: torvalds#35 torvalds#39 torvalds#54 torvalds#55 torvalds#83 torvalds#94 torvalds#96 torvalds#102 torvalds#649 torvalds#690 torvalds#695 Change-Id: I1b9a9384100f4e39da246c5242de8e506671454d Signed-off-by: Evoke Zhang <evoke.zhang@amlogic.com>
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.
For user with an iMON PAD Remote control, the keyboard mode is very touchy and almost useless with XBMC. Event with stabilized() algorithm the behaviour is unexpected. To make it less touchy, I make it ignore any value too close to the diagonals.