1. 09 Sep, 2016 15 commits
  2. 08 Sep, 2016 15 commits
    • Jean Delvare's avatar
      cpufreq-stats: Minor documentation fix · 3732b30a
      Jean Delvare authored
      The cpufreq-stats code can no longer be built as a module, so it now
      appears with square brackets in menuconfig.
      Signed-off-by: default avatarJean Delvare <jdelvare@suse.de>
      Fixes: 1aefc75b (cpufreq: stats: Make the stats code non-modular)
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3732b30a
    • Linus Torvalds's avatar
      Merge tag 'ceph-for-4.8-rc6' of git://github.com/ceph/ceph-client · 711bef65
      Linus Torvalds authored
      Pull ceph fix from Ilya Dryomov:
       "A fix for a 4.7 performance regression, caused by a typo in an if
        condition"
      
      * tag 'ceph-for-4.8-rc6' of git://github.com/ceph/ceph-client:
        ceph: do not modify fi->frag in need_reset_readdir()
      711bef65
    • Linus Torvalds's avatar
      Merge branch 'dmi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging · acdfffb5
      Linus Torvalds authored
      Pull dmi fix from Jean Delvare.
      
      * 'dmi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging:
        dmi-id: don't free dev structure after calling device_register
      acdfffb5
    • Linus Torvalds's avatar
      Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · e8b3b45d
      Linus Torvalds authored
      Pull ARM SoC fixes from Olof Johansson:
       "This is a slightly larger batch of fixes that we've been sitting on a
        few -rcs.  Most of them are simple oneliners, but there are two sets
        that are slightly larger and worth pointing out:
      
         - A set of patches to OMAP to deal with hwmod for RTC on am33xx
           (beaglebone SoC, among others).  It's the only clock that ever has
           a valid offset of 0, so a new flag needed introduction once this
           problem was discovered.
      
         - A collection of CCI fixes for performance counters discovered once
           people started using it on X-Gene CPUs"
      
      * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (37 commits)
        arm-cci: pmu: Fix typo in event name
        Revert "ARM: tegra: fix erroneous address in dts"
        ARM: dts: imx6qdl: Fix SPDIF regression
        ARM: imx6: add missing BM_CLPCR_BYPASS_PMIC_READY setting for imx6sx
        ARM: dts: imx7d-sdb: fix ti,x-plate-ohms property name
        ARM: dts: kirkwood: Fix PCIe label on OpenRD
        ARM: kirkwood: ib62x0: fix size of u-boot environment partition
        bus: arm-ccn: make event groups reliable
        bus: arm-ccn: fix hrtimer registration
        bus: arm-ccn: fix PMU interrupt flags
        ARM: tegra: Correct polarity for Tegra114 PMIC interrupt
        MAINTAINERS: add tree entry for ARM/UniPhier architecture
        ARM: sun5i: Fix typo in trip point temperature
        MAINTAINERS: Switch to kernel.org account for Krzysztof Kozlowski
        ARM: imx6ul: populates platform device at .init_machine
        bus: arm-ccn: Add missing event attribute exclusions for host/guest
        bus: arm-ccn: Correct required arguments for XP PMU events
        bus: arm-ccn: Fix XP watchpoint settings bitmask
        bus: arm-ccn: Do not attempt to configure XPs for cycle counter
        bus: arm-ccn: Fix PMU handling of MN
        ...
      e8b3b45d
    • Takashi Iwai's avatar
      ALSA: rawmidi: Fix possible deadlock with virmidi registration · 816f318b
      Takashi Iwai authored
      When a seq-virmidi driver is initialized, it registers a rawmidi
      instance with its callback to create an associated seq kernel client.
      Currently it's done throughly in rawmidi's register_mutex context.
      Recently it was found that this may lead to a deadlock another rawmidi
      device that is being attached with the sequencer is accessed, as both
      open with the same register_mutex.  This was actually triggered by
      syzkaller, as Dmitry Vyukov reported:
      
      ======================================================
       [ INFO: possible circular locking dependency detected ]
       4.8.0-rc1+ #11 Not tainted
       -------------------------------------------------------
       syz-executor/7154 is trying to acquire lock:
        (register_mutex#5){+.+.+.}, at: [<ffffffff84fd6d4b>] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341
      
       but task is already holding lock:
        (&grp->list_mutex){++++.+}, at: [<ffffffff850138bb>] check_and_subscribe_port+0x5b/0x5c0 sound/core/seq/seq_ports.c:495
      
       which lock already depends on the new lock.
      
       the existing dependency chain (in reverse order) is:
      
       -> #1 (&grp->list_mutex){++++.+}:
          [<ffffffff8147a3a8>] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746
          [<ffffffff863f6199>] down_read+0x49/0xc0 kernel/locking/rwsem.c:22
          [<     inline     >] deliver_to_subscribers sound/core/seq/seq_clientmgr.c:681
          [<ffffffff85005c5e>] snd_seq_deliver_event+0x35e/0x890 sound/core/seq/seq_clientmgr.c:822
          [<ffffffff85006e96>] > snd_seq_kernel_client_dispatch+0x126/0x170 sound/core/seq/seq_clientmgr.c:2418
          [<ffffffff85012c52>] snd_seq_system_broadcast+0xb2/0xf0 sound/core/seq/seq_system.c:101
          [<ffffffff84fff70a>] snd_seq_create_kernel_client+0x24a/0x330 sound/core/seq/seq_clientmgr.c:2297
          [<     inline     >] snd_virmidi_dev_attach_seq sound/core/seq/seq_virmidi.c:383
          [<ffffffff8502d29f>] snd_virmidi_dev_register+0x29f/0x750 sound/core/seq/seq_virmidi.c:450
          [<ffffffff84fd208c>] snd_rawmidi_dev_register+0x30c/0xd40 sound/core/rawmidi.c:1645
          [<ffffffff84f816d3>] __snd_device_register.part.0+0x63/0xc0 sound/core/device.c:164
          [<     inline     >] __snd_device_register sound/core/device.c:162
          [<ffffffff84f8235d>] snd_device_register_all+0xad/0x110 sound/core/device.c:212
          [<ffffffff84f7546f>] snd_card_register+0xef/0x6c0 sound/core/init.c:749
          [<ffffffff85040b7f>] snd_virmidi_probe+0x3ef/0x590 sound/drivers/virmidi.c:123
          [<ffffffff833ebf7b>] platform_drv_probe+0x8b/0x170 drivers/base/platform.c:564
          ......
      
       -> #0 (register_mutex#5){+.+.+.}:
          [<     inline     >] check_prev_add kernel/locking/lockdep.c:1829
          [<     inline     >] check_prevs_add kernel/locking/lockdep.c:1939
          [<     inline     >] validate_chain kernel/locking/lockdep.c:2266
          [<ffffffff814791f4>] __lock_acquire+0x4d44/0x4d80 kernel/locking/lockdep.c:3335
          [<ffffffff8147a3a8>] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746
          [<     inline     >] __mutex_lock_common kernel/locking/mutex.c:521
          [<ffffffff863f0ef1>] mutex_lock_nested+0xb1/0xa20 kernel/locking/mutex.c:621
          [<ffffffff84fd6d4b>] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341
          [<ffffffff8502e7c7>] midisynth_subscribe+0xf7/0x350 sound/core/seq/seq_midi.c:188
          [<     inline     >] subscribe_port sound/core/seq/seq_ports.c:427
          [<ffffffff85013cc7>] check_and_subscribe_port+0x467/0x5c0 sound/core/seq/seq_ports.c:510
          [<ffffffff85015da9>] snd_seq_port_connect+0x2c9/0x500 sound/core/seq/seq_ports.c:579
          [<ffffffff850079b8>] snd_seq_ioctl_subscribe_port+0x1d8/0x2b0 sound/core/seq/seq_clientmgr.c:1480
          [<ffffffff84ffe9e4>] snd_seq_do_ioctl+0x184/0x1e0 sound/core/seq/seq_clientmgr.c:2225
          [<ffffffff84ffeae8>] snd_seq_kernel_client_ctl+0xa8/0x110 sound/core/seq/seq_clientmgr.c:2440
          [<ffffffff85027664>] snd_seq_oss_midi_open+0x3b4/0x610 sound/core/seq/oss/seq_oss_midi.c:375
          [<ffffffff85023d67>] snd_seq_oss_synth_setup_midi+0x107/0x4c0 sound/core/seq/oss/seq_oss_synth.c:281
          [<ffffffff8501b0a8>] snd_seq_oss_open+0x748/0x8d0 sound/core/seq/oss/seq_oss_init.c:274
          [<ffffffff85019d8a>] odev_open+0x6a/0x90 sound/core/seq/oss/seq_oss.c:138
          [<ffffffff84f7040f>] soundcore_open+0x30f/0x640 sound/sound_core.c:639
          ......
      
       other info that might help us debug this:
      
       Possible unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock(&grp->list_mutex);
                                      lock(register_mutex#5);
                                      lock(&grp->list_mutex);
         lock(register_mutex#5);
      
       *** DEADLOCK ***
      ======================================================
      
      The fix is to simply move the registration parts in
      snd_rawmidi_dev_register() to the outside of the register_mutex lock.
      The lock is needed only to manage the linked list, and it's not
      necessarily to cover the whole initialization process.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      816f318b
    • Takashi Iwai's avatar
      ALSA: timer: Fix zero-division by continue of uninitialized instance · 9f8a7658
      Takashi Iwai authored
      When a user timer instance is continued without the explicit start
      beforehand, the system gets eventually zero-division error like:
      
        divide error: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
        CPU: 1 PID: 27320 Comm: syz-executor Not tainted 4.8.0-rc3-next-20160825+ #8
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
         task: ffff88003c9b2280 task.stack: ffff880027280000
         RIP: 0010:[<ffffffff858e1a6c>]  [<     inline     >] ktime_divns include/linux/ktime.h:195
         RIP: 0010:[<ffffffff858e1a6c>]  [<ffffffff858e1a6c>] snd_hrtimer_callback+0x1bc/0x3c0 sound/core/hrtimer.c:62
        Call Trace:
         <IRQ>
         [<     inline     >] __run_hrtimer kernel/time/hrtimer.c:1238
         [<ffffffff81504335>] __hrtimer_run_queues+0x325/0xe70 kernel/time/hrtimer.c:1302
         [<ffffffff81506ceb>] hrtimer_interrupt+0x18b/0x420 kernel/time/hrtimer.c:1336
         [<ffffffff8126d8df>] local_apic_timer_interrupt+0x6f/0xe0 arch/x86/kernel/apic/apic.c:933
         [<ffffffff86e13056>] smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:957
         [<ffffffff86e1210c>] apic_timer_interrupt+0x8c/0xa0 arch/x86/entry/entry_64.S:487
         <EOI>
         .....
      
      Although a similar issue was spotted and a fix patch was merged in
      commit [6b760bb2: ALSA: timer: fix division by zero after
      SNDRV_TIMER_IOCTL_CONTINUE], it seems covering only a part of
      iceberg.
      
      In this patch, we fix the issue a bit more drastically.  Basically the
      continue of an uninitialized timer is supposed to be a fresh start, so
      we do it for user timers.  For the direct snd_timer_continue() call,
      there is no way to pass the initial tick value, so we kick out for the
      uninitialized case.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      9f8a7658
    • Allen Hung's avatar
      dmi-id: don't free dev structure after calling device_register · 9b41b92b
      Allen Hung authored
      dmi_dev is freed in error exit code but, according to the document
      of device_register, it should never directly free device structure
      after calling this function, even if it returned an error! Use
      put_device() instead.
      Signed-off-by: default avatarAllen Hung <allen_hung@dell.com>
      Signed-off-by: default avatarJean Delvare <jdelvare@suse.de>
      9b41b92b
    • Linus Torvalds's avatar
      Merge branch 'for-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux · d71f0586
      Linus Torvalds authored
      Pull thermal fix from Zhang Rui:
       "Only one patch this time, which fixes a crash in rcar_thermal driver.
        From Dirk Behme"
      
      * 'for-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux:
        thermal: rcar_thermal: Fix priv->zone error handling
      d71f0586
    • Olof Johansson's avatar
      Merge tag 'sunxi-fixes-for-4.8' of... · 95390e32
      Olof Johansson authored
      Merge tag 'sunxi-fixes-for-4.8' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into fixes
      
      Allwinner fixes for 4.8
      
      A single patch fixing a typo in the temperature trip points in the A13
      DTSI.
      
      * tag 'sunxi-fixes-for-4.8' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux:
        ARM: sun5i: Fix typo in trip point temperature
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      95390e32
    • Suzuki K Poulose's avatar
      arm-cci: pmu: Fix typo in event name · 1d3ef9c2
      Suzuki K Poulose authored
      For one of the CCI events exposed under sysfs, "snoop" was typo'd as
      "snopp". Correct this such that users see the expected event name when
      enumerating events via sysfs.
      
      Cc: arm@kernel.org
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      1d3ef9c2
    • Olof Johansson's avatar
      Merge tag 'imx-fixes-4.8-2' of... · 28fa9917
      Olof Johansson authored
      Merge tag 'imx-fixes-4.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into fixes
      
      i.MX fixes for 4.8, 2nd round:
       - Fix misspelled "ti,x-plate-ohms" property name of touchscreen
         controller for imx7d-sdb DTS.
       - Add missing BM_CLPCR_BYPASS_PMIC_READY setting for i.MX6SX to get
         suspend/resume work properly.
       - Fix SPDIF regression on imx6qdl which caused by a clock update on
         spdif device node.
      
      * tag 'imx-fixes-4.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
        ARM: dts: imx6qdl: Fix SPDIF regression
        ARM: imx6: add missing BM_CLPCR_BYPASS_PMIC_READY setting for imx6sx
        ARM: dts: imx7d-sdb: fix ti,x-plate-ohms property name
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      28fa9917
    • Olof Johansson's avatar
      Revert "ARM: tegra: fix erroneous address in dts" · d8b795f5
      Olof Johansson authored
      This reverts commit b5c86b74.
      
      This is no longer needed due to other changes going into 4.8 to rename
      the unit addresses on a large number of device nodes. So it was picked up
      for v4.8-rc1 in error.
      Reported-by: default avatarRalf Ramsauer <ralf@ramses-pyramidenbau.de>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      d8b795f5
    • Paul Mackerras's avatar
      powerpc/mm: Don't alias user region to other regions below PAGE_OFFSET · f077aaf0
      Paul Mackerras authored
      In commit c60ac569 ("powerpc: Update kernel VSID range", 2013-03-13)
      we lost a check on the region number (the top four bits of the effective
      address) for addresses below PAGE_OFFSET.  That commit replaced a check
      that the top 18 bits were all zero with a check that bits 46 - 59 were
      zero (performed for all addresses, not just user addresses).
      
      This means that userspace can access an address like 0x1000_0xxx_xxxx_xxxx
      and we will insert a valid SLB entry for it.  The VSID used will be the
      same as if the top 4 bits were 0, but the page size will be some random
      value obtained by indexing beyond the end of the mm_ctx_high_slices_psize
      array in the paca.  If that page size is the same as would be used for
      region 0, then userspace just has an alias of the region 0 space.  If the
      page size is different, then no HPTE will be found for the access, and
      the process will get a SIGSEGV (since hash_page_mm() will refuse to create
      a HPTE for the bogus address).
      
      The access beyond the end of the mm_ctx_high_slices_psize can be at most
      5.5MB past the array, and so will be in RAM somewhere.  Since the access
      is a load performed in real mode, it won't fault or crash the kernel.
      At most this bug could perhaps leak a little bit of information about
      blocks of 32 bytes of memory located at offsets of i * 512kB past the
      paca->mm_ctx_high_slices_psize array, for 1 <= i <= 11.
      
      Fixes: c60ac569 ("powerpc: Update kernel VSID range")
      Cc: stable@vger.kernel.org # v3.9+
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Reviewed-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      f077aaf0
    • Christophe Leroy's avatar
      powerpc/32: Fix again csum_partial_copy_generic() · 8540571e
      Christophe Leroy authored
      Commit 7aef4136 ("powerpc32: rewrite csum_partial_copy_generic()
      based on copy_tofrom_user()") introduced a bug when destination address
      is odd and len is lower than cacheline size.
      
      In that case the resulting csum value doesn't have to be rotated one
      byte because the cache-aligned copy part is skipped so no alignment
      is performed.
      
      Fixes: 7aef4136 ("powerpc32: rewrite csum_partial_copy_generic() based on copy_tofrom_user()")
      Cc: stable@vger.kernel.org # v4.6+
      Reported-by: default avatarAlessio Igor Bogani <alessio.bogani@elettra.eu>
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Tested-by: default avatarAlessio Igor Bogani <alessio.bogani@elettra.eu>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      8540571e
    • Gavin Shan's avatar
      powerpc/powernv: Fix corrupted PE allocation bitmap on releasing PE · caa58f80
      Gavin Shan authored
      In pnv_ioda_free_pe(), the PE object (including the associated PE
      number) is cleared before resetting the corresponding bit in the
      PE allocation bitmap. It means PE#0 is always released to the bitmap
      wrongly.
      
      This fixes above issue by caching the PE number before the PE object
      is cleared.
      
      Fixes: 1e916772 ("powerpc/powernv: Use PE instead of number during setup and release"
      Cc: stable@vger.kernel.org # v4.7+
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      caa58f80
  3. 07 Sep, 2016 10 commits