1. 13 Nov, 2016 9 commits
    • Lukas Wunner's avatar
      x86/efi: Retrieve and assign Apple device properties · 58c5475a
      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: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarMatt 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.ukSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      58c5475a
    • Lukas Wunner's avatar
      efi: Allow bitness-agnostic protocol calls · 3552fdf2
      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: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarMatt 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.ukSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      3552fdf2
    • Lukas Wunner's avatar
      efi: Add device path parser · 46cd4b75
      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: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarMatt 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.ukSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      46cd4b75
    • Ard Biesheuvel's avatar
      efi/arm*/libstub: Invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table · 568bc4e8
      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: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Reviewed-by: default avatarKees 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.ukSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      568bc4e8
    • Ard Biesheuvel's avatar
      efi/libstub: Add random.c to ARM build · a6a14469
      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: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Reviewed-by: default avatarKees 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.ukSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      a6a14469
    • Ard Biesheuvel's avatar
      efi: Add support for seeding the RNG from a UEFI config table · 63625988
      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: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Reviewed-by: default avatarKees 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.ukSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      63625988
    • Ard Biesheuvel's avatar
      MAINTAINERS: Add ARM and arm64 EFI specific files to EFI subsystem · f135a176
      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: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Acked-by: default avatarRussell 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.ukSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      f135a176
    • Roy Franz's avatar
      efi/libstub: Fix allocation size calculations · 5b88a31c
      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: default avatarRoy Franz <roy.franz@hpe.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarMatt 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.ukSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      5b88a31c
    • Ingo Molnar's avatar
      74239ac2
  2. 12 Nov, 2016 9 commits
    • Linus Torvalds's avatar
      Merge tag 'acpi-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · 86e4ee76
      Linus 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
      86e4ee76
    • Linus Torvalds's avatar
      Merge tag 'pm-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · b9f659b8
      Linus 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
      b9f659b8
    • Linus Torvalds's avatar
      Merge tag 'arc-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc · e6251f00
      Linus 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
      e6251f00
    • Linus Torvalds's avatar
      Merge tag 'platform-drivers-x86-v4.9-3' of... · e3d183c0
      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
      e3d183c0
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.dk/linux-block · 5f3a5cb8
      Linus 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
      5f3a5cb8
    • Linus Torvalds's avatar
      Merge tag 'pci-v4.9-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci · 8233008f
      Linus 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
      8233008f
    • Linus Torvalds's avatar
      Merge tag 'drm-fixes-for-v4.9-rc5' of git://people.freedesktop.org/~airlied/linux · 4fb68f97
      Linus 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
        ...
      4fb68f97
    • Linus Torvalds's avatar
      Merge tag 'mmc-v4.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc · b8b73df3
      Linus 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
      b8b73df3
    • Linus Torvalds's avatar
      Merge tag 'pinctrl-v4.9-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl · 5c03b53c
      Linus 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
      5c03b53c
  3. 11 Nov, 2016 22 commits
    • Rafael J. Wysocki's avatar
      Merge branches 'pm-tools-fixes' and 'pm-sleep-fixes' · cd16f3dc
      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
      cd16f3dc
    • Rafael J. Wysocki's avatar
      Merge branch 'device-properties' · 66f5854c
      Rafael J. Wysocki authored
      * device-properties:
        ACPI / platform: Add support for build-in properties
      66f5854c
    • Linus Torvalds's avatar
      Merge branch 'maybe-uninitialized' (patches from Arnd) · 015ed943
      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"
      015ed943
    • Linus Torvalds's avatar
      Merge branch 'akpm' (patches from Andrew) · 968ef8de
      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
      968ef8de
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs · c5e4ca6d
      Linus 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
      c5e4ca6d
    • Linus Torvalds's avatar
      Merge tag 'ceph-for-4.9-rc5' of git://github.com/ceph/ceph-client · ef091b3c
      Linus 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
      ef091b3c
    • Linus Torvalds's avatar
      Merge tag 'nfs-for-4.9-3' of git://git.linux-nfs.org/projects/anna/linux-nfs · ef5beed9
      Linus 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
      ef5beed9
    • Linus Torvalds's avatar
      Merge tag 'xfs-fixes-for-linus-4.9-rc5' of... · a4fac3b5
      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
      a4fac3b5
    • Arnd Bergmann's avatar
      Kbuild: enable -Wmaybe-uninitialized warnings by default · 4324cb23
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4324cb23
    • Arnd Bergmann's avatar
      pcmcia: fix return value of soc_pcmcia_regulator_set · 75ed2687
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      75ed2687
    • Arnd Bergmann's avatar
      infiniband: shut up a maybe-uninitialized warning · c50e90d0
      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: default avatarHaggai Eran <haggaie@mellanox.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c50e90d0
    • Arnd Bergmann's avatar
      crypto: aesni: shut up -Wmaybe-uninitialized warning · beae2c9e
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      beae2c9e
    • Arnd Bergmann's avatar
      rc: print correct variable for z8f0811 · 9cdbe14f
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9cdbe14f
    • Sean Young's avatar
      dib0700: fix nec repeat handling · ba13e98f
      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: default avatarSean Young <sean@mess.org>
      Tested-by: default avatarSean Young <sean@mess.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ba13e98f
    • Arnd Bergmann's avatar
      s390: pci: don't print uninitialized data for debugging · 92dfffee
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarSebastian Ott <sebott@linux.vnet.ibm.com>
      Acked-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      92dfffee
    • Arnd Bergmann's avatar
      nios2: fix timer initcall return value · 069013a9
      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: default avatarLey Foon Tan <lftan@altera.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      069013a9
    • Arnd Bergmann's avatar
      x86: apm: avoid uninitialized data · 3a6d8676
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarJiri Kosina <jkosina@suse.cz>
      Reviewed-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3a6d8676
    • Arnd Bergmann's avatar
      NFSv4.1: work around -Wmaybe-uninitialized warning · e84efa32
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e84efa32
    • Arnd Bergmann's avatar
      Kbuild: enable -Wmaybe-uninitialized warning for "make W=1" · a76bcf55
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a76bcf55
    • Chris Wilson's avatar
      lib/stackdepot: export save/fetch stack for drivers · ae65a21f
      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.ukSigned-off-by: default avatarChris 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ae65a21f
    • Jakub Kicinski's avatar
      mm: kmemleak: scan .data.ro_after_init · d7c19b06
      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.comReviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarJakub 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d7c19b06
    • Greg Thelen's avatar
      memcg: prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB · f773e36d
      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.comSigned-off-by: default avatarGreg Thelen <gthelen@google.com>
      Signed-off-by: default avatarThomas Garnier <thgarnie@google.com>
      Tested-by: default avatarThomas Garnier <thgarnie@google.com>
      Acked-by: default avatarChristoph 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f773e36d