All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ignat Korchagin <ignat@cloudflare.com>
To: kvm@vger.kernel.org
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Sean Christopherson <seanjc@google.com>,
	stevensd@chromium.org, kernel-team <kernel-team@cloudflare.com>
Subject: Re: Potential bug in TDP MMU
Date: Fri, 10 Dec 2021 23:04:47 +0000	[thread overview]
Message-ID: <CALrw=nE+yGtRi-0bFFwXa9R8ydHKV7syRYeAYuC0EBTvdFiidQ@mail.gmail.com> (raw)
In-Reply-To: <CALrw=nGrAhSn=MkW-wvNr=UnaS5=t24yY-TWjSvcNJa1oJ85ww@mail.gmail.com>

I've been trying to figure out the difference between "good" runs and
"bad" runs of gvisor. So, if I've been running the following bpftrace
onliner:

$ bpftrace -e 'kprobe:kvm_set_pfn_dirty { @[kstack] = count(); }'

while also executing a single:

$ sudo runsc --platform=kvm --network=none do echo ok

So, for "good" runs the stacks are the following:

# bpftrace -e 'kprobe:kvm_set_pfn_dirty { @[kstack] = count(); }'
Attaching 1 probe...
^C

@[
    kvm_set_pfn_dirty+1
    __handle_changed_spte+2535
    __tdp_mmu_set_spte+396
    zap_gfn_range+2229
    kvm_tdp_mmu_unmap_gfn_range+331
    kvm_unmap_gfn_range+774
    kvm_mmu_notifier_invalidate_range_start+743
    __mmu_notifier_invalidate_range_start+508
    unmap_vmas+566
    unmap_region+494
    __do_munmap+1172
    __vm_munmap+226
    __x64_sys_munmap+98
    do_syscall_64+64
    entry_SYSCALL_64_after_hwframe+68
]: 1
@[
    kvm_set_pfn_dirty+1
    __handle_changed_spte+2535
    __tdp_mmu_set_spte+396
    zap_gfn_range+2229
    kvm_tdp_mmu_unmap_gfn_range+331
    kvm_unmap_gfn_range+774
    kvm_mmu_notifier_invalidate_range_start+743
    __mmu_notifier_invalidate_range_start+508
    zap_page_range_single+870
    unmap_mapping_pages+434
    shmem_fallocate+2518
    vfs_fallocate+684
    __x64_sys_fallocate+181
    do_syscall_64+64
    entry_SYSCALL_64_after_hwframe+68
]: 32
@[
    kvm_set_pfn_dirty+1
    __handle_changed_spte+2535
    __handle_changed_spte+1746
    __handle_changed_spte+1746
    __handle_changed_spte+1746
    __tdp_mmu_set_spte+396
    zap_gfn_range+2229
    __kvm_tdp_mmu_zap_gfn_range+162
    kvm_tdp_mmu_zap_all+34
    kvm_mmu_zap_all+518
    kvm_mmu_notifier_release+83
    __mmu_notifier_release+420
    exit_mmap+965
    mmput+167
    do_exit+2482
    do_group_exit+236
    get_signal+1000
    arch_do_signal_or_restart+580
    exit_to_user_mode_prepare+300
    syscall_exit_to_user_mode+25
    do_syscall_64+77
    entry_SYSCALL_64_after_hwframe+68
]: 365

For "bad" runs, when I get the warning - I get this:

# bpftrace -e 'kprobe:kvm_set_pfn_dirty { @[kstack] = count(); }'
Attaching 1 probe...
^C

