search for: unmap_page_range

...[.] _dl_lookup_symbol_x 1.85% ld-2.24.so [.] _dl_name_match_p 1.46% [kernel.kallsyms] [k] copy_page 1.38% ld-2.24.so [.] _dl_map_object 1.30% [kernel.kallsyms] [k] unmap_page_range 1.28% [kernel.kallsyms] [k] filemap_map_pages 1.26% libLLVMSupport.so.6.0.0svn [.] sstep % grep -v '^#' perf-sysv/perf.report-by-dso-sym | head 42.18% ld-2.24.so [.] do_lookup_x 17.73% ld-2.24.so...

...r_run_queues+0x133/0x280 [ 2504.186409] ? recalibrate_cpu_khz+0x10/0x10 [ 2504.186409] __do_softirq+0xd8/0x2e4 [ 2504.186409] irq_exit+0xa3/0xb0 [ 2504.186410] smp_apic_timer_interrupt+0x67/0x120 [ 2504.186410] apic_timer_interrupt+0xf/0x20 [ 2504.186410] </IRQ> [ 2504.186410] RIP: 0010:unmap_page_range+0x47a/0x9b0 [ 2504.186411] Code: 0f 46 46 10 49 39 6e 18 49 89 46 10 48 89 e8 49 0f 43 46 18 41 80 4e 20 08 4d 85 c9 49 89 46 18 0f 84 68 ff ff ff 49 8b 51 08 <48> 8d 42 ff 83 e2 01 49 0f 44 c1 f6 40 18 01 75 38 48 ba ff 0f 00 [ 2504.186411] RSP: 0018:ffffc900036cbcc8 EFLAGS: 00000282 ORIG_RA...

...r_run_queues+0x133/0x280 [ 2504.186409] ? recalibrate_cpu_khz+0x10/0x10 [ 2504.186409] __do_softirq+0xd8/0x2e4 [ 2504.186409] irq_exit+0xa3/0xb0 [ 2504.186410] smp_apic_timer_interrupt+0x67/0x120 [ 2504.186410] apic_timer_interrupt+0xf/0x20 [ 2504.186410] </IRQ> [ 2504.186410] RIP: 0010:unmap_page_range+0x47a/0x9b0 [ 2504.186411] Code: 0f 46 46 10 49 39 6e 18 49 89 46 10 48 89 e8 49 0f 43 46 18 41 80 4e 20 08 4d 85 c9 49 89 46 18 0f 84 68 ff ff ff 49 8b 51 08 <48> 8d 42 ff 83 e2 01 49 0f 44 c1 f6 40 18 01 75 38 48 ba ff 0f 00 [ 2504.186411] RSP: 0018:ffffc900036cbcc8 EFLAGS: 00000282 ORIG_RA...

...libdrm_nouveau.so.2.0.0 pushbuf_validate 1249 100.000 pushbuf.c:482 libdrm_nouveau.so.2.0.0 pushbuf_validate [self] ------------------------------------------------------------------------------- 1123 0.5411 (no location information) kallsyms unmap_page_range 1123 100.000 (no location information) kallsyms unmap_page_range [self] ------------------------------------------------------------------------------- 1088 0.5242 (no location information) kallsyms atomic_sub_return.constprop.3 1088 100.000 (...

...>] bad_page+0x58/0x89 Jul 2 16:40:40 lvs2 kernel: [<c014f2e1>] free_hot_cold_page+0x5f/0xc8 Jul 2 16:40:40 lvs2 kernel: [<c0159b6a>] zap_pte_range+0x1d9/0x226 Jul 2 16:40:40 lvs2 kernel: [<c0159bf9>] zap_pmd_range+0x42/0x68 Jul 2 16:40:40 lvs2 kernel: [<c0159c58>] unmap_page_range+0x39/0x5f Jul 2 16:40:40 lvs2 kernel: [<c0159d7f>] unmap_vmas+0x101/0x1f8 Jul 2 16:40:40 lvs2 kernel: [<c015ed4a>] exit_mmap+0xb8/0x1d0 Jul 2 16:40:40 lvs2 kernel: [<c0121bb4>] mmput+0xb3/0xd6 Jul 2 16:40:40 lvs2 kernel: [<c0127248>] do_exit+0x255/0x59c Jul 2 16:40:...

