1. 26 Nov, 2016 2 commits
    • Linus Torvalds's avatar
      Merge tag 'powerpc-4.9-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux · 39c15737
      Linus Torvalds authored
      Pull powerpc fixes from Michael Ellerman:
       "Fixes marked for stable:
         - Set missing wakeup bit in LPCR on POWER9
         - Fix the early OPAL console wrappers
         - Fixup kernel read only mapping
      
        Fixes for code merged this cycle:
         - Fix missing CRCs, add more asm-prototypes.h declarations"
      
      * tag 'powerpc-4.9-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
        powerpc/mm: Fixup kernel read only mapping
        powerpc/boot: Fix the early OPAL console wrappers
        powerpc: Fix missing CRCs, add more asm-prototypes.h declarations
        powerpc: Set missing wakeup bit in LPCR on POWER9
      39c15737
    • Linus Torvalds's avatar
      Merge branch 'parisc-4.9-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux · 3ad0e83c
      Linus Torvalds authored
      Pull parisc fixes from Helge Deller:
       "On parisc we were still seeing occasional random segmentation faults
        and memory corruption on SMP machines. Dave Anglin then looked again
        at the TLB related code and found two issues in the PCI DMA and
        generic TLB flush functions.
      
        Then, in our startup code we had some timing of the cache and TLB
        functions to calculate a threshold when to use a complete TLB/cache
        flush or just to flush a specific range. This code produced a race
        with newly started CPUs and thus lead to occasional kernel crashes
        (due to stale TLB/cache entries). The patch by Dave fixes this issue
        by flushing the local caches before starting secondary CPUs and by
        removing the race.
      
        The last problem fixed by this series is that we quite often suffered
        from hung tasks and self-detected stalls on the CPUs. It was somehow
        clear that this was related to the (in v4.7) newly introduced cr16
        clocksource and the own implementation of sched_clock(). I replaced
        the open-coded sched_clock() function and switched to the generic
        sched_clock() implementation which seems to have fixed this isse as
        well.
      
        All patches have been sucessfully tested on a variety of machines,
        including our debian buildd servers.
      
        All patches (beside the small pr_cont fix) are tagged for stable
        releases"
      
      * 'parisc-4.9-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
        parisc: Also flush data TLB in flush_icache_page_asm
        parisc: Fix race in pci-dma.c
        parisc: Switch to generic sched_clock implementation
        parisc: Fix races in parisc_setup_cache_timing()
        parisc: Fix printk continuations in system detection
      3ad0e83c
  2. 25 Nov, 2016 19 commits
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security · 86b01b54
      Linus Torvalds authored
      Pull keys fixes from James Morris:
       "From David:
      
         - Fix mpi_powm()'s handling of a number with a zero exponent
           [CVE-2016-8650].
      
           Integrate my and Andrey's patches for mpi_powm() and use
           mpi_resize() instead of RESIZE_IF_NEEDED() - the latter adds a
           duplicate check into the execution path of a trivial case we
           don't normally expect to be taken.
      
         - Fix double free in X.509 error handling"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
        mpi: Fix NULL ptr dereference in mpi_powm() [ver #3]
        X.509: Fix double free in x509_cert_parse() [ver #3]
      86b01b54
    • Linus Torvalds's avatar
      Fix subtle CONFIG_MODVERSIONS problems · cd3caefb
      Linus Torvalds authored
      CONFIG_MODVERSIONS has been broken for pretty much the whole 4.9 series,
      and quite frankly, nobody has cared very deeply.  We absolutely know how
      to fix it, and it's not _complicated_, but it's not exactly pretty
      either.
      
      This oneliner fixes it without the ugliness, and allows for further
      future cleanups.
      
        "We've secretly replaced their regular MODVERSIONS with nothing at
         all, let's see if they notice"
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      cd3caefb
    • Linus Torvalds's avatar
      Merge tag 'acpi-4.9-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · beb53e4b
      Linus Torvalds authored
      Pull ACPI fixes from Rafael Wysocki:
       "Two ACPI fixes for 4.9-rc7.
      
        One of them reverts a recent ACPI commit that attempted to improve
        reboot/power-off on some systems, but introduced problems elsewhere,
        and the other one fixes kernel builds with the new WDAT watchdog
        driver enabled in some configurations.
      
        Specifics:
      
         - Revert the recent commit that caused the ACPI _PTS method to be
           executed in the power-off/reboot code path (as per the
           specification) in an attempt to improve things on some systems
           (apparently expecting _PTS to be executed in that code path), but
           broke power-off/reboot on at least one other machine (Rafael
           Wysocki).
      
         - Fix kernel builds with the new WDAT watchdog driver enabled in some
           configurations by explicitly selecting WATCHDOG_CORE when enabling
           the WDAT watchdog driver (Mika Westerberg)"
      
      * tag 'acpi-4.9-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        watchdog: wdat_wdt: Select WATCHDOG_CORE
        Revert "ACPI: Execute _PTS before system reboot"
      beb53e4b
    • Rafael J. Wysocki's avatar
      MAINTAINERS: Add bug tracking system location entry type · 68656443
      Rafael J. Wysocki authored
      Following the kernel Bugzilla discussion during the Kernel Summit
      (https://lwn.net/Articles/705245/), add bug tracking system location
      entry type (B) to MAINTAINERS and populate it for several subsystems
      known to be using the kernel BZ actively (and add the upstream BZ for
      ACPICA too).
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      68656443
    • Rafael J. Wysocki's avatar
      Merge branches 'acpi-sleep-fixes' and 'acpi-wdat-fixes' · 7e5c07af
      Rafael J. Wysocki authored
      * acpi-sleep-fixes:
        Revert "ACPI: Execute _PTS before system reboot"
      
      * acpi-wdat-fixes:
        watchdog: wdat_wdt: Select WATCHDOG_CORE
      7e5c07af
    • Linus Torvalds's avatar
      Merge tag 'mfd-fixes-4.9.1' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd · f2051f8f
      Linus Torvalds authored
      Pull MFD fixes from Lee Jones:
       "Received a copule of last minute fixes for v4.9.
      
        The patches from Viresh are fixing issues displayed in KernelCI"
      
      * tag 'mfd-fixes-4.9.1' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd:
        mfd: wm8994-core: Don't use managed regulator bulk get API
        mfd: wm8994-core: Disable regulators before removing them
        mfd: syscon: Support native-endian regmaps
      f2051f8f
    • Linus Torvalds's avatar
      Merge tag 'media/v4.9-4' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media · ea9ea6c6
      Linus Torvalds authored
      Pull media fix from Mauro Carvalho Chehab:
       "Fix for the firmware load logic of the tuner-xc2028 driver"
      
      * tag 'media/v4.9-4' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
        xc2028: Fix use-after-free bug properly
      ea9ea6c6
    • Linus Torvalds's avatar
      Merge tag 'drm-fixes-for-v4.9-rc7' of git://people.freedesktop.org/~airlied/linux · 6006d6e7
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "Seems to be quietening down nicely, a few mediatek, one exynos and one
        hdlcd fix, along with two amd fixes"
      
      * tag 'drm-fixes-for-v4.9-rc7' of git://people.freedesktop.org/~airlied/linux:
        gpu/drm/exynos/exynos_hdmi - Unmap region obtained by of_iomap
        drm/mediatek: fix null pointer dereference
        drm/mediatek: fixed the calc method of data rate per lane
        drm/mediatek: fix a typo of DISP_OD_CFG to OD_RELAYMODE
        drm/radeon: fix power state when port pm is unavailable (v2)
        drm/amdgpu: fix power state when port pm is unavailable
        drm/arm: hdlcd: fix plane base address update
        drm/amd/powerplay: avoid out of bounds access on array ps.
      6006d6e7
    • John David Anglin's avatar
      parisc: Also flush data TLB in flush_icache_page_asm · 5035b230
      John David Anglin authored
      This is the second issue I noticed in reviewing the parisc TLB code.
      
      The fic instruction may use either the instruction or data TLB in
      flushing the instruction cache.  Thus, on machines with a split TLB, we
      should also flush the data TLB after setting up the temporary alias
      registers.
      
      Although this has no functional impact, I changed the pdtlb and pitlb
      instructions to consistently use the index register %r0.  These
      instructions do not support integer displacements.
      
      Tested on rp3440 and c8000.
      Signed-off-by: default avatarJohn David Anglin  <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org> # v3.16+
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      5035b230
    • John David Anglin's avatar
      parisc: Fix race in pci-dma.c · c0452fb9
      John David Anglin authored
      We are still troubled by occasional random segmentation faults and
      memory memory corruption on SMP machines.  The causes quite a few
      package builds to fail on the Debian buildd machines for parisc.  When
      gcc-6 failed to build three times in a row, I looked again at the TLB
      related code.  I found a couple of issues.  This is the first.
      
      In general, we need to ensure page table updates and corresponding TLB
      purges are atomic.  The attached patch fixes an instance in pci-dma.c
      where the page table update was not guarded by the TLB lock.
      
      Tested on rp3440 and c8000.  So far, no further random segmentation
      faults have been observed.
      Signed-off-by: default avatarJohn David Anglin  <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org> # v3.16+
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      c0452fb9
    • Helge Deller's avatar
      parisc: Switch to generic sched_clock implementation · 43b1f6ab
      Helge Deller authored
      Drop the open-coded sched_clock() function and replace it by the provided
      GENERIC_SCHED_CLOCK implementation.  We have seen quite some hung tasks in the
      past, which seem to be fixed by this patch.
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Cc: <stable@vger.kernel.org> # v4.7+
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      43b1f6ab
    • John David Anglin's avatar
      parisc: Fix races in parisc_setup_cache_timing() · 741dc7bf
      John David Anglin authored
      Helge reported to me the following startup crash:
      
      [    0.000000] Linux version 4.8.0-1-parisc64-smp (debian-kernel@lists.debian.org) (gcc version 5.4.1 20161019 (GCC) ) #1 SMP Debian 4.8.7-1 (2016-11-13)
      [    0.000000] The 64-bit Kernel has started...
      [    0.000000] Kernel default page size is 4 KB. Huge pages enabled with 1 MB physical and 2 MB virtual size.
      [    0.000000] Determining PDC firmware type: System Map.
      [    0.000000] model 9000/785/J5000
      [    0.000000] Total Memory: 2048 MB
      [    0.000000] Memory: 2018528K/2097152K available (9272K kernel code, 3053K rwdata, 1319K rodata, 1024K init, 840K bss, 78624K reserved, 0K cma-reserved)
      [    0.000000] virtual kernel memory layout:
      [    0.000000]     vmalloc : 0x0000000000008000 - 0x000000003f000000   (1007 MB)
      [    0.000000]     memory  : 0x0000000040000000 - 0x00000000c0000000   (2048 MB)
      [    0.000000]       .init : 0x0000000040100000 - 0x0000000040200000   (1024 kB)
      [    0.000000]       .data : 0x0000000040b0e000 - 0x0000000040f533e0   (4372 kB)
      [    0.000000]       .text : 0x0000000040200000 - 0x0000000040b0e000   (9272 kB)
      [    0.768910] Brought up 1 CPUs
      [    0.992465] NET: Registered protocol family 16
      [    2.429981] Releasing cpu 1 now, hpa=fffffffffffa2000
      [    2.635751] CPU(s): 2 out of 2 PA8500 (PCX-W) at 440.000000 MHz online
      [    2.726692] Setting cache flush threshold to 1024 kB
      [    2.729932] Not-handled unaligned insn 0x43ffff80
      [    2.798114] Setting TLB flush threshold to 140 kB
      [    2.928039] Unaligned handler failed, ret = -1
      [    3.000419]       _______________________________
      [    3.000419]      < Your System ate a SPARC! Gah! >
      [    3.000419]       -------------------------------
      [    3.000419]              \   ^__^
      [    3.000419]                  (__)\       )\/\
      [    3.000419]                   U  ||----w |
      [    3.000419]                      ||     ||
      [    9.340055] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0-1-parisc64-smp #1 Debian 4.8.7-1
      [    9.448082] task: 00000000bfd48060 task.stack: 00000000bfd50000
      [    9.528040]
      [   10.760029] IASQ: 0000000000000000 0000000000000000 IAOQ: 000000004025d154 000000004025d158
      [   10.868052]  IIR: 43ffff80    ISR: 0000000000340000  IOR: 000001ff54150960
      [   10.960029]  CPU:        1   CR30: 00000000bfd50000 CR31: 0000000011111111
      [   11.052057]  ORIG_R28: 000000004021e3b4
      [   11.100045]  IAOQ[0]: irq_exit+0x94/0x120
      [   11.152062]  IAOQ[1]: irq_exit+0x98/0x120
      [   11.208031]  RP(r2): irq_exit+0xb8/0x120
      [   11.256074] Backtrace:
      [   11.288067]  [<00000000402cd944>] cpu_startup_entry+0x1e4/0x598
      [   11.368058]  [<0000000040109528>] smp_callin+0x2c0/0x2f0
      [   11.436308]  [<00000000402b53fc>] update_curr+0x18c/0x2d0
      [   11.508055]  [<00000000402b73b8>] dequeue_entity+0x2c0/0x1030
      [   11.584040]  [<00000000402b3cc0>] set_next_entity+0x80/0xd30
      [   11.660069]  [<00000000402c1594>] pick_next_task_fair+0x614/0x720
      [   11.740085]  [<000000004020dd34>] __schedule+0x394/0xa60
      [   11.808054]  [<000000004020e488>] schedule+0x88/0x118
      [   11.876039]  [<0000000040283d3c>] rescuer_thread+0x4d4/0x5b0
      [   11.948090]  [<000000004028fc4c>] kthread+0x1ec/0x248
      [   12.016053]  [<0000000040205020>] end_fault_vector+0x20/0xc0
      [   12.092239]  [<00000000402050c0>] _switch_to_ret+0x0/0xf40
      [   12.164044]
      [   12.184036] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0-1-parisc64-smp #1 Debian 4.8.7-1
      [   12.244040] Backtrace:
      [   12.244040]  [<000000004021c480>] show_stack+0x68/0x80
      [   12.244040]  [<00000000406f332c>] dump_stack+0xec/0x168
      [   12.244040]  [<000000004021c74c>] die_if_kernel+0x25c/0x430
      [   12.244040]  [<000000004022d320>] handle_unaligned+0xb48/0xb50
      [   12.244040]
      [   12.632066] ---[ end trace 9ca05a7215c7bbb2 ]---
      [   12.692036] Kernel panic - not syncing: Attempted to kill the idle task!
      
      We have the insn 0x43ffff80 in IIR but from IAOQ we should have:
         4025d150:   0f f3 20 df     ldd,s r19(r31),r31
         4025d154:   0f 9f 00 9c     ldw r31(ret0),ret0
         4025d158:   bf 80 20 58     cmpb,*<> r0,ret0,4025d18c <irq_exit+0xcc>
      
      Cpu0 has just completed running parisc_setup_cache_timing:
      
      [    2.429981] Releasing cpu 1 now, hpa=fffffffffffa2000
      [    2.635751] CPU(s): 2 out of 2 PA8500 (PCX-W) at 440.000000 MHz online
      [    2.726692] Setting cache flush threshold to 1024 kB
      [    2.729932] Not-handled unaligned insn 0x43ffff80
      [    2.798114] Setting TLB flush threshold to 140 kB
      [    2.928039] Unaligned handler failed, ret = -1
      
      From the backtrace, cpu1 is in smp_callin:
      
      void __init smp_callin(void)
      {
             int slave_id = cpu_now_booting;
      
             smp_cpu_init(slave_id);
             preempt_disable();
      
             flush_cache_all_local(); /* start with known state */
             flush_tlb_all_local(NULL);
      
             local_irq_enable();  /* Interrupts have been off until now */
      
             cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);
      
      So, it has just flushed its caches and the TLB. It would seem either the
      flushes in parisc_setup_cache_timing or smp_callin have corrupted kernel
      memory.
      
      The attached patch reworks parisc_setup_cache_timing to remove the races
      in setting the cache and TLB flush thresholds. It also corrects the
      number of bytes flushed in the TLB calculation.
      
      The patch flushes the cache and TLB on cpu0 before starting the
      secondary processors so that they are started from a known state.
      
      Tested with a few reboots on c8000.
      Signed-off-by: default avatarJohn David Anglin  <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org> # v3.18+
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      741dc7bf
    • Viresh Kumar's avatar
      mfd: wm8994-core: Don't use managed regulator bulk get API · 1a41741f
      Viresh Kumar authored
      The kernel WARNs and then crashes today if wm8994_device_init() fails
      after calling devm_regulator_bulk_get().
      
      That happens because there are multiple devices involved here and the
      order in which managed resources are freed isn't correct.
      
      The regulators are added as children of wm8994->dev.  Whereas,
      devm_regulator_bulk_get() receives wm8994->dev as the device, though it
      gets the same regulators which were added as children of wm8994->dev
      earlier.
      
      During failures, the children are removed first and the core eventually
      calls regulator_unregister() for them. As regulator_put() was never done
      for them (opposite of devm_regulator_bulk_get()), the kernel WARNs at
      
      	WARN_ON(rdev->open_count);
      
      And eventually it crashes from debugfs_remove_recursive().
      
      --------x------------------x----------------
      
       wm8994 3-001a: Device is not a WM8994, ID is 0
       ------------[ cut here ]------------
       WARNING: CPU: 0 PID: 1 at /mnt/ssd/all/work/repos/devel/linux/drivers/regulator/core.c:4072 regulator_unregister+0xc8/0xd0
       Modules linked in:
       CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc6-00154-g54fe84cbd50b #41
       Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
       [<c010e24c>] (unwind_backtrace) from [<c010af38>] (show_stack+0x10/0x14)
       [<c010af38>] (show_stack) from [<c032a1c4>] (dump_stack+0x88/0x9c)
       [<c032a1c4>] (dump_stack) from [<c011a98c>] (__warn+0xe8/0x100)
       [<c011a98c>] (__warn) from [<c011aa54>] (warn_slowpath_null+0x20/0x28)
       [<c011aa54>] (warn_slowpath_null) from [<c0384a0c>] (regulator_unregister+0xc8/0xd0)
       [<c0384a0c>] (regulator_unregister) from [<c0406434>] (release_nodes+0x16c/0x1dc)
       [<c0406434>] (release_nodes) from [<c04039c4>] (__device_release_driver+0x8c/0x110)
       [<c04039c4>] (__device_release_driver) from [<c0403a64>] (device_release_driver+0x1c/0x28)
       [<c0403a64>] (device_release_driver) from [<c0402b24>] (bus_remove_device+0xd8/0x104)
       [<c0402b24>] (bus_remove_device) from [<c03ffcd8>] (device_del+0x10c/0x218)
       [<c03ffcd8>] (device_del) from [<c0404e4c>] (platform_device_del+0x1c/0x88)
       [<c0404e4c>] (platform_device_del) from [<c0404ec4>] (platform_device_unregister+0xc/0x20)
       [<c0404ec4>] (platform_device_unregister) from [<c0428bc0>] (mfd_remove_devices_fn+0x5c/0x64)
       [<c0428bc0>] (mfd_remove_devices_fn) from [<c03ff9d8>] (device_for_each_child_reverse+0x4c/0x78)
       [<c03ff9d8>] (device_for_each_child_reverse) from [<c04288c4>] (mfd_remove_devices+0x20/0x30)
       [<c04288c4>] (mfd_remove_devices) from [<c042758c>] (wm8994_device_init+0x2ac/0x7f0)
       [<c042758c>] (wm8994_device_init) from [<c04f14a8>] (i2c_device_probe+0x178/0x1fc)
       [<c04f14a8>] (i2c_device_probe) from [<c04036fc>] (driver_probe_device+0x214/0x2c0)
       [<c04036fc>] (driver_probe_device) from [<c0403854>] (__driver_attach+0xac/0xb0)
       [<c0403854>] (__driver_attach) from [<c0401a74>] (bus_for_each_dev+0x68/0x9c)
       [<c0401a74>] (bus_for_each_dev) from [<c0402cf0>] (bus_add_driver+0x1a0/0x218)
       [<c0402cf0>] (bus_add_driver) from [<c040406c>] (driver_register+0x78/0xf8)
       [<c040406c>] (driver_register) from [<c04f20a0>] (i2c_register_driver+0x34/0x84)
       [<c04f20a0>] (i2c_register_driver) from [<c01017d0>] (do_one_initcall+0x40/0x170)
       [<c01017d0>] (do_one_initcall) from [<c0a00dbc>] (kernel_init_freeable+0x15c/0x1fc)
       [<c0a00dbc>] (kernel_init_freeable) from [<c06e07b0>] (kernel_init+0x8/0x114)
       [<c06e07b0>] (kernel_init) from [<c0107978>] (ret_from_fork+0x14/0x3c)
       ---[ end trace 0919d3d0bc998260 ]---
      
       [snip..]
      
       Unable to handle kernel NULL pointer dereference at virtual address 00000078
       pgd = c0004000
       [00000078] *pgd=00000000
       Internal error: Oops: 5 [#1] PREEMPT SMP ARM
       Modules linked in:
       CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W       4.8.0-rc6-00154-g54fe84cbd50b #41
       Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
       task: ee874000 task.stack: ee878000
       PC is at down_write+0x14/0x54
       LR is at debugfs_remove_recursive+0x30/0x150
      
       [snip..]
      
       [<c06e489c>] (down_write) from [<c02e9954>] (debugfs_remove_recursive+0x30/0x150)
       [<c02e9954>] (debugfs_remove_recursive) from [<c0382b78>] (_regulator_put+0x24/0xac)
       [<c0382b78>] (_regulator_put) from [<c0382c1c>] (regulator_put+0x1c/0x2c)
       [<c0382c1c>] (regulator_put) from [<c0406434>] (release_nodes+0x16c/0x1dc)
       [<c0406434>] (release_nodes) from [<c04035d4>] (driver_probe_device+0xec/0x2c0)
       [<c04035d4>] (driver_probe_device) from [<c0403854>] (__driver_attach+0xac/0xb0)
       [<c0403854>] (__driver_attach) from [<c0401a74>] (bus_for_each_dev+0x68/0x9c)
       [<c0401a74>] (bus_for_each_dev) from [<c0402cf0>] (bus_add_driver+0x1a0/0x218)
       [<c0402cf0>] (bus_add_driver) from [<c040406c>] (driver_register+0x78/0xf8)
       [<c040406c>] (driver_register) from [<c04f20a0>] (i2c_register_driver+0x34/0x84)
       [<c04f20a0>] (i2c_register_driver) from [<c01017d0>] (do_one_initcall+0x40/0x170)
       [<c01017d0>] (do_one_initcall) from [<c0a00dbc>] (kernel_init_freeable+0x15c/0x1fc)
       [<c0a00dbc>] (kernel_init_freeable) from [<c06e07b0>] (kernel_init+0x8/0x114)
       [<c06e07b0>] (kernel_init) from [<c0107978>] (ret_from_fork+0x14/0x3c)
       Code: e1a04000 f590f000 e3a03001 e34f3fff (e1902f9f)
       ---[ end trace 0919d3d0bc998262 ]---
      
      --------x------------------x----------------
      
      Fix the kernel warnings and crashes by using regulator_bulk_get()
      instead of devm_regulator_bulk_get() and explicitly freeing the supplies
      in exit paths.
      
      Tested on Exynos 5250, dual core ARM A15 machine.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: default avatarCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      1a41741f
    • Viresh Kumar's avatar
      mfd: wm8994-core: Disable regulators before removing them · 3cfc43df
      Viresh Kumar authored
      The order in which resources were freed in wm8994_device_exit() isn't
      correct. The regulators are removed before they are disabled.
      
      Fix it by reordering code a bit, which makes it exact opposite of
      wm8994_device_init() as well.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: default avatarCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      3cfc43df
    • Paul Burton's avatar
      mfd: syscon: Support native-endian regmaps · d29ccdb3
      Paul Burton authored
      The regmap devicetree binding documentation states that a native-endian
      property should be supported as well as big-endian & little-endian,
      however syscon in its duplication of the parsing of these properties
      omits support for native-endian. Fix this by setting
      REGMAP_ENDIAN_NATIVE when a native-endian property is found.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: Lee Jones <lee.jones@linaro.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      d29ccdb3
    • Dave Airlie's avatar
      Merge branch 'mediatek-drm-fixes-2016-11-24' of... · 9704668e
      Dave Airlie authored
      Merge branch 'mediatek-drm-fixes-2016-11-24' of https://github.com/ckhu-mediatek/linux.git-tags into drm-fixes
      
      This branch include patches of fixing a typo, accurate dsi frame rate,
      and fixing null pointer dereference.
      
      * 'mediatek-drm-fixes-2016-11-24' of https://github.com/ckhu-mediatek/linux.git-tags:
        drm/mediatek: fix null pointer dereference
        drm/mediatek: fixed the calc method of data rate per lane
        drm/mediatek: fix a typo of DISP_OD_CFG to OD_RELAYMODE
      9704668e
    • Aneesh Kumar K.V's avatar
      powerpc/mm: Fixup kernel read only mapping · 984d7a1e
      Aneesh Kumar K.V authored
      With commit e58e87ad ("powerpc/mm: Update _PAGE_KERNEL_RO") we
      started using the ppp value 0b110 to map kernel readonly. But that
      facility was only added as part of ISA 2.04. For earlier ISA version
      only supported ppp bit value for readonly mapping is 0b011. (This
      implies both user and kernel get mapped using the same ppp bit value for
      readonly mapping.).
      Update the code such that for earlier architecture version we use ppp
      value 0b011 for readonly mapping. We don't differentiate between power5+
      and power5 here and apply the new ppp bits only from power6 (ISA 2.05).
      This keep the changes minimal.
      
      This fixes issue with PS3 spu usage reported at
      https://lkml.kernel.org/r/rep.1421449714.geoff@infradead.org
      
      Fixes: e58e87ad ("powerpc/mm: Update _PAGE_KERNEL_RO")
      Cc: stable@vger.kernel.org # v4.7+
      Tested-by: default avatarGeoff Levand <geoff@infradead.org>
      Signed-off-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      984d7a1e
    • Andrey Ryabinin's avatar
      mpi: Fix NULL ptr dereference in mpi_powm() [ver #3] · f5527fff
      Andrey Ryabinin authored
      This fixes CVE-2016-8650.
      
      If mpi_powm() is given a zero exponent, it wants to immediately return
      either 1 or 0, depending on the modulus.  However, if the result was
      initalised with zero limb space, no limbs space is allocated and a
      NULL-pointer exception ensues.
      
      Fix this by allocating a minimal amount of limb space for the result when
      the 0-exponent case when the result is 1 and not touching the limb space
      when the result is 0.
      
      This affects the use of RSA keys and X.509 certificates that carry them.
      
      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: [<ffffffff8138ce5d>] mpi_powm+0x32/0x7e6
      PGD 0
      Oops: 0002 [#1] SMP
      Modules linked in:
      CPU: 3 PID: 3014 Comm: keyctl Not tainted 4.9.0-rc6-fscache+ #278
      Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
      task: ffff8804011944c0 task.stack: ffff880401294000
      RIP: 0010:[<ffffffff8138ce5d>]  [<ffffffff8138ce5d>] mpi_powm+0x32/0x7e6
      RSP: 0018:ffff880401297ad8  EFLAGS: 00010212
      RAX: 0000000000000000 RBX: ffff88040868bec0 RCX: ffff88040868bba0
      RDX: ffff88040868b260 RSI: ffff88040868bec0 RDI: ffff88040868bee0
      RBP: ffff880401297ba8 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000047 R11: ffffffff8183b210 R12: 0000000000000000
      R13: ffff8804087c7600 R14: 000000000000001f R15: ffff880401297c50
      FS:  00007f7a7918c700(0000) GS:ffff88041fb80000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000000 CR3: 0000000401250000 CR4: 00000000001406e0
      Stack:
       ffff88040868bec0 0000000000000020 ffff880401297b00 ffffffff81376cd4
       0000000000000100 ffff880401297b10 ffffffff81376d12 ffff880401297b30
       ffffffff81376f37 0000000000000100 0000000000000000 ffff880401297ba8
      Call Trace:
       [<ffffffff81376cd4>] ? __sg_page_iter_next+0x43/0x66
       [<ffffffff81376d12>] ? sg_miter_get_next_page+0x1b/0x5d
       [<ffffffff81376f37>] ? sg_miter_next+0x17/0xbd
       [<ffffffff8138ba3a>] ? mpi_read_raw_from_sgl+0xf2/0x146
       [<ffffffff8132a95c>] rsa_verify+0x9d/0xee
       [<ffffffff8132acca>] ? pkcs1pad_sg_set_buf+0x2e/0xbb
       [<ffffffff8132af40>] pkcs1pad_verify+0xc0/0xe1
       [<ffffffff8133cb5e>] public_key_verify_signature+0x1b0/0x228
       [<ffffffff8133d974>] x509_check_for_self_signed+0xa1/0xc4
       [<ffffffff8133cdde>] x509_cert_parse+0x167/0x1a1
       [<ffffffff8133d609>] x509_key_preparse+0x21/0x1a1
       [<ffffffff8133c3d7>] asymmetric_key_preparse+0x34/0x61
       [<ffffffff812fc9f3>] key_create_or_update+0x145/0x399
       [<ffffffff812fe227>] SyS_add_key+0x154/0x19e
       [<ffffffff81001c2b>] do_syscall_64+0x80/0x191
       [<ffffffff816825e4>] entry_SYSCALL64_slow_path+0x25/0x25
      Code: 56 41 55 41 54 53 48 81 ec a8 00 00 00 44 8b 71 04 8b 42 04 4c 8b 67 18 45 85 f6 89 45 80 0f 84 b4 06 00 00 85 c0 75 2f 41 ff ce <49> c7 04 24 01 00 00 00 b0 01 75 0b 48 8b 41 18 48 83 38 01 0f
      RIP  [<ffffffff8138ce5d>] mpi_powm+0x32/0x7e6
       RSP <ffff880401297ad8>
      CR2: 0000000000000000
      ---[ end trace d82015255d4a5d8d ]---
      
      Basically, this is a backport of a libgcrypt patch:
      
      	http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=patch;h=6e1adb05d290aeeb1c230c763970695f4a538526
      
      Fixes: cdec9cb5 ("crypto: GnuPG based MPI lib - source files (part 1)")
      Signed-off-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
      cc: linux-ima-devel@lists.sourceforge.net
      cc: stable@vger.kernel.org
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      f5527fff
    • Andrey Ryabinin's avatar
      X.509: Fix double free in x509_cert_parse() [ver #3] · 2b95fda2
      Andrey Ryabinin authored
      We shouldn't free cert->pub->key in x509_cert_parse() because
      x509_free_certificate() also does this:
      	BUG: Double free or freeing an invalid pointer
      	...
      	Call Trace:
      	 [<ffffffff81896c20>] dump_stack+0x63/0x83
      	 [<ffffffff81356571>] kasan_object_err+0x21/0x70
      	 [<ffffffff81356ed9>] kasan_report_double_free+0x49/0x60
      	 [<ffffffff813561ad>] kasan_slab_free+0x9d/0xc0
      	 [<ffffffff81350b7a>] kfree+0x8a/0x1a0
      	 [<ffffffff81844fbf>] public_key_free+0x1f/0x30
      	 [<ffffffff818455d4>] x509_free_certificate+0x24/0x90
      	 [<ffffffff818460bc>] x509_cert_parse+0x2bc/0x300
      	 [<ffffffff81846cae>] x509_key_preparse+0x3e/0x330
      	 [<ffffffff818444cf>] asymmetric_key_preparse+0x6f/0x100
      	 [<ffffffff8178bec0>] key_create_or_update+0x260/0x5f0
      	 [<ffffffff8178e6d9>] SyS_add_key+0x199/0x2a0
      	 [<ffffffff821d823b>] entry_SYSCALL_64_fastpath+0x1e/0xad
      	Object at ffff880110bd1900, in cache kmalloc-512 size: 512
      	....
      	Freed:
      	PID = 2579
      	[<ffffffff8104283b>] save_stack_trace+0x1b/0x20
      	[<ffffffff813558f6>] save_stack+0x46/0xd0
      	[<ffffffff81356183>] kasan_slab_free+0x73/0xc0
      	[<ffffffff81350b7a>] kfree+0x8a/0x1a0
      	[<ffffffff818460a3>] x509_cert_parse+0x2a3/0x300
      	[<ffffffff81846cae>] x509_key_preparse+0x3e/0x330
      	[<ffffffff818444cf>] asymmetric_key_preparse+0x6f/0x100
      	[<ffffffff8178bec0>] key_create_or_update+0x260/0x5f0
      	[<ffffffff8178e6d9>] SyS_add_key+0x199/0x2a0
      	[<ffffffff821d823b>] entry_SYSCALL_64_fastpath+0x1e/0xad
      
      Fixes: db6c43bd ("crypto: KEYS: convert public key and digsig asym to the akcipher api")
      Signed-off-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      2b95fda2
  3. 24 Nov, 2016 11 commits
  4. 23 Nov, 2016 8 commits
    • Takashi Iwai's avatar
      xc2028: Fix use-after-free bug properly · 22a1e778
      Takashi Iwai authored
      The commit 8dfbcc43 ("[media] xc2028: avoid use after free") tried
      to address the reported use-after-free by clearing the reference.
      
      However, it's clearing the wrong pointer; it sets NULL to
      priv->ctrl.fname, but it's anyway overwritten by the next line
      memcpy(&priv->ctrl, p, sizeof(priv->ctrl)).
      
      OTOH, the actual code accessing the freed string is the strcmp() call
      with priv->fname:
      	if (!firmware_name[0] && p->fname &&
      	    priv->fname && strcmp(p->fname, priv->fname))
      		free_firmware(priv);
      
      where priv->fname points to the previous file name, and this was
      already freed by kfree().
      
      For fixing the bug properly, this patch does the following:
      
      - Keep the copy of firmware file name in only priv->fname,
        priv->ctrl.fname isn't changed;
      - The allocation is done only when the firmware gets loaded;
      - The kfree() is called in free_firmware() commonly
      
      Fixes: commit 8dfbcc43 ('[media] xc2028: avoid use after free')
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      22a1e778
    • Linus Torvalds's avatar
      Merge tag 'nfs-for-4.9-4' of git://git.linux-nfs.org/projects/anna/linux-nfs · 10b9dd56
      Linus Torvalds authored
      Pull NFS client bugfixes from Anna Schumaker:
       "Most of these fix regressions or races, but there is one patch for
        stable that Arnd sent me
      
        Stable bugfix:
         - Hide array-bounds warning
      
        Bugfixes:
         - Keep a reference on lock states while checking
         - Handle NFS4ERR_OLD_STATEID in nfs4_reclaim_open_state
         - Don't call close if the open stateid has already been cleared
         - Fix CLOSE rases with OPEN
         - Fix a regression in DELEGRETURN"
      
      * tag 'nfs-for-4.9-4' of git://git.linux-nfs.org/projects/anna/linux-nfs:
        NFSv4.x: hide array-bounds warning
        NFSv4.1: Keep a reference on lock states while checking
        NFSv4.1: Handle NFS4ERR_OLD_STATEID in nfs4_reclaim_open_state
        NFSv4: Don't call close if the open stateid has already been cleared
        NFSv4: Fix CLOSE races with OPEN
        NFSv4.1: Fix a regression in DELEGRETURN
      10b9dd56
    • Linus Torvalds's avatar
      Merge branch 'stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile · 4d92c8d0
      Linus Torvalds authored
      Pull arch/tile bugfix from Chris Metcalf:
       "This fixes a bug that causes reboots after 208 days of uptime :-)"
      
      * 'stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile:
        tile: avoid using clocksource_cyc2ns with absolute cycle count
      4d92c8d0
    • Chris Metcalf's avatar
      tile: avoid using clocksource_cyc2ns with absolute cycle count · e658a6f1
      Chris Metcalf authored
      For large values of "mult" and long uptimes, the intermediate
      result of "cycles * mult" can overflow 64 bits.  For example,
      the tile platform calls clocksource_cyc2ns with a 1.2 GHz clock;
      we have mult = 853, and after 208.5 days, we overflow 64 bits.
      
      Since clocksource_cyc2ns() is intended to be used for relative
      cycle counts, not absolute cycle counts, performance is more
      importance than accepting a wider range of cycle values.  So,
      just use mult_frac() directly in tile's sched_clock().
      
      Commit 4cecf6d4 ("sched, x86: Avoid unnecessary overflow
      in sched_clock") by Salman Qazi results in essentially the same
      generated code for x86 as this change does for tile.  In fact,
      a follow-on change by Salman introduced mult_frac() and switched
      to using it, so the C code was largely identical at that point too.
      
      Peter Zijlstra then added mul_u64_u32_shr() and switched x86
      to use it.  This is, in principle, better; by optimizing the
      64x64->64 multiplies to be 32x32->64 multiplies we can potentially
      save some time.  However, the compiler piplines the 64x64->64
      multiplies pretty well, and the conditional branch in the generic
      mul_u64_u32_shr() causes some bubbles in execution, with the
      result that it's pretty much a wash.  If tilegx provided its own
      implementation of mul_u64_u32_shr() without the conditional branch,
      we could potentially save 3 cycles, but that seems like small gain
      for a fair amount of additional build scaffolding; no other platform
      currently provides a mul_u64_u32_shr() override, and tile doesn't
      currently have an <asm/div64.h> header to put the override in.
      
      Additionally, gcc currently has an optimization bug that prevents
      it from recognizing the opportunity to use a 32x32->64 multiply,
      and so the result would be no better than the existing mult_frac()
      until such time as the compiler is fixed.
      
      For now, just using mult_frac() seems like the right answer.
      
      Cc: stable@kernel.org [v3.4+]
      Signed-off-by: default avatarChris Metcalf <cmetcalf@mellanox.com>
      e658a6f1
    • Peter Wu's avatar
      drm/radeon: fix power state when port pm is unavailable (v2) · d3ac31f3
      Peter Wu authored
      When PCIe port PM is not enabled (system BIOS is pre-2015 or the
      pcie_port_pm=off parameter is set), legacy ATPX PM should still be
      marked as supported. Otherwise the GPU can fail to power on after
      runtime suspend. This affected a Dell Inspiron 5548.
      
      Ideally the BIOS date in the PCI core is lowered to 2013 (the first year
      where hybrid graphics platforms using power resources was introduced),
      but that seems more risky at this point and would not solve the
      pcie_port_pm=off issue.
      
      v2: agd: fix typo
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98505Signed-off-by: default avatarPeter Wu <peter@lekensteyn.nl>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: <stable@vger.kernel.org> # 4.8+
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      d3ac31f3
    • Peter Wu's avatar
      drm/amdgpu: fix power state when port pm is unavailable · 1db4496f
      Peter Wu authored
      When PCIe port PM is not enabled (system BIOS is pre-2015 or the
      pcie_port_pm=off parameter is set), legacy ATPX PM should still be
      marked as supported. Otherwise the GPU can fail to power on after
      runtime suspend. This affected a Dell Inspiron 5548.
      
      Ideally the BIOS date in the PCI core is lowered to 2013 (the first year
      where hybrid graphics platforms using power resources was introduced),
      but that seems more risky at this point and would not solve the
      pcie_port_pm=off issue.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98505Reported-and-tested-by: default avatarNayan Deshmukh <nayan26deshmukh@gmail.com>
      Signed-off-by: default avatarPeter Wu <peter@lekensteyn.nl>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: <stable@vger.kernel.org> # 4.8+
      Acked-by: default avatarChristian König <christian.koenig@amd.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      1db4496f
    • Song Hongyan's avatar
      HID: hid-sensor-hub: clear memory to avoid random data · d443a0aa
      Song Hongyan authored
      When user tried to read some fields like hysteresis from IIO sysfs on some
      systems, it fails. The reason is that this field is a byte field and caller
      of sensor_hub_get_feature() passes a buffer of 4 bytes. Here the function
      sensor_hub_get_feature() copies the single byte from the report to the
      caller buffer and returns "1" as the number of bytes copied. So caller
      can use the return value.
      
      But this is done by multiple callers, so if we just change the
      sensor_hub_get_feature so that caller buffer is initialized with 0s
      then we don't to change all functions.
      Signed-off-by: default avatarSong Hongyan <hongyan.song@intel.com>
      Acked-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      d443a0aa
    • Benjamin Tissoires's avatar
      HID: rmi: make transfer buffers DMA capable · 6dab07df
      Benjamin Tissoires authored
      Kernel v4.9 strictly enforces DMA capable buffers, so we need to remove
      buffers allocated on the stack.
      Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      6dab07df