@[
    kvm_set_pfn_dirty+1
    __handle_changed_spte+2535
    __tdp_mmu_set_spte+396
    zap_gfn_range+2229
    kvm_tdp_mmu_unmap_gfn_range+331
    kvm_unmap_gfn_range+774
    kvm_mmu_notifier_invalidate_range_start+743
    __mmu_notifier_invalidate_range_start+508
    unmap_vmas+566
    unmap_region+494
    __do_munmap+1172
    __vm_munmap+226
    __x64_sys_munmap+98
    do_syscall_64+64
    entry_SYSCALL_64_after_hwframe+68
]: 1
@[
    kvm_set_pfn_dirty+1
    __handle_changed_spte+2535
    __handle_changed_spte+1746
    __handle_changed_spte+1746
    __handle_changed_spte+1746
    __tdp_mmu_set_spte+396
    zap_gfn_range+2229
    kvm_tdp_mmu_put_root+465
    mmu_free_root_page+537
    kvm_mmu_free_roots+629
    kvm_mmu_unload+28
    kvm_arch_destroy_vm+510
    kvm_put_kvm+1017
    kvm_vcpu_release+78
    __fput+516
    task_work_run+206
    do_exit+2615
    do_group_exit+236
    get_signal+1000
    arch_do_signal_or_restart+580
    exit_to_user_mode_prepare+300
    syscall_exit_to_user_mode+25
    do_syscall_64+77
    entry_SYSCALL_64_after_hwframe+68
]: 2
@[
    kvm_set_pfn_dirty+1
    __handle_changed_spte+2535
    __tdp_mmu_set_spte+396
    zap_gfn_range+2229
    kvm_tdp_mmu_unmap_gfn_range+331
    kvm_unmap_gfn_range+774
    kvm_mmu_notifier_invalidate_range_start+743
    __mmu_notifier_invalidate_range_start+508
    zap_page_range_single+870
    unmap_mapping_pages+434
    shmem_fallocate+2518
    vfs_fallocate+684
    __x64_sys_fallocate+181
    do_syscall_64+64
    entry_SYSCALL_64_after_hwframe+68
]: 32
@[
    kvm_set_pfn_dirty+1
    __handle_changed_spte+2535
    __handle_changed_spte+1746
    __handle_changed_spte+1746
    __handle_changed_spte+1746
    __tdp_mmu_set_spte+396
    zap_gfn_range+2229
    __kvm_tdp_mmu_zap_gfn_range+162
    kvm_tdp_mmu_zap_all+34
    kvm_mmu_zap_all+518
    kvm_mmu_notifier_release+83
    __mmu_notifier_release+420
    exit_mmap+965
    mmput+167
    do_exit+2482
    do_group_exit+236
    get_signal+1000
    arch_do_signal_or_restart+580
    exit_to_user_mode_prepare+300
    syscall_exit_to_user_mode+25
    do_syscall_64+77
    entry_SYSCALL_64_after_hwframe+68
]: 344

That is, I never get a stack with
kvm_tdp_mmu_put_root->..->kvm_set_pfn_dirty with a "good" run.
Perhaps, this may shed some light onto what is going on.

Ignat

  reply	other threads:[~2021-12-10 23:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-29 21:44 Potential bug in TDP MMU Ignat Korchagin
2021-11-30  9:29 ` Paolo Bonzini
2021-11-30 10:58   ` Ignat Korchagin
2021-11-30 10:59     ` Ignat Korchagin
2021-11-30 11:11     ` Paolo Bonzini
2021-11-30 11:19       ` Ignat Korchagin
2021-11-30 11:43         ` Ignat Korchagin
2021-11-30 11:49           ` Paolo Bonzini
2021-11-30 12:13           ` Paolo Bonzini
2021-11-30 20:23     ` Sean Christopherson
2021-12-01 23:44       ` Ignat Korchagin
2021-12-10 23:04         ` Ignat Korchagin [this message]
2021-12-11  1:34           ` David Matlack
2021-12-11  1:49             ` Paolo Bonzini
2021-12-11 17:46               ` David Matlack
2021-12-11  1:37           ` Paolo Bonzini
2021-12-11  2:39           ` Sean Christopherson
2021-12-11  9:38             ` Ignat Korchagin
2021-12-11 20:49             ` Paolo Bonzini
2021-12-13 16:14               ` Sean Christopherson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALrw=nE+yGtRi-0bFFwXa9R8ydHKV7syRYeAYuC0EBTvdFiidQ@mail.gmail.com' \
    --to=ignat@cloudflare.com \
    --cc=kernel-team@cloudflare.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=stevensd@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.