- Nov 13, 2016
-
-
Lukas Wunner authored
Apple's EFI drivers supply device properties which are needed to support Macs optimally. They contain vital information which cannot be obtained any other way (e.g. Thunderbolt Device ROM). They're also used to convey the current device state so that OS drivers can pick up where EFI drivers left (e.g. GPU mode setting). There's an EFI driver dubbed "AAPL,PathProperties" which implements a per-device key/value store. Other EFI drivers populate it using a custom protocol. The macOS bootloader /System/Library/CoreServices/boot.efi retrieves the properties with the same protocol. The kernel extension AppleACPIPlatform.kext subsequently merges them into the I/O Kit registry (see ioreg(8)) where they can be queried by other kernel extensions and user space. This commit extends the efistub to retrieve the device properties before ExitBootServices is called. It assigns them to devices in an fs_initcall so that they can be queried with the API in <linux/property.h>. Note that the device properties will only be available if the kernel is booted with the efistub. Distros should adjust their installers to always use the efistub on Macs. grub with the "linux" directive will not work unless the functionality of this commit is duplicated in grub. (The "linuxefi" directive should work but is not included upstream as of this writing.) The custom protocol has GUID 91BD12FE-F6C3-44FB-A5B7-5122AB303AE0 and looks like this: typedef struct { unsigned long version; /* 0x10000 */ efi_status_t (*get) ( IN struct apple_properties_protocol *this, IN struct efi_dev_path *device, IN efi_char16_t *property_name, OUT void *buffer, IN OUT u32 *buffer_len); /* EFI_SUCCESS, EFI_NOT_FOUND, EFI_BUFFER_TOO_SMALL */ efi_status_t (*set) ( IN struct apple_properties_protocol *this, IN struct efi_dev_path *device, IN efi_char16_t *property_name, IN void *property_value, IN u32 property_value_len); /* allocates copies of property name and value */ /* EFI_SUCCESS, EFI_OUT_OF_RESOURCES */ efi_status_t (*del) ( IN struct apple_properties_protocol *this, IN struct efi_dev_path *device, IN efi_char16_t *property_name); /* EFI_SUCCESS, EFI_NOT_FOUND */ efi_status_t (*get_all) ( IN struct apple_properties_protocol *this, OUT void *buffer, IN OUT u32 *buffer_len); /* EFI_SUCCESS, EFI_BUFFER_TOO_SMALL */ } apple_properties_protocol; Thanks to Pedro Vilaça for this blog post which was helpful in reverse engineering Apple's EFI drivers and bootloader: https://reverse.put.as/2016/06/25/apple-efi-firmware-passwords-and-the-scbo-myth/ If someone at Apple is reading this, please note there's a memory leak in your implementation of the del() function as the property struct is freed but the name and value allocations are not. Neither the macOS bootloader nor Apple's EFI drivers check the protocol version, but we do to avoid breakage if it's ever changed. It's been the same since at least OS X 10.6 (2009). The get_all() function conveniently fills a buffer with all properties in marshalled form which can be passed to the kernel as a setup_data payload. The number of device properties is dynamic and can change between a first invocation of get_all() (to determine the buffer size) and a second invocation (to retrieve the actual buffer), hence the peculiar loop which does not finish until the buffer size settles. The macOS bootloader does the same. The setup_data payload is later on unmarshalled in an fs_initcall. The idea is that most buses instantiate devices in "subsys" initcall level and drivers are usually bound to these devices in "device" initcall level, so we assign the properties in-between, i.e. in "fs" initcall level. This assumes that devices to which properties pertain are instantiated from a "subsys" initcall or earlier. That should always be the case since on macOS, AppleACPIPlatformExpert::matchEFIDevicePath() only supports ACPI and PCI nodes and we've fully scanned those buses during "subsys" initcall level. The second assumption is that properties are only needed from a "device" initcall or later. Seems reasonable to me, but should this ever not work out, an alternative approach would be to store the property sets e.g. in a btree early during boot. Then whenever device_add() is called, an EFI Device Path would have to be constructed for the newly added device, and looked up in the btree. That way, the property set could be assigned to the device immediately on instantiation. And this would also work for devices instantiated in a deferred fashion. It seems like this approach would be more complicated and require more code. That doesn't seem justified without a specific use case. For comparison, the strategy on macOS is to assign properties to objects in the ACPI namespace (AppleACPIPlatformExpert::mergeEFIProperties()). That approach is definitely wrong as it fails for devices not present in the namespace: The NHI EFI driver supplies properties for attached Thunderbolt devices, yet on Macs with Thunderbolt 1 only one device level behind the host controller is described in the namespace. Consequently macOS cannot assign properties for chained devices. With Thunderbolt 2 they started to describe three device levels behind host controllers in the namespace but this grossly inflates the SSDT and still fails if the user daisy-chained more than three devices. We copy the property names and values from the setup_data payload to swappable virtual memory and afterwards make the payload available to the page allocator. This is just for the sake of good housekeeping, it wouldn't occupy a meaningful amount of physical memory (4444 bytes on my machine). Only the payload is freed, not the setup_data header since otherwise we'd break the list linkage and we cannot safely update the predecessor's ->next link because there's no locking for the list. The payload is currently not passed on to kexec'ed kernels, same for PCI ROMs retrieved by setup_efi_pci(). This can be added later if there is demand by amending setup_efi_state(). The payload can then no longer be made available to the page allocator of course. Tested-by: Lukas Wunner <lukas@wunner.de> [MacBookPro9,1] Tested-by: Pierre Moreau <pierre.morrow@free.fr> [MacBookPro11,3] Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
Matt Fleming <matt@codeblueprint.co.uk> Cc: Andreas Noever <andreas.noever@gmail.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Pedro Vilaça <reverser@put.as> Cc: Peter Jones <pjones@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: grub-devel@gnu.org Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20161112213237.8804-9-matt@codeblueprint.co.uk Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Lukas Wunner authored
We already have a macro to invoke boot services which on x86 adapts automatically to the bitness of the EFI firmware: efi_call_early(). The macro allows sharing of functions across arches and bitness variants as long as those functions only call boot services. However in practice functions in the EFI stub contain a mix of boot services calls and protocol calls. Add an efi_call_proto() macro for bitness-agnostic protocol calls to allow sharing more code across arches as well as deduplicating 32 bit and 64 bit code paths. On x86, implement it using a new efi_table_attr() macro for bitness- agnostic table lookups. Refactor efi_call_early() to make use of the same macro. (The resulting object code remains identical.) Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
Matt Fleming <matt@codeblueprint.co.uk> Cc: Andreas Noever <andreas.noever@gmail.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Jones <pjones@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20161112213237.8804-8-matt@codeblueprint.co.uk Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Lukas Wunner authored
We're about to extended the efistub to retrieve device properties from EFI on Apple Macs. The properties use EFI Device Paths to indicate the device they belong to. This commit adds a parser which, given an EFI Device Path, locates the corresponding struct device and returns a reference to it. Initially only ACPI and PCI Device Path nodes are supported, these are the only types needed for Apple device properties (the corresponding macOS function AppleACPIPlatformExpert::matchEFIDevicePath() does not support any others). Further node types can be added with little to moderate effort. Apple device properties is currently the only use case of this parser, but Peter Jones intends to use it to match up devices with the ConInDev/ConOutDev/ErrOutDev variables and add sysfs attributes to these devices to say the hardware supports using them as console. Thus, make this parser a separate component which can be selected with config option EFI_DEV_PATH_PARSER. It can in principle be compiled as a module if acpi_get_first_physical_node() and acpi_bus_type are exported (and efi_get_device_by_path() itself is exported). The dependency on CONFIG_ACPI is needed for acpi_match_device_ids(). It can be removed if an empty inline stub is added for that function. Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
Matt Fleming <matt@codeblueprint.co.uk> Cc: Andreas Noever <andreas.noever@gmail.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Jones <pjones@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20161112213237.8804-7-matt@codeblueprint.co.uk Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Ard Biesheuvel authored
Invoke the EFI_RNG_PROTOCOL protocol in the context of the stub and install the Linux-specific RNG seed UEFI config table. This will be picked up by the EFI routines in the core kernel to seed the kernel entropy pool. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Matt Fleming <matt@codeblueprint.co.uk> Reviewed-by:
Kees Cook <keescook@chromium.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20161112213237.8804-6-matt@codeblueprint.co.uk Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Ard Biesheuvel authored
Make random.c build for ARM by moving the fallback definition of EFI_ALLOC_ALIGN to efistub.h, and replacing a division by a value we know to be a power of 2 with a right shift (this is required since ARM does not have any integer division helper routines in its decompressor) Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Matt Fleming <matt@codeblueprint.co.uk> Reviewed-by:
Kees Cook <keescook@chromium.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20161112213237.8804-5-matt@codeblueprint.co.uk Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Ard Biesheuvel authored
Specify a Linux specific UEFI configuration table that carries some random bits, and use the contents during early boot to seed the kernel's random number generator. This allows much strong random numbers to be generated early on. The entropy is fed to the kernel using add_device_randomness(), which is documented as being appropriate for being called very early. Since UEFI configuration tables may also be consumed by kexec'd kernels, register a reboot notifier that updates the seed in the table. Note that the config table could be generated by the EFI stub or by any other UEFI driver or application (e.g., GRUB), but the random seed table GUID and the associated functionality should be considered an internal kernel interface (unless it is promoted to ABI later on) Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Matt Fleming <matt@codeblueprint.co.uk> Reviewed-by:
Kees Cook <keescook@chromium.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20161112213237.8804-4-matt@codeblueprint.co.uk Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Ard Biesheuvel authored
Since I will be co-maintaining the EFI subsystem, it makes sense to mention the ARM and arm64 EFI bits in the EFI section in MAINTAINERS so that Matt, the list and I get cc'ed on proposed changes. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Matt Fleming <matt@codeblueprint.co.uk> Acked-by:
Will Deacon <will.deacon@arm.com> Acked-by:
Russell King <rmk+kernel@armlinux.org.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: M: Matthew Garrett <matthew.garrett@nebula.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20161112213237.8804-3-matt@codeblueprint.co.uk Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Roy Franz authored
Adjust the size used in calculations to match the actual size of allocation that will be performed based on EFI size/alignment constraints. efi_high_alloc() and efi_low_alloc() use the passed size in bytes directly to find space in the memory map for the allocation, rather than the actual allocation size that has been adjusted for size and alignment constraints. This results in failed allocations and retries in efi_high_alloc(). The same error is present in efi_low_alloc(), although failure will only happen if the lowest memory block is small. Also use EFI_PAGE_SIZE consistently and remove use of EFI_PAGE_SHIFT to calculate page size. Signed-off-by:
Roy Franz <roy.franz@hpe.com> Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Matt Fleming <matt@codeblueprint.co.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20161112213237.8804-2-matt@codeblueprint.co.uk Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Ingo Molnar authored
Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
- Nov 12, 2016
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pmLinus Torvalds authored
Pull ACPI fix from Rafael Wysocki: "Fix a recent regression in the 8250_dw serial driver introduced by adding a quirk for the APM X-Gene SoC to it which uncovered an issue related to the handling of built-in device properties in the core ACPI device enumeration code (Heikki Krogerus)" * tag 'acpi-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI / platform: Add support for build-in properties
-
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pmLinus Torvalds authored
Pull power management fixes from Rafael Wysocki: "These fix two bugs in error code paths in the PM core (system-wide suspend of devices), a device reference leak in the boot-time suspend test code and a cpupower utility regression from the 4.7 cycle. Specifics: - Prevent the PM core from attempting to suspend parent devices if any of their children, whose suspend callbacks were invoked asynchronously, have failed to suspend during the "late" and "noirq" phases of system-wide suspend of devices (Brian Norris). - Prevent the boot-time system suspend test code from leaking a reference to the RTC device used by it (Johan Hovold). - Fix cpupower to use the return value of one of its library functions correctly and restore the correct behavior of it when used for setting cpufreq tunables broken during the 4.7 development cycle (Laura Abbott)" * tag 'pm-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: PM / sleep: don't suspend parent when async child suspend_{noirq, late} fails PM / sleep: fix device reference leak in test_suspend cpupower: Correct return type of cpu_power_is_cpu_online() in cpufreq-set
-
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arcLinus Torvalds authored
Pull ARC fixes from Vineet Gupta: - mmap handler for dma ops as generic handler no longer works for us [Alexey] - Fixes for EZChip platform [Noam] - Fix RTC clocksource driver build issue - ARC IRQ handling fixes [Yuriy] - Revert a recent makefile change which doesn't go well with oldish tools out in the wild * tag 'arc-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc: ARCv2: MCIP: Use IDU_M_DISTRI_DEST mode if there is only 1 destination core ARC: IRQ: Do not use hwirq as virq and vice versa ARC: [plat-eznps] set default baud for early console ARC: [plat-eznps] remove IPI clear from SMP operations Revert "ARC: build: retire old toggles" ARC: timer: rtc: implement read loop in "C" vs. inline asm ARC: change return value of userspace cmpxchg assist syscall arc: Implement arch-specific dma_map_ops.mmap ARC: [SMP] avoid overriding present cpumask ARC: Enable PERF_EVENTS in nSIM driven platforms
-
Linus Torvalds authored
Merge tag 'platform-drivers-x86-v4.9-3' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86 Pull x86 platform driver fixes from Darren Hart: "Minor doc fix, a DMI match for ideapad and a fix to toshiba-wmi to avoid loading on non-toshiba systems. Documentation/ABI: - ibm_rtl: The "What:" fields are incomplete toshiba-wmi: - Fix loading the driver on non Toshiba laptops ideapad-laptop: - Add another DMI entry for Yoga 900" * tag 'platform-drivers-x86-v4.9-3' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86: Documentation/ABI: ibm_rtl: The "What:" fields are incomplete toshiba-wmi: Fix loading the driver on non Toshiba laptops ideapad-laptop: Add another DMI entry for Yoga 900
-
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull block fixes from Jens Axboe: "Two small (really, one liners both of them!) fixes that should go into this series: - Request allocation error handling fix for nbd, from Christophe, fixing a regression in this series. - An oops fix for drbd. Not a regression in this series, but stable material. From Richard" * 'for-linus' of git://git.kernel.dk/linux-block: drbd: Fix kernel_sendmsg() usage - potential NULL deref nbd: Fix error handling
-
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pciLinus Torvalds authored
Pull PCI fixes from Bjorn Helgaas: - Update MAINTAINERS for Intel VMD driver filename - Update Rockchip rk3399 host bridge driver DTS and resets - Fix ROM shadow problem that made some video device initialization fail * tag 'pci-v4.9-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: PCI: VMD: Update filename to reflect move arm64: dts: rockchip: add three new resets for rk3399 PCIe controller PCI: rockchip: Add three new resets as required properties PCI: Don't attempt to claim shadow copies of ROM
-
git://people.freedesktop.org/~airlied/linuxLinus Torvalds authored
Pull drm fixes from Dave Airlie: "AMD, radeon, i915, imx, msm and udl fixes: - amdgpu/radeon have a number of power management regressions and fixes along with some better error checking - imx has a single regression fix - udl has a single kmalloc instead of stack for usb control msg fix - msm has some fixes for modesetting bugs and regressions - i915 has a one fix for a Sandybridge regression along with some others for DP audio. They all seem pretty okay at this stage, we've got one MST fix I know going through process for i915, but I expect it'll be next week" * tag 'drm-fixes-for-v4.9-rc5' of git://people.freedesktop.org/~airlied/linux: (30 commits) drm/udl: make control msg static const. (v2) drm/amd/powerplay: implement get_clock_by_type for iceland. drm/amd/powerplay/smu7: fix checks in smu7_get_evv_voltages (v2) drm/amd/powerplay: update phm_get_voltage_evv_on_sclk for iceland drm/amd/powerplay: propagate errors in phm_get_voltage_evv_on_sclk drm/imx: disable planes before DC drm/amd/powerplay: return false instead of -EINVAL drm/amdgpu/powerplay/smu7: fix unintialized data usage drm/amdgpu: fix crash in acp_hw_fini drm/i915: Limit Valleyview and earlier to only using mappable scanout drm/i915: Round tile chunks up for constructing partial VMAs drm/i915/dp: Extend BDW DP audio workaround to GEN9 platforms drm/i915/dp: BDW cdclk fix for DP audio drm/i915/vlv: Prevent enabling hpd polling in late suspend drm/i915: Respect alternate_ddc_pin for all DDI ports drm/msm: Fix error handling crashes seen when VRAM allocation fails drm/msm/mdp5: 8x16 actually has 8 mixer stages drm/msm/mdp5: no scaling support on RGBn pipes for 8x16 drm/msm/mdp5: handle non-fullscreen base plane case drm/msm: Set CLK_IGNORE_UNUSED flag for PLL clocks ...
-
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmcLinus Torvalds authored
Pull MMC fixes from Ulf Hansson: "MMC core: - Fix mmc card initialization for hosts not supporting HW busy detection - Fix mmc_test for sending commands during non-blocking write MMC host: - mxs: Avoid using an uninitialized - sdhci: Restore enhanced strobe setting during runtime resume - sdhci: Fix a couple of reset related issues - dw_mmc: Fix a reset controller issue" * tag 'mmc-v4.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: mxs: Initialize the spinlock prior to using it mmc: mmc: Use 500ms as the default generic CMD6 timeout mmc: mmc_test: Fix "Commands during non-blocking write" tests mmc: sdhci: Fix missing enhanced strobe setting during runtime resume mmc: sdhci: Reset cmd and data circuits after tuning failure mmc: sdhci: Fix unexpected data interrupt handling mmc: sdhci: Fix CMD line reset interfering with ongoing data transfer mmc: dw_mmc: add the "reset" as name of reset controller Documentation: synopsys-dw-mshc: add binding for reset-names
-
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrlLinus Torvalds authored
Pull pin control fixes from Linus Walleij: "All is about drivers, no core business going on. - Fix a host of runtime problems with the Intel Cherryview driver: suspend/resume needs to be marshalled properly, and strange effects from BIOS interaction during suspend/resume need to be dealt with. - A single bit was being set wrong in the Aspeed driver. - Fix an iProc probe ordering fallout resulting from v4.9 refactorings for bus population. - Do not specify a default trigger in the ST Micro cascaded GPIO IRQ controller: the kernel will moan. - Make IRQs optional altogether on the STM32 driver, it turns out not all systems have them or want them. - Fix a re-probe bug in the i.MX driver, it will eventually crash if probed repeatedly, not good" * tag 'pinctrl-v4.9-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl-aspeed-g5: Never set SCU90[6] pinctrl: cherryview: Prevent possible interrupt storm on resume pinctrl: cherryview: Serialize register access in suspend/resume pinctrl: imx: reset group index on probe pinctrl: stm32: move gpio irqs binding to optional pinctrl: stm32: remove dependency with interrupt controller pinctrl: st: don't specify default interrupt trigger pinctrl: iproc: Fix iProc and NSP GPIO support
-
Rafael J. Wysocki authored
* pm-tools-fixes: cpupower: Correct return type of cpu_power_is_cpu_online() in cpufreq-set * pm-sleep-fixes: PM / sleep: don't suspend parent when async child suspend_{noirq, late} fails PM / sleep: fix device reference leak in test_suspend
-
Rafael J. Wysocki authored
* device-properties: ACPI / platform: Add support for build-in properties
-
Linus Torvalds authored
Merge fixes for -Wmaybe-uninitialized from Arnd Bergmann: "It took a while for some patches to make it into mainline through maintainer trees, but the 28-patch series is now reduced to 10, with one tiny patch added at the end. Aside from patches that are no longer required, I did these changes compared to version 1: - Dropped "iio: maxim_thermocouple: detect invalid storage size in read()", which is currently in linux-next as commit 32cb7d27. This is the only remaining warning I see for a couple of corner cases (kbuild bot reports it on blackfin, kernelci bot and arm-soc bot both report it on arm64) - Dropped "brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap", which is currently in net/master merge pending. - Dropped two x86 patches, "x86: math-emu: possible uninitialized variable use" and "x86: mark target address as output in 'insb' asm" as they do not seem to trigger for a default build, and I got no feedback on them. Both of these are ancient issues and seem harmless, I will send them again to the x86 maintainers once the rest is merged. - Dropped "rbd: false-postive gcc-4.9 -Wmaybe-uninitialized" based on feedback from Ilya Dryomov, who already has a different fix queued up for v4.10. The kbuild bot reports this as a warning for xtensa. - Replaced "crypto: aesni: avoid -Wmaybe-uninitialized warning" with a simpler patch, this one always triggers but my first solution would not be safe for linux-4.9 any more at this point. I'll follow up with the larger patch as a cleanup for 4.10. - Replaced "dib0700: fix nec repeat handling" with a better one, contributed by Sean Young" * -Wmaybe-uninitialized fixes: Kbuild: enable -Wmaybe-uninitialized warnings by default pcmcia: fix return value of soc_pcmcia_regulator_set infiniband: shut up a maybe-uninitialized warning crypto: aesni: shut up -Wmaybe-uninitialized warning rc: print correct variable for z8f0811 dib0700: fix nec repeat handling s390: pci: don't print uninitialized data for debugging nios2: fix timer initcall return value x86: apm: avoid uninitialized data NFSv4.1: work around -Wmaybe-uninitialized warning Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"
-
Linus Torvalds authored
Merge misc fixes from Andrew Morton: "15 fixes" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: lib/stackdepot: export save/fetch stack for drivers mm: kmemleak: scan .data.ro_after_init memcg: prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB coredump: fix unfreezable coredumping task mm/filemap: don't allow partially uptodate page for pipes mm/hugetlb: fix huge page reservation leak in private mapping error paths ocfs2: fix not enough credit panic Revert "console: don't prefer first registered if DT specifies stdout-path" mm: hwpoison: fix thp split handling in memory_failure() swapfile: fix memory corruption via malformed swapfile mm/cma.c: check the max limit for cma allocation scripts/bloat-o-meter: fix SIGPIPE shmem: fix pageflags after swapping DMA32 object mm, frontswap: make sure allocated frontswap map is assigned mm: remove extra newline from allocation stall warning
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull VFS fixes from Al Viro: "Christoph's and Jan's aio fixes, fixup for generic_file_splice_read (removal of pointless detritus that actually breaks it when used for gfs2 ->splice_read()) and fixup for generic_file_read_iter() interaction with ITER_PIPE destinations." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: splice: remove detritus from generic_file_splice_read() mm/filemap: don't allow partially uptodate page for pipes aio: fix freeze protection of aio writes fs: remove aio_run_iocb fs: remove the never implemented aio_fsync file operation aio: hold an extra file reference over AIO read/write operations
-
git://github.com/ceph/ceph-clientLinus Torvalds authored
Pull Ceph fixes from Ilya Dryomov: "Ceph's ->read_iter() implementation is incompatible with the new generic_file_splice_read() code that went into -rc1. Switch to the less efficient default_file_splice_read() for now; the proper fix is being held for 4.10. We also have a fix for a 4.8 regression and a trival libceph fixup" * tag 'ceph-for-4.9-rc5' of git://github.com/ceph/ceph-client: libceph: initialize last_linger_id with a large integer libceph: fix legacy layout decode with pool 0 ceph: use default file splice read callback
-
git://git.linux-nfs.org/projects/anna/linux-nfsLinus Torvalds authored
Pull NFS client bugfixes from Anna Schumaker: "Most of these fix regressions in 4.9, and none are going to stable this time around. Bugfixes: - Trim extra slashes in v4 nfs_paths to fix tools that use this - Fix a -Wmaybe-uninitialized warnings - Fix suspicious RCU usages - Fix Oops when mounting multiple servers at once - Suppress a false-positive pNFS error - Fix a DMAR failure in NFS over RDMA" * tag 'nfs-for-4.9-3' of git://git.linux-nfs.org/projects/anna/linux-nfs: xprtrdma: Fix DMAR failure in frwr_op_map() after reconnect fs/nfs: Fix used uninitialized warn in nfs4_slot_seqid_in_use() NFS: Don't print a pNFS error if we aren't using pNFS NFS: Ignore connections that have cl_rpcclient uninitialized SUNRPC: Fix suspicious RCU usage NFSv4.1: work around -Wmaybe-uninitialized warning NFS: Trim extra slash in v4 nfs_path
-
Linus Torvalds authored
Merge tag 'xfs-fixes-for-linus-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs Pull xfs fix from Dave Chinner: "This is a fix for an unmount hang (regression) when the filesystem is shutdown. It was supposed to go to you for -rc3, but I accidentally tagged the commit prior to it in that pullreq. Summary: - fix for aborting deferred transactions on filesystem shutdown" * tag 'xfs-fixes-for-linus-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs: xfs: defer should abort intent items if the trans roll fails
-
Arnd Bergmann authored
Previously the warnings were added back at the W=1 level and above, this now turns them on again by default, assuming that we have addressed all warnings and again have a clean build for v4.10. I found a number of new warnings in linux-next already and submitted bugfixes for those. Hopefully they are caught by the 0day builder in the future as soon as this patch is merged. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Arnd Bergmann authored
The newly introduced soc_pcmcia_regulator_set() function sometimes returns without setting its return code, as shown by this warning: drivers/pcmcia/soc_common.c: In function 'soc_pcmcia_regulator_set': drivers/pcmcia/soc_common.c:112:5: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized] This changes it to propagate the regulator_disable() result instead. Fixes: ac61b600 ("pcmcia: soc_common: add support for Vcc and Vpp regulators") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Arnd Bergmann authored
Some configurations produce this harmless warning when built with gcc -Wmaybe-uninitialized: infiniband/core/cma.c: In function 'cma_get_net_dev': infiniband/core/cma.c:1242:12: warning: 'src_addr_storage.sin_addr.s_addr' may be used uninitialized in this function [-Wmaybe-uninitialized] I previously reported this for the powerpc64 defconfig, but have now reproduced the same thing for x86 as well, using gcc-5 or higher. The code looks correct to me, and this change just rearranges it by making sure we alway initialize the entire address structure to make the warning disappear. My first approach added an initialization at the time of the declaration, which Doug commented may be too costly, so I hope this version doesn't add overhead. Link: http://arm-soc.lixom.net/buildlogs/mainline/v4.7-rc6/buildall.powerpc.ppc64_defconfig.log.passed Link: https://patchwork.kernel.org/patch/9212825/ Acked-by:
Haggai Eran <haggaie@mellanox.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Arnd Bergmann authored
The rfc4106 encrypy/decrypt helper functions cause an annoying false-positive warning in allmodconfig if we turn on -Wmaybe-uninitialized warnings again: arch/x86/crypto/aesni-intel_glue.c: In function ‘helper_rfc4106_decrypt’: include/linux/scatterlist.h:67:31: warning: ‘dst_sg_walk.sg’ may be used uninitialized in this function [-Wmaybe-uninitialized] The problem seems to be that the compiler doesn't track the state of the 'one_entry_in_sg' variable across the kernel_fpu_begin/kernel_fpu_end section. This takes the easy way out by adding a bogus initialization, which should be harmless enough to get the patch into v4.9 so we can turn on this warning again by default without producing useless output. A follow-up patch for v4.10 rearranges the code to make the warning go away. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Arnd Bergmann authored
A recent rework accidentally left a debugging printk untouched while changing the meaning of the variables, leading to an uninitialized variable being printed: drivers/media/i2c/ir-kbd-i2c.c: In function 'get_key_haup_common': drivers/media/i2c/ir-kbd-i2c.c:62:2: error: 'toggle' may be used uninitialized in this function [-Werror=maybe-uninitialized] This prints the correct one instead, as we did before the patch. Fixes: 00bb8207 ("[media] rc: Hauppauge z8f0811 can decode RC6") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Sean Young authored
When receiving a nec repeat, ensure the correct scancode is repeated rather than a random value from the stack. This removes the need for the bogus uninitialized_var() and also fixes the warnings: drivers/media/usb/dvb-usb/dib0700_core.c: In function ‘dib0700_rc_urb_completion’: drivers/media/usb/dvb-usb/dib0700_core.c:679: warning: ‘protocol’ may be used uninitialized in this function [sean addon: So after writing the patch and submitting it, I've bought the hardware on ebay. Without this patch you get random scancodes on nec repeats, which the patch indeed fixes.] Signed-off-by:
Sean Young <sean@mess.org> Tested-by:
Sean Young <sean@mess.org> Cc: stable@vger.kernel.org Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Arnd Bergmann authored
gcc correctly warns about an incorrect use of the 'pa' variable in case we pass an empty scatterlist to __s390_dma_map_sg: arch/s390/pci/pci_dma.c: In function '__s390_dma_map_sg': arch/s390/pci/pci_dma.c:309:13: warning: 'pa' may be used uninitialized in this function [-Wmaybe-uninitialized] This adds a bogus initialization to the function to sanitize the debug output. I would have preferred a solution without the initialization, but I only got the report from the kbuild bot after turning on the warning again, and didn't manage to reproduce it myself. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Sebastian Ott <sebott@linux.vnet.ibm.com> Acked-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Arnd Bergmann authored
When called more than twice, the nios2_time_init() function return an uninitialized value, as detected by gcc -Wmaybe-uninitialized arch/nios2/kernel/time.c: warning: 'ret' may be used uninitialized in this function This makes it return '0' here, matching the comment above the function. Acked-by:
Ley Foon Tan <lftan@altera.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Arnd Bergmann authored
apm_bios_call() can fail, and return a status in its argument structure. If that status however is zero during a call from apm_get_power_status(), we end up using data that may have never been set, as reported by "gcc -Wmaybe-uninitialized": arch/x86/kernel/apm_32.c: In function ‘apm’: arch/x86/kernel/apm_32.c:1729:17: error: ‘bx’ may be used uninitialized in this function [-Werror=maybe-uninitialized] arch/x86/kernel/apm_32.c:1835:5: error: ‘cx’ may be used uninitialized in this function [-Werror=maybe-uninitialized] arch/x86/kernel/apm_32.c:1730:17: note: ‘cx’ was declared here arch/x86/kernel/apm_32.c:1842:27: error: ‘dx’ may be used uninitialized in this function [-Werror=maybe-uninitialized] arch/x86/kernel/apm_32.c:1731:17: note: ‘dx’ was declared here This changes the function to return "APM_NO_ERROR" here, which makes the code more robust to broken BIOS versions, and avoids the warning. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Jiri Kosina <jkosina@suse.cz> Reviewed-by:
Luis R. Rodriguez <mcgrof@kernel.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Arnd Bergmann authored
A bugfix introduced a harmless gcc warning in nfs4_slot_seqid_in_use if we enable -Wmaybe-uninitialized again: fs/nfs/nfs4session.c:203:54: error: 'cur_seq' may be used uninitialized in this function [-Werror=maybe-uninitialized] gcc is not smart enough to conclude that the IS_ERR/PTR_ERR pair results in a nonzero return value here. Using PTR_ERR_OR_ZERO() instead makes this clear to the compiler. Fixes: e09c978a ("NFSv4.1: Fix Oopsable condition in server callback races") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Arnd Bergmann authored
Traditionally, we have always had warnings about uninitialized variables enabled, as this is part of -Wall, and generally a good idea [1], but it also always produced false positives, mainly because this is a variation of the halting problem and provably impossible to get right in all cases [2]. Various people have identified cases that are particularly bad for false positives, and in commit e74fc973 ("Turn off -Wmaybe-uninitialized when building with -Os"), I turned off the warning for any build that was done with CC_OPTIMIZE_FOR_SIZE. This drastically reduced the number of false positive warnings in the default build but unfortunately had the side effect of turning the warning off completely in 'allmodconfig' builds, which in turn led to a lot of warnings (both actual bugs, and remaining false positives) to go in unnoticed. With commit 877417e6 ("Kbuild: change CC_OPTIMIZE_FOR_SIZE definition") enabled the warning again for allmodconfig builds in v4.7 and in v4.8-rc1, I had finally managed to address all warnings I get in an ARM allmodconfig build and most other maybe-uninitialized warnings for ARM randconfig builds. However, commit 6e8d666e ("Disable "maybe-uninitialized" warning globally") was merged at the same time and disabled it completely for all configurations, because of false-positive warnings on x86 that I had not addressed until then. This caused a lot of actual bugs to get merged into mainline, and I sent several dozen patches for these during the v4.9 development cycle. Most of these are actual bugs, some are for correct code that is safe because it is only called under external constraints that make it impossible to run into the case that gcc sees, and in a few cases gcc is just stupid and finds something that can obviously never happen. I have now done a few thousand randconfig builds on x86 and collected all patches that I needed to address every single warning I got (I can provide the combined patch for the other warnings if anyone is interested), so I hope we can get the warning back and let people catch the actual bugs earlier. This reverts the change to disable the warning completely and for now brings it back at the "make W=1" level, so we can get it merged into mainline without introducing false positives. A follow-up patch enables it on all levels unless some configuration option turns it off because of false-positives. Link: https://rusty.ozlabs.org/?p=232 [1] Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2] Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Chris Wilson authored
Some drivers would like to record stacktraces in order to aide leak tracing. As stackdepot already provides a facility for only storing the unique traces, thereby reducing the memory required, export that functionality for use by drivers. The code was originally created for KASAN and moved under lib in commit cd11016e ("mm, kasan: stackdepot implementation. Enable stackdepot for SLAB") so that it could be shared with mm/. In turn, we want to share it now with drivers. Link: http://lkml.kernel.org/r/20161108133209.22704-1-chris@chris-wilson.co.uk Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: "Kirill A. Shutemov" <kirill@shutemov.name> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <to...
-
Jakub Kicinski authored
Limit the number of kmemleak false positives by including .data.ro_after_init in memory scanning. To achieve this we need to add symbols for start and end of the section to the linker scripts. The problem was been uncovered by commit 56989f6d ("genetlink: mark families as __ro_after_init"). Link: http://lkml.kernel.org/r/1478274173-15218-1-git-send-email-jakub.kicinski@netronome.com Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Cong Wang <xiyou.wangcong@gmail.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Greg Thelen authored
While testing OBJFREELIST_SLAB integration with pagealloc, we found a bug where kmem_cache(sys) would be created with both CFLGS_OFF_SLAB & CFLGS_OBJFREELIST_SLAB. When it happened, critical allocations needed for loading drivers or creating new caches will fail. The original kmem_cache is created early making OFF_SLAB not possible. When kmem_cache(sys) is created, OFF_SLAB is possible and if pagealloc is enabled it will try to enable it first under certain conditions. Given kmem_cache(sys) reuses the original flag, you can have both flags at the same time resulting in allocation failures and odd behaviors. This fix discards allocator specific flags from memcg before calling create_cache. The bug exists since 4.6-rc1 and affects testing debug pagealloc configurations. Fixes: b03a017b ("mm/slab: introduce new slab management type, OBJFREELIST_SLAB") Link: http://lkml.kernel.org/r/1478553075-120242-1-git-send-email-thgarnie@google.com Signed-off-by:
Greg Thelen <gthelen@google.com> Signed-off-by:
Thomas Garnier <thgarnie@google.com> Tested-by:
Thomas Garnier <thgarnie@google.com> Acked-by:
Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Vladimir Davydov <vdavydov.dev@gmail.com> Cc: Michal Hocko <mhocko@kernel.org> Cc: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-