Pull EFI fixes from Ingo Molnar:
"Various fixes all over the map: prevent boot crashes on HyperV,
classify UEFI randomness as bootloader randomness, fix EFI boot for
the Raspberry Pi2, fix efi_test permissions, etc"
* 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
efi/efi_test: Lock down /dev/efi_test and require CAP_SYS_ADMIN
x86, efi: Never relocate kernel below lowest acceptable address
efi: libstub/arm: Account for firmware reserved memory at the base of RAM
efi/random: Treat EFI_RNG_PROTOCOL output as bootloader randomness
efi/tpm: Return -EINVAL when determining tpm final events log size fails
efi: Make CONFIG_EFI_RCI2_TABLE selectable on x86 only
- Enable CPU errata workarounds for Broadcom Brahma-B53
- Enable CPU errata workarounds for Qualcomm Hydra/Kryo CPUs
- Fix initial dirty status of writeable, shared mappings
-----BEGIN PGP SIGNATURE-----
iQFEBAABCgAuFiEEPxTL6PPUbjXGY88ct6xw3ITBYzQFAl28HzAQHHdpbGxAa2Vy
bmVsLm9yZwAKCRC3rHDchMFjNH3gB/4hJoYsASohxTVEcILOp7gZQZd4zgMuF16Z
ci9XcUgmpT3LNQTqSYASDxZZylVdK7eEq4yUXFpe57D5WL6GyEBLDWr09O6qb6F1
p/IuyEkUjram8GzRZsdW3/i786m887T1VYtRg6C7GKU9dHTRzkZcPTklWqc1CsEN
u7KqLGzWHxRNNUVWFhEsn9kTSARVOMfqXfERcpc2f6E5olXz8E62K+av2NL3u5o7
JQqHFqi5iJB66qc0AvUxc7oq/+Hvtz5nQfFm0IWQvGy3dvZ/vTGxYwAW2f7t70SH
MGHT+MsqYEENDjunMKtdHZ+D3A1xkYcrsKgOBkSBTTVlgrSonCr/
=0QZC
-----END PGP SIGNATURE-----
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Will Deacon:
"These are almost exclusively related to CPU errata in CPUs from
Broadcom and Qualcomm where the workarounds were either not being
enabled when they should have been or enabled when they shouldn't have
been.
The only "interesting" fix is ensuring that writeable, shared mappings
are initially mapped as clean since we inadvertently broke the logic
back in v4.14 and then noticed the problem via code inspection the
other day.
The only critical issue we have outstanding is a sporadic NULL
dereference in the scheduler, which doesn't appear to be
arm64-specific and PeterZ is tearing his hair out over it at the
moment.
Summary:
- Enable CPU errata workarounds for Broadcom Brahma-B53
- Enable CPU errata workarounds for Qualcomm Hydra/Kryo CPUs
- Fix initial dirty status of writeable, shared mappings"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: apply ARM64_ERRATUM_843419 workaround for Brahma-B53 core
arm64: Brahma-B53 is SSB and spectre v2 safe
arm64: apply ARM64_ERRATUM_845719 workaround for Brahma-B53 core
arm64: cpufeature: Enable Qualcomm Falkor errata 1009 for Kryo
arm64: cpufeature: Enable Qualcomm Falkor/Kryo errata 1003
arm64: Ensure VM_WRITE|VM_SHARED ptes are clean by default
x86: fix MMU corner case with AMD nested paging disabled.
-----BEGIN PGP SIGNATURE-----
iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAl27ZC8UHHBib256aW5p
QHJlZGhhdC5jb20ACgkQv/vSX3jHroNw/wf9EN2AQuyfkwMxLdh2VlyMg9SzRBgn
SZt6EmC8Pbfqqri2pPlDh1e1rk5CdIKM3EtcnNYvbZddXuAiORLx62lQCKu9UWzJ
mfVpahjFdx+6wFCI2IUB66Qat/E34uFP91h8cKxdwuTrgeT1V+HeFomwqmVQVkym
urqEQSWJh6SLl3ZeeiuVaxQdcqq8dW+PChKwrLmgQ4Dz8aREHEbd9ukHAopcyE+T
L8B29LtrBh2KCZeH7g91d5hGgGFeJCd1q+rXKOJLvpPJCZ0fnxtL9Va3h2y4TIbF
utDAA17Hu5QmnAJw7Lh7nN0mHGPejbs763IaGrW2nrY70pVeO6bDMh8M2Q==
=w2Y0
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull kvm fixes from Paolo Bonzini:
"generic:
- fix memory leak on failure to create VM
x86:
- fix MMU corner case with AMD nested paging disabled"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: vmx, svm: always run with EFER.NXE=1 when shadow paging is active
kvm: call kvm_arch_destroy_vm if vm creation fails
kvm: Allocate memslots and buses before calling kvm_arch_init_vm
amdgpu:
- clang alignment fixes
- Updated golden settings
- navi: gpuvm, sdma and display fixes
- Freesync fix
- Gamma fix for DCN
- DP dongle detection fix
- vega10: Fix for undervolting
radeon:
- reenable kexec fix for ppc
scheduler:
- set an error if hw job failed
i915:
- fix PCH reference clock for HSW/BDW
- TGL display PLL doc fix
panfrost:
- warning fix
- runtime pm fix
- bad pointer dereference fix
v3d:
- memleak fix
etnaviv:
- memory corruption fix
- deadlock fix
- reintroduce lost debug message
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJdu786AAoJEAx081l5xIa+O5gQAKW+TAPJzM4iGs0fv7AgprTH
ts5uY9hTk1Toc3Tl9KhRZauy36dcfOvoo3RD+bqbJju6e+ouMlK0uUyJvC30mpEY
9WczrXMYL4qhcnxnkOiLw76RZOuEX5WM2YkVbrB4qdNU3N55ZukeXgtDr+e9hSzy
nI+X+/8sgQOeFy8oE7s9k/I8Tn8CIgXvzWzH3L7P1r+t+rKvHF2i0NdanNk9dwrs
e8WmkzQhw0sdkLxZKh9sWxw0EipqJkP5y+XsUwYvyL97XhMsw59YF/OXk4OXFTbu
uct22gf8nYj1MbW93IQkoN5JQ09G1nnwYsvFERfZWeKgAL5oXGMdZbfEhwxHaymG
fD0ce2brs0chQVK7RbN7UQ30XgZBsG3H5JdPXNHrcqiIKfsLqtUvqLM3CoSfokUu
PGNDDpbU9LLOjI7s6DqX1FulQTYeIs49l0TIcgAGp7fxwU3GQFmFO8COqn28b54y
IHSB8vXwOYxC0NFTE3/H5z9h5PIXKBgnyMHouUehg9dGjEnuX/M7hiDgUZDqPPQW
REAEaSlyUB9wDYQbw92QaMhNSbK7jR+X+TqFkYn3GAwtq8XLrSB6+EzgQhnDgOPs
GQc0X+E0WFE4NgWnDYkHhsylFKdLtNZ2eghtlGpE/S+3PjO2jhhTdyo8o39QoI/Y
agFin9YQphep0HWq6p3Y
=4aG/
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2019-11-01' of git://anongit.freedesktop.org/drm/drm
Pull drm fixes from Dave Airlie:
"This is the regular drm fixes pull request for 5.4-rc6. It's a bit
larger than I'd like but then last week was quieter than usual.
The main fixes are amdgpu, and the two bigger area are navi fixes
which are the newest GPU range so still getting actively fixed up, but
also a bunch of clang stack alignment fixes (as amdgpu uses double in
some places).
Otherwise it's all fairly run of the mill fixes, i915, panfrost,
etnaviv, v3d and radeon, along with a core scheduler fix.
Summary:
amdgpu:
- clang alignment fixes
- Updated golden settings
- navi: gpuvm, sdma and display fixes
- Freesync fix
- Gamma fix for DCN
- DP dongle detection fix
- vega10: Fix for undervolting
radeon:
- reenable kexec fix for ppc
scheduler:
- set an error if hw job failed
i915:
- fix PCH reference clock for HSW/BDW
- TGL display PLL doc fix
panfrost:
- warning fix
- runtime pm fix
- bad pointer dereference fix
v3d:
- memleak fix
etnaviv:
- memory corruption fix
- deadlock fix
- reintroduce lost debug message"
* tag 'drm-fixes-2019-11-01' of git://anongit.freedesktop.org/drm/drm: (29 commits)
drm/amdgpu: enable -msse2 for GCC 7.1+ users
drm/amdgpu: fix stack alignment ABI mismatch for GCC 7.1+
drm/amdgpu: fix stack alignment ABI mismatch for Clang
drm/radeon: Fix EEH during kexec
drm/amdgpu/gmc10: properly set BANK_SELECT and FRAGMENT_SIZE
drm/amdgpu/powerplay/vega10: allow undervolting in p7
dc.c:use kzalloc without test
drm/amd/display: setting the DIG_MODE to the correct value.
drm/amd/display: Passive DP->HDMI dongle detection fix
drm/amd/display: add 50us buffer as WA for pstate switch in active
drm/amd/display: Allow inverted gamma
drm/amd/display: do not synchronize "drr" displays
drm/amdgpu: If amdgpu_ib_schedule fails return back the error.
drm/sched: Set error to s_fence if HW job submission failed.
drm/amdgpu/gfx10: update gfx golden settings for navi12
drm/amdgpu/gfx10: update gfx golden settings for navi14
drm/amdgpu/gfx10: update gfx golden settings
drm/amd/display: Change Navi14's DWB flag to 1
drm/amdgpu/sdma5: do not execute 0-sized IBs (v2)
drm/amdgpu: Fix SDMA hang when performing VKexample test
...
Fix a recently introduced (mostly theoretical) issue that the requests
to confine the maximum CPU frequency coming from the platform firmware
may not be taken into account if multiple CPUs are covered by one
cpufreq policy on a system with ACPI.
-----BEGIN PGP SIGNATURE-----
iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAl27SPISHHJqd0Byand5
c29ja2kubmV0AAoJEILEb/54YlRxx/8P/2k+HUgBdNOmWe4I6XRx0cPuROZTS/IO
aaXB6CiT0jVauG5fsAgSs7Hddzd15S3TQ+Xb1bIWgeB84pLv7lSVTZdJlCO4X3gx
Hq8hQasRNfuhuk0Y8l8Me9ouY2B/MNtm9nuetU9s0ADAjbGuTU7thfDOtu1a9Bv1
6Jn+yaHhkq4oA9kkJH0A/jIACe8xVUygsPimzedPfLEQzri/5Y/USNmGefn8HF5D
pwLeQf6H1KIQcyP1XqzFPTGG4iRzdrPyBbYdFnrKVoUrNSug6zDzuXktiJgcLhHC
LKCpyoINM2N5mKc7JDEWfp+FbVy44Hz6LlZayS36uLRlemNNlGnXP43J1GLmEg6J
fX//EBVF3NwZ+Ms1v6kUy4Yev/ElS/S2t+6SxAeP5JcMLRXNPj+gCDMCfYMPbHAg
jFTQ4svJ20PqMSRFVfEi63RwHWzSuXzPtu4Hj+3Q6NP9Hir0z1GRwc7QdNUwtHKn
fEhSEAQHl/M8PrPUHkYYz5kyzuwdF/XARsRT5tOtSuVU0iXxLyd0pGy23018lKk1
JQKSBghmianHHhcO5AeTnRG9fIEqPD+JAPnjlMGssgmXsEn5E4yvev0S5ouaQRJg
y9yvjQZmNQZbcYsCxyeViFH4sgBf5F9OFo8Xz957UoKFnaQrx27+HpcZy/30md9k
htXCZbeItcc+
=dPAj
-----END PGP SIGNATURE-----
Merge tag 'pm-5.4-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fix from Rafael Wysocki:
"Fix a recently introduced (mostly theoretical) issue that the requests
to confine the maximum CPU frequency coming from the platform firmware
may not be taken into account if multiple CPUs are covered by one
cpufreq policy on a system with ACPI"
* tag 'pm-5.4-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: processor: Add QoS requests for all CPUs
A number of bug fixes and a regression fix:
- Various issues from static analysis in hfi1, uverbs, hns, and cxgb4
- Fix for deadlock in a case when the new auto RDMA module loading is
used
- Missing _irq notation in a prior -rc patch found by lockdep
- Fix a locking and lifetime issue in siw
- Minor functional bug fixes in cxgb4, mlx5, qedr
- Fix a regression where vlan interfaces no longer worked with RDMA CM in
some cases
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEfB7FMLh+8QxL+6i3OG33FX4gmxoFAl27JLIACgkQOG33FX4g
mxqJbBAAj+ZpUkpwCzOcP09bxyEIX38j/22AqHFQ6MWA5FWkvEDrGAsTxYRArKHv
dXq1kHd/ofX3TSR5beFdldoz6chjfqaq3whJEpGv22sDvUNATKl+5YnU1vdrgEGR
ApimSV90s5lGwdZ3NaVWQHvH6vzwyTjR9sS1xd/uIYku9hvWimaQVw0Phutf6qVW
GIem0fHRQihKwzg/kd3fk9u7ac9o43gSSWSSBQoBlT/PD6T8QOv1yLZ9BEAicynt
6QGt/6QbNfidm5R9iuKB+TIPt/6j3ISVUqGLEQCSKBj122uT6s+u9lZnUFu4LRkp
AfBL18RUlCFnNiiEVJSfxwSm9GMZdyZQlmmLTnO+DLugWpaarr8PNkpjlTVP1Oyh
JpEG/blf8pOU3ZMEVwVBHE/1NMs0x5Rp4u1eccNVNM4rh9FyHEnllKYeMA8rz7tz
7JgnueyMvMVVvXMQ14A2Zx+6kBdDQyAHMEBiZujRr7P1PDsocHZDrCIN/ouAIzPS
tZLoiTToaaG84+HdzhF+swKAqXouwSh8Feu9zG/XzULn2yJip0pZV5Uuqj5FB5nP
R19wcCG5ehW84XUgpStK3FpXpw2pmPaI/aZbiiNkD6kbDW/rs7uhKBd87yFFxMfV
50SoFWZUYMNqkGe0NeEvDuYMONOFI372v40zB4jMQDzb8wTXZ6Q=
=MHSu
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma
Pull rdma fixes from Jason Gunthorpe:
"A number of bug fixes and a regression fix:
- Various issues from static analysis in hfi1, uverbs, hns, and cxgb4
- Fix for deadlock in a case when the new auto RDMA module loading is
used
- Missing _irq notation in a prior -rc patch found by lockdep
- Fix a locking and lifetime issue in siw
- Minor functional bug fixes in cxgb4, mlx5, qedr
- Fix a regression where vlan interfaces no longer worked with RDMA
CM in some cases"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma:
RDMA/hns: Prevent memory leaks of eq->buf_list
RDMA/iw_cxgb4: Avoid freeing skb twice in arp failure case
RDMA/mlx5: Use irq xarray locking for mkey_table
IB/core: Avoid deadlock during netlink message handling
RDMA/nldev: Skip counter if port doesn't match
RDMA/uverbs: Prevent potential underflow
IB/core: Use rdma_read_gid_l2_fields to compare GID L2 fields
RDMA/qedr: Fix reported firmware version
RDMA/siw: free siw_base_qp in kref release routine
RDMA/iwcm: move iw_rem_ref() calls out of spinlock
iw_cxgb4: fix ECN check on the passive accept
IB/hfi1: Use a common pad buffer for 9B and 16B packets
IB/hfi1: Avoid excessive retry for TID RDMA READ request
RDMA/mlx5: Clear old rate limit when closing QP
A copule of regression fixes and a fix for mutex deadlock at
hog-unplug, as well as other device-specific fixes:
- A commit for avoiding the spurious unsolicited interrupt on HD-
audio bus caused a stall at shutdown, so it's reverted now.
- The recent support of AMD/Nvidia audio component binding caused
a mutex deadlock; fixed by splitting to another mutex
- The device hot-unplug and the ALSA timer close combo may lead to
another mutex deadlock; fixed by moving put_device() calls
- Usual device-specific small quirks for HD- and USB-audio drivers
- An old error check fix in FireWire driver
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAl26CfIOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE8rlRAAytCk4/fyNpxEk0IV7cfqMWKuqwtUiQlR7BNt
dGW0arnTDVfIonwYH2M83iDS7LgNOu1kw4ids3ofif8BLvmcaBr60pWkzWz3PITN
e4+eY4JEVmkXHjVcZxwarzDOpo3XPI7PAM07fbE76IkrPFasFvUXBARF8RQqRQy2
JmrJF99ylOM/YATT6faw6qFiDa+ZMU8HYfa+Rj+GPKQAgQupEBIgyvt35nxAupHM
rPn3IwXaYq6TQTPeZB8dH0GJzEHKLwozfQoqRzO6Zjwlg7dVhyUYOYDW2ID4I0ci
KMs9RRRx3Ai7Id1nECJw6adwIlqviNzQntlpzvvQT7SAGGQebNeVET+1+7GLPEM/
ZvGi2nmIZpNU5nHde+4XLuRfFjJawzyNjA9ud7S3XnXJbO6m9Lgmx34EQ86KLd9g
zr4aJL6343NSICoco4FHqfQ+YmWxV3Jc2Dsz2zrS20Xw/rokei1ngpL/+N9EVE6T
qCOwP6TzsafsRsuqV2fPx+dswYnUQfiFxfer6eRRx+B74d274qepPAJTgnPbknQt
xaC4CwYRKe1HMSsUwgKQV0XSduwXI5fAc7n7gikYYxbabAseycz3xHxS6csqbRaq
Kjom6F7BI43cQSHXlfLNEnMHtnkE+x9cx1ymO0BJzVojtNCL/Syx3JpNBUFJXP9/
8Rn1qfA=
=Qt/i
-----END PGP SIGNATURE-----
Merge tag 'sound-5.4-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"A couple of regression fixes and a fix for mutex deadlock at
hog-unplug, as well as other device-specific fixes:
- A commit to avoid the spurious unsolicited interrupt on HD-audio
bus caused a stall at shutdown, so it's reverted now.
- The recent support of AMD/Nvidia audio component binding caused a
mutex deadlock; fixed by splitting to another mutex
- The device hot-unplug and the ALSA timer close combo may lead to
another mutex deadlock; fixed by moving put_device() calls
- Usual device-specific small quirks for HD- and USB-audio drivers
- An old error check fix in FireWire driver"
* tag 'sound-5.4-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: timer: Fix mutex deadlock at releasing card
ALSA: hda - Fix mutex deadlock in HDMI codec driver
Revert "ALSA: hda: Flush interrupts on disabling"
ALSA: bebob: Fix prototype of helper function to return negative value
ALSA: hda/realtek - Fix 2 front mics of codec 0x623
ALSA: hda/realtek - Add support for ALC623
ALSA: usb-audio: Add DSD support for Gustard U16/X26 USB Interface
The Broadcom Brahma-B53 core is susceptible to the issue described by
ARM64_ERRATUM_843419 so this commit enables the workaround to be applied
when executing on that core.
Since there are now multiple entries to match, we must convert the
existing ARM64_ERRATUM_843419 into an erratum list and use
cpucap_multi_entry_cap_matches to match our entries.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Will Deacon <will@kernel.org>
Add the Brahma-B53 CPU (all versions) to the whitelists of CPUs for the
SSB and spectre v2 mitigations.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Will Deacon <will@kernel.org>
The Broadcom Brahma-B53 core is susceptible to the issue described by
ARM64_ERRATUM_845719 so this commit enables the workaround to be applied
when executing on that core.
Since there are now multiple entries to match, we must convert the
existing ARM64_ERRATUM_845719 into an erratum list.
Signed-off-by: Doug Berger <opendmb@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Will Deacon <will@kernel.org>
runtime_pm and one to prevent bogus pointer dereferences
- one fix for a memleak in v3d
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXbnUpgAKCRDj7w1vZxhR
xQu2AQCrrb55ZigyN9XuPcrf0vjuRJJjyVZjBaTMqX9j72M9owEArHEYUUlFgI8K
9J4LCwIXEU69jQiTtFngiRHQVFZUYAs=
=BEcB
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-fixes-2019-10-30-1' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
- three fixes for panfrost, one to silence a warning, one to fix
runtime_pm and one to prevent bogus pointer dereferences
- one fix for a memleak in v3d
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191030182207.evrscl7lnv42u5zu@hendrix
The Kryo cores share errata 1009 with Falkor, so add their model
definitions and enable it for them as well.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[will: Update entry in silicon-errata.rst]
Signed-off-by: Will Deacon <will@kernel.org>
VMX already does so if the host has SMEP, in order to support the combination of
CR0.WP=1 and CR4.SMEP=1. However, it is perfectly safe to always do so, and in
fact VMX already ends up running with EFER.NXE=1 on old processors that lack the
"load EFER" controls, because it may help avoiding a slow MSR write. Removing
all the conditionals simplifies the code.
SVM does not have similar code, but it should since recent AMD processors do
support SMEP. So this patch also makes the code for the two vendors more similar
while fixing NPT=0, CR0.WP=1 and CR4.SMEP=1 on AMD processors.
Cc: stable@vger.kernel.org
Cc: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In kvm_create_vm(), if we've successfully called kvm_arch_init_vm(), but
then fail later in the function, we need to call kvm_arch_destroy_vm()
so that it can do any necessary cleanup (like freeing memory).
Fixes: 44a95dae1d ("KVM: x86: Detect and Initialize AVIC support")
Signed-off-by: John Sperbeck <jsperbeck@google.com>
Signed-off-by: Jim Mattson <jmattson@google.com>
Reviewed-by: Junaid Shahid <junaids@google.com>
[Remove dependency on "kvm: Don't clear reference count on
kvm_create_vm() error path" which was not committed. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The driver exposes EFI runtime services to user-space through an IOCTL
interface, calling the EFI services function pointers directly without
using the efivar API.
Disallow access to the /dev/efi_test character device when the kernel is
locked down to prevent arbitrary user-space to call EFI runtime services.
Also require CAP_SYS_ADMIN to open the chardev to prevent unprivileged
users to call the EFI runtime services, instead of just relying on the
chardev file mode bits for this.
The main user of this driver is the fwts [0] tool that already checks if
the effective user ID is 0 and fails otherwise. So this change shouldn't
cause any regression to this tool.
[0]: https://wiki.ubuntu.com/FirmwareTestSuite/Reference/uefivarinfo
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Matthew Garrett <mjg59@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191029173755.27149-7-ardb@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Currently, kernel fails to boot on some HyperV VMs when using EFI.
And it's a potential issue on all x86 platforms.
It's caused by broken kernel relocation on EFI systems, when below three
conditions are met:
1. Kernel image is not loaded to the default address (LOAD_PHYSICAL_ADDR)
by the loader.
2. There isn't enough room to contain the kernel, starting from the
default load address (eg. something else occupied part the region).
3. In the memmap provided by EFI firmware, there is a memory region
starts below LOAD_PHYSICAL_ADDR, and suitable for containing the
kernel.
EFI stub will perform a kernel relocation when condition 1 is met. But
due to condition 2, EFI stub can't relocate kernel to the preferred
address, so it fallback to ask EFI firmware to alloc lowest usable memory
region, got the low region mentioned in condition 3, and relocated
kernel there.
It's incorrect to relocate the kernel below LOAD_PHYSICAL_ADDR. This
is the lowest acceptable kernel relocation address.
The first thing goes wrong is in arch/x86/boot/compressed/head_64.S.
Kernel decompression will force use LOAD_PHYSICAL_ADDR as the output
address if kernel is located below it. Then the relocation before
decompression, which move kernel to the end of the decompression buffer,
will overwrite other memory region, as there is no enough memory there.
To fix it, just don't let EFI stub relocate the kernel to any address
lower than lowest acceptable address.
[ ardb: introduce efi_low_alloc_above() to reduce the scope of the change ]
Signed-off-by: Kairui Song <kasong@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191029173755.27149-6-ardb@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The EFI stubloader for ARM starts out by allocating a 32 MB window
at the base of RAM, in order to ensure that the decompressor (which
blindly copies the uncompressed kernel into that window) does not
overwrite other allocations that are made while running in the context
of the EFI firmware.
In some cases, (e.g., U-Boot running on the Raspberry Pi 2), this is
causing boot failures because this initial allocation conflicts with
a page of reserved memory at the base of RAM that contains the SMP spin
tables and other pieces of firmware data and which was put there by
the bootloader under the assumption that the TEXT_OFFSET window right
below the kernel is only used partially during early boot, and will be
left alone once the memory reservations are processed and taken into
account.
So let's permit reserved memory regions to exist in the region starting
at the base of RAM, and ending at TEXT_OFFSET - 5 * PAGE_SIZE, which is
the window below the kernel that is not touched by the early boot code.
Tested-by: Guillaume Gardet <Guillaume.Gardet@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Chester Lin <clin@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191029173755.27149-5-ardb@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Commit 428826f535 ("fdt: add support for rng-seed") introduced
add_bootloader_randomness(), permitting randomness provided by the
bootloader or firmware to be credited as entropy. However, the fact
that the UEFI support code was already wired into the RNG subsystem
via a call to add_device_randomness() was overlooked, and so it was
not converted at the same time.
Note that this UEFI (v2.4 or newer) feature is currently only
implemented for EFI stub booting on ARM, and further note that
CONFIG_RANDOM_TRUST_BOOTLOADER must be enabled, and this should be
done only if there indeed is sufficient trust in the bootloader
_and_ its source of randomness.
[ ardb: update commit log ]
Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191029173755.27149-4-ardb@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Currently nothing checks the return value of efi_tpm_eventlog_init(),
but in case that changes in the future make sure an error is
returned when it fails to determine the tpm final events log
size.
Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Fixes: e658c82be5 ("efi/tpm: Only set 'efi_tpm_final_log_size' after ...")
Link: https://lkml.kernel.org/r/20191029173755.27149-3-ardb@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
For the EFI_RCI2_TABLE Kconfig option, 'make oldconfig' asks the user
for input on platforms where the option may not be applicable. This patch
modifies the Kconfig option to ask the user for input only when CONFIG_X86
or CONFIG_COMPILE_TEST is set to y.
Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Narendra K <Narendra.K@dell.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191029173755.27149-2-ardb@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Few fixes on the dmaengine drivers:
- fix in sprd driver for link list and potential memory leak
- tegra transfer failure fix
- imx size check fix for script_number
- xilinx fix for 64bit AXIDMA and control reg update
- qcom bam dma resource leak fix
- cppi slave transfer fix when idle
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE+vs47OPLdNbVcHzyfBQHDyUjg0cFAl26hEgACgkQfBQHDyUj
g0cAjRAAweFLgnBti+Cqb3mjbHxYfSknw/4CNis5XvhXfCGUupgqQQfL1mjH1ZGv
GPz0lOjgkaUwtioxMrIqGSc/7MCsHOK02kktfY87SSraSQrKF2Hl9Y0KRYu8FIWW
AFvmbhXAtLqRY87r6K/S7LzQzSrYjfGHxHV5ShsA18+2Y2gtuQQ2V6nbkjZquOle
So27cjAZXYQJP9YI2DJXpcgwe2DSO2cgfcLH58t6Prw4/piJf7P1Qhs/ng5Egfbe
RahP8AdTSjRf2ylVHngaM5EFuDsjn/uslEfh93dL4gQH/NWqNgTbk02R0HtwrRjs
F8EVNsDqVjWrc1D/tKWUucYVMDdGHmNovN0sGESbuVBgUKwqjrhLMrEzxs2d0cgN
h2YRbPnAHRmO/F0x789TGFsw3BU0T/gAl+LrVFUBCKvhwtEtsG6rmX1wjSVca3lM
zMhV9oipMUBPSVQQhyIf/yizEqw0YkgFKelQppb6e/I+OBgQGYchgaiQtbNcI4L2
jOkQ7dsFPL8a8bmN+r38IzJMjHp5F+Govuc+1nmhuALpGxgBtmEqzgzBiP3AZgcJ
XjkKW3IQdK+TAcqA6eDFLlm33Npe+flXQ/QvJlpYfHLDzZx2CNQExaFVo4meNwDu
iGajKgP9DhO6l7uaep2mDxMPz7u/edhfvHy6cjWUIH9KjwPZ64w=
=e87E
-----END PGP SIGNATURE-----
Merge tag 'dmaengine-fix-5.4-rc6' of git://git.infradead.org/users/vkoul/slave-dma
Pull dmaengine fixes from Vinod Koul:
"A few fixes to the dmaengine drivers:
- fix in sprd driver for link list and potential memory leak
- tegra transfer failure fix
- imx size check fix for script_number
- xilinx fix for 64bit AXIDMA and control reg update
- qcom bam dma resource leak fix
- cppi slave transfer fix when idle"
* tag 'dmaengine-fix-5.4-rc6' of git://git.infradead.org/users/vkoul/slave-dma:
dmaengine: cppi41: Fix cppi41_dma_prep_slave_sg() when idle
dmaengine: qcom: bam_dma: Fix resource leak
dmaengine: sprd: Fix the possible memory leak issue
dmaengine: xilinx_dma: Fix control reg update in vdma_channel_set_config
dmaengine: xilinx_dma: Fix 64-bit simple AXIDMA transfer
dmaengine: imx-sdma: fix size check for sdma script_number
dmaengine: tegra210-adma: fix transfer failure
dmaengine: sprd: Fix the link-list pointer register configuration issue
When a card is disconnected while in use, the system waits until all
opened files are closed then releases the card. This is done via
put_device() of the card device in each device release code.
The recently reported mutex deadlock bug happens in this code path;
snd_timer_close() for the timer device deals with the global
register_mutex and it calls put_device() there. When this timer
device is the last one, the card gets freed and it eventually calls
snd_timer_free(), which has again the protection with the global
register_mutex -- boom.
Basically put_device() call itself is race-free, so a relative simple
workaround is to move this put_device() call out of the mutex. For
achieving that, in this patch, snd_timer_close_locked() got a new
argument to store the card device pointer in return, and each caller
invokes put_device() with the returned object after the mutex unlock.
Reported-and-tested-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A final attempt at enabling sse2 for GCC users.
Orininally attempted in:
commit 1011745073 ("drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines")
Reverted due to "reported instability" in:
commit 193392ed9f ("Revert "drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines"")
Re-added just for Clang in:
commit 0f0727d971 ("drm/amd/display: readd -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines")
The original report didn't have enough information to know if the GPF
was due to misalignment, but I suspect that it was. (The missing
information was the disassembly of the function at the bottom of the
trace, to see if the instruction pointer pointed to an instruction with
16B alignment memory operand requirements. The stack trace does show
the stack was only 8B but not 16B aligned though, which makes this a
strong possibility).
Now that the stack misalignment issue has been fixed for users of GCC
7.1+, reattempt adding -msse2. This matches Clang.
It will likely never be safe to enable this for pre-GCC 7.1 AND use a
16B aligned stack in these translation units.
This is only a functional change for GCC 7.1+ users, and should be boot
tested.
Link: https://bugs.freedesktop.org/show_bug.cgi?id=109487
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
GCC earlier than 7.1 errors when compiling code that makes use of
`double`s and sets a stack alignment outside of the range of [2^4-2^12]:
$ cat foo.c
double foo(double x, double y) {
return x + y;
}
$ gcc-4.9 -mpreferred-stack-boundary=3 foo.c
error: -mpreferred-stack-boundary=3 is not between 4 and 12
This is likely why the AMDGPU driver was ever compiled with a different
stack alignment (and thus different ABI) than the rest of the x86
kernel. The kernel uses 8B stack alignment, while the driver was using
16B stack alignment in a few places.
Since GCC 7.1+ doesn't error, fix the ABI mismatch for users of newer
versions of GCC.
There was discussion about whether to mark the driver broken or not for
users of GCC earlier than 7.1, but since the driver currently is
working, don't explicitly break the driver for them here.
Relying on differing stack alignment is unspecified behavior, and
brittle, and may break in the future.
This patch is no functional change for GCC users earlier than 7.1. It's
been compile tested on GCC 4.9 and 8.3 to check the correct flags. It
should be boot tested when built with GCC 7.1+.
-mincoming-stack-boundary= or -mstackrealign may help keep this code
building for pre-GCC 7.1 users.
The version check for GCC is broken into two conditionals, both because
cc-ifversion is currently GCC specific, and it simplifies a subsequent
patch.
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The x86 kernel is compiled with an 8B stack alignment via
`-mpreferred-stack-boundary=3` for GCC since 3.6-rc1 via
commit d9b0cde91c ("x86-64, gcc: Use -mpreferred-stack-boundary=3 if supported")
or `-mstack-alignment=8` for Clang. Parts of the AMDGPU driver are
compiled with 16B stack alignment.
Generally, the stack alignment is part of the ABI. Linking together two
different translation units with differing stack alignment is dangerous,
particularly when the translation unit with the smaller stack alignment
makes calls into the translation unit with the larger stack alignment.
While 8B aligned stacks are sometimes also 16B aligned, they are not
always.
Multiple users have reported General Protection Faults (GPF) when using
the AMDGPU driver compiled with Clang. Clang is placing objects in stack
slots assuming the stack is 16B aligned, and selecting instructions that
require 16B aligned memory operands.
At runtime, syscall handlers with 8B aligned stack call into code that
assumes 16B stack alignment. When the stack is a multiple of 8B but not
16B, these instructions result in a GPF.
Remove the code that added compatibility between the differing compiler
flags, as it will result in runtime GPFs when built with Clang. Cleanups
for GCC will be sent in later patches in the series.
Link: https://github.com/ClangBuiltLinux/linux/issues/735
Debugged-by: Yuxuan Shui <yshuiv7@gmail.com>
Reported-by: Shirish S <shirish.s@amd.com>
Reported-by: Yuxuan Shui <yshuiv7@gmail.com>
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
During kexec some adapters hit an EEH since they are not properly
shut down in the radeon_pci_shutdown() function. Adding
radeon_suspend_kms() fixes this issue.
Enabled only on PPC because this patch causes issues on some other
boards.
Signed-off-by: Kyle Mahlkuch <kmahlkuc@linux.vnet.ibm.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
These were not aligned for optimal performance for GPUVM.
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tianci Yin <tianci.yin@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
The vega10_odn_update_soc_table() function does not allow the SCLK
dependent voltage to be set for power-state 7 to a value below the default
in pptable. Change the for-loop condition to allow undervolting in the
highest state.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205277
Signed-off-by: Pelle van Gils <pelle@vangils.xyz>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
dc.c:583:null check is needed after using kzalloc function
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: zhongshiqi <zhong.shiqi@zte.com.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
This patch is for fixing Navi14 HDMI display pink screen issue.
[How]
Call stream->link->link_enc->funcs->setup twice. This is setting
the DIG_MODE to the correct value after having been overridden by
the call to transmitter control.
Signed-off-by: Zhan Liu <zhan.liu@amd.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[WHY]
i2c_read is called to differentiate passive DP->HDMI and DP->DVI-D dongles
The call is expected to fail in DVI-D case but pass in HDMI case
Some HDMI dongles have a chance to fail as well, causing misdetection as DVI-D
[HOW]
Retry i2c_read to ensure failed result is valid
Signed-off-by: Michael Strauss <michael.strauss@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jun Lei <Jun.Lei@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
There's a use case for inverted gamma
and it's been confirmed that negative slopes are ok.
[how]
Remove code for blocking non-monotonically increasing gamma
Signed-off-by: Aidan Yang <Aidan.Yang@amd.com>
Reviewed-by: Krunoslav Kovac <Krunoslav.Kovac@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Acked-by: Reza Amini <Reza.Amini@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
A display that supports DRR can never really be considered
"synchronized" with any other display because we can dynamically
enable DRR (i.e. without modeset). this will cause their
relative CRTC positions to drift and lose sync. this will disrupt
features such as MCLK switching that assume and depend on
their permanent alignment (that can only change with modeset)
[how]
check for ignore_msa in stream when considered synchronizability
this ignore_msa is basically actually implemented as "supports drr"
Signed-off-by: Jun Lei <Jun.Lei@amd.com>
Reviewed-by: Yongqiang Sun <yongqiang.sun@amd.com>
Acked-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Use ERR_PTR to return back the error happened during amdgpu_ib_schedule.
Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Problem:
When run_job fails and HW fence returned is NULL we still signal
the s_fence to avoid hangs but the user has no way of knowing if
the actual HW job was ran and finished.
Fix:
Allow .run_job implementations to return ERR_PTR in the fence pointer
returned and then set this error for s_fence->finished fence so whoever
wait on this fence can inspect the signaled fence for an error.
Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
DWB (Display Writeback) flag needs to be enabled as 1, or system
will throw out a few warnings when creating dcn20 resource pool.
Also, Navi14's dwb setting needs to match Navi10's,
which has already been set to 1.
[How]
Change value of num_dwb from 0 to 1.
Signed-off-by: Zhan Liu <zhan.liu@amd.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This seems to help with https://bugs.freedesktop.org/show_bug.cgi?id=111481.
v2: insert a NOP instead of skipping all 0-sized IBs to avoid breaking older hw
Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
VKexample test hang during Occlusion/SDMA/Varia runs.
Clear XNACK_WATERMK in reg SDMA0_UTCL1_WATERMK to fix this issue.
Signed-off-by: chen gong <curry.gong@amd.com>
Reviewed-by: Aaron Liu <aaron.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
The commit ade49db337 ("ALSA: hda/hdmi - Allow audio component for
AMD/ATI and Nvidia HDMI") introduced the spec->pcm_lock mutex lock to
the whole generic_hdmi_init() function for avoiding the race with the
audio component registration. However, this caused a dead lock when
the unsolicited event is handled without the audio component, as the
codec gets runtime-resumed in hdmi_present_sense() which is already
inside the spec->pcm_lock in its caller.
For avoiding this deadlock, add a new mutex only for the audio
component binding that is used in both generic_hdmi_init() and the
audio notifier registration where the jack callbacks are handled /
re-registered.
Fixes: ade49db337 ("ALSA: hda/hdmi - Allow audio component for AMD/ATI and Nvidia HDMI")
Reported-and-tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/s5himo7i89i.wl-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Including:
- Follow-on fix for Renesas IPMMU to get rid of a redundant
error message.
- Quirk for AMD IOMMU to make it work on another Acer Laptop
model with a broken IVRS ACPI table.
- Fix for a panic at kdump in the Intel IOMMU driver.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEr9jSbILcajRFYWYyK/BELZcBGuMFAl25hsUACgkQK/BELZcB
GuNl8hAAid3MRnf1p/k2W/a3OX6u3hAM0URTqKra5b6Dle8qWfJkcxyrRlcj9NBM
0IgRgHXrSCn9srIXhMuseZyasK88Kqao2ZzesUihCWPT4WRFXDL2SRhPSYiUAwLV
07H04VbVxzjJKDJeuyPyLhuUsYHEApYXVJcM/pBX1fXCPfuYquM9orIVIkY1N6iK
ncDiJDEP2sm///J5OvMFKfWKC5ZEAjUjKDvXMUTw3/VfIyUKsPQT5Jc8VdsOKJOx
DkadXp991IHfGnB4ZYGx7HBkaudTI5Fs6kPFvffQmGYKQBFnNzbcL1XKJe46ZvF9
PrfE3n3zgTAPjYynSGwpM6y2JsinX1iCTlzTkd9p7YY+0g/sVEKiMVkFocmgUmGU
fYzxBiigi1L6WWe/tKs8/gnBC/tuzZiAJzlSuZhLjLxbEhOZJunRze6hdH7401CN
JY4JtVgKijgzxqVhV3KOO0cOnzPR6uEfyIsPvs66scyYyjihooOOc+90MaOWPjNb
DfIoLkFyLM+50qViI3RJlkNpkhTqL+qCLZIkdcutIUdPP/xQxQ/TG+R0GNnAW9uc
+BxiAkDwNjDCBsTWe1mVR7cyxBIv17lZkh8nyi34oTTa4JvKL9sbxDkWNj2OV9Sg
ybq5Zuq9UyEVI86kCx8k3Ul4Nd4O726jOv0JPQ+1CmxeVVNuTEM=
=Sce8
-----END PGP SIGNATURE-----
Merge tag 'iommu-fixes-v5.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu
Pull iommu fixes from Joerg Roedel:
- Follow-on fix for Renesas IPMMU to get rid of a redundant error
message.
- Quirk for AMD IOMMU to make it work on another Acer Laptop model with
a broken IVRS ACPI table.
- Fix for a panic at kdump in the Intel IOMMU driver.
* tag 'iommu-fixes-v5.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
iommu/vt-d: Fix panic after kexec -p for kdump
iommu/amd: Apply the same IVRS IOAPIC workaround to Acer Aspire A315-41
iommu/ipmmu-vmsa: Remove dev_err() on platform_get_irq() failure
When gfs2 was converted to use fs_context, the initialisation of the
mount args structure to the currently active args was lost with the
removal of gfs2_remount_fs(), so the checks of the new args on remount
became checks against the default values instead of the current ones.
This caused unexpected remount behaviour and test failures (xfstests
generic/294, generic/306 and generic/452).
Reinstate the args initialisation, this time in gfs2_init_fs_context()
and conditional upon fc->purpose, as that's the only time we get control
before the mount args are parsed in the remount process.
Fixes: 1f52aa08d1 ("gfs2: Convert gfs2 to fs_context")
Signed-off-by: Andrew Price <anprice@redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
