summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2018-01-12x86/spectre: Add boot time option to select Spectre v2 mitigationDavid Woodhouse
Add a spectre_v2= option to select the mitigation used for the indirect branch speculation vulnerability. Currently, the only option available is retpoline, in its various forms. This will be expanded to cover the new IBRS/IBPB microcode features. The RETPOLINE_AMD feature relies on a serializing LFENCE for speculation control. For AMD hardware, only set RETPOLINE_AMD if LFENCE is a serializing instruction, which is indicated by the LFENCE_RDTSC feature. [ tglx: Folded back the LFENCE/AMD fixes and reworked it so IBRS integration becomes simple ] Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: gnomes@lxorguk.ukuu.org.uk Cc: Rik van Riel <riel@redhat.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: thomas.lendacky@amd.com Cc: Peter Zijlstra <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jikos@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Kees Cook <keescook@google.com> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org> Cc: Paul Turner <pjt@google.com> Link: https://lkml.kernel.org/r/1515707194-20531-5-git-send-email-dwmw@amazon.co.uk
2018-01-12x86/retpoline: Add initial retpoline supportDavid Woodhouse
Enable the use of -mindirect-branch=thunk-extern in newer GCC, and provide the corresponding thunks. Provide assembler macros for invoking the thunks in the same way that GCC does, from native and inline assembler. This adds X86_FEATURE_RETPOLINE and sets it by default on all CPUs. In some circumstances, IBRS microcode features may be used instead, and the retpoline can be disabled. On AMD CPUs if lfence is serialising, the retpoline can be dramatically simplified to a simple "lfence; jmp *\reg". A future patch, after it has been verified that lfence really is serialising in all circumstances, can enable this by setting the X86_FEATURE_RETPOLINE_AMD feature bit in addition to X86_FEATURE_RETPOLINE. Do not align the retpoline in the altinstr section, because there is no guarantee that it stays aligned when it's copied over the oldinstr during alternative patching. [ Andi Kleen: Rename the macros, add CONFIG_RETPOLINE option, export thunks] [ tglx: Put actual function CALL/JMP in front of the macros, convert to symbolic labels ] [ dwmw2: Convert back to numeric labels, merge objtool fixes ] Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Arjan van de Ven <arjan@linux.intel.com> Acked-by: Ingo Molnar <mingo@kernel.org> Cc: gnomes@lxorguk.ukuu.org.uk Cc: Rik van Riel <riel@redhat.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: thomas.lendacky@amd.com Cc: Peter Zijlstra <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jikos@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Kees Cook <keescook@google.com> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org> Cc: Paul Turner <pjt@google.com> Link: https://lkml.kernel.org/r/1515707194-20531-4-git-send-email-dwmw@amazon.co.uk
2018-01-11x86/pti: Make unpoison of pgd for trusted boot work for realDave Hansen
The inital fix for trusted boot and PTI potentially misses the pgd clearing if pud_alloc() sets a PGD. It probably works in *practice* because for two adjacent calls to map_tboot_page() that share a PGD entry, the first will clear NX, *then* allocate and set the PGD (without NX clear). The second call will *not* allocate but will clear the NX bit. Defer the NX clearing to a point after it is known that all top-level allocations have occurred. Add a comment to clarify why. [ tglx: Massaged changelog ] Fixes: 262b6b30087 ("x86/tboot: Unbreak tboot with PTI enabled") Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Andrea Arcangeli <aarcange@redhat.com> Cc: Jon Masters <jcm@redhat.com> Cc: "Tim Chen" <tim.c.chen@linux.intel.com> Cc: gnomes@lxorguk.ukuu.org.uk Cc: peterz@infradead.org Cc: ning.sun@intel.com Cc: tboot-devel@lists.sourceforge.net Cc: andi@firstfloor.org Cc: luto@kernel.org Cc: law@redhat.com Cc: pbonzini@redhat.com Cc: torvalds@linux-foundation.org Cc: gregkh@linux-foundation.org Cc: dwmw@amazon.co.uk Cc: nickc@redhat.com Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20180110224939.2695CD47@viggo.jf.intel.com
2018-01-11x86/PCI: Move and shrink AMD 64-bit window to avoid conflict=?UTF-8?q?Christian=20K=C3=B6nig?=
Avoid problems with BIOS implementations which don't report all used resources to the OS by only allocating a 256GB window directly below the hardware limit (from the BKDG, sec 2.4.6). Fixes a silent reboot loop reported by Aaro Koskinen <aaro.koskinen@iki.fi> on an AMD-based MSI MS-7699/760GA-P43(FX) system. This was apparently caused by RAM or other unreported hardware that conflicted with the new window. Link: https://support.amd.com/TechDocs/49125_15h_Models_30h-3Fh_BKDG.pdf Link: https://lkml.kernel.org/r/20180105220412.fzpwqe4zljdawr36@darkstar.musicnaut.iki.fi Fixes: fa564ad96366 ("x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 00-1f, 30-3f, 60-7f)") Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Christian König <christian.koenig@amd.com> [bhelgaas: changelog, comment, Fixes:] Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
2018-01-11x86/PCI: Add "pci=big_root_window" option for AMD 64-bit windows=?UTF-8?q?Christian=20K=C3=B6nig?=
Only try to enable a 64-bit window on AMD CPUs when "pci=big_root_window" is specified. This taints the kernel because the new 64-bit window uses address space we don't know anything about, and it may contain unreported devices or memory that would conflict with the window. The pci_amd_enable_64bit_bar() quirk that enables the window is specific to AMD CPUs. The generic solution would be to have the firmware enable the window and describe it in the host bridge's _CRS method, or at least describe it in the _PRS method so the OS would have the option of enabling it. Signed-off-by: Christian König <christian.koenig@amd.com> [bhelgaas: changelog, extend doc, mention taint in dmesg] Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
2018-01-11Merge branch 'kvm-insert-lfence' into kvm-masterPaolo Bonzini
Topic branch for CVE-2017-5753, avoiding conflicts in the next merge window.
2018-01-11KVM: x86: Add memory barrier on vmcs field lookupAndrew Honig
This adds a memory barrier when performing a lookup into the vmcs_field_to_offset_table. This is related to CVE-2017-5753. Signed-off-by: Andrew Honig <ahonig@google.com> Reviewed-by: Jim Mattson <jmattson@google.com> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-01-11KVM: x86: emulate #UD while in guest modePaolo Bonzini
This reverts commits ae1f57670703656cc9f293722c3b8b6782f8ab3f and ac9b305caa0df6f5b75d294e4b86c1027648991e. If the hardware doesn't support MOVBE, but L0 sets CPUID.01H:ECX.MOVBE in L1's emulated CPUID information, then L1 is likely to pass that CPUID bit through to L2. L2 will expect MOVBE to work, but if L1 doesn't intercept #UD, then any MOVBE instruction executed in L2 will raise #UD, and the exception will be delivered in L2. Commit ac9b305caa0df6f5b75d294e4b86c1027648991e is a better and more complete version of ae1f57670703 ("KVM: nVMX: Do not emulate #UD while in guest mode"); however, neither considers the above case. Suggested-by: Jim Mattson <jmattson@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-01-11x86: kvm: propagate register_shrinker return codeArnd Bergmann
Patch "mm,vmscan: mark register_shrinker() as __must_check" is queued for 4.16 in linux-mm and adds a warning about the unchecked call to register_shrinker: arch/x86/kvm/mmu.c:5485:2: warning: ignoring return value of 'register_shrinker', declared with attribute warn_unused_result [-Wunused-result] This changes the kvm_mmu_module_init() function to fail itself when the call to register_shrinker fails. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-01-11x86/gart: Exclude GART aperture from vmcoreJiri Bohac
On machines where the GART aperture is mapped over physical RAM /proc/vmcore contains the remapped range and reading it may cause hangs or reboots. In the past, the GART region was added into the resource map, implemented by commit 56dd669a138c ("[PATCH] Insert GART region into resource map") However, inserting the iomem_resource from the early GART code caused resource conflicts with some AGP drivers (bko#72201), which got avoided by reverting the patch in commit 707d4eefbdb3 ("Revert [PATCH] Insert GART region into resource map"). This revert introduced the /proc/vmcore bug. The vmcore ELF header is either prepared by the kernel (when using the kexec_file_load syscall) or by the kexec userspace (when using the kexec_load syscall). Since we no longer have the GART iomem resource, the userspace kexec has no way of knowing which region to exclude from the ELF header. Changes from v1 of this patch: Instead of excluding the aperture from the ELF header, this patch makes /proc/vmcore return zeroes in the second kernel when attempting to read the aperture region. This is done by reusing the gart_oldmem_pfn_is_ram infrastructure originally intended to exclude XEN balooned memory. This works for both, the kexec_file_load and kexec_load syscalls. [Note that the GART region is the same in the first and second kernels: regardless whether the first kernel fixed up the northbridge/bios setting and mapped the aperture over physical memory, the second kernel finds the northbridge properly configured by the first kernel and the aperture never overlaps with e820 memory because the second kernel has a fake e820 map created from the crashkernel memory regions. Thus, the second kernel keeps the aperture address/size as configured by the first kernel.] register_oldmem_pfn_is_ram can only register one callback and returns an error if the callback has been registered already. Since XEN used to be the only user of this function, it never checks the return value. Now that we have more than one user, I added a WARN_ON just in case agp, XEN, or any other future user of register_oldmem_pfn_is_ram were to step on each other's toes. Fixes: 707d4eefbdb3 ("Revert [PATCH] Insert GART region into resource map") Signed-off-by: Jiri Bohac <jbohac@suse.cz> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Baoquan He <bhe@redhat.com> Cc: Toshi Kani <toshi.kani@hpe.com> Cc: David Airlie <airlied@linux.ie> Cc: yinghai@kernel.org Cc: joro@8bytes.org Cc: kexec@lists.infradead.org Cc: Borislav Petkov <bp@alien8.de> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Dave Young <dyoung@redhat.com> Cc: Vivek Goyal <vgoyal@redhat.com> Link: https://lkml.kernel.org/r/20180106010013.73suskgxm7lox7g6@dwarf.suse.cz
2018-01-11MIPS: Implement __multi3 for GCC7 MIPS64r6 buildsJames Hogan
GCC7 is a bit too eager to generate suboptimal __multi3 calls (128bit multiply with 128bit result) for MIPS64r6 builds, even in code which doesn't explicitly use 128bit types, such as the following: unsigned long func(unsigned long a, unsigned long b) { return a > (~0UL) / b; } Which GCC rearanges to: return (unsigned __int128)a * (unsigned __int128)b > 0xffffffffffffffff; Therefore implement __multi3, but only for MIPS64r6 with GCC7 as under normal circumstances we wouldn't expect any calls to __multi3 to be generated from kernel code. Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: James Hogan <jhogan@kernel.org> Tested-by: Waldemar Brodkorb <wbx@openadk.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Maciej W. Rozycki <macro@mips.com> Cc: Matthew Fortune <matthew.fortune@mips.com> Cc: Florian Fainelli <florian@openwrt.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/17890/
2018-01-11Merge tag 'kvm-ppc-fixes-4.15-3' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc into kvm-master PPC KVM fixes for 4.15 Four commits here, including two that were tagged but never merged. Three of them are for the HPT resizing code; two of those fix a user-triggerable use-after-free in the host, and one that fixes stale TLB entries in the guest. The remaining commit fixes a bug causing PR KVM guests under PowerVM to fail to start.
2018-01-11KVM MMU: check pending exception before injecting APFHaozhong Zhang
For example, when two APF's for page ready happen after one exit and the first one becomes pending, the second one will result in #DF. Instead, just handle the second page fault synchronously. Reported-by: Ross Zwisler <zwisler@gmail.com> Message-ID: <CAOxpaSUBf8QoOZQ1p4KfUp0jq76OKfGY4Uxs-Gg8ngReD99xww@mail.gmail.com> Reported-by: Alec Blayne <ab@tevsa.net> Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-01-11KVM: PPC: Use seq_puts() in kvmppc_exit_timing_show()Markus Elfring
A headline should be quickly put into a sequence. Thus use the function "seq_puts" instead of "seq_printf" for this purpose. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2018-01-11KVM: PPC: Book3S HV: Remove vcpu->arch.dec usageAlexander Graf
On Book3S in HV mode, we don't use the vcpu->arch.dec field at all. Instead, all logic is built around vcpu->arch.dec_expires. So let's remove the one remaining piece of code that was setting it. Signed-off-by: Alexander Graf <agraf@suse.de> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2018-01-10Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds
Pull networking fixes from David Miller: 1) BPF speculation prevention and BPF_JIT_ALWAYS_ON, from Alexei Starovoitov. 2) Revert dev_get_random_name() changes as adjust the error code returns seen by userspace definitely breaks stuff. 3) Fix TX DMA map/unmap on older iwlwifi devices, from Emmanuel Grumbach. 4) From wrong AF family when requesting sock diag modules, from Andrii Vladyka. 5) Don't add new ipv6 routes attached to the null_entry, from Wei Wang. 6) Some SCTP sockopt length fixes from Marcelo Ricardo Leitner. 7) Don't leak when removing VLAN ID 0, from Cong Wang. 8) Hey there's a potential leak in ipv6_make_skb() too, from Eric Dumazet. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (27 commits) ipv6: sr: fix TLVs not being copied using setsockopt ipv6: fix possible mem leaks in ipv6_make_skb() mlxsw: spectrum_qdisc: Don't use variable array in mlxsw_sp_tclass_congestion_enable mlxsw: pci: Wait after reset before accessing HW nfp: always unmask aux interrupts at init 8021q: fix a memory leak for VLAN 0 device of_mdio: avoid MDIO bus removal when a PHY is missing caif_usb: use strlcpy() instead of strncpy() doc: clarification about setting SO_ZEROCOPY net: gianfar_ptp: move set_fipers() to spinlock protecting area sctp: make use of pre-calculated len sctp: add a ceiling to optlen in some sockopts sctp: GFP_ATOMIC is not needed in sctp_setsockopt_events bpf: introduce BPF_JIT_ALWAYS_ON config bpf: avoid false sharing of map refcount with max_entries ipv6: remove null_entry before adding default route SolutionEngine771x: add Ether TSU resource SolutionEngine771x: fix Ether platform data docs-rst: networking: wire up msg_zerocopy net: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg() ...
2018-01-10PCI: Add #defines for Completion Timeout Disable featureBjorn Helgaas
Add #defines for the Completion Timeout Disable feature and use them. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
2018-01-10Merge tag 'irqchip-4.16' of ↵Thomas Gleixner
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core Pull irqchip updates for 4.16 from Marc Zyngier - Fix a GICv3 issue when parsing ACPI entries for disabled CPUs - Driver for the MIPS Goldfish virtual platform - Small fixlet for the ompic driver - Interrupt polarity support for the Raspberry Pi irqchip
2018-01-10Merge tag 'imx-defconfig-4.16' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into next/soc i.MX defconfig updates for 4.16: - Enable CPU_FREQ_STAT for cpufreq transtion statistics support. - Enable SRTC driver RTC_DRV_MXC_V2 for i.MX53. - Turn on a few drivers useful for DART-MX6 SoM support, SERDEV bluetooth, SERIAL_DEV_BUS, WL18XX, and DEFAULT_ON LED Trigger. * tag 'imx-defconfig-4.16' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: ARM: imx_v6_v7_defconfig: enable CONFIG_CPU_FREQ_STAT ARM: imx_v6_v7_defconfig: enable RTC_DRV_MXC_V2 ARM: imx_v6_v7_defconfig: Add missing config for DART-MX6 SoM Signed-off-by: Olof Johansson <olof@lixom.net>
2018-01-10x86/alternatives: Fix optimize_nops() checkingBorislav Petkov
The alternatives code checks only the first byte whether it is a NOP, but with NOPs in front of the payload and having actual instructions after it breaks the "optimized' test. Make sure to scan all bytes before deciding to optimize the NOPs in there. Reported-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Jiri Kosina <jikos@kernel.org> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Andrew Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org> Cc: Paul Turner <pjt@google.com> Link: https://lkml.kernel.org/r/20180110112815.mgciyf5acwacphkq@pd.tnic
2018-01-10MIPS: mm: Fix duplicate "const" on insn_table_MMJames Hogan
Fix the following gcc 7.x build error on microMIPS builds: arch/mips/mm/uasm-micromips.c:43:26: error: duplicate ‘const’ declaration specifier [-Werror=duplicate-decl-specifier] static const struct insn const insn_table_MM[insn_invalid] = { ^~~~~ The same issue has already been fixed in uasm-mips by commit 00e06297b351 ("MIPS: mm: remove duplicate "const" qualifier on insn_table"). Signed-off-by: James Hogan <jhogan@kernel.org> Fixes: ce807d5f67ed ("MIPS: Optimize uasm insn lookup.") Cc: David Daney <david.daney@cavium.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/17889/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2018-01-10MIPS: CM: Drop WARN_ON(vp != 0)James Hogan
Since commit 68923cdc2eb3 ("MIPS: CM: Add cluster & block args to mips_cm_lock_other()"), mips_smp_send_ipi_mask() has used mips_cm_lock_other_cpu() with each CPU number, rather than mips_cm_lock_other() with the first VPE in each core. Prior to r6, multicore multithreaded systems such as dual-core dual-thread interAptivs with CPU Idle enabled (e.g. MIPS Creator Ci40) results in mips_cm_lock_other() repeatedly hitting WARN_ON(vp != 0). There doesn't appear to be anything fundamentally wrong about passing a non-zero VP/VPE number, even if it is a core's region that is locked into the other region before r6, so remove that particular WARN_ON(). Fixes: 68923cdc2eb3 ("MIPS: CM: Add cluster & block args to mips_cm_lock_other()") Signed-off-by: James Hogan <jhogan@kernel.org> Reviewed-by: Paul Burton <paul.burton@mips.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org # 4.14+ Patchwork: https://patchwork.linux-mips.org/patch/17883/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2018-01-10MIPS: ralink: Fix platform_get_irq's error checkingArvind Yadav
The platform_get_irq() function returns negative if an error occurs. zero or positive number on success. platform_get_irq() error checking for zero is not correct. Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Cc: john@phrozen.org Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/17783/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2018-01-10MIPS: Fix CPS SMP NS16550 UART defaultsJames Hogan
The MIPS_CPS_NS16550_BASE and MIPS_CPS_NS16550_SHIFT options have no defaults for non-Malta platforms which select SYS_SUPPORTS_MIPS_CPS (i.e. the pistachio and generic platforms). This is problematic for automated allyesconfig and allmodconfig builds based on these platforms, since make silentoldconfig tries to ask the user for values, and especially since v4.15 where the default platform was switched to generic. Default these options to 0 and arrange for MIPS_CPS_NS16550 to be no when using that default base address, so that the option only has an effect when the default is provided (i.e. Malta) or when a value is provided by the user. Fixes: 609cf6f2291a ("MIPS: CPS: Early debug using an ns16550-compatible UART") Signed-off-by: James Hogan <jhogan@kernel.org> Reviewed-by: Paul Burton <paul.burton@mips.com> Tested-by: Guenter Roeck <linux@roeck-us.net> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/17749/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2018-01-10MIPS: BCM47XX Avoid compile error with MIPS allnoconfigMatt Redfearn
Currently MIPS allnoconfig with CONFIG_BCM47XX=y fails to compile due to neither BCM47XX_BCMA nor BCM47XX_SSB being selected. This leads the enumeration in arch/mips/include/asm/mach-bcm47xx/bcm47xx.h to be empty, and compilation fails: In file included from arch/mips/bcm47xx/irq.c:32:0: ./arch/mips/include/asm/mach-bcm47xx/bcm47xx.h:34:1: error: expected identifier before '}' token }; ^ make[2]: *** [scripts/Makefile.build:314: arch/mips/bcm47xx/irq.o] Error 1 Fix this by ensuring that BCM47XX_SSB is selected if BCM47XX_BCMA is not. This allows us to select either system or both, but not neither. Signed-off-by: Matt Redfearn <matt.redfearn@mips.com> Cc: James Hogan <james.hogan@mips.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17703/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2018-01-10s390: move s390_pci_dma_ops to asm/pci_dma.hChristoph Hellwig
This is not needed in drivers, so move it to a private header. Signed-off-by: Christoph Hellwig <hch@lst.de>
2018-01-10microblaze: remove the dead !NOT_COHERENT_CACHE dma codeChristoph Hellwig
Signed-off-by: Christoph Hellwig <hch@lst.de>
2018-01-10microblaze: remove dma_nommu_dma_supportedChristoph Hellwig
Always returning 1 is the same behavior as not supplying a method at all. Signed-off-by: Christoph Hellwig <hch@lst.de>
2018-01-10microblaze: rename dma_direct to dma_nommuChristoph Hellwig
This frees the dma_direct_* namespace for a generic implementation. Signed-off-by: Christoph Hellwig <hch@lst.de>
2018-01-10powerpc: rename dma_direct_ to dma_nommu_Christoph Hellwig
We want to use the dma_direct_ namespace for a generic implementation, so rename powerpc to the second best choice: dma_nommu_. Signed-off-by: Christoph Hellwig <hch@lst.de>
2018-01-10hexagon: use the generic dma_capable helperChristoph Hellwig
Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Richard Kuo <rkuo@codeaurora.org>
2018-01-10dma-mapping: move dma_mark_clean to dma-direct.hChristoph Hellwig
And unlike the other helpers we don't require a <asm/dma-direct.h> as this helper is a special case for ia64 only, and this keeps it as simple as possible. Signed-off-by: Christoph Hellwig <hch@lst.de>
2018-01-10dma-mapping: move swiotlb arch helpers to a new headerChristoph Hellwig
phys_to_dma, dma_to_phys and dma_capable are helpers published by architecture code for use of swiotlb and xen-swiotlb only. Drivers are not supposed to use these directly, but use the DMA API instead. Move these to a new asm/dma-direct.h helper, included by a linux/dma-direct.h wrapper that provides the default linear mapping unless the architecture wants to override it. In the MIPS case the existing dma-coherent.h is reused for now as untangling it will take a bit of work. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Robin Murphy <robin.murphy@arm.com>
2018-01-10MIPS: RB532: Avoid undefined mac_pton without GENERIC_NET_UTILSMatt Redfearn
Currently MIPS allnoconfig with CONFIG_MIKROTIK_RB532=y fails to link due to missing support for mac_pton(): LD vmlinux arch/mips/rb532/devices.o: In function `setup_kmac': devices.c:(.init.text+0xc): undefined reference to `mac_pton' Rather than adding dependencies to the platform to force inclusion of GENERIC_NET_UTILS which is selected by CONFIG_NET, just exclude the setup of the MAC address if CONFIG_NET is not selected in the kernel config. Signed-off-by: Matt Redfearn <matt.redfearn@mips.com> Cc: James Hogan <james.hogan@mips.com> Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Tony Lindgren <tony@atomide.com> Cc: Vladimir Zapolskiy <vz@mleia.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17702/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2018-01-10MIPS: RB532: Avoid undefined early_serial_setup() without SERIAL_8250_CONSOLEMatt Redfearn
Currently MIPS allnoconfig with CONFIG_MIKROTIK_RB532=y fails to link due to missing support for early_serial_setup(): LD vmlinux arch/mips/rb532/serial.o: In function `setup_serial_port': serial.c:(.init.text+0x14): undefined reference to `early_serial_setup' Rather than adding dependencies to the platform to force inclusion of SERIAL_8250_CONSOLE together with it's dependencies like TTY, HAS_IOMEM, etc, just exclude arch/mips/rb532/serial.c from the build when it's dependency is not selected in the kernel config. Reported-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Matt Redfearn <matt.redfearn@mips.com> Cc: James Hogan <james.hogan@mips.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17701/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2018-01-10MIPS: ath25: Avoid undefined early_serial_setup() without SERIAL_8250_CONSOLEMatt Redfearn
Currently MIPS allnoconfig with CONFIG_ATH25=y fails to link due to missing support for early_serial_setup(): LD vmlinux arch/mips/ath25/devices.o: In function ath25_serial_setup': devices.c:(.init.text+0x68): undefined reference to 'early_serial_setup' Rather than adding dependencies to the platform to force inclusion of SERIAL_8250_CONSOLE together with it's dependencies like TTY, HAS_IOMEM, etc, just make ath25_serial_setup() a no-op when the dependency is not selected in the kernel config. Signed-off-by: Matt Redfearn <matt.redfearn@mips.com> Cc: James Hogan <james.hogan@mips.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Philippe Ombredanne <pombredanne@nexb.com> Cc: Kate Stewart <kstewart@linuxfoundation.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17700/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2018-01-10mips: fix an off-by-one in dma_capableChristoph Hellwig
This makes it match the generic version. Reported-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2018-01-10arm64: don't override dma_max_pfnChristoph Hellwig
The generic version now takes dma_pfn_offset into account, so there is no more need for an architecture override. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
2018-01-11powerpc: Don't preempt_disable() in show_cpuinfo()Benjamin Herrenschmidt
This causes warnings from cpufreq mutex code. This is also rather unnecessary and ineffective. If we really want to prevent concurrent unplug, we could take the unplug read lock but I don't see this being critical. Fixes: cd77b5ce208c ("powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo") Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-01-11powerpc/xmon: Don't print hashed pointers in paca dumpMichael Ellerman
Remember when the biggest problem we had to worry about was hashed pointers, those were the days. These were missed in my earlier patch because they don't match "%p", but the macro is hiding a "%p", so these all end up being hashed, which is not what we want in xmon. Convert them to "%px". Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-01-11powerpc/xmon: Add RFI flush related fields to paca dumpMichael Ellerman
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-01-10MIPS: AR7: ensure the port type's FCR value is usedJonas Gorski
Since commit aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers"), the port's default FCR value isn't used in serial8250_do_set_termios anymore, but copied over once in serial8250_config_port and then modified as needed. Unfortunately, serial8250_config_port will never be called if the port is shared between kernel and userspace, and the port's flag doesn't have UPF_BOOT_AUTOCONF, which would trigger a serial8250_config_port as well. This causes garbled output from userspace: [ 5.220000] random: procd urandom read with 49 bits of entropy available ers [kee Fix this by forcing it to be configured on boot, resulting in the expected output: [ 5.250000] random: procd urandom read with 50 bits of entropy available Press the [f] key and hit [enter] to enter failsafe mode Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level Fixes: aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers") Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Nicolas Schichan <nschichan@freebox.fr> Cc: linux-mips@linux-mips.org Cc: linux-serial@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17544/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2018-01-10powerpc/powernv: Check device-tree for RFI flush settingsOliver O'Halloran
New device-tree properties are available which tell the hypervisor settings related to the RFI flush. Use them to determine the appropriate flush instruction to use, and whether the flush is required. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-01-10powerpc/pseries: Query hypervisor for RFI flush settingsMichael Neuling
A new hypervisor call is available which tells the guest settings related to the RFI flush. Use it to query the appropriate flush instruction(s), and whether the flush is required. Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-01-10powerpc/64s: Support disabling RFI flush with no_rfi_flush and noptiMichael Ellerman
Because there may be some performance overhead of the RFI flush, add kernel command line options to disable it. We add a sensibly named 'no_rfi_flush' option, but we also hijack the x86 option 'nopti'. The RFI flush is not the same as KPTI, but if we see 'nopti' we can guess that the user is trying to avoid any overhead of Meltdown mitigations, and it means we don't have to educate every one about a different command line option. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-01-10powerpc/64s: Add support for RFI flush of L1-D cacheMichael Ellerman
On some CPUs we can prevent the Meltdown vulnerability by flushing the L1-D cache on exit from kernel to user mode, and from hypervisor to guest. This is known to be the case on at least Power7, Power8 and Power9. At this time we do not know the status of the vulnerability on other CPUs such as the 970 (Apple G5), pasemi CPUs (AmigaOne X1000) or Freescale CPUs. As more information comes to light we can enable this, or other mechanisms on those CPUs. The vulnerability occurs when the load of an architecturally inaccessible memory region (eg. userspace load of kernel memory) is speculatively executed to the point where its result can influence the address of a subsequent speculatively executed load. In order for that to happen, the first load must hit in the L1, because before the load is sent to the L2 the permission check is performed. Therefore if no kernel addresses hit in the L1 the vulnerability can not occur. We can ensure that is the case by flushing the L1 whenever we return to userspace. Similarly for hypervisor vs guest. In order to flush the L1-D cache on exit, we add a section of nops at each (h)rfi location that returns to a lower privileged context, and patch that with some sequence. Newer firmwares are able to advertise to us that there is a special nop instruction that flushes the L1-D. If we do not see that advertised, we fall back to doing a displacement flush in software. For guest kernels we support migration between some CPU versions, and different CPUs may use different flush instructions. So that we are prepared to migrate to a machine with a different flush instruction activated, we may have to patch more than one flush instruction at boot if the hypervisor tells us to. In the end this patch is mostly the work of Nicholas Piggin and Michael Ellerman. However a cast of thousands contributed to analysis of the issue, earlier versions of the patch, back ports testing etc. Many thanks to all of them. Tested-by: Jon Masters <jcm@redhat.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-01-10KVM: PPC: Book3S HV: Always flush TLB in kvmppc_alloc_reset_hpt()David Gibson
The KVM_PPC_ALLOCATE_HTAB ioctl(), implemented by kvmppc_alloc_reset_hpt() is supposed to completely clear and reset a guest's Hashed Page Table (HPT) allocating or re-allocating it if necessary. In the case where an HPT of the right size already exists and it just zeroes it, it forces a TLB flush on all guest CPUs, to remove any stale TLB entries loaded from the old HPT. However, that situation can arise when the HPT is resizing as well - or even when switching from an RPT to HPT - so those cases need a TLB flush as well. So, move the TLB flush to trigger in all cases except for errors. Cc: stable@vger.kernel.org # v4.10+ Fixes: f98a8bf9ee20 ("KVM: PPC: Book3S HV: Allow KVM_PPC_ALLOCATE_HTAB ioctl() to change HPT size") Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2018-01-10KVM: PPC: Book3S PR: Fix WIMG handling under pHypAlexey Kardashevskiy
Commit 96df226 ("KVM: PPC: Book3S PR: Preserve storage control bits") added code to preserve WIMG bits but it missed 2 special cases: - a magic page in kvmppc_mmu_book3s_64_xlate() and - guest real mode in kvmppc_handle_pagefault(). For these ptes, WIMG was 0 and pHyp failed on these causing a guest to stop in the very beginning at NIP=0x100 (due to bd9166ffe "KVM: PPC: Book3S PR: Exit KVM on failed mapping"). According to LoPAPR v1.1 14.5.4.1.2 H_ENTER: The hypervisor checks that the WIMG bits within the PTE are appropriate for the physical page number else H_Parameter return. (For System Memory pages WIMG=0010, or, 1110 if the SAO option is enabled, and for IO pages WIMG=01**.) This hence initializes WIMG to non-zero value HPTE_R_M (0x10), as expected by pHyp. [paulus@ozlabs.org - fix compile for 32-bit] Cc: stable@vger.kernel.org # v4.11+ Fixes: 96df226 "KVM: PPC: Book3S PR: Preserve storage control bits" Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Tested-by: Ruediger Oertel <ro@suse.de> Reviewed-by: Greg Kurz <groug@kaod.org> Tested-by: Greg Kurz <groug@kaod.org> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2018-01-10ARM: dts: imx6ul: add 696MHz operating pointAnson Huang
Add 696MHz operating point according to datasheet (Rev. 0, 12/2015). Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com> Acked-by: Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-01-09Merge tag 'riscv-for-linus-4.15-rc8_cleanups' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux Pull RISC-V updates from Palmer Dabbelt: "This contains what I hope are the last RISC-V changes to go into 4.15. I know it's a bit last minute, but I think they're all fairly small changes: - SR_* constants have been renamed to match the latest ISA specification. - Some CONFIG_MMU #ifdef cruft has been removed. We've never supported !CONFIG_MMU. - __NR_riscv_flush_icache is now visible to userspace. We were hoping to avoid making this public in order to force userspace to call the vDSO entry, but it looks like QEMU's user-mode emulation doesn't want to emulate a vDSO. In order to allow glibc to fall back to a system call when the vDSO entry doesn't exist we're just - Our defconfig is no long empty. This is another one that just slipped through the cracks. The defconfig isn't perfect, but it's at least close to what users will want for the first RISC-V development board. Getting closer is kind of splitting hairs here: none of the RISC-V specific drivers are in yet, so it's not like things will boot out of the box. The only one that's strictly necessary is the __NR_riscv_flush_icache change, as I want that to be part of the public API starting from our first kernel so nobody has to worry about it. The others are nice to haves, but they seem sane for 4.15 to me" * tag 'riscv-for-linus-4.15-rc8_cleanups' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux: riscv: rename SR_* constants to match the spec riscv: remove CONFIG_MMU ifdefs RISC-V: Make __NR_riscv_flush_icache visible to userspace RISC-V: Add a basic defconfig
generated by cgit (git 2.34.1) at 2025-09-25 05:50:09 +0000