...nitize the ret to EAGAIN or 0 Humm. Actually having looked this some more, I wonder if this is a problem: I see in __oom_reap_task_mm(): if (mmu_notifier_invalidate_range_start_nonblock(&range)) { tlb_finish_mmu(&tlb, range.start, range.end); ret = false; continue; } unmap_page_range(&tlb, vma, range.start, range.end, NULL); mmu_notifier_invalidate_range_end(&range); Which looks like it creates an unbalanced start/end pairing if any start returns EAGAIN? This does not seem OK.. Many users require start/end to be paired to keep track of their internal locking. Ie fo...

...4.186409] ? recalibrate_cpu_khz+0x10/0x10 > [ 2504.186409] __do_softirq+0xd8/0x2e4 > [ 2504.186409] irq_exit+0xa3/0xb0 > [ 2504.186410] smp_apic_timer_interrupt+0x67/0x120 > [ 2504.186410] apic_timer_interrupt+0xf/0x20 > [ 2504.186410] </IRQ> > [ 2504.186410] RIP: 0010:unmap_page_range+0x47a/0x9b0 > [ 2504.186411] Code: 0f 46 46 10 49 39 6e 18 49 89 46 10 48 89 e8 49 0f 43 46 > 18 41 80 4e 20 08 4d 85 c9 49 89 46 18 0f 84 68 ff ff ff 49 8b 51 08 <48> 8d > 42 ff 83 e2 01 49 0f 44 c1 f6 40 18 01 75 38 48 ba ff 0f 00 > [ 2504.186411] RSP: 0018:ffffc900036cbcc8 EFLA...

