27 Sep, 2022
1 commit
-
This is the 5.15.70 stable release
* tag 'v5.15.70': (2444 commits)
Linux 5.15.70
ALSA: hda/sigmatel: Fix unused variable warning for beep power change
cgroup: Add missing cpus_read_lock() to cgroup_attach_task_all()
...Signed-off-by: Jason Liu
Conflicts:
arch/arm/boot/dts/imx6ul.dtsi
arch/arm/mm/mmu.c
arch/arm64/boot/dts/freescale/imx8mp-evk.dts
drivers/gpu/drm/imx/dcss/dcss-kms.c
drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.h
drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
drivers/soc/fsl/Kconfig
drivers/soc/imx/gpcv2.c
drivers/usb/dwc3/host.c
net/dsa/slave.c
sound/soc/fsl/imx-card.c
31 Aug, 2022
2 commits
-
commit 7df548840c496b0141fb2404b889c346380c2b22 upstream.
Older Intel CPUs that are not in the affected processor list for MMIO
Stale Data vulnerabilities currently report "Not affected" in sysfs,
which may not be correct. Vulnerability status for these older CPUs is
unknown.Add known-not-affected CPUs to the whitelist. Report "unknown"
mitigation status for CPUs that are not in blacklist, whitelist and also
don't enumerate MSR ARCH_CAPABILITIES bits that reflect hardware
immunity to MMIO Stale Data vulnerabilities.Mitigation is not deployed when the status is unknown.
[ bp: Massage, fixup. ]
Fixes: 8d50cdf8b834 ("x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data")
Suggested-by: Andrew Cooper
Suggested-by: Tony Luck
Signed-off-by: Pawan Gupta
Signed-off-by: Borislav Petkov
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/a932c154772f2121794a5f2eded1a11013114711.1657846269.git.pawan.kumar.gupta@linux.intel.com
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 5dcd08cd19912892586c6082d56718333e2d19db ]
While reading netdev_max_backlog, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its readers.While at it, we remove the unnecessary spaces in the doc.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Kuniyuki Iwashima
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
17 Aug, 2022
5 commits
-
commit e6cfcdda8cbe81eaf821c897369a65fec987b404 upstream.
AMD's "Technical Guidance for Mitigating Branch Type Confusion,
Rev. 1.0 2022-07-12" whitepaper, under section 6.1.2 "IBPB On
Privileged Mode Entry / SMT Safety" says:Similar to the Jmp2Ret mitigation, if the code on the sibling thread
cannot be trusted, software should set STIBP to 1 or disable SMT to
ensure SMT safety when using this mitigation.So, like already being done for retbleed=unret, and now also for
retbleed=ibpb, force STIBP on machines that have it, and report its SMT
vulnerability status accordingly.[ bp: Remove the "we" and remove "[AMD]" applicability parameter which
doesn't work here. ]Fixes: 3ebc17006888 ("x86/bugs: Add retbleed=ibpb")
Signed-off-by: Kim Phillips
Signed-off-by: Borislav Petkov
Cc: stable@vger.kernel.org # 5.10, 5.15, 5.19
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
Link: https://lore.kernel.org/r/20220804192201.439596-1-kim.phillips@amd.com
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 2ee73ef60db4d79b9f9b8cd501e8188b5179449f ]
Change dm-writecache, so that it counts the number of blocks discarded
instead of the number of discard bios. Make it consistent with the
read and write statistics counters that were changed to count the
number of blocks instead of bios.Fixes: e3a35d03407c ("dm writecache: add event counters")
Signed-off-by: Mikulas Patocka
Signed-off-by: Mike Snitzer
Signed-off-by: Sasha Levin -
[ Upstream commit b2676e1482af89714af6988ce5d31a84692e2530 ]
Change dm-writecache, so that it counts the number of blocks written
instead of the number of write bios. Bios can be split and requeued
using the dm_accept_partial_bio function, so counting bios caused
inaccurate results.Fixes: e3a35d03407c ("dm writecache: add event counters")
Reported-by: Yu Kuai
Signed-off-by: Mikulas Patocka
Signed-off-by: Mike Snitzer
Signed-off-by: Sasha Levin -
[ Upstream commit 2c6e755b49d273243431f5f1184654e71221fc78 ]
Change dm-writecache, so that it counts the number of blocks read
instead of the number of read bios. Bios can be split and requeued
using the dm_accept_partial_bio function, so counting bios caused
inaccurate results.Fixes: e3a35d03407c ("dm writecache: add event counters")
Reported-by: Yu Kuai
Signed-off-by: Mikulas Patocka
Signed-off-by: Mike Snitzer
Signed-off-by: Sasha Levin -
[ Upstream commit 8bcedb4ce04750e1ccc9a6b6433387f6a9166a56 ]
When kernel is booted with idle=nomwait do not use MWAIT as the
default idle state.If the user boots the kernel with idle=nomwait, it is a clear
direction to not use mwait as the default idle state.
However, the current code does not take this into consideration
while selecting the default idle state on x86.Fix it by checking for the idle=nomwait boot option in
prefer_mwait_c1_over_halt().Also update the documentation around idle=nomwait appropriately.
[ dhansen: tweak commit message ]
Signed-off-by: Wyes Karny
Signed-off-by: Dave Hansen
Tested-by: Zhang Rui
Link: https://lkml.kernel.org/r/fdc2dc2d0a1bc21c2f53d989ea2d2ee3ccbc0dbe.1654538381.git-series.wyes.karny@amd.com
Signed-off-by: Sasha Levin
11 Aug, 2022
1 commit
-
commit 2b1299322016731d56807aa49254a5ea3080b6b3 upstream.
tl;dr: The Enhanced IBRS mitigation for Spectre v2 does not work as
documented for RET instructions after VM exits. Mitigate it with a new
one-entry RSB stuffing mechanism and a new LFENCE.== Background ==
Indirect Branch Restricted Speculation (IBRS) was designed to help
mitigate Branch Target Injection and Speculative Store Bypass, i.e.
Spectre, attacks. IBRS prevents software run in less privileged modes
from affecting branch prediction in more privileged modes. IBRS requires
the MSR to be written on every privilege level change.To overcome some of the performance issues of IBRS, Enhanced IBRS was
introduced. eIBRS is an "always on" IBRS, in other words, just turn
it on once instead of writing the MSR on every privilege level change.
When eIBRS is enabled, more privileged modes should be protected from
less privileged modes, including protecting VMMs from guests.== Problem ==
Here's a simplification of how guests are run on Linux' KVM:
void run_kvm_guest(void)
{
// Prepare to run guest
VMRESUME();
// Clean up after guest runs
}The execution flow for that would look something like this to the
processor:1. Host-side: call run_kvm_guest()
2. Host-side: VMRESUME
3. Guest runs, does "CALL guest_function"
4. VM exit, host runs again
5. Host might make some "cleanup" function calls
6. Host-side: RET from run_kvm_guest()Now, when back on the host, there are a couple of possible scenarios of
post-guest activity the host needs to do before executing host code:* on pre-eIBRS hardware (legacy IBRS, or nothing at all), the RSB is not
touched and Linux has to do a 32-entry stuffing.* on eIBRS hardware, VM exit with IBRS enabled, or restoring the host
IBRS=1 shortly after VM exit, has a documented side effect of flushing
the RSB except in this PBRSB situation where the software needs to stuff
the last RSB entry "by hand".IOW, with eIBRS supported, host RET instructions should no longer be
influenced by guest behavior after the host retires a single CALL
instruction.However, if the RET instructions are "unbalanced" with CALLs after a VM
exit as is the RET in #6, it might speculatively use the address for the
instruction after the CALL in #3 as an RSB prediction. This is a problem
since the (untrusted) guest controls this address.Balanced CALL/RET instruction pairs such as in step #5 are not affected.
== Solution ==
The PBRSB issue affects a wide variety of Intel processors which
support eIBRS. But not all of them need mitigation. Today,
X86_FEATURE_RSB_VMEXIT triggers an RSB filling sequence that mitigates
PBRSB. Systems setting RSB_VMEXIT need no further mitigation - i.e.,
eIBRS systems which enable legacy IBRS explicitly.However, such systems (X86_FEATURE_IBRS_ENHANCED) do not set RSB_VMEXIT
and most of them need a new mitigation.Therefore, introduce a new feature flag X86_FEATURE_RSB_VMEXIT_LITE
which triggers a lighter-weight PBRSB mitigation versus RSB_VMEXIT.The lighter-weight mitigation performs a CALL instruction which is
immediately followed by a speculative execution barrier (INT3). This
steers speculative execution to the barrier -- just like a retpoline
-- which ensures that speculation can never reach an unbalanced RET.
Then, ensure this CALL is retired before continuing execution with an
LFENCE.In other words, the window of exposure is opened at VM exit where RET
behavior is troublesome. While the window is open, force RSB predictions
sampling for RET targets to a dead end at the INT3. Close the window
with the LFENCE.There is a subset of eIBRS systems which are not vulnerable to PBRSB.
Add these systems to the cpu_vuln_whitelist[] as NO_EIBRS_PBRSB.
Future systems that aren't vulnerable will set ARCH_CAP_PBRSB_NO.[ bp: Massage, incorporate review comments from Andy Cooper. ]
Signed-off-by: Daniel Sneddon
Co-developed-by: Pawan Gupta
Signed-off-by: Pawan Gupta
Signed-off-by: Borislav Petkov
Signed-off-by: Greg Kroah-Hartman
03 Aug, 2022
1 commit
-
commit ea304a8b89fd0d6cf94ee30cb139dc23d9f1a62f upstream.
Updates descriptions for "mitigations=off" and "mitigations=auto,nosmt"
with the respective retbleed= settings.Signed-off-by: Eiichi Tsukata
Signed-off-by: Borislav Petkov
Cc: corbet@lwn.net
Link: https://lore.kernel.org/r/20220728043907.165688-1-eiichi.tsukata@nutanix.com
Signed-off-by: Greg Kroah-Hartman
29 Jul, 2022
1 commit
-
[ Upstream commit 39c65a94cd9661532be150e88f8b02f4a6844a35 ]
For embedded systems with low total memory, having to run applications
with relatively large memory requirements, 10% max limitation for
watermark_scale_factor poses an issue of triggering direct reclaim every
time such application is started. This results in slow application
startup times and bad end-user experience.By increasing watermark_scale_factor max limit we allow vendors more
flexibility to choose the right level of kswapd aggressiveness for their
device and workload requirements.Link: https://lkml.kernel.org/r/20211124193604.2758863-1-surenb@google.com
Signed-off-by: Suren Baghdasaryan
Acked-by: Johannes Weiner
Cc: Michal Hocko
Cc: Lukas Middendorf
Cc: Antti Palosaari
Cc: Luis Chamberlain
Cc: Kees Cook
Cc: Iurii Zaikin
Cc: Dave Hansen
Cc: Vlastimil Babka
Cc: Mel Gorman
Cc: Jonathan Corbet
Cc: Zhang Yi
Cc: Fengfei Xi
Cc: Mike Rapoport
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
23 Jul, 2022
4 commits
-
commit 3ebc170068885b6fc7bedda6c667bb2c4d533159 upstream.
jmp2ret mitigates the easy-to-attack case at relatively low overhead.
It mitigates the long speculation windows after a mispredicted RET, but
it does not mitigate the short speculation window from arbitrary
instruction boundaries.On Zen2, there is a chicken bit which needs setting, which mitigates
"arbitrary instruction boundaries" down to just "basic block boundaries".But there is no fix for the short speculation window on basic block
boundaries, other than to flush the entire BTB to evict all attacker
predictions.On the spectrum of "fast & blurry" -> "safe", there is (on top of STIBP
or no-SMT):1) Nothing System wide open
2) jmp2ret May stop a script kiddy
3) jmp2ret+chickenbit Raises the bar rather further
4) IBPB Only thing which can count as "safe".Tentative numbers put IBPB-on-entry at a 2.5x hit on Zen2, and a 10x hit
on Zen1 according to lmbench.[ bp: Fixup feature bit comments, document option, 32-bit build fix. ]
Suggested-by: Andrew Cooper
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Borislav Petkov
Reviewed-by: Josh Poimboeuf
Signed-off-by: Borislav Petkov
Signed-off-by: Thadeu Lima de Souza Cascardo
Signed-off-by: Greg Kroah-Hartman -
commit 7c693f54c873691a4b7da05c7e0f74e67745d144 upstream.
Extend spectre_v2= boot option with Kernel IBRS.
[jpoimboe: no STIBP with IBRS]
Signed-off-by: Pawan Gupta
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Borislav Petkov
Reviewed-by: Josh Poimboeuf
Signed-off-by: Borislav Petkov
Signed-off-by: Thadeu Lima de Souza Cascardo
Signed-off-by: Greg Kroah-Hartman -
commit e8ec1b6e08a2102d8755ccb06fa26d540f26a2fa upstream.
For untrained return thunks to be fully effective, STIBP must be enabled
or SMT disabled.Co-developed-by: Josh Poimboeuf
Signed-off-by: Josh Poimboeuf
Signed-off-by: Kim Phillips
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Borislav Petkov
Signed-off-by: Thadeu Lima de Souza Cascardo
Signed-off-by: Greg Kroah-Hartman -
commit 7fbf47c7ce50b38a64576b150e7011ae73d54669 upstream.
Add the "retbleed=" boot parameter to select a mitigation for
RETBleed. Possible values are "off", "auto" and "unret"
(JMP2RET mitigation). The default value is "auto".Currently, "retbleed=auto" will select the unret mitigation on
AMD and Hygon and no mitigation on Intel (JMP2RET is not effective on
Intel).[peterz: rebase; add hygon]
[jpoimboe: cleanups]Signed-off-by: Alexandre Chartre
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Borislav Petkov
Reviewed-by: Josh Poimboeuf
Signed-off-by: Borislav Petkov
Signed-off-by: Thadeu Lima de Souza Cascardo
Signed-off-by: Greg Kroah-Hartman
30 Jun, 2022
2 commits
-
This is the 5.15.50 stable release
* tag 'v5.15.50': (1395 commits)
Linux 5.15.50
arm64: mm: Don't invalidate FROM_DEVICE buffers at start of DMA transfer
serial: core: Initialize rs485 RTS polarity already on probe
...Signed-off-by: Jason Liu
Conflicts:
drivers/bus/fsl-mc/fsl-mc-bus.c
drivers/crypto/caam/ctrl.c
drivers/pci/controller/dwc/pci-imx6.c
drivers/spi/spi-fsl-qspi.c
drivers/tty/serial/fsl_lpuart.c
include/uapi/linux/dma-buf.h -
This is the 5.15.41 stable release
* tag 'v5.15.41': (1977 commits)
Linux 5.15.41
usb: gadget: uvc: allow for application to cleanly shutdown
usb: gadget: uvc: rename function to be more consistent
...Signed-off-by: Jason Liu
Conflicts:
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
arch/arm64/configs/defconfig
drivers/clk/imx/clk-imx8qxp-lpcg.c
drivers/dma/imx-sdma.c
drivers/gpu/drm/bridge/nwl-dsi.c
drivers/mailbox/imx-mailbox.c
drivers/net/phy/at803x.c
drivers/tty/serial/fsl_lpuart.c
security/keys/trusted-keys/trusted_core.c
16 Jun, 2022
2 commits
-
commit 8cb861e9e3c9a55099ad3d08e1a3b653d29c33ca upstream
Processor MMIO Stale Data is a class of vulnerabilities that may
expose data after an MMIO operation. For details please refer to
Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst.These vulnerabilities are broadly categorized as:
Device Register Partial Write (DRPW):
Some endpoint MMIO registers incorrectly handle writes that are
smaller than the register size. Instead of aborting the write or only
copying the correct subset of bytes (for example, 2 bytes for a 2-byte
write), more bytes than specified by the write transaction may be
written to the register. On some processors, this may expose stale
data from the fill buffers of the core that created the write
transaction.Shared Buffers Data Sampling (SBDS):
After propagators may have moved data around the uncore and copied
stale data into client core fill buffers, processors affected by MFBDS
can leak data from the fill buffer.Shared Buffers Data Read (SBDR):
It is similar to Shared Buffer Data Sampling (SBDS) except that the
data is directly read into the architectural software-visible state.An attacker can use these vulnerabilities to extract data from CPU fill
buffers using MDS and TAA methods. Mitigate it by clearing the CPU fill
buffers using the VERW instruction before returning to a user or a
guest.On CPUs not affected by MDS and TAA, user application cannot sample data
from CPU fill buffers using MDS or TAA. A guest with MMIO access can
still use DRPW or SBDR to extract data architecturally. Mitigate it with
VERW instruction to clear fill buffers before VMENTER for MMIO capable
guests.Add a kernel parameter mmio_stale_data={off|full|full,nosmt} to control
the mitigation.Signed-off-by: Pawan Gupta
Signed-off-by: Borislav Petkov
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 4419470191386456e0b8ed4eb06a70b0021798a6 upstream
Add the admin guide for Processor MMIO stale data vulnerabilities.
Signed-off-by: Pawan Gupta
Signed-off-by: Borislav Petkov
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
30 May, 2022
4 commits
-
commit 069c4ea6871c18bd368f27756e0f91ffb524a788 upstream.
A semicolon was missing, and the almost-alphabetical-but-not ordering
was confusing, so regroup these by category instead.Signed-off-by: Jason A. Donenfeld
Signed-off-by: Greg Kroah-Hartman -
commit d97c68d178fbf8aaaf21b69b446f2dfb13909316 upstream.
If CONFIG_RANDOM_TRUST_CPU is set, the RNG initializes using RDRAND.
But, the user can disable (or enable) this behavior by setting
`random.trust_cpu=0/1` on the kernel command line. This allows system
builders to do reasonable things while avoiding howls from tinfoil
hatters. (Or vice versa.)CONFIG_RANDOM_TRUST_BOOTLOADER is basically the same thing, but regards
the seed passed via EFI or device tree, which might come from RDRAND or
a TPM or somewhere else. In order to allow distros to more easily enable
this while avoiding those same howls (or vice versa), this commit adds
the corresponding `random.trust_bootloader=0/1` toggle.Cc: Theodore Ts'o
Cc: Graham Christensen
Reviewed-by: Ard Biesheuvel
Reviewed-by: Dominik Brodowski
Link: https://github.com/NixOS/nixpkgs/pull/165355
Signed-off-by: Jason A. Donenfeld
Signed-off-by: Greg Kroah-Hartman -
commit 95e6060c20a7f5db60163274c5222a725ac118f9 upstream.
With tools like kbench9000 giving more finegrained responses, and this
basically never having been used ever since it was initially added,
let's just get rid of this. There *is* still work to be done on the
interrupt handler, but this really isn't the way it's being developed.Cc: Theodore Ts'o
Reviewed-by: Eric Biggers
Reviewed-by: Dominik Brodowski
Signed-off-by: Jason A. Donenfeld
Signed-off-by: Greg Kroah-Hartman -
commit 489c7fc44b5740d377e8cfdbf0851036e493af00 upstream.
Now that POOL_BITS == POOL_MIN_BITS, we must unconditionally wake up
entropy writers after every extraction. Therefore there's no point of
write_wakeup_threshold, so we can move it to the dustbin of unused
compatibility sysctls. While we're at it, we can fix a small comparison
where we were waking up after < min.Cc: Theodore Ts'o
Suggested-by: Eric Biggers
Reviewed-by: Eric Biggers
Reviewed-by: Dominik Brodowski
Signed-off-by: Jason A. Donenfeld
Signed-off-by: Greg Kroah-Hartman
04 May, 2022
2 commits
-
The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core
built into many newer i.MX and QorIQ SoCs by NXP.The CAAM does crypto acceleration, hardware number generation and
has a blob mechanism for encapsulation/decapsulation of sensitive material.This blob mechanism depends on a device specific random 256-bit One Time
Programmable Master Key that is fused in each SoC at manufacturing
time. This key is unreadable and can only be used by the CAAM for AES
encryption/decryption of user data.This makes it a suitable backend (source) for kernel trusted keys.
Previous commits generalized trusted keys to support multiple backends
and added an API to access the CAAM blob mechanism. Based on these,
provide the necessary glue to use the CAAM for trusted keys.Reviewed-by: David Gstir
Reviewed-by: Pankaj Gupta
Tested-by: Tim Harvey
Tested-by: Matthias Schiffer
Tested-by: Pankaj Gupta
Signed-off-by: Ahmad Fatoum -
The two existing trusted key sources don't make use of the kernel RNG, but instead let the hardware doing the sealing/unsealing also generate the random key material. However, both users and future backends may want to place less trust into the quality of the trust source's random number generator and instead reuse the kernel entropy pool, which can be seeded from multiple entropy sources.
Make this possible by adding a new trusted.rng parameter, that will force use of the kernel RNG. In its absence, it's up to the trust source to decide, which random numbers to use, maintaining the existing behavior.
Suggested-by: Jarkko Sakkinen
Acked-by: Sumit Garg
Acked-by: Pankaj Gupta
Reviewed-by: David Gstir
Reviewed-by: Pankaj Gupta
Reviewed-by: Jarkko Sakkinen
Signed-off-by: Ahmad Fatoum
08 Apr, 2022
2 commits
-
commit a1ff1de00db21ecb956213f046b79741b64c6b65 upstream.
Patch series "Some improvements on panic_print".
This is a mix of a documentation fix with some additions to the
"panic_print" syscall / parameter. The goal here is being able to collect
all CPUs backtraces during a panic event and also to enable "panic_print"
in a kdump event - details of the reasoning and design choices in the
patches.This patch (of 3):
Commit de6da1e8bcf0 ("panic: add an option to replay all the printk
message in buffer") added a new bit to the sysctl/kernel parameter
"panic_print", but the documentation was added only in
kernel-parameters.txt, not in the sysctl guide.Fix it here by adding bit 5 to sysctl admin-guide documentation.
[rdunlap@infradead.org: fix table format warning]
Link: https://lkml.kernel.org/r/20220109055635.6999-1-rdunlap@infradead.orgLink: https://lkml.kernel.org/r/20211109202848.610874-1-gpiccoli@igalia.com
Link: https://lkml.kernel.org/r/20211109202848.610874-2-gpiccoli@igalia.com
Fixes: de6da1e8bcf0 ("panic: add an option to replay all the printk message in buffer")
Signed-off-by: Guilherme G. Piccoli
Reviewed-by: Feng Tang
Cc: Luis Chamberlain
Cc: Kees Cook
Cc: Iurii Zaikin
Cc: Samuel Iglesias Gonsalvez
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 84842911322fc6a02a03ab9e728a48c691fe3efd ]
Although kptr_restrict is set to 0 and the kernel is booted with
no_hash_pointers parameter, the content of /proc/vmallocinfo is
lacking the real addresses./ # cat /proc/vmallocinfo
0x(ptrval)-0x(ptrval) 8192 load_module+0xc0c/0x2c0c pages=1 vmalloc
0x(ptrval)-0x(ptrval) 12288 start_kernel+0x4e0/0x690 pages=2 vmalloc
0x(ptrval)-0x(ptrval) 12288 start_kernel+0x4e0/0x690 pages=2 vmalloc
0x(ptrval)-0x(ptrval) 8192 _mpic_map_mmio.constprop.0+0x20/0x44 phys=0x80041000 ioremap
0x(ptrval)-0x(ptrval) 12288 _mpic_map_mmio.constprop.0+0x20/0x44 phys=0x80041000 ioremap
...According to the documentation for /proc/sys/kernel/, %pK is
equivalent to %p when kptr_restrict is set to 0.Fixes: 5ead723a20e0 ("lib/vsprintf: no_hash_pointers prints all addresses as unhashed")
Signed-off-by: Christophe Leroy
Reviewed-by: Petr Mladek
Signed-off-by: Petr Mladek
Link: https://lore.kernel.org/r/107476128e59bff11a309b5bf7579a1753a41aca.1645087605.git.christophe.leroy@csgroup.eu
Signed-off-by: Sasha Levin
22 Mar, 2022
1 commit
-
This is the 5.15.30 stable release
* tag 'v5.15.30': (197 commits)
Linux 5.15.30
ice: Fix race condition during interface enslave
x86/module: Fix the paravirt vs alternative order
...Signed-off-by: Jason Liu
11 Mar, 2022
3 commits
-
commit e9b6013a7ce31535b04b02ba99babefe8a8599fa upstream.
Update the link to the "Software Techniques for Managing Speculation
on AMD Processors" whitepaper.Signed-off-by: Kim Phillips
Signed-off-by: Borislav Petkov
Signed-off-by: Greg Kroah-Hartman -
commit 5ad3eb1132453b9795ce5fd4572b1c18b292cca9 upstream.
Update the doc with the new fun.
[ bp: Massage commit message. ]
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Borislav Petkov
Reviewed-by: Thomas Gleixner
[fllinden@amazon.com: backported to 5.15]
Signed-off-by: Frank van der Linden
Signed-off-by: Greg Kroah-Hartman -
This is the 5.15.27 stable release
* tag 'v5.15.27': (3069 commits)
Linux 5.15.27
hamradio: fix macro redefine warning
KVM: x86/mmu: Passing up the error state of mmu_alloc_shadow_roots()
...Signed-off-by: Jason Liu
Conflicts:
arch/arm/boot/dts/imx7ulp.dtsi
arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
arch/arm64/boot/dts/freescale/imx8mq.dtsi
drivers/dma-buf/heaps/cma_heap.c
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
drivers/gpu/drm/mxsfb/mxsfb_kms.c
drivers/mmc/host/sdhci-esdhc-imx.c
drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
drivers/rpmsg/rpmsg_char.c
drivers/soc/imx/gpcv2.c
drivers/thermal/imx_thermal.c
09 Mar, 2022
1 commit
-
commit dd21bfa425c098b95ca86845f8e7d1ec1ddf6e4a upstream.
Since bit 57 was exported for uffd-wp write-protected (commit
fb8e37f35a2f: "mm/pagemap: export uffd-wp protection information"),
fixing it can reduce some unnecessary confusion.Link: https://lkml.kernel.org/r/20220301044538.3042713-1-yun.zhou@windriver.com
Fixes: fb8e37f35a2fe1 ("mm/pagemap: export uffd-wp protection information")
Signed-off-by: Yun Zhou
Reviewed-by: Peter Xu
Cc: Jonathan Corbet
Cc: Tiberiu A Georgescu
Cc: Florian Schmidt
Cc: Ivan Teterevkov
Cc: SeongJae Park
Cc: Yang Shi
Cc: David Hildenbrand
Cc: Axel Rasmussen
Cc: Miaohe Lin
Cc: Andrea Arcangeli
Cc: Colin Cross
Cc: Alistair Popple
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
27 Jan, 2022
3 commits
-
commit 82ca67321f55a8d1da6ac3ed611da3c32818bb37 upstream.
The config RANDOMIZE_SLAB does not exist, the authors probably intended to
refer to the config RANDOMIZE_BASE, which provides kernel address-space
randomization. They probably just confused SLAB with BASE (these two
four-letter words coincidentally share three common letters), as they also
point out the config SLAB_FREELIST_RANDOM as further randomization within
the same sentence.Fix the reference of the config for kernel address-space randomization to
the config that provides that.Fixes: 6e88559470f5 ("Documentation: Add section about CPU vulnerabilities for Spectre")
Signed-off-by: Lukas Bulwahn
Link: https://lore.kernel.org/r/20211230171940.27558-1-lukas.bulwahn@gmail.com
Signed-off-by: Jonathan Corbet
Signed-off-by: Greg Kroah-Hartman -
commit 2ac7069ad7647cd1d9ca5b08765a1e116e13cdc4 upstream.
This config was removed so remove all references to it.
Fixes: 76a3c92ec9e0 ("cifs: remove support for NTLM and weaker authentication algorithms")
Signed-off-by: Alexandre Ghiti
Reviewed-by: Steve French
Acked-by: Arnd Bergmann [arch/arm/configs]
Acked-by: Thomas Bogendoerfer
Signed-off-by: Arnd Bergmann
Signed-off-by: Greg Kroah-Hartman -
commit 473dcf0ffc31ce1135cd10578e7e06698cf51f4a upstream.
Raw device interface was removed so remove all references to configs
related to it.Fixes: 603e4922f1c8 ("remove the raw driver")
Signed-off-by: Alexandre Ghiti
Acked-by: Arnd Bergmann [arch/arm/configs]
Signed-off-by: Arnd Bergmann
Signed-off-by: Greg Kroah-Hartman
05 Jan, 2022
1 commit
-
[ Upstream commit 9222ba68c3f4065f6364b99cc641b6b019ef2d42 ]
We've got a bug report about the non-working keyboard on ASUS ZenBook
UX425UA. It seems that the PS/2 device isn't ready immediately at
boot but takes some seconds to get ready. Until now, the only
workaround is to defer the probe, but it's available only when the
driver is a module. However, many distros, including openSUSE as in
the original report, build the PS/2 input drivers into kernel, hence
it won't work easily.This patch adds the support for the deferred probe for i8042 stuff as
a workaround of the problem above. When the deferred probe mode is
enabled and the device couldn't be probed, it'll be repeated with the
standard deferred probe mechanism.The deferred probe mode is enabled either via the new option
i8042.probe_defer or via the quirk table entry. As of this patch, the
quirk table contains only ASUS ZenBook UX425UA.The deferred probe part is based on Fabio's initial work.
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1190256
Signed-off-by: Takashi Iwai
Tested-by: Samuel Čavoj
Link: https://lore.kernel.org/r/20211117063757.11380-1-tiwai@suse.deSigned-off-by: Dmitry Torokhov
Signed-off-by: Sasha Levin
29 Dec, 2021
1 commit
-
commit 0ff29701ffad9a5d5a24344d8b09f3af7b96ffda upstream.
Update the documentation for kvm-intel's emulate_invalid_guest_state to
rectify the description of KVM's default behavior, and to document that
the behavior and thus parameter only applies to L1.Fixes: a27685c33acc ("KVM: VMX: Emulate invalid guest state by default")
Signed-off-by: Sean Christopherson
Message-Id:
Reviewed-by: Maxim Levitsky
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman
01 Dec, 2021
2 commits
-
commit 0f60a29c52b515532e6b11dc6b3c9e5b5f7ff2b4 upstream.
The file name: accounting/delay-accounting.rst
should be, instead: Documentation/accounting/delay-accounting.rst.Also, there's no need to use doc:`foo`, as automarkup.py will
automatically handle plain text mentions to Documentation/
files.So, update its cross-reference accordingly.
Fixes: fcb501704554 ("delayacct: Document task_delayacct sysctl")
Fixes: c3123552aad3 ("docs: accounting: convert to ReST")
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Jonathan Corbet
Signed-off-by: Greg Kroah-Hartman -
This is the 5.15.5 stable release
* tag 'v5.15.5': (1261 commits)
Linux 5.15.5
ALSA: hda: hdac_stream: fix potential locking issue in snd_hdac_stream_assign()
ALSA: hda: hdac_ext_stream: fix potential locking issues
...Conflicts:
arch/powerpc/platforms/85xx/Makefile
drivers/crypto/caam/caampkc.c
drivers/gpu/drm/bridge/nwl-dsi.c
drivers/gpu/drm/imx/imx-drm-core.c
drivers/remoteproc/imx_rproc.c
drivers/soc/imx/gpcv2.c
include/linux/rpmsg.h
19 Nov, 2021
1 commit
-
commit 40fdea0284bb20814399da0484a658a96c735d90 upstream.
When running as PVH or HVM guest with actual memory < max memory the
hypervisor is using "populate on demand" in order to allow the guest
to balloon down from its maximum memory size. For this to work
correctly the guest must not touch more memory pages than its target
memory size as otherwise the PoD cache will be exhausted and the guest
is crashed as a result of that.In extreme cases ballooning down might not be finished today before
the init process is started, which can consume lots of memory.In order to avoid random boot crashes in such cases, add a late init
call to wait for ballooning down having finished for PVH/HVM guests.Warn on console if initial ballooning fails, panic() after stalling
for more than 3 minutes per default. Add a module parameter for
changing this timeout.[boris: replaced pr_info() with pr_notice()]
Cc:
Reported-by: Marek Marczykowski-Górecki
Signed-off-by: Juergen Gross
Link: https://lore.kernel.org/r/20211102091944.17487-1-jgross@suse.com
Reviewed-by: Boris Ostrovsky
Signed-off-by: Boris Ostrovsky
Signed-off-by: Greg Kroah-Hartman
