kernel/linux.git, branch v5.12.15

Linux 5.12.15

2021-07-07T12:26:52+00:00

Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Justin M. Forbes Signed-off-by: Sasha Levin

Revert "KVM: x86/mmu: Drop kvm_mmu_extended_role.cr4_la57 hack"

2021-07-07T12:22:39+00:00

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

gpio: AMD8111 and TQMX86 require HAS_IOPORT_MAP

2021-07-07T12:22:39+00:00

[ Upstream commit c6414e1a2bd26b0071e2b9d6034621f705dfd4c0 ] Both of these drivers use ioport_map(), so they need to depend on HAS_IOPORT_MAP. Otherwise, they cannot be built even with COMPILE_TEST on architectures without an ioport implementation, such as ARCH=um. Reported-by: kernel test robot Signed-off-by: Johannes Berg Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin

drm/nouveau: fix dma_address check for CPU/GPU sync

2021-07-07T12:22:38+00:00

[ Upstream commit d330099115597bbc238d6758a4930e72b49ea9ba ] AGP for example doesn't have a dma_address array. Signed-off-by: Christian König Acked-by: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20210614110517.1624-1-christian.koenig@amd.com Signed-off-by: Sasha Levin

gpio: mxc: Fix disabled interrupt wake-up support

2021-07-07T12:22:38+00:00

[ Upstream commit 3093e6cca3ba7d47848068cb256c489675125181 ] A disabled/masked interrupt marked as wakeup source must be re-enable and unmasked in order to be able to wake-up the host. That can be done by flaging the irqchip with IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND. Note: It 'sometimes' works without that change, but only thanks to the lazy generic interrupt disabling (keeping interrupt unmasked). Reported-by: Michal Koziel Signed-off-by: Loic Poulain Reviewed-by: Linus Walleij Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin

s390/vfio-ap: clean up mdev resources when remove callback invoked

2021-07-07T12:22:38+00:00

[ Upstream commit 8c0795d2a0f50e2b131f5b2a8c2795939a94058e ] The mdev remove callback for the vfio_ap device driver bails out with -EBUSY if the mdev is in use by a KVM guest (i.e., the KVM pointer in the struct ap_matrix_mdev is not NULL). The intended purpose was to prevent the mdev from being removed while in use. There are two problems with this scenario: 1. Returning a non-zero return code from the remove callback does not prevent the removal of the mdev. 2. The KVM pointer in the struct ap_matrix_mdev will always be NULL because the remove callback will not get invoked until the mdev fd is closed. When the mdev fd is closed, the mdev release callback is invoked and clears the KVM pointer from the struct ap_matrix_mdev. Let's go ahead and remove the check for KVM in the remove callback and allow the cleanup of mdev resources to proceed. Signed-off-by: Tony Krowiak Reviewed-by: Jason Gunthorpe Link: https://lore.kernel.org/r/20210609224634.575156-2-akrowiak@linux.ibm.com Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin

scsi: sr: Return appropriate error code when disk is ejected

2021-07-07T12:22:38+00:00

[ Upstream commit 7dd753ca59d6c8cc09aa1ed24f7657524803c7f3 ] Handle a reported media event code of 3. This indicates that the media has been removed from the drive and user intervention is required to proceed. Return DISK_EVENT_EJECT_REQUEST in that case. Link: https://lore.kernel.org/r/20210611094402.23884-1-limanyi@uniontech.com Signed-off-by: ManYi Li Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

Linux 5.12.14

2021-06-30T13:03:25+00:00

Tested-by: Fox Chen Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Signed-off-by: Sasha Levin

integrity: Load mokx variables into the blacklist keyring

2021-06-30T12:47:09+00:00

[ Upstream commit ebd9c2ae369a45bdd9f8615484db09be58fc242b ] During boot the Secure Boot Forbidden Signature Database, dbx, is loaded into the blacklist keyring. Systems booted with shim have an equivalent Forbidden Signature Database called mokx. Currently mokx is only used by shim and grub, the contents are ignored by the kernel. Add the ability to load mokx into the blacklist keyring during boot. Signed-off-by: Eric Snowberg Suggested-by: James Bottomley Signed-off-by: David Howells Reviewed-by: Jarkko Sakkinen cc: keyrings@vger.kernel.org Link: https://lore.kernel.org/r/c33c8e3839a41e9654f41cc92c7231104931b1d7.camel@HansenPartnership.com/ Link: https://lore.kernel.org/r/20210122181054.32635-5-eric.snowberg@oracle.com/ # v5 Link: https://lore.kernel.org/r/161428674320.677100.12637282414018170743.stgit@warthog.procyon.org.uk/ Link: https://lore.kernel.org/r/161433313205.902181.2502803393898221637.stgit@warthog.procyon.org.uk/ # v2 Link: https://lore.kernel.org/r/161529607422.163428.13530426573612578854.stgit@warthog.procyon.org.uk/ # v3 Signed-off-by: Sasha Levin

certs: Add ability to preload revocation certs

2021-06-30T12:47:09+00:00

[ Upstream commit d1f044103dad70c1cec0a8f3abdf00834fec8b98 ] Add a new Kconfig option called SYSTEM_REVOCATION_KEYS. If set, this option should be the filename of a PEM-formated file containing X.509 certificates to be included in the default blacklist keyring. DH Changes: - Make the new Kconfig option depend on SYSTEM_REVOCATION_LIST. - Fix SYSTEM_REVOCATION_KEYS=n, but CONFIG_SYSTEM_REVOCATION_LIST=y[1][2]. - Use CONFIG_SYSTEM_REVOCATION_LIST for extract-cert[3]. - Use CONFIG_SYSTEM_REVOCATION_LIST for revocation_certificates.o[3]. Signed-off-by: Eric Snowberg Acked-by: Jarkko Sakkinen Signed-off-by: David Howells cc: Randy Dunlap cc: keyrings@vger.kernel.org Link: https://lore.kernel.org/r/e1c15c74-82ce-3a69-44de-a33af9b320ea@infradead.org/ [1] Link: https://lore.kernel.org/r/20210303034418.106762-1-eric.snowberg@oracle.com/ [2] Link: https://lore.kernel.org/r/20210304175030.184131-1-eric.snowberg@oracle.com/ [3] Link: https://lore.kernel.org/r/20200930201508.35113-3-eric.snowberg@oracle.com/ Link: https://lore.kernel.org/r/20210122181054.32635-4-eric.snowberg@oracle.com/ # v5 Link: https://lore.kernel.org/r/161428673564.677100.4112098280028451629.stgit@warthog.procyon.org.uk/ Link: https://lore.kernel.org/r/161433312452.902181.4146169951896577982.stgit@warthog.procyon.org.uk/ # v2 Link: https://lore.kernel.org/r/161529606657.163428.3340689182456495390.stgit@warthog.procyon.org.uk/ # v3 Signed-off-by: Sasha Levin