On 5/14/19 7:54 AM, Pankaj Gupta wrote: > + if (!list_empty(&vpmem->req_list)) { > + req_buf = list_first_entry(&vpmem->req_list, > + struct virtio_pmem_request, list); > + req_buf->wq_buf_avail = true; > + wake_up(&req_buf->wq_buf); > + list_del(&req_buf->list); Yes, this change is the right one, thank you! > + /* > + * If

On 5/14/19 7:54 AM, Pankaj Gupta wrote: > + if (!list_empty(&vpmem->req_list)) { > + req_buf = list_first_entry(&vpmem->req_list, > + struct virtio_pmem_request, list); > + req_buf->wq_buf_avail = true; > + wake_up(&req_buf->wq_buf); > + list_del(&req_buf->list); Yes, this change is the right one, thank you! > + /* > + * If

...ng looked this some more, I wonder if this is a > problem: > > I see in __oom_reap_task_mm(): > > if (mmu_notifier_invalidate_range_start_nonblock(&range)) { > tlb_finish_mmu(&tlb, range.start, range.end); > ret = false; > continue; > } > unmap_page_range(&tlb, vma, range.start, range.end, NULL); > mmu_notifier_invalidate_range_end(&range); > > Which looks like it creates an unbalanced start/end pairing if any > start returns EAGAIN? > > This does not seem OK.. Many users require start/end to be paired to > keep tra...

...ve some clues: 1)If we map a foreign page(DomainU or VMX) to Domain0 through xc_map_foreign_range, the pfn(in Domain0''s memory space)which points to the mapped mfn should not correlate with any page structure. Is it right? I suppose it to be true. The question is when the kernel calls unmap_page_range, it should try to call vm_normal_page on the related pte to get the page structure. Which flag will lead vm_normal_page to return the NULL pointer? 2)IMHO, I expect only the local mapped page, which belongs to the same domain could be passed to page_remove_rmap and kick out the bug I met! direct_rm...

On 01/06/2018 03:16 AM, Dmitry Melekhov wrote: > The same problem with latest centos 6 kernel,i.e. with meltdown fix. > > I can't see console output, because I have it on "cloud" provider > hosting :-) > > > > 06.01.2018 05:13, Shaun Reitan ?????: >> Broken! >> >> For those of you looking for a PV enabled client Kernel for CentOS Linux

...lt;ffffffff813656db>] xen_evtchn_do_upcall+0x2b/0x50 > [? 587.145018]? [<ffffffff815f3f7e>] xen_do_hypervisor_callback+0x1e/0x30 > [? 587.145018]? <EOI> > [? 587.145018]? [<ffffffff812b8419>] ? free_cpumask_var+0x9/0x10 > [? 587.145018]? [<ffffffff81169618>] ? unmap_page_range+0x5f8/0x860 > [? 587.145018]? [<ffffffff81169901>] ? unmap_single_vma+0x81/0xf0 > [? 587.145018]? [<ffffffff8116a9c9>] ? unmap_vmas+0x49/0x90 > [? 587.145018]? [<ffffffff8117367c>] ? exit_mmap+0xac/0x1a0 > [? 587.145018]? [<ffffffff8105b187>] ? mmput+0x67/0xf0 &g...

...[ 587.145018] [<ffffffff813656db>] xen_evtchn_do_upcall+0x2b/0x50 [ 587.145018] [<ffffffff815f3f7e>] xen_do_hypervisor_callback+0x1e/0x30 [ 587.145018] <EOI> [ 587.145018] [<ffffffff812b8419>] ? free_cpumask_var+0x9/0x10 [ 587.145018] [<ffffffff81169618>] ? unmap_page_range+0x5f8/0x860 [ 587.145018] [<ffffffff81169901>] ? unmap_single_vma+0x81/0xf0 [ 587.145018] [<ffffffff8116a9c9>] ? unmap_vmas+0x49/0x90 [ 587.145018] [<ffffffff8117367c>] ? exit_mmap+0xac/0x1a0 [ 587.145018] [<ffffffff8105b187>] ? mmput+0x67/0xf0 [ 587.145018] [<f...

...c015a487 00000000 00040004 da4d6b78 b79cd000 b79cd000 b79ccfff c015a5e5 c13eef00 da4d6b78 b79cc000 b79cd000 00000000 00001000 b79cd000 d1d5b134 b79cd000 c015a7e3 c13eef00 d1d5b134 b79cc000 b79cd000 00000000 Call Trace: [<c015a487>] zap_pte_range+0x1a7/0x280 [<c015a5e5>] unmap_page_range+0x85/0xc0 [<c015a7e3>] unmap_vmas+0x1c3/0x290 [<c015f8f5>] unmap_region+0xb5/0x170 [<c015fc87>] do_munmap+0x107/0x150 [<c015fd2a>] sys_munmap+0x5a/0x80 [<c0109493>] syscall_call+0x7/0xb I suspect the oops in set_page_dirty is because of either a junk page->map...

...t; > problem: > > > > I see in __oom_reap_task_mm(): > > > > if (mmu_notifier_invalidate_range_start_nonblock(&range)) { > > tlb_finish_mmu(&tlb, range.start, range.end); > > ret = false; > > continue; > > } > > unmap_page_range(&tlb, vma, range.start, range.end, NULL); > > mmu_notifier_invalidate_range_end(&range); > > > > Which looks like it creates an unbalanced start/end pairing if any > > start returns EAGAIN? > > > > This does not seem OK.. Many users require start/end...

Hi, Under linux a large portion of the profiling these days happens with perf, but there's no support for it from LLVM's JITs. For a while perf could associate address+size to symbols by writing a /tmp/perf-$pid.map file: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/tools/perf/Documentation/jit-interface.txt A year or so perf also gained the ability to actually

...utionEngine::runFunctionAsMain main __libc_start_main 0xec26258d4c544155 + 0.55% lli ld-2.24.so [.] do_lookup_x + 0.22% lli ld-2.24.so [.] _dl_lookup_symbol_x + 0.17% lli [kernel.vmlinux] [k] unmap_page_range + 0.16% lli ld-2.24.so [.] _dl_fixup Instruction level view: │ Disassembly of section .text: │ │ 0000000000000040 <stupid_isprime>: │ stupid_isprime(): │ #include <stdint.h> │ #include...

The hmm_mirror_ops callback function sync_cpu_device_pagetables() passes a struct hmm_update which is a simplified version of struct mmu_notifier_range. This is unnecessary so replace hmm_update with mmu_notifier_range directly. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> Cc: "Jérôme Glisse" <jglisse at redhat.com> Cc: Jason Gunthorpe <jgg at mellanox.com>

changeset: 8830:fcc833cbaf82 tag: tip user: kaf24@firebug.cl.cam.ac.uk date: Mon Feb 13 10:41:23 2006 +0100 summary: Return real error code from Xen /dev/mem, not EAGAIN. x460: x86_32: Status: - dom0 boots fine - xend loads fine - single HVM domain loads fine - Multiple HVM domains load fine - destruction of any HVM domain causes dom0 to reboot Issues affecting