commit 3d13cb77d7e0a97881cabe17a6bd700617ea8d4a Author: Alexandre Frade Date: Wed Jul 7 15:39:55 2021 +0000 Linux 5.13.1-xanmod1 Signed-off-by: Alexandre Frade commit dfab9965acca301229e8ff35edea219b3e2b38cd Merge: 3d67869ba083 aaa1f5834d71 Author: Alexandre Frade Date: Wed Jul 7 15:36:10 2021 +0000 Merge tag 'v5.13.1' into 5.13 Linux 5.13.1 commit aaa1f5834d71fe7b687a0c41834bd8d4cc733d90 Author: Sasha Levin Date: Wed Jul 7 08:24:58 2021 -0400 Linux 5.13.1 Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Signed-off-by: Sasha Levin commit 7f6cbd0b3e1e8c96e1c8773bb3978825dec5d00a Author: Mel Gorman Date: Mon Jun 28 19:33:29 2021 -0700 mm/page_alloc: correct return value of populated elements if bulk array is populated commit ff4b2b4014cbffb3d32b22629252f4dc8616b0fe upstream. Dave Jones reported the following This made it into 5.13 final, and completely breaks NFSD for me (Serving tcp v3 mounts). Existing mounts on clients hang, as do new mounts from new clients. Rebooting the server back to rc7 everything recovers. The commit b3b64ebd3822 ("mm/page_alloc: do bulk array bounds check after checking populated elements") returns the wrong value if the array is already populated which is interpreted as an allocation failure. Dave reported this fixes his problem and it also passed a test running dbench over NFS. Link: https://lkml.kernel.org/r/20210628150219.GC3840@techsingularity.net Fixes: b3b64ebd3822 ("mm/page_alloc: do bulk array bounds check after checking populated elements") Signed-off-by: Mel Gorman Reported-by: Dave Jones Tested-by: Dave Jones Cc: Dan Carpenter Cc: Jesper Dangaard Brouer Cc: Vlastimil Babka Cc: [5.13+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5863699d23914b2526b519adc17cb02fb76c165f Author: Sean Christopherson Date: Tue Jun 22 10:56:50 2021 -0700 Revert "KVM: x86/mmu: Drop kvm_mmu_extended_role.cr4_la57 hack" commit f71a53d1180d5ecc346f0c6a23191d837fe2871b upstream. Restore CR4.LA57 to the mmu_role to fix an amusing edge case with nested virtualization. When KVM (L0) is using TDP, CR4.LA57 is not reflected in mmu_role.base.level because that tracks the shadow root level, i.e. TDP level. Normally, this is not an issue because LA57 can't be toggled while long mode is active, i.e. the guest has to first disable paging, then toggle LA57, then re-enable paging, thus ensuring an MMU reinitialization. But if L1 is crafty, it can load a new CR4 on VM-Exit and toggle LA57 without having to bounce through an unpaged section. L1 can also load a new CR3 on exit, i.e. it doesn't even need to play crazy paging games, a single entry PML5 is sufficient. Such shenanigans are only problematic if L0 and L1 use TDP, otherwise L1 and L2 share an MMU that gets reinitialized on nested VM-Enter/VM-Exit due to mmu_role.base.guest_mode. Note, in the L2 case with nested TDP, even though L1 can switch between L2s with different LA57 settings, thus bypassing the paging requirement, in that case KVM's nested_mmu will track LA57 in base.level. This reverts commit 8053f924cad30bf9f9a24e02b6c8ddfabf5202ea. Fixes: 8053f924cad3 ("KVM: x86/mmu: Drop kvm_mmu_extended_role.cr4_la57 hack") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210622175739.3610207-6-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman