user/sven/linux.git/Documentation, branch v5.19.8

rtla: Fix tracer name

2022-09-05T08:31:31Z

[ Upstream commit f1432cd24c240cedf78c0d026631e3b10052c8e1 ] The correct tracer name is timerlat and not timelat. Link: https://lore.kernel.org/linux-trace-devel/20220808180343.22262-1-alexandre.vicenzi@suse.com Signed-off-by: Alexandre Vicenzi Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin

arm64: errata: Add Cortex-A510 to the repeat tlbi list

2022-09-05T08:31:26Z

commit 39fdb65f52e9a53d32a6ba719f96669fd300ae78 upstream. Cortex-A510 is affected by an erratum where in rare circumstances the CPUs may not handle a race between a break-before-make sequence on one CPU, and another CPU accessing the same page. This could allow a store to a page that has been unmapped. Work around this by adding the affected CPUs to the list that needs TLB sequences to be done twice. Signed-off-by: James Morse Link: https://lore.kernel.org/r/20220704155732.21216-1-james.morse@arm.com Signed-off-by: Will Deacon Cc: Lucas Wei Signed-off-by: Greg Kroah-Hartman

docs: kerneldoc-preamble: Test xeCJK.sty before loading

2022-09-05T08:31:26Z

commit cee7db1b0239468b22c295cf04a8c40c34ecd35a upstream. On distros whose texlive packaging is fine-grained, texlive-xecjk can be installed/removed independently of other texlive packages. Conditionally loading xeCJK depending only on the existence of the "Noto Sans CJK SC" font might end up in xelatex error of "xeCJK.sty not found!". Improve the situation by testing existence of xeCJK.sty before loading it. This is useful on RHEL 9 and its clone distros where texlive-xecjk doesn't work at the moment due to a missing dependency [1]. "make pdfdocs" for non-CJK contents should work after removing texlive-xecjk. Link: [1] https://bugzilla.redhat.com/show_bug.cgi?id=2086254 Fixes: 398f7abdcb7e ("docs: pdfdocs: Pull LaTeX preamble part out of conf.py") Cc: stable@vger.kernel.org # v5.18+ Signed-off-by: Akira Yokosawa Acked-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/c24c2a87-70b2-5342-bcc9-de467940466e@gmail.com Signed-off-by: Jonathan Corbet Signed-off-by: Greg Kroah-Hartman

arm64: fix rodata=full

2022-08-31T15:18:19Z

commit 2e8cff0a0eee87b27f0cf87ad8310eb41b5886ab upstream. On arm64, "rodata=full" has been suppored (but not documented) since commit: c55191e96caa9d78 ("arm64: mm: apply r/o permissions of VM areas to its linear alias as well") As it's necessary to determine the rodata configuration early during boot, arm64 has an early_param() handler for this, whereas init/main.c has a __setup() handler which is run later. Unfortunately, this split meant that since commit: f9a40b0890658330 ("init/main.c: return 1 from handled __setup() functions") ... passing "rodata=full" would result in a spurious warning from the __setup() handler (though RO permissions would be configured appropriately). Further, "rodata=full" has been broken since commit: 0d6ea3ac94ca77c5 ("lib/kstrtox.c: add "false"/"true" support to kstrtobool()") ... which caused strtobool() to parse "full" as false (in addition to many other values not documented for the "rodata=" kernel parameter. This patch fixes this breakage by: * Moving the core parameter parser to an __early_param(), such that it is available early. * Adding an (optional) arch hook which arm64 can use to parse "full". * Updating the documentation to mention that "full" is valid for arm64. * Having the core parameter parser handle "on" and "off" explicitly, such that any undocumented values (e.g. typos such as "ful") are reported as errors rather than being silently accepted. Note that __setup() and early_param() have opposite conventions for their return values, where __setup() uses 1 to indicate a parameter was handled and early_param() uses 0 to indicate a parameter was handled. Fixes: f9a40b089065 ("init/main.c: return 1 from handled __setup() functions") Fixes: 0d6ea3ac94ca ("lib/kstrtox.c: add "false"/"true" support to kstrtobool()") Signed-off-by: Mark Rutland Cc: Andy Shevchenko Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: Jagdish Gediya Cc: Matthew Wilcox Cc: Randy Dunlap Cc: Will Deacon Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20220817154022.3974645-1-mark.rutland@arm.com Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman

