summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-01-20dt-bindings: sdhci-omap: Add am335x and am437x specific bindingsFaiz Abbas
Add binding for the TI's sdhci-omap controller present in am335x and am437x devices. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200116105154.7685-9-faiz_abbas@ti.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20mmc: sdhci-omap: Disable data timeout interrupt during eraseFaiz Abbas
Disable data timeout interrupt during an erase operation. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200116105154.7685-8-faiz_abbas@ti.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20mmc: sdhci: Refactor sdhci_set_timeout()Faiz Abbas
Refactor sdhci_set_timeout() such that platform drivers can do some functionality in a set_timeout() callback and then call __sdhci_set_timeout() to complete the operation. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200116105154.7685-7-faiz_abbas@ti.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20mmc: sdhci: Convert sdhci_set_timeout_irq() to non-staticFaiz Abbas
Export sdhci_set_timeout_irq() so that it is accessible from platform drivers. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200116105154.7685-6-faiz_abbas@ti.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20mmc: sdhci-omap: Add using external dmaChunyan Zhang
sdhci-omap can support both external dma controller via dmaengine framework as well as ADMA which standard SD host controller provides. Fixes by Faiz Abbas <fazi_abbas@ti.com>: 1. Switch to DMA slave mode when using external DMA 2. Add offset to mapbase Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200116105154.7685-5-faiz_abbas@ti.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20mmc: sdhci: add support for using external DMA devicesChunyan Zhang
Some standard SD host controllers can support both external dma controllers as well as ADMA/SDMA in which the SD host controller acts as DMA master. TI's omap controller is the case as an example. Currently the generic SDHCI code supports ADMA/SDMA integrated in the host controller but does not have any support for external DMA controllers implemented using dmaengine, meaning that custom code is needed for any systems that use an external DMA controller with SDHCI. Fixes by Faiz Abbas <faiz_abbas@ti.com>: 1. Map scatterlists before dmaengine_prep_slave_sg() 2. Use dma_async() functions inside of the send_command() path and call terminate_sync() in non-atomic context in case of an error. Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200116105154.7685-4-faiz_abbas@ti.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20mmc: sdhci: Factor out some operations set to their own functionsFaiz Abbas
In preparation for adding external dma support, factor out data initialization, block info and mrq_done to their own functions. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Tested-by: Baolin Wang <baolin.wang7@gmail.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200116105154.7685-3-faiz_abbas@ti.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20dt-bindings: sdhci-omap: Add properties for using external dmaChunyan Zhang
sdhci-omap can support both external dma controller via dmaengine framework as well as ADMA which standard SD host controller provides. Add binding documentation for these external dma properties. Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200116105154.7685-2-faiz_abbas@ti.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20dt-bindings: mmc: fsl-imx-esdhc: add i.MX8MP compatible stringAnson Huang
Add compatible string for imx8mp Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/1578893602-14395-2-git-send-email-Anson.Huang@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20net: dsa: mv88e6xxx: Add SERDES stats counters to all 6390 family membersAndrew Lunn
The SERDES statistics are valid for all members of the 6390 family, not just the 6390 itself. Add the needed callbacks to all members of the family. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-20net: phylink: allow in-band AN for USXGMIIAlex Marginean
USXGMII supports passing link information in-band between PHY and MAC PCS, add it to the list of protocols that support in-band AN mode. Being a MAC-PHY protocol that can auto-negotiate link speeds up to 10 Gbps, we populate the initial supported mask with the entire spectrum of link modes up to 10G that PHYLINK supports, and we let the driver reduce that mask in its .phylink_validate method. Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-20gpio/sifive: Add DT documentation for SiFive GPIOYash Shah
DT json-schema for GPIO controller added. Signed-off-by: Wesley W. Terpstra <wesley@sifive.com> [Atish: Compatible string update] Signed-off-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Yash Shah <yash.shah@sifive.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/1575976274-13487-5-git-send-email-yash.shah@sifive.com
2020-01-20irqchip/sifive-plic: Support irq domain hierarchyYash Shah
Add support for hierarchical irq domains. This is needed as pre-requisite for gpio-sifive driver. Signed-off-by: Yash Shah <yash.shah@sifive.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/1575976274-13487-4-git-send-email-yash.shah@sifive.com
2020-01-20irqchip/nvic: Use irq_domain_translate_onecell instead of custom funcYash Shah
Make use of newly introduced irq_domain_translate_onecell() instead of custom made function. Signed-off-by: Yash Shah <yash.shah@sifive.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/1575976274-13487-3-git-send-email-yash.shah@sifive.com
2020-01-20genirq: Introduce irq_domain_translate_onecellYash Shah
Add a new function irq_domain_translate_onecell() that is to be used as the translate function in struct irq_domain_ops. Signed-off-by: Yash Shah <yash.shah@sifive.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/1575976274-13487-2-git-send-email-yash.shah@sifive.com
2020-01-20net: phy: don't crash in phy_read/_write_mmd without a PHY driverAlex Marginean
The APIs can be used by Ethernet drivers without actually loading a PHY driver. This may become more widespread in the future with 802.3z compatible MAC PCS devices being locally driven by the MAC driver when configuring for a PHY mode with in-band negotiation. Check that drv is not NULL before reading from it. Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-20net: phylink: Allow 2.5BASE-T, 5GBASE-T and 10GBASE-T for the 10G link modesVladimir Oltean
For some reason, PHYLINK does not put the copper modes for 802.3bz (NBASE-T) and 802.3an-2006 (10GBASE-T) in the PHY's supported mask, when the PHY-MAC connection is a 10G-capable one (10GBase-KR, 10GBase-R, USXGMII). One possible way through which the cable side can work at the lower speed is by having the PHY emit PAUSE frames towards the MAC. So fix that omission. Also include the 2500Base-X fiber mode in this list while we're at it. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-20net: ip6_gre: fix moving ip6gre between namespacesNiko Kortstrom
Support for moving IPv4 GRE tunnels between namespaces was added in commit b57708add314 ("gre: add x-netns support"). The respective change for IPv6 tunnels, commit 22f08069e8b4 ("ip6gre: add x-netns support") did not drop NETIF_F_NETNS_LOCAL flag so moving them from one netns to another is still denied in IPv6 case. Drop NETIF_F_NETNS_LOCAL flag from ip6gre tunnels to allow moving ip6gre tunnel endpoints between network namespaces. Signed-off-by: Niko Kortstrom <niko.kortstrom@nokia.com> Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Acked-by: William Tu <u9012063@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-20net: stmmac: modified pcs mode support for RGMIIDejin Zheng
snps databook noted that physical coding sublayer (PCS) interface that can be used when the MAC is configured for the TBI, RTBI, or SGMII PHY interface. we have RGMII and SGMII in a SoC and it also has the PCS block. it needs stmmac_init_phy and stmmac_mdio_register function for initializing phy when it used RGMII interface. Signed-off-by: Dejin Zheng <zhengdejin5@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-20cpufreq: brcmstb-avs: fix imbalance of cpufreq policy refcountchenqiwu
brcm_avs_cpufreq_get() calls cpufreq_cpu_get() to get the cpufreq policy, meanwhile, it also increments the kobject reference count to mark it busy. However, a corresponding call of cpufreq_cpu_put() is ignored to decrement the kobject reference count back, which may lead to a potential stuck risk that the cpuhp thread deadly waits for dropping of kobject refcount when cpufreq policy free. With this patch, the cpuhp thread can be easily exercised by attempting to force an unbind of the CPUfreq driver. Signed-off-by: chenqiwu <chenqiwu@xiaomi.com> [ Viresh: Dropped !policy check ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-01-20Merge tag 'perf-core-for-mingo-5.6-20200116' of ↵Ingo Molnar
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo: perf report: Andi Kleen: - Clarify in help that --children is default. Jin Yao: - Fix no libunwind compiled warning breaking s390. perf annotate/report/top: Andi Kleen: - Support --prefix/--prefix-strip, use it with objdump when doing disassembly. perf c2c: Andres Freund: - Fix return type for histogram sorting comparision functions. perf header: Michael Petlan: - Use last modification time for timestamp, i.e. st.st_mtime instead of the st_ctime. perf beauty: Cengiz Can: - Fix sockaddr printf format for long integers. libperf: Jiri Olsa: - Setup initial evlist::all_cpus value perf parser: Jiri Olsa: - Use %define api.pure full instead of %pure-parser, nuking warning from bison about using deprecated stuff. perf ui gtk: - Add missing zalloc object, fixing gtk browser build. perf clang: Maciej S. Szmigiero: - Fix build issues with Clang 9 and 8+. Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2020-01-20Merge tag 'v5.5-rc7' into perf/core, to pick up fixesIngo Molnar
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2020-01-20x86/boot/compressed: Relax sed symbol type regex for LLVM ld.lldArd Biesheuvel
The final build stage of the x86 kernel captures some symbol addresses from the decompressor binary and copies them into zoffset.h. It uses sed with a regular expression that matches the address, symbol type and symbol name, and mangles the captured addresses and the names of symbols of interest into #define directives that are added to zoffset.h The symbol type is indicated by a single letter, which we match strictly: only letters in the set 'ABCDGRSTVW' are matched, even though the actual symbol type is relevant and therefore ignored. Commit bc7c9d620 ("efi/libstub/x86: Force 'hidden' visibility for extern declarations") made a change to the way external symbol references are classified, resulting in 'startup_32' now being emitted as a hidden symbol. This prevents the use of GOT entries to refer to this symbol via its absolute address, which recent toolchains (including Clang based ones) already avoid by default, making this change a no-op in the majority of cases. However, as it turns out, the LLVM linker classifies such hidden symbols as symbols with static linkage in fully linked ELF binaries, causing tools such as NM to output a lowercase 't' rather than an upper case 'T' for the type of such symbols. Since our sed expression only matches upper case letters for the symbol type, the line describing startup_32 is disregarded, resulting in a build error like the following arch/x86/boot/header.S:568:18: error: symbol 'ZO_startup_32' can not be undefined in a subtraction expression init_size: .long (0x00000000008fd000 - ZO_startup_32 + (((0x0000000001f6361c + ((0x0000000001f6361c >> 8) + 65536) - 0x00000000008c32e5) + 4095) & ~4095)) # kernel initialization size Given that we are only interested in the value of the symbol, let's match any character in the set 'a-zA-Z' instead. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Tested-by: Nathan Chancellor <natechancellor@gmail.com>
2020-01-20efi/x86: avoid KASAN false positives when accessing the 1: 1 mappingArd Biesheuvel
When installing the EFI virtual address map during early boot, we access the EFI system table to retrieve the 1:1 mapped address of the SetVirtualAddressMap() EFI runtime service. This memory is not known to KASAN, so on KASAN enabled builds, this may result in a splat like ================================================================== BUG: KASAN: user-memory-access in efi_set_virtual_address_map+0x141/0x354 Read of size 4 at addr 000000003fbeef38 by task swapper/0/0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.5.0-rc5+ #758 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack+0x8b/0xbb ? efi_set_virtual_address_map+0x141/0x354 ? efi_set_virtual_address_map+0x141/0x354 __kasan_report+0x176/0x192 ? efi_set_virtual_address_map+0x141/0x354 kasan_report+0xe/0x20 efi_set_virtual_address_map+0x141/0x354 ? efi_thunk_runtime_setup+0x148/0x148 ? __inc_numa_state+0x19/0x90 ? memcpy+0x34/0x50 efi_enter_virtual_mode+0x5fd/0x67d start_kernel+0x5cd/0x682 ? mem_encrypt_init+0x6/0x6 ? x86_family+0x5/0x20 ? load_ucode_bsp+0x46/0x154 secondary_startup_64+0xa4/0xb0 ================================================================== Since this code runs only a single time during early boot, let's annotate it as __no_sanitize_address so KASAN disregards it entirely. Fixes: 698294704573 ("efi/x86: Split SetVirtualAddresMap() wrappers into ...") Reported-by: Qian Cai <cai@lca.pw> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2020-01-20efi: Fix handling of multiple efi_fake_mem= entriesDan Williams
Dave noticed that when specifying multiple efi_fake_mem= entries only the last entry was successfully being reflected in the efi memory map. This is due to the fact that the efi_memmap_insert() is being called multiple times, but on successive invocations the insertion should be applied to the last new memmap rather than the original map at efi_fake_memmap() entry. Rework efi_fake_memmap() to install the new memory map after each efi_fake_mem= entry is parsed. This also fixes an issue in efi_fake_memmap() that caused it to litter emtpy entries into the end of the efi memory map. An empty entry causes efi_memmap_insert() to attempt more memmap splits / copies than efi_memmap_split_count() accounted for when sizing the new map. When that happens efi_memmap_insert() may overrun its allocation, and if you are lucky will spill over to an unmapped page leading to crash signature like the following rather than silent corruption: BUG: unable to handle page fault for address: ffffffffff281000 [..] RIP: 0010:efi_memmap_insert+0x11d/0x191 [..] Call Trace: ? bgrt_init+0xbe/0xbe ? efi_arch_mem_reserve+0x1cb/0x228 ? acpi_parse_bgrt+0xa/0xd ? acpi_table_parse+0x86/0xb8 ? acpi_boot_init+0x494/0x4e3 ? acpi_parse_x2apic+0x87/0x87 ? setup_acpi_sci+0xa2/0xa2 ? setup_arch+0x8db/0x9e1 ? start_kernel+0x6a/0x547 ? secondary_startup_64+0xb6/0xc0 Commit af1648984828 "x86/efi: Update e820 with reserved EFI boot services data to fix kexec breakage" introduced more occurrences where efi_memmap_insert() is invoked after an efi_fake_mem= configuration has been parsed. Previously the side effects of vestigial empty entries were benign, but with commit af1648984828 that follow-on efi_memmap_insert() invocation triggers efi_memmap_insert() overruns. Reported-by: Dave Young <dyoung@redhat.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20191231014630.GA24942@dhcp-128-65.nay.redhat.com Link: https://lore.kernel.org/r/20200113172245.27925-14-ardb@kernel.org
2020-01-20efi: Fix efi_memmap_alloc() leaksDan Williams
With efi_fake_memmap() and efi_arch_mem_reserve() the efi table may be updated and replaced multiple times. When that happens a previous dynamically allocated efi memory map can be garbage collected. Use the new EFI_MEMMAP_{SLAB,MEMBLOCK} flags to detect when a dynamically allocated memory map is being replaced. Debug statements in efi_memmap_free() reveal: efi: __efi_memmap_free:37: phys: 0x23ffdd580 size: 2688 flags: 0x2 efi: __efi_memmap_free:37: phys: 0x9db00 size: 2640 flags: 0x2 efi: __efi_memmap_free:37: phys: 0x9e580 size: 2640 flags: 0x2 ...a savings of 7968 bytes on a qemu boot with 2 entries specified to efi_fake_mem=. [ ardb: added a comment to clarify that efi_memmap_free() does nothing when called from efi_clean_memmap(), i.e., with data->flags == 0x0 ] Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200113172245.27925-13-ardb@kernel.org
2020-01-20efi: Add tracking for dynamically allocated memmapsDan Williams
In preparation for fixing efi_memmap_alloc() leaks, add support for recording whether the memmap was dynamically allocated from slab, memblock, or is the original physical memmap provided by the platform. Given this tracking is established in efi_memmap_alloc() and needs to be carried to efi_memmap_install(), use 'struct efi_memory_map_data' to convey the flags. Some small cleanups result from this reorganization, specifically the removal of local variables for 'phys' and 'size' that are already tracked in @data. Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200113172245.27925-12-ardb@kernel.org
2020-01-20efi: Add a flags parameter to efi_memory_mapDan Williams
In preparation for garbage collecting dynamically allocated EFI memory maps, where the allocation method of memblock vs slab needs to be recalled, convert the existing 'late' flag into a 'flags' bitmask. Arrange for the flag to be passed via 'struct efi_memory_map_data'. This structure grows additional flags in follow-on changes. Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200113172245.27925-11-ardb@kernel.org
2020-01-20efi: Fix comment for efi_mem_type() wrt absent physical addressesAnshuman Khandual
A previous commit f99afd08a45f ("efi: Update efi_mem_type() to return an error rather than 0") changed the return value from EFI_RESERVED_TYPE to -EINVAL when the searched physical address is not present in any memory descriptor. But the comment preceding the function never changed. Let's change the comment now to reflect the new return value -EINVAL. Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200113172245.27925-10-ardb@kernel.org
2020-01-20efi/arm: Defer probe of PCIe backed efifb on DT systemsArd Biesheuvel
The new of_devlink support breaks PCIe probing on ARM platforms booting via UEFI if the firmware exposes a EFI framebuffer that is backed by a PCI device. The reason is that the probing order gets reversed, resulting in a resource conflict on the framebuffer memory window when the PCIe probes last, causing it to give up entirely. Given that we rely on PCI quirks to deal with EFI framebuffers that get moved around in memory, we cannot simply drop the memory reservation, so instead, let's use the device link infrastructure to register this dependency, and force the probing to occur in the expected order. Co-developed-by: Saravana Kannan <saravanak@google.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200113172245.27925-9-ardb@kernel.org
2020-01-20efi/x86: Limit EFI old memory map to SGI UV machinesArd Biesheuvel
We carry a quirk in the x86 EFI code to switch back to an older method of mapping the EFI runtime services memory regions, because it was deemed risky at the time to implement a new method without providing a fallback to the old method in case problems arose. Such problems did arise, but they appear to be limited to SGI UV1 machines, and so these are the only ones for which the fallback gets enabled automatically (via a DMI quirk). The fallback can be enabled manually as well, by passing efi=old_map, but there is very little evidence that suggests that this is something that is being relied upon in the field. Given that UV1 support is not enabled by default by the distros (Ubuntu, Fedora), there is no point in carrying this fallback code all the time if there are no other users. So let's move it into the UV support code, and document that efi=old_map now requires this support code to be enabled. Note that efi=old_map has been used in the past on other SGI UV machines to work around kernel regressions in production, so we keep the option to enable it by hand, but only if the kernel was built with UV support. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200113172245.27925-8-ardb@kernel.org
2020-01-20efi/x86: Avoid RWX mappings for all of DRAMArd Biesheuvel
The EFI code creates RWX mappings for all memory regions that are occupied after the stub completes, and in the mixed mode case, it even creates RWX mappings for all of the remaining DRAM as well. Let's try to avoid this, by setting the NX bit for all memory regions except the ones that are marked as EFI runtime services code [which means text+rodata+data in practice, so we cannot mark them read-only right away]. For cases of buggy firmware where boot services code is called during SetVirtualAddressMap(), map those regions with exec permissions as well - they will be unmapped in efi_free_boot_services(). Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200113172245.27925-7-ardb@kernel.org
2020-01-20efi/x86: Don't map the entire kernel text RW for mixed modeArd Biesheuvel
The mixed mode thunking routine requires a part of it to be mapped 1:1, and for this reason, we currently map the entire kernel .text read/write in the EFI page tables, which is bad. In fact, the kernel_map_pages_in_pgd() invocation that installs this mapping is entirely redundant, since all of DRAM is already 1:1 mapped read/write in the EFI page tables when we reach this point, which means that .rodata is mapped read-write as well. So let's remap both .text and .rodata read-only in the EFI page tables. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200113172245.27925-6-ardb@kernel.org
2020-01-20x86/mm: Fix NX bit clearing issue in kernel_map_pages_in_pgdArd Biesheuvel
The following commit: 15f003d20782 ("x86/mm/pat: Don't implicitly allow _PAGE_RW in kernel_map_pages_in_pgd()") modified kernel_map_pages_in_pgd() to manage writable permissions of memory mappings in the EFI page table in a different way, but in the process, it removed the ability to clear NX attributes from read-only mappings, by clobbering the clear mask if _PAGE_RW is not being requested. Failure to remove the NX attribute from read-only mappings is unlikely to be a security issue, but it does prevent us from tightening the permissions in the EFI page tables going forward, so let's fix it now. Fixes: 15f003d20782 ("x86/mm/pat: Don't implicitly allow _PAGE_RW in kernel_map_pages_in_pgd() Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200113172245.27925-5-ardb@kernel.org
2020-01-20efi/libstub/x86: Fix unused-variable warningArnd Bergmann
The only users of these got removed, so they also need to be removed to avoid warnings: arch/x86/boot/compressed/eboot.c: In function 'setup_efi_pci': arch/x86/boot/compressed/eboot.c:117:16: error: unused variable 'nr_pci' [-Werror=unused-variable] unsigned long nr_pci; ^~~~~~ arch/x86/boot/compressed/eboot.c: In function 'setup_uga': arch/x86/boot/compressed/eboot.c:244:16: error: unused variable 'nr_ugas' [-Werror=unused-variable] unsigned long nr_ugas; ^~~~~~~ Fixes: 2732ea0d5c0a ("efi/libstub: Use a helper to iterate over a EFI handle array") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200113172245.27925-4-ardb@kernel.org
2020-01-20efi/libstub/x86: Use mandatory 16-byte stack alignment in mixed modeArd Biesheuvel
Reduce the stack frame of the EFI stub's mixed mode thunk routine by 8 bytes, by moving the GDT and return addresses to EBP and EBX, which we need to preserve anyway, since their top halves will be cleared by the call into 32-bit firmware code. Doing so results in the UEFI code being entered with a 16 byte aligned stack, as mandated by the UEFI spec, fixing the last occurrence in the 64-bit kernel where we violate this requirement. Also, move the saved GDT from a global variable to an unused part of the stack frame, and touch up some other parts of the code. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200113172245.27925-3-ardb@kernel.org
2020-01-20efi/libstub/x86: Use const attribute for efi_is_64bit()Ard Biesheuvel
Reshuffle the x86 stub code a bit so that we can tag the efi_is_64bit() function with the 'const' attribute, which permits the compiler to optimize away any redundant calls. Since we have two different entry points for 32 and 64 bit firmware in the startup code, this also simplifies the C code since we'll enter it with the efi_is64 variable already set. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200113172245.27925-2-ardb@kernel.org
2020-01-20Merge tag 'v5.5-rc7' into efi/core, to pick up fixesIngo Molnar
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2020-01-20sched/fair: Define sched_idle_cpu() only for SMP configurationsViresh Kumar
sched_idle_cpu() isn't used for non SMP configuration and with a recent change, we have started getting following warning: kernel/sched/fair.c:5221:12: warning: ‘sched_idle_cpu’ defined but not used [-Wunused-function] Fix that by defining sched_idle_cpu() only for SMP configurations. Fixes: 323af6deaf70 ("sched/fair: Load balance aggressively for SCHED_IDLE CPUs") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Juri Lelli <juri.lelli@redhat.com> Cc: Vincent Guittot <vincent.guittot@linaro.org> Cc: Dietmar Eggemann <dietmar.eggemann@arm.com> Link: https://lore.kernel.org/r/f0554f590687478b33914a4aff9f0e6a62886d44.1579499907.git.viresh.kumar@linaro.org
2020-01-20Merge tag 'drm-msm-next-2020-01-14' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/msm into drm-next + sc7180 display + DSI support + a618 (sc7180) support + more UBWC (bandwidth compression) support + various cleanups to handle devices that use vs don't use zap fw, etc + usual random cleanups and fixes Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/ <CAF6AEGvv03ifuP0tp7-dmqZtr1iS=s8Vc=az8BNGtEoSMD-dkw@mail.gmail.com
2020-01-19Merge branch 'work.openat2' of ↵Jens Axboe
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs into for-5.6/io_uring-vfs Pull in Al's openat2 branch, since we'll need that for the openat2 support. * 'work.openat2' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: Documentation: path-lookup: include new LOOKUP flags selftests: add openat2(2) selftests open: introduce openat2(2) syscall namei: LOOKUP_{IN_ROOT,BENEATH}: permit limited ".." resolution namei: LOOKUP_IN_ROOT: chroot-like scoped resolution namei: LOOKUP_BENEATH: O_BENEATH-like scoped resolution namei: LOOKUP_NO_XDEV: block mountpoint crossing namei: LOOKUP_NO_MAGICLINKS: block magic-link resolution namei: LOOKUP_NO_SYMLINKS: block symlink resolution namei: allow set_root() to produce errors namei: allow nd_jump_link() to produce errors nsfs: clean-up ns_get_path() signature to return int namei: only return -ECHILD from follow_dotdot_rcu()
2020-01-20Backmerge v5.5-rc7 into drm-nextDave Airlie
msm needs 5.5-rc4, go to the latest. Signed-off-by: Dave Airlie <airlied@redhat.com>
2020-01-19Linux 5.5-rc7Linus Torvalds
2020-01-19um: Fix time-travel=inf-cpu with xor/raid6Johannes Berg
Today, I erroneously built a time-travel configuration with btrfs enabled, and noticed it cannot boot in time-travel=inf-cpu mode, both xor and raid6 speed measurement gets stuck. For xor, work around it by picking the first algorithm if inf-cpu mode is enabled. For raid6, I didn't find such a workaround, so disallow enabling time-travel mode if RAID6_PQ_BENCHMARK is enabled. With this, and RAID6_PQ_BENCHMARK disabled, I can boot a kernel that has btrfs enabled in time-travel=inf-cpu mode. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Acked-by: Anton Ivanov <anton.ivanov@cambridgegreys.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2020-01-19Revert "um: Enable CONFIG_CONSTRUCTORS"Johannes Berg
This reverts commit 786b2384bf1c ("um: Enable CONFIG_CONSTRUCTORS"). There are two issues with this commit, uncovered by Anton in tests on some (Debian) systems: 1) I completely forgot to call any constructors if CONFIG_CONSTRUCTORS isn't set. Don't recall now if it just wasn't needed on my system, or if I never tested this case. 2) With that fixed, it works - with CONFIG_CONSTRUCTORS *unset*. If I set CONFIG_CONSTRUCTORS, it fails again, which isn't totally unexpected since whatever wanted to run is likely to have to run before the kernel init etc. that calls the constructors in this case. Basically, some constructors that gcc emits (libc has?) need to run very early during init; the failure mode otherwise was that the ptrace fork test already failed: ---------------------- $ ./linux mem=512M Core dump limits : soft - 0 hard - NONE Checking that ptrace can change system call numbers...check_ptrace : child exited with exitcode 6, while expecting 0; status 0x67f Aborted ---------------------- Thinking more about this, it's clear that we simply cannot support CONFIG_CONSTRUCTORS in UML. All the cases we need now (gcov, kasan) involve not use of the __attribute__((constructor)), but instead some constructor code/entry generated by gcc. Therefore, we cannot distinguish between kernel constructors and system constructors. Thus, revert this commit. Cc: stable@vger.kernel.org [5.4+] Fixes: 786b2384bf1c ("um: Enable CONFIG_CONSTRUCTORS") Reported-by: Anton Ivanov <anton.ivanov@cambridgegreys.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Acked-by: Anton Ivanov <anton.ivanov@cambridgegreys.co.uk> Signed-off-by: Richard Weinberger <richard@nod.at>
2020-01-19um: Mark non-vector net transports as obsoleteBrendan Higgins
UML_NET_VECTOR now supports filters compiled with pcap outside of UML; it also supports: EoGRE, EoL2TPv3, RAW (+/- BPF), TAP and BESS. While vector drivers are not 1:1 replacements for the existing drivers, you can achieve the same topologies and the same connectivity at much higher performance (2.5 to 9 Gbit on mid-range Ryzen desktop) - the old drivers test out in the 500Mbit range on the same hardware. For all these reasons, the non-vector based transports are now unnecessary, and some, most notably pcap and vde are maintenance burdens. Thus, it makes sense to at least start thinking about removing the non-vector transports, so for now, mark them as obsolete. Link: https://lore.kernel.org/lkml/15f048d3-07ab-61c1-c6e0-0712e626dd33@cambridgegreys.com/T/#u Suggested-by: Anton Ivanov <anton.ivanov@cambridgegreys.com> Signed-off-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2020-01-19um: Add an option to make serial driver non-rawJohannes Berg
In some cases, for example when the program(s) running inside UML isn't/aren't interactive (like the hwsim tests for wpa_supplicant) there's really no value in having the serial lines configured to be raw as they are now by default. Setting them to non-raw lets one abort the whole UML with Ctrl-C, which is really the right thing to do in these cases, basically the whole UML instance is more like a single (testing) program. Add a "ssl-non-raw" option to UML to support such a mode. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2020-01-19Merge ra.kernel.org:/pub/scm/linux/kernel/git/netdev/netDavid S. Miller
2020-01-19Merge tag 'riscv/for-v5.5-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Paul Walmsley: "Three fixes for RISC-V: - Don't free and reuse memory containing the code that CPUs parked at boot reside in. - Fix rv64 build problems for ubsan and some modules by adding logical and arithmetic shift helpers for 128-bit values. These are from libgcc and are similar to what's present for ARM64. - Fix vDSO builds to clean up their own temporary files" * tag 'riscv/for-v5.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: Less inefficient gcc tishift helpers (and export their symbols) riscv: delete temporary files riscv: make sure the cores stay looping in .Lsecondary_park
2020-01-19Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netLinus Torvalds
Pull networking fixes from David Miller: 1) Fix non-blocking connect() in x25, from Martin Schiller. 2) Fix spurious decryption errors in kTLS, from Jakub Kicinski. 3) Netfilter use-after-free in mtype_destroy(), from Cong Wang. 4) Limit size of TSO packets properly in lan78xx driver, from Eric Dumazet. 5) r8152 probe needs an endpoint sanity check, from Johan Hovold. 6) Prevent looping in tcp_bpf_unhash() during sockmap/tls free, from John Fastabend. 7) hns3 needs short frames padded on transmit, from Yunsheng Lin. 8) Fix netfilter ICMP header corruption, from Eyal Birger. 9) Fix soft lockup when low on memory in hns3, from Yonglong Liu. 10) Fix NTUPLE firmware command failures in bnxt_en, from Michael Chan. 11) Fix memory leak in act_ctinfo, from Eric Dumazet. * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (91 commits) cxgb4: reject overlapped queues in TC-MQPRIO offload cxgb4: fix Tx multi channel port rate limit net: sched: act_ctinfo: fix memory leak bnxt_en: Do not treat DSN (Digital Serial Number) read failure as fatal. bnxt_en: Fix ipv6 RFS filter matching logic. bnxt_en: Fix NTUPLE firmware command failures. net: systemport: Fixed queue mapping in internal ring map net: dsa: bcm_sf2: Configure IMP port for 2Gb/sec net: dsa: sja1105: Don't error out on disabled ports with no phy-mode net: phy: dp83867: Set FORCE_LINK_GOOD to default after reset net: hns: fix soft lockup when there is not enough memory net: avoid updating qdisc_xmit_lock_key in netdev_update_lockdep_key() net/sched: act_ife: initalize ife->metalist earlier netfilter: nat: fix ICMP header corruption on ICMP errors net: wan: lapbether.c: Use built-in RCU list checking netfilter: nf_tables: fix flowtable list del corruption netfilter: nf_tables: fix memory leak in nf_tables_parse_netdev_hooks() netfilter: nf_tables: remove WARN and add NLA_STRING upper limits netfilter: nft_tunnel: ERSPAN_VERSION must not be null netfilter: nft_tunnel: fix null-attribute check ...
generated by cgit (git 2.34.1) at 2025-09-16 05:19:46 +0000