Skip to content

ASoC: SOF: byt: fix IPC handled wrong issue - #341

Merged
plbossart merged 1 commit into
thesofproject:topic/sof-devfrom
keyonjie:sof-pr
Dec 5, 2018
Merged

ASoC: SOF: byt: fix IPC handled wrong issue#341
plbossart merged 1 commit into
thesofproject:topic/sof-devfrom
keyonjie:sof-pr

Conversation

@keyonjie

Copy link
Copy Markdown

Align with apl/cnl, to fix the issue with dmesg shows "error: rx list
empty but received ...", add mask check for interrupt handling.

Signed-off-by: Keyon Jie yang.jie@linux.intel.com

Only compile passed, any help on byt testing is appreciated.

Align with apl/cnl, to fix the issue with dmesg shows "error: rx list
empty but received ...", add mask check for interrupt handling.
Signed-off-by: Keyon Jie <yang.jie@linux.intel.com>

@plbossartplbossart left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see there are parallel PRs for firmware, please let me know when this has been tested and the fixes approved in firmware. Not going to merge is there is no matching code on the other side.

@keyonjie

Copy link
Copy Markdown
Author

@plbossart yes, that is thesofproject/sof#656, let's merge this after FW one is merged, though merging partially only don't have side effect actually.

@keyonjie

Copy link
Copy Markdown
Author

@plbossartthesofproject/sof#656 on FW side is merged.

@plbossart

Copy link
Copy Markdown
Member

ok, let's merge and test further.

@plbossart
plbossart merged commit ac14451 into thesofproject:topic/sof-devDec 5, 2018
oder-chiou pushed a commit to oder-chiou/linux-soundwire that referenced this pull request May 5, 2026
Add a test case which replaces an active ingress qdisc while keeping the
miniq in-tact during the transition period to the new clsact qdisc.
# ./vmtest.sh -- ./test_progs -t tc_link
[...]
./test_progs -t tc_link
[ 3.412871] bpf_testmod: loading out-of-tree module taints kernel.
[ 3.413343] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel
thesofproject#332 tc_links_after:OK
thesofproject#333 tc_links_append:OK
thesofproject#334 tc_links_basic:OK
thesofproject#335 tc_links_before:OK
thesofproject#336 tc_links_chain_classic:OK
thesofproject#337 tc_links_chain_mixed:OK
thesofproject#338 tc_links_dev_chain0:OK
thesofproject#339 tc_links_dev_cleanup:OK
thesofproject#340 tc_links_dev_mixed:OK
thesofproject#341 tc_links_ingress:OK
thesofproject#342 tc_links_invalid:OK
thesofproject#343 tc_links_prepend:OK
thesofproject#344 tc_links_replace:OK
thesofproject#345 tc_links_revision:OK
Summary: 14/0 PASSED, 0 SKIPPED, 0 FAILED
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Martin KaFai Lau <martin.lau@kernel.org>
Link: https://lore.kernel.org/r/20240708133130.11609-2-daniel@iogearbox.net
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
ujfalusi pushed a commit to ujfalusi/sof-linux that referenced this pull request Jul 29, 2026
…ng level
When recovering hugepages in the shadow MMU, verify that the base gfn of
the shadow page is actually contained within the target memslot, *before*
querying the max mapping level given the shadow page's gfn. Failure to
pre-check the validity of the gfn can lead to an out-of-bounds access to
the slot's lpage_info (which typically manifests as a host #PF because the
lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its
PTEs) that extends "below" the bounds of a memslot.
When faulting in memory for a guest, and the size of the guest mapping is
greater than KVM's (current) max mapping, then KVM will create a "direct"
shadow page (direct in that there are no gPTEs to shadow, and so the target
gfn is a direct calculation given the base gfn of the shadow page). The
hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB
mappings when dirty logging generates the guest > host mapping size case.
When the 4KiB restriction is lifted, then KVM can replace the shadow page
with a hugepage.
But if KVM originally used a smaller mapping than the guest because the
range of memory covered by the guest hugepage exceeds the bounds of a
memslot, then KVM will link a direct shadow page with a gfn that is outside
the bounds of the memslot being used to fault in memory. The rmap entry
added for the leaf mapping is correct and within bounds, but the gfn of the
leaf SPTE's parent shadow page will be out of bounds.
BUG: unable to handle page fault for address: ffffc90000806ffc
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0
Oops: Oops: 0000 [thesofproject#1] SMP
CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm thesofproject#341 PREEMPT
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm]
Call Trace:
<TASK>
kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm]
kvm_set_memslot+0x1ee/0x590 [kvm]
kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm]
kvm_vm_ioctl+0x9bf/0x15d0 [kvm]
__x64_sys_ioctl+0x8a/0xd0
do_syscall_64+0xb7/0xbb0
entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x7f21c0f1a9bf
</TASK>
Don't bother pre-checking the bounds of the potential hugepage, i.e. don't
check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also
within the memslot, as the checks performed by kvm_mmu_max_mapping_level()
are a superset of the basic bounds checks. I.e. pre-checking the full
range would be a dubious micro-optimization.
Fixes: 9eba50f ("KVM: x86/mmu: Consult max mapping level when zapping collapsible SPTEs")
Cc: stable@vger.kernel.org
Cc: David Matlack <dmatlack@google.com>
Cc: James Houghton <jthoughton@google.com>
Cc: Alexander Bulekov <bkov@amazon.com>
Cc: Fred Griffoul <fgriffo@amazon.co.uk>
Cc: Alexander Graf <graf@amazon.de>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Filippo Sironi <sironi@amazon.de>
Cc: Ivan Orlov <iorlov@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@keyonjie@plbossart