Documentation/ABI: Mention retbleed vulnerability info file for sysfs

2022-08-31T15:18:18Z

commit 00da0cb385d05a89226e150a102eb49d8abb0359 upstream. While reporting for the AMD retbleed vulnerability was added in 6b80b59b3555 ("x86/bugs: Report AMD retbleed vulnerability") the new sysfs file was not mentioned so far in the ABI documentation for sysfs-devices-system-cpu. Fix that. Fixes: 6b80b59b3555 ("x86/bugs: Report AMD retbleed vulnerability") Signed-off-by: Salvatore Bonaccorso Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/20220801091529.325327-1-carnil@debian.org Signed-off-by: Greg Kroah-Hartman

x86/bugs: Add "unknown" reporting for MMIO Stale Data

2022-08-31T15:18:14Z

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

net: Fix data-races around netdev_max_backlog.

2022-08-31T15:18:08Z

[ 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

powerpc/pseries/mobility: set NMI watchdog factor during an LPM

2022-08-25T09:45:51Z

[ Upstream commit 118b1366930c8c833b8b36abef657f40d4e26610 ] During an LPM, while the memory transfer is in progress on the arrival side, some latencies are generated when accessing not yet transferred pages on the arrival side. Thus, the NMI watchdog may be triggered too frequently, which increases the risk to hit an NMI interrupt in a bad place in the kernel, leading to a kernel panic. Disabling the Hard Lockup Watchdog until the memory transfer could be a too strong work around, some users would want this timeout to be eventually triggered if the system is hanging even during an LPM. Introduce a new sysctl variable nmi_watchdog_factor. It allows to apply a factor to the NMI watchdog timeout during an LPM. Just before the CPUs are stopped for the switchover sequence, the NMI watchdog timer is set to watchdog_thresh + factor% A value of 0 has no effect. The default value is 200, meaning that the NMI watchdog is set to 30s during LPM (based on a 10s watchdog_thresh value). Once the memory transfer is achieved, the factor is reset to 0. Setting this value to a high number is like disabling the NMI watchdog during an LPM. Signed-off-by: Laurent Dufour Reviewed-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220713154729.80789-5-ldufour@linux.ibm.com Signed-off-by: Sasha Levin

dt-bindings: display: sun4i: Add D1 TCONs to conditionals

2022-08-25T09:45:36Z

commit 2a29f80e155a9cf40ca8b6648bcdc8422db4c4e4 upstream. When adding the D1 TCON bindings, I missed the conditional blocks that restrict the binding for TCON LCD vs TCON TV hardware. Add the D1 TCON variants to the appropriate blocks for DE2 TCON LCDs and TCON TVs. Fixes: ae5a5d26c15c ("dt-bindings: display: Add D1 display engine compatibles") Signed-off-by: Samuel Holland Acked-by: Krzysztof Kozlowski Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20220812073702.57618-1-samuel@sholland.org Signed-off-by: Greg Kroah-Hartman

regulator: pca9450: Remove restrictions for regulator-name

2022-08-25T09:45:36Z

commit b0de7fa706506bf0591037908376351beda8c5d6 upstream. The device bindings shouldn't put any constraints on the regulator-name property specified in the generic bindings. This allows using arbitrary and descriptive names for the regulators. Suggested-by: Mark Brown Fixes: 7ae9e3a6bf3f ("dt-bindings: regulator: add pca9450 regulator yaml") Signed-off-by: Frieder Schrempf Link: https://lore.kernel.org/r/20220802064335.8481-1-frieder@fris.de Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman