- 16 Sep, 2019 40 commits
-
-
Dexuan Cui authored
[ Upstream commit d544c22d ] No functional change. Signed-off-by:
Dexuan Cui <decui@microsoft.com> Cc: K. Y. Srinivasan <kys@microsoft.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Lyude Paul authored
[ Upstream commit 4d802739 ] With the exception of modesets which would switch the DPMS state of a connector from on to off, we want to make sure that we disallow all modesets which would result in enabling a new monitor or a new mode configuration on a monitor if the connector for the display in question is no longer registered. This allows us to stop userspace from trying to enable new displays on connectors for an MST topology that were just removed from the system, without preventing userspace from disabling DPMS on those connectors. Changes since v5: - Fix typo in comment, nothing else Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20181008232437.5571-2-lyude@redhat.comSigned-off-by:
-
Imre Deak authored
[ Upstream commit 914a4fd8 ] If BIOS configured a Y tiled FB we failed to set up the backing object tiling accordingly, leading to a lack of GT fence installed and a garbled console. The problem was bisected to commit 011f22eb ("drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers v2") but it just revealed a pre-existing issue. Kudos to Ville who suspected a missing fence looking at the corruption on the screen. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: <ronald@innovation.ch> Cc: <stable@vger.kernel.org> Reported-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Reported-by: <ronald@innovation.ch> Tested-by: <ronald@innovation.ch> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108264 Fixes: bc8d7dff ("drm/i915/skl: Provide a Skylake version of get_plane_config()") Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181016160011.28347-1-imre.deak@intel.comSigned-off-by:
-
Dhinakaran Pandiyan authored
[ Upstream commit 53867b46 ] Rename PLANE_CTL_DECOMPRESSION_ENABLE to resemble the bpsec name - PLANE_CTL_RENDER_DECOMPRESSION_ENABLE Suggested-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
-
Lyude Paul authored
[ Upstream commit a9f9ca33 ] Currently, i915 appears to rely on blocking modesets on no-longer-present MSTB ports by simply returning NULL for ->best_encoder(), which in turn causes any new atomic commits that don't disable the CRTC to fail. This is wrong however, since we still want to allow userspace to disable CRTCs on no-longer-present MSTB ports by changing the DPMS state to off and this still requires that we retrieve an encoder. So, fix this by always returning a valid encoder regardless of the state of the MST port. Changes since v1: - Remove mst atomic helper, since this got replaced with a much simpler solution Signed-off-by:
-
Vitaly Kuznetsov authored
[ Upstream commit a7c42bb6 ] vcpu->arch.pv_eoi is accessible through both HV_X64_MSR_VP_ASSIST_PAGE and MSR_KVM_PV_EOI_EN so on migration userspace may try to restore them in any order. Values match, however, kvm_lapic_enable_pv_eoi() uses different length: for Hyper-V case it's the whole struct hv_vp_assist_page, for KVM native case it is 8. In case we restore KVM-native MSR last cache will be reinitialized with len=8 so trying to access VP assist page beyond 8 bytes with kvm_read_guest_cached() will fail. Check if we re-initializing cache for the same address and preserve length in case it was greater. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Ladi Prosek authored
[ Upstream commit 72bbf935 ] The state related to the VP assist page is still managed by the LAPIC code in the pv_eoi field. Signed-off-by:
Ladi Prosek <lprosek@redhat.com> Signed-off-by:
Liran Alon <liran.alon@oracle.com> Signed-off-by:
-
Vitaly Kuznetsov authored
[ Upstream commit 87ee613d ] In most common cases VP index of a vcpu matches its vcpu index. Userspace is, however, free to set any mapping it wishes and we need to account for that when we need to find a vCPU with a particular VP index. To keep search algorithms optimal in both cases introduce 'num_mismatched_vp_indexes' counter showing how many vCPUs with mismatching VP index we have. In case the counter is zero we can assume vp_index == vcpu_idx. Signed-off-by:
Roman Kagan <rkagan@virtuozzo.com> Signed-off-by:
-
Vitaly Kuznetsov authored
[ Upstream commit 1779a39f ] Rename 'hv' to 'hv_vcpu' in kvm_hv_set_msr/kvm_hv_get_msr(); 'hv' is 'reserved' for 'struct kvm_hv' variables across the file. Signed-off-by:
-
Vitaly Kuznetsov authored
[ Upstream commit 9170200e ] Hyper-V TLFS (5.0b) states: > Virtual processors are identified by using an index (VP index). The > maximum number of virtual processors per partition supported by the > current implementation of the hypervisor can be obtained through CPUID > leaf 0x40000005. A virtual processor index must be less than the > maximum number of virtual processors per partition. Forbid userspace to set VP_INDEX above KVM_MAX_VCPUS. get_vcpu_by_vpidx() can now be optimized to bail early when supplied vpidx is >= KVM_MAX_VCPUS. Signed-off-by:
-
Feifei Xu authored
[ Upstream commit c55045ad ] Add mmDB_DEBUG3 settings. Signed-off-by:
Feifei Xu <Feifei.Xu@amd.com> Reviewed-by:
Evan Quan <evan.quan@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Feifei Xu authored
[ Upstream commit 54d682d9 ] Update the goldensettings for vega20. Signed-off-by:
Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by:
-
Brian Norris authored
[ Upstream commit bbcda302 ] The memory ownership transfer request is performed using SCM, ensure that SCM is available before we probe the driver if memory protection is needed by the subsystem. Fixes: 6c5a9dc2 ("remoteproc: qcom: Make secure world call for mem ownership switch") Cc: stable@vger.kernel.org Signed-off-by:
Brian Norris <briannorris@chromium.org> [bjorn: Added condition for need_mem_protection, updated commit message] Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Zhimin Gu authored
[ Upstream commit cc55f753 ] On 32bit systems, nosave_regions(non RAM areas) located between max_low_pfn and max_pfn are not excluded from hibernation snapshot currently, which may result in a machine check exception when trying to access these unsafe regions during hibernation: [ 612.800453] Disabling lock debugging due to kernel taint [ 612.805786] mce: [Hardware Error]: CPU 0: Machine Check Exception: 5 Bank 6: fe00000000801136 [ 612.814344] mce: [Hardware Error]: RIP !INEXACT! 60:<00000000d90be566> {swsusp_save+0x436/0x560} [ 612.823167] mce: [Hardware Error]: TSC 1f5939fe276 ADDR dd000000 MISC 30e0000086 [ 612.830677] mce: [Hardware Error]: PROCESSOR 0:306c3 TIME 1529487426 SOCKET 0 APIC 0 microcode 24 [ 612.839581] mce: [Hardware Error]: Run the above through 'mcelog --ascii' [ 612.846394] mce: [Hardware Error]: Machine check: Processor context corrupt [ 612.853380] Kernel panic - not syncing: Fatal machine check [ 612.858978] Kernel Offset: 0x18000000 from 0xc1000000 (relocation range: 0xc0000000-0xf7ffdfff) This is because on 32bit systems, pages above max_low_pfn are regarded as high memeory, and accessing unsafe pages might cause expected MCE. On the problematic 32bit system, there are reserved memory above low memory, which triggered the MCE: e820 memory mapping: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009d7ff] usable [ 0.000000] BIOS-e820: [mem 0x000000000009d800-0x000000000009ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000d160cfff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d160d000-0x00000000d1613fff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x00000000d1614000-0x00000000d1a44fff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d1a45000-0x00000000d1ecffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000d1ed0000-0x00000000d7eeafff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d7eeb000-0x00000000d7ffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000d8000000-0x00000000d875ffff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d8760000-0x00000000d87fffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000d8800000-0x00000000d8fadfff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d8fae000-0x00000000d8ffffff] ACPI data [ 0.000000] BIOS-e820: [mem 0x00000000d9000000-0x00000000da71bfff] usable [ 0.000000] BIOS-e820: [mem 0x00000000da71c000-0x00000000da7fffff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x00000000da800000-0x00000000dbb8bfff] usable [ 0.000000] BIOS-e820: [mem 0x00000000dbb8c000-0x00000000dbffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000dd000000-0x00000000df1fffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed00000-0x00000000fed03fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000041edfffff] usable Fix this problem by changing pfn limit from max_low_pfn to max_pfn. This fix does not impact 64bit system because on 64bit max_low_pfn is the same as max_pfn. Signed-off-by:
Zhimin Gu <kookoo.gu@intel.com> Acked-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
Chen Yu <yu.c.chen@intel.com> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Cc: All applicable <stable@vger.kernel.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Dexuan Cui authored
[ Upstream commit fc62c3b1 ] We don't need to call process_ib_ipinfo() if message->kvp_hdr.operation is KVP_OP_GET_IP_INFO in kvp_send_key(), because here we just need to pass on the op code from the host to the userspace; when the userspace returns the info requested by the host, we pass the info on to the host in kvp_respond_to_host() -> process_ob_ipinfo(). BTW, the current buggy code actually doesn't cause any harm, because only message->kvp_hdr.operation is used by the userspace, in the case of KVP_OP_GET_IP_INFO. The patch also adds a missing "break;" in kvp_send_key(). BTW, the current buggy code actually doesn't cause any harm, because in the case of KVP_OP_SET, the unexpected fall-through corrupts message->body.kvp_set.data.key_size, but that is not really used: see the definition of struct hv_kvp_exchg_msg_value. Signed-off-by:
-
David Howells authored
[ Upstream commit 2ecefa0a ] The keyctl_dh_params struct in uapi/linux/keyctl.h contains the symbol "private" which means that the header file will cause compilation failure if #included in to a C++ program. Further, the patch that added the same struct to the keyutils package named the symbol "priv", not "private". The previous attempt to fix this (commit 8a2336e5) did so by simply renaming the kernel's copy of the field to dh_private, but this then breaks existing userspace and as such has been reverted (commit 8c0f9f5b). [And note, to those who think that wrapping the struct in extern "C" {} will work: it won't; that only changes how symbol names are presented to the assembler and linker.]. Instead, insert an anonymous union around the "private" member and add a second member in there with the name "priv" to match the one in the keyutils package. The "private" member is then wrapped in !__cplusplus cpp-conditionals to hide it from C++. Fixes: ddbb4114 ("KEYS: Add KEYCTL_DH_COMPUTE command") Fixes: 8a2336e5 ("uapi/linux/keyctl.h: don't use C++ reserved keyword as a struct member name") Signed-off-by:
David Howells <dhowells@redhat.com> cc: Randy Dunlap <rdunlap@infradead.org> cc: Lubomir Rintel <lkundrak@v3.sk> cc: James Morris <jmorris@namei.org> cc: Mat Martineau <mathew.j.martineau@linux.intel.com> cc: Stephan Mueller <smueller@chronox.de> cc: Andrew Morton <akpm@linux-foundation.org> cc: Linus Torvalds <torvalds@linux-foundation.org> cc: stable@vger.kernel.org Signed-off-by:
James Morris <james.morris@microsoft.com> Signed-off-by:
-
Giridhar Malavali authored
[ Upstream commit 9fe278f4 ] There is a probability that the SRB structure might have been released by the time the debug log message dereferences it. This patch moved the log messages before the command is issued to the firmware to prevent unknown behavior and kernel crash Fixes: 726b8548 ("qla2xxx: Add framework for async fabric discovery") Cc: <stable@vger.kernel.org> Signed-off-by:
Giridhar Malavali <giridhar.malavali@cavium.com> Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Signed-off-by:
Himanshu Madhani <himanshu.madhani@cavium.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Hans Verkuil authored
[ Upstream commit f94d463f ] Move cec_get_edid_phys_addr() to cec-adap.c. It's not worth keeping a separate source for this. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Cc: <stable@vger.kernel.org> # for v4.17 and up Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Hans Verkuil authored
[ Upstream commit 9cfd2753 ] Several CEC functions are actually specific for use with receivers, i.e. they should be part of the V4L2 subsystem, not CEC. These functions deal with validating and modifying EDIDs for (HDMI) receivers, and they do not actually have anything to do with the CEC subsystem and whether or not CEC is enabled. The problem was that if the CEC_CORE config option was not set, then these functions would become stubs, but that's not right: they should always be valid. So replace the cec_ prefix by v4l2_ and move them to v4l2-dv-timings.c. Update all drivers that call these accordingly. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Cc: <stable@vger.kernel.org> # for v4.17 and up Signed-off-by:
-
Jan-Marek Glogowski authored
[ Upstream commit 3cf71bc9 ] This re-applies the workaround for "some DP sinks, [which] are a little nuts" from commit 1a36147b ("drm/i915: Perform link quality check unconditionally during long pulse"). It makes the secondary AOC E2460P monitor connected via DP to an acer Veriton N4640G usable again. This hunk was dropped in commit c85d200e ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") Fixes: c85d200e ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") [Cleaned up commit message, added stable cc] Signed-off-by:
Jan-Marek Glogowski <glogow@fbihome.de> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20180825191035.3945-1-lyude@redhat.comSigned-off-by:
-
YueHaibing authored
[ Upstream commit bc6f2a75 ] In module_add_modinfo_attrs if sysfs_create_file fails, we forget to free allocated modinfo_attrs and roll back the sysfs files. Fixes: 03e88ae1 ("[PATCH] fix module sysfs files reference counting") Reviewed-by:
Miroslav Benes <mbenes@suse.cz> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
Jessica Yu <jeyu@kernel.org> Signed-off-by:
-
Jessica Yu authored
[ Upstream commit 38f054d5 ] Some arches (e.g., arm64, x86) have moved towards non-executable module_alloc() allocations for security hardening reasons. That means that the module loader will need to set the text section of a module to executable, regardless of whether or not CONFIG_STRICT_MODULE_RWX is set. When CONFIG_STRICT_MODULE_RWX=y, module section allocations are always page-aligned to handle memory rwx permissions. On some arches with CONFIG_STRICT_MODULE_RWX=n however, when setting the module text to executable, the BUG_ON() in frob_text() gets triggered since module section allocations are not page-aligned when CONFIG_STRICT_MODULE_RWX=n. Since the set_memory_* API works with pages, and since we need to call set_memory_x() regardless of whether CONFIG_STRICT_MODULE_RWX is set, we might as well page-align all module section allocations for ease of managing rwx permissions of module sections (text, rodata, etc). Fixes: 2eef1399 ("modules: fix BUG when load module with rodata=n") Reported-by:
Martin Kaiser <lists@kaiser.cx> Reported-by:
Bartosz Golaszewski <brgl@bgdev.pl> Tested-by:
David Lechner <david@lechnology.com> Tested-by:
Martin Kaiser <martin@kaiser.cx> Tested-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by:
-
Brian Norris authored
[ Upstream commit 1e2517d1 ] Commit d5269c45 ("remoteproc: qcom: q6v5: Propagate EPROBE_DEFER") fixed up our probe code to handle -EPROBE_DEFER, but it ignored one of our interrupts, and it also didn't really handle all the other error codes you might get (e.g., with a bad DT definition). Handle those all explicitly. Fixes: d5269c45 ("remoteproc: qcom: q6v5: Propagate EPROBE_DEFER") Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit 9c940bbe ] Clang warns after commit 8985167e ("clk: s2mps11: Fix matching when built as module and DT node contains compatible"): drivers/clk/clk-s2mps11.c:242:34: warning: variable 's2mps11_dt_match' is not needed and will not be emitted [-Wunneeded-internal-declaration] static const struct of_device_id s2mps11_dt_match[] = { ^ 1 warning generated. This warning happens when a variable is used in some construct that doesn't require a reference to that variable to be emitted in the symbol table; in this case, it's MODULE_DEVICE_TABLE, which only needs to hold the data of the variable, not the variable itself. $ nm -S drivers/clk/clk-s2mps11.o | rg s2mps11_dt_match 00000078 000003d4 R __mod_of__s2mps11_dt_match_device_table Normally, with device ID table variables, it means that the variable just needs to be tied to the device declaration at the bottom of the file, like s2mps11_clk_id: $ nm -S drivers/clk/clk-s2mps11.o | rg s2mps11_clk_id 00000000 00000078 R __mod_platform__s2mps11_clk_id_device_table 00000000 00000078 r s2mps11_clk_id However, because the comment above this deliberately doesn't want this variable added to .of_match_table, we need to mark s2mps11_dt_match as __used to silence this warning. This makes it clear to Clang that the variable is used for something, even if a reference to it isn't being emitted. Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Fixes: 8985167e ("clk: s2mps11: Fix matching when built as module and DT node contains compatible") Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Hannes Reinecke authored
[ Upstream commit 8730c1dd ] When tearing down a controller the following warning is issued: WARNING: CPU: 0 PID: 30681 at ../kernel/workqueue.c:2418 check_flush_dependency This happens as the err_work workqueue item is scheduled on the system workqueue (which has WQ_MEM_RECLAIM not set), but is flushed from a workqueue which has WQ_MEM_RECLAIM set. Fix this by providing an FC-NVMe specific workqueue. Fixes: 4cff280a ("nvme-fc: resolve io failures during connect") Signed-off-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
David Abdurachmanov authored
[ Upstream commit 397182e0 ] Noticed while building kernel-4.20.0-0.rc5.git2.1.fc30 for Fedora 30/RISCV. [..] BUILDSTDERR: arch/riscv/kernel/ftrace.c: In function 'prepare_ftrace_return': BUILDSTDERR: arch/riscv/kernel/ftrace.c:135:6: warning: unused variable 'err' [-Wunused-variable] BUILDSTDERR: int err; BUILDSTDERR: ^~~ [..] Signed-off-by:
David Abdurachmanov <david.abdurachmanov@gmail.com> Fixes: e949b6db ("riscv/function_graph: Simplify with function_graph_enter()") Reviewed-by:
Olof Johansson <olof@lixom.net> Acked-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
Palmer Dabbelt <palmer@sifive.com> Signed-off-by:
-
Nicolas Boichat authored
[ Upstream commit 31013836 ] The basepath may contain special characters, which would confuse the regex matcher. ${var#prefix} does the right thing. Link: http://lkml.kernel.org/r/20190518055946.181563-1-drinkcat@chromium.org Fixes: 67a28de4 ("scripts/decode_stacktrace: only strip base path when a prefix of the path") Signed-off-by:
Nicolas Boichat <drinkcat@chromium.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Dmitry Voytik authored
[ Upstream commit 26e2d7b0 ] After commit ef05bcb6, boot from USB drives is broken. Fix this problem by enabling usb-host regulators during boot time. Fixes: ef05bcb6 ("arm64: dts: rockchip: fix vcc_host1_5v pin assign on rk3328-rock64") Cc: stable@vger.kernel.org Signed-off-by:
Dmitry Voytik <voytikd@gmail.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Fabien Dessenne authored
[ Upstream commit dbb9fcc8 ] Manage the irq = 0 case, where we shall return an error. Fixes: b5b5a27b ("media: stm32-dcmi: return appropriate error codes during probe") Signed-off-by:
Fabien Dessenne <fabien.dessenne@st.com> Reported-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Christophe Leroy authored
[ Upstream commit 9c4e4c90 ] Otherwise, the following warning is encountered: WARNING: vmlinux.o(.text+0x3dc6): Section mismatch in reference from the variable start_here_multiplatform to the function .init.text:.early_setup() The function start_here_multiplatform() references the function __init .early_setup(). This is often because start_here_multiplatform lacks a __init annotation or the annotation of .early_setup is wrong. Fixes: 56c46bba ("powerpc/64: Fix booting large kernels with STRICT_KERNEL_RWX") Cc: Russell Currey <ruscur@russell.cc> Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Steven Rostedt (VMware) authored
[ Upstream commit 745cfeaa ] Arnd reported the following compiler warning: arch/x86/kernel/ftrace.c:669:23: error: 'ftrace_jmp_replace' defined but not used [-Werror=unused-function] The ftrace_jmp_replace() function now only has a single user and should be simply moved by that user. But looking at the code, it shows that ftrace_jmp_replace() is similar to ftrace_call_replace() except that instead of using the opcode of 0xe8 it uses 0xe9. It makes more sense to consolidate that function into one implementation that both ftrace_jmp_replace() and ftrace_call_replace() use by passing in the op code separate. The structure in ftrace_code_union is also modified to replace the "e8" field with the more appropriate name "op". Cc: stable@vger.kernel.org Reported-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
-
Hangbin Liu authored
[ Upstream commit 34632975 ] DEV_ADDR is defined but not used. Use it in address setting. Do the same with IPv6 for consistency. Reported-by:
David Ahern <dsahern@gmail.com> Fixes: fc82d93e ("selftests: fib_rule_tests: fix local IPv4 address typo") Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Jason A. Donenfeld authored
[ Upstream commit 0354c1a3 ] While this doesn't actually amount to a real difference, since the macro evaluates to the same thing, every place else operates on ktime_t using these functions, so let's not break the pattern. Fixes: e3ff9c36 ("timekeeping: Repair ktime_get_coarse*() granularity") Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
-
Manikanta Pubbisetty authored
[ Upstream commit e6f40511 ] Commit 33d915d9 ("{nl,mac}80211: allow 4addr AP operation on crypto controlled devices") has introduced a change which allows 4addr operation on crypto controlled devices (ex: ath10k). This change has inadvertently impacted the interface combinations logic on such devices. General rule is that software interfaces like AP/VLAN should not be listed under supported interface combinations and should not be considered during validation of these combinations; because of the aforementioned change, AP/VLAN interfaces(if present) will be checked against interfaces supported by the device and blocks valid interface combinations. Consider a case where an AP and AP/VLAN are up and running; when a second AP device is brought up on the same physical device, this AP will be checked against the AP/VLAN interface (which will not be part of supported interface combinations of the device) and blocks second AP to come up. Add a new API cfg80211_iftype_allowed() to fix the problem, this API works for all devices with/without SW crypto control. Signed-off-by:
Manikanta Pubbisetty <mpubbise@codeaurora.org> Fixes: 33d915d9 ("{nl,mac}80211: allow 4addr AP operation on crypto controlled devices") Link: https://lore.kernel.org/r/1563779690-9716-1-git-send-email-mpubbise@codeaurora.orgSigned-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Dennis Zhou authored
[ Upstream commit c9b3007f ] The iolatency controller is based on rq_qos. It increments on rq_qos_throttle() and decrements on either rq_qos_cleanup() or rq_qos_done_bio(). a3fb01ba fixes the double accounting issue where blk_mq_make_request() may call both rq_qos_cleanup() and rq_qos_done_bio() on REQ_NO_WAIT. So checking STS_AGAIN prevents the double decrement. The above works upstream as the only way we can get STS_AGAIN is from blk_mq_get_request() failing. The STS_AGAIN handling isn't a real problem as bio_endio() skipping only happens on reserved tag allocation failures which can only be caused by driver bugs and already triggers WARN. However, the fix creates a not so great dependency on how STS_AGAIN can be propagated. Internally, we (Facebook) carry a patch that kills read ahead if a cgroup is io congested or a fatal signal is pending. This combined with chained bios progagate their bi_status to the parent is not already set can can cause the parent bio to not clean up properly even though it was successful. This consequently leaks the inflight counter and can hang all IOs under that blkg. To nip the adverse interaction early, this removes the rq_qos_cleanup() callback in iolatency in favor of cleaning up always on the rq_qos_done_bio() path. Fixes: a3fb01ba ("blk-iolatency: only account submitted bios") Debugged-by:
Tejun Heo <tj@kernel.org> Debugged-by:
Josef Bacik <josef@toxicpanda.com> Signed-off-by:
Dennis Zhou <dennis@kernel.org> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Liu Bo authored
[ Upstream commit 391f552a ] This is to catch any unexpected negative value of inflight IO counter. Signed-off-by:
Liu Bo <bo.liu@linux.alibaba.com> Signed-off-by:
-
Dexuan Cui authored
[ Upstream commit 685703b4 ] There is a race condition for an established connection that is being closed by the guest: the refcnt is 4 at the end of hvs_release() (Note: here the 'remove_sock' is false): 1 for the initial value; 1 for the sk being in the bound list; 1 for the sk being in the connected list; 1 for the delayed close_work. After hvs_release() finishes, __vsock_release() -> sock_put(sk) *may* decrease the refcnt to 3. Concurrently, hvs_close_connection() runs in another thread: calls vsock_remove_sock() to decrease the refcnt by 2; call sock_put() to decrease the refcnt to 0, and free the sk; next, the "release_sock(sk)" may hang due to use-after-free. In the above, after hvs_release() finishes, if hvs_close_connection() runs faster than "__vsock_release() -> sock_put(sk)", then there is not any issue, because at the beginning of hvs_close_connection(), the refcnt is still 4. The issue can be resolved if an extra reference is taken when the connection is established. Fixes: a9eeb998 ("hv_sock: Add support for delayed close") Signed-off-by:
Sunil Muthuswamy <sunilmut@microsoft.com> Signed-off-by:
-
Sven Eckelmann authored
commit a15d56a6 upstream. Multiple batadv_ogm_packet can be stored in an skbuff. The functions batadv_iv_ogm_send_to_if()/batadv_iv_ogm_receive() use batadv_iv_ogm_aggr_packet() to check if there is another additional batadv_ogm_packet in the skb or not before they continue processing the packet. The length for such an OGM is BATADV_OGM_HLEN + batadv_ogm_packet->tvlv_len. The check must first check that at least BATADV_OGM_HLEN bytes are available before it accesses tvlv_len (which is part of the header. Otherwise it might try read outside of the currently available skbuff to get the content of tvlv_len. Fixes: ef261577 ("batman-adv: tvlv - basic infrastructure") Reported-by: syzbot+355cab184197dbbfa384@syzkaller.appspotmail.com Signed-off-by:
Sven Eckelmann <sven@narfation.org> Acked-by:
Antonio Quartulli <a@unstable.cc> Signed-off-by:
Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by:
-
Eric Dumazet authored
commit 3ee1bb7a upstream. batadv_netlink_get_ifindex() needs to make sure user passed a correct u32 attribute. syzbot reported : BUG: KMSAN: uninit-value in batadv_netlink_dump_hardif+0x70d/0x880 net/batman-adv/netlink.c:968 CPU: 1 PID: 11705 Comm: syz-executor888 Not tainted 5.1.0+ #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x191/0x1f0 lib/dump_stack.c:113 kmsan_report+0x130/0x2a0 mm/kmsan/kmsan.c:622 __msan_warning+0x75/0xe0 mm/kmsan/kmsan_instr.c:310 batadv_netlink_dump_hardif+0x70d/0x880 net/batman-adv/netlink.c:968 genl_lock_dumpit+0xc6/0x130 net/netlink/genetlink.c:482 netlink_dump+0xa84/0x1ab0 net/netlink/af_netlink.c:2253 __netlink_dump_start+0xa3a/0xb30 net/netlink/af_netlink.c:2361 genl_family_rcv_msg net/netlink/genetlink.c:550 [inline] genl_rcv_msg+0xfc1/0x1a40 net/netlink/genetlink.c:627 netlink_rcv_skb+0x431/0x620 net/netlink/af_netlink.c:2486 genl_rcv+0x63/0x80 net/netlink/genetlink.c:638 netlink_unicast_kernel net/netlink/af_netlink.c:1311 [inline] netlink_unicast+0xf3e/0x1020 net/netlink/af_netlink.c:1337 netlink_sendmsg+0x127e/0x12f0 net/netlink/af_netlink.c:1926 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg net/socket.c:661 [inline] ___sys_sendmsg+0xcc6/0x1200 net/socket.c:2260 __sys_sendmsg net/socket.c:2298 [inline] __do_sys_sendmsg net/socket.c:2307 [inline] __se_sys_sendmsg+0x305/0x460 net/socket.c:2305 __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2305 do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291 entry_SYSCALL_64_after_hwframe+0x63/0xe7 RIP: 0033:0x440209 Fixes: b60620cf ("batman-adv: netlink: hardif query") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
-
Gustavo Romero authored
commit 8205d5d9 upstream. When we take an FP unavailable exception in a transaction we have to account for the hardware FP TM checkpointed registers being incorrect. In this case for this process we know the current and checkpointed FP registers must be the same (since FP wasn't used inside the transaction) hence in the thread_struct we copy the current FP registers to the checkpointed ones. This copy is done in tm_reclaim_thread(). We use thread->ckpt_regs.msr to determine if FP was on when in userspace. thread->ckpt_regs.msr represents the state of the MSR when exiting userspace. This is setup by check_if_tm_restore_required(). Unfortunatley there is an optimisation in giveup_all() which returns early if tsk->thread.regs->msr (via local variable `usermsr`) has FP=VEC=VSX=SPE=0. This optimisation means that check_if_tm_restore_required() is not called and hence thread->ckpt_regs.msr is not updated and will contain an old value. This can happen if due to load_fp=255 we start a userspace process with MSR FP=1 and then we are context switched out. In this case thread->ckpt_regs.msr will contain FP=1. If that same process is then context switched in and load_fp overflows, MSR will have FP=0. If that process now enters a transaction and does an FP instruction, the FP unavailable will not update thread->ckpt_regs.msr (the bug) and MSR FP=1 will be retained in thread->ckpt_regs.msr. tm_reclaim_thread() will then not perform the required memcpy and the checkpointed FP regs in the thread struct will contain the wrong values. The code path for this happening is: Userspace: Kernel Start userspace with MSR FP/VEC/VSX/SPE=0 TM=1 < ----- ... tbegin bne fp instruction FP unavailable ---- > fp_unavailable_tm() tm_reclaim_current() tm_reclaim_thread() giveup_all() return early since FP/VMX/VSX=0 /* ckpt MSR not updated (Incorrect) */ tm_reclaim() /* thread_struct ckpt FP regs contain junk (OK) */ /* Sees ckpt MSR FP=1 (Incorrect) */ no memcpy() performed /* thread_struct ckpt FP regs not fixed (Incorrect) */ tm_recheckpoint() /* Put junk in hardware checkpoint FP regs */ .... < ----- Return to userspace with MSR TM=1 FP=1 with junk in the FP TM checkpoint TM rollback reads FP junk This is a data integrity problem for the current process as the FP registers are corrupted. It's also a security problem as the FP registers from one process may be leaked to another. This patch moves up check_if_tm_restore_required() in giveup_all() to ensure thread->ckpt_regs.msr is updated correctly. A simple testcase to replicate this will be posted to tools/testing/selftests/powerpc/tm/tm-poison.c Similarly for VMX. This fixes CVE-2019-15030. Fixes: f48e91e8 ("powerpc/tm: Fix FP and VMX register corruption") Cc: stable@vger.kernel.org # 4.12+ Signed-off-by:
Gustavo Romero <gromero@linux.vnet.ibm.com> Signed-off-by:
Michael Neuling <mikey@neuling.org> Signed-off-by:
-
