1. 30 Jun, 2015 12 commits
    • Dan Williams's avatar
      block: fix ext_dev_lock lockdep report · f65addea
      Dan Williams authored
      commit 4d66e5e9 upstream.
      
       =================================
       [ INFO: inconsistent lock state ]
       4.1.0-rc7+ #217 Tainted: G           O
       ---------------------------------
       inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
       swapper/6/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
        (ext_devt_lock){+.?...}, at: [<ffffffff8143a60c>] blk_free_devt+0x3c/0x70
       {SOFTIRQ-ON-W} state was registered at:
         [<ffffffff810bf6b1>] __lock_acquire+0x461/0x1e70
         [<ffffffff810c1947>] lock_acquire+0xb7/0x290
         [<ffffffff818ac3a8>] _raw_spin_lock+0x38/0x50
         [<ffffffff8143a07d>] blk_alloc_devt+0x6d/0xd0  <-- take the lock in process context
      [..]
        [<ffffffff810bf64e>] __lock_acquire+0x3fe/0x1e70
        [<ffffffff810c00ad>] ? __lock_acquire+0xe5d/0x1e70
        [<ffffffff810c1947>] lock_acquire+0xb7/0x290
        [<ffffffff8143a60c>] ? blk_free_devt+0x3c/0x70
        [<ffffffff818ac3a8>] _raw_spin_lock+0x38/0x50
        [<ffffffff8143a60c>] ? blk_free_devt+0x3c/0x70
        [<ffffffff8143a60c>] blk_free_devt+0x3c/0x70    <-- take the lock in softirq
        [<ffffffff8143bfec>] part_release+0x1c/0x50
        [<ffffffff8158edf6>] device_release+0x36/0xb0
        [<ffffffff8145ac2b>] kobject_cleanup+0x7b/0x1a0
        [<ffffffff8145aad0>] kobject_put+0x30/0x70
        [<ffffffff8158f147>] put_device+0x17/0x20
        [<ffffffff8143c29c>] delete_partition_rcu_cb+0x16c/0x180
        [<ffffffff8143c130>] ? read_dev_sector+0xa0/0xa0
        [<ffffffff810e0e0f>] rcu_process_callbacks+0x2ff/0xa90
        [<ffffffff810e0dcf>] ? rcu_process_callbacks+0x2bf/0xa90
        [<ffffffff81067e2e>] __do_softirq+0xde/0x600
      
      Neil sees this in his tests and it also triggers on pmem driver unbind
      for the libnvdimm tests.  This fix is on top of an initial fix by Keith
      for incorrect usage of mutex_lock() in this path: 2da78092 "block:
      Fix dev_t minor allocation lifetime".  Both this and 2da78092 are
      candidates for -stable.
      
      Fixes: 2da78092 ("block: Fix dev_t minor allocation lifetime")
      Cc: Keith Busch <keith.busch@intel.com>
      Reported-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f65addea
    • Wang Long's avatar
      ring-buffer-benchmark: Fix the wrong sched_priority of producer · 52db637c
      Wang Long authored
      commit 10802932 upstream.
      
      The producer should be used producer_fifo as its sched_priority,
      so correct it.
      
      Link: http://lkml.kernel.org/r/1433923957-67842-1-git-send-email-long.wanglong@huawei.comSigned-off-by: default avatarWang Long <long.wanglong@huawei.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      52db637c
    • Gu Zheng's avatar
      mm/memory_hotplug.c: set zone->wait_table to null after freeing it · 3237299a
      Gu Zheng authored
      commit 85bd8399 upstream.
      
      Izumi found the following oops when hot re-adding a node:
      
          BUG: unable to handle kernel paging request at ffffc90008963690
          IP: __wake_up_bit+0x20/0x70
          Oops: 0000 [#1] SMP
          CPU: 68 PID: 1237 Comm: rs:main Q:Reg Not tainted 4.1.0-rc5 #80
          Hardware name: FUJITSU PRIMEQUEST2800E/SB, BIOS PRIMEQUEST 2000 Series BIOS Version 1.87 04/28/2015
          task: ffff880838df8000 ti: ffff880017b94000 task.ti: ffff880017b94000
          RIP: 0010:[<ffffffff810dff80>]  [<ffffffff810dff80>] __wake_up_bit+0x20/0x70
          RSP: 0018:ffff880017b97be8  EFLAGS: 00010246
          RAX: ffffc90008963690 RBX: 00000000003c0000 RCX: 000000000000a4c9
          RDX: 0000000000000000 RSI: ffffea101bffd500 RDI: ffffc90008963648
          RBP: ffff880017b97c08 R08: 0000000002000020 R09: 0000000000000000
          R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a0797c73800
          R13: ffffea101bffd500 R14: 0000000000000001 R15: 00000000003c0000
          FS:  00007fcc7ffff700(0000) GS:ffff880874800000(0000) knlGS:0000000000000000
          CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
          CR2: ffffc90008963690 CR3: 0000000836761000 CR4: 00000000001407e0
          Call Trace:
            unlock_page+0x6d/0x70
            generic_write_end+0x53/0xb0
            xfs_vm_write_end+0x29/0x80 [xfs]
            generic_perform_write+0x10a/0x1e0
            xfs_file_buffered_aio_write+0x14d/0x3e0 [xfs]
            xfs_file_write_iter+0x79/0x120 [xfs]
            __vfs_write+0xd4/0x110
            vfs_write+0xac/0x1c0
            SyS_write+0x58/0xd0
            system_call_fastpath+0x12/0x76
          Code: 5d c3 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 45 f8 31 c0 48 8d 47 48 <48> 39 47 48 48 c7 45 e8 00 00 00 00 48 c7 45 f0 00 00 00 00 48
          RIP  [<ffffffff810dff80>] __wake_up_bit+0x20/0x70
           RSP <ffff880017b97be8>
          CR2: ffffc90008963690
      
      Reproduce method (re-add a node)::
        Hot-add nodeA --> remove nodeA --> hot-add nodeA (panic)
      
      This seems an use-after-free problem, and the root cause is
      zone->wait_table was not set to *NULL* after free it in
      try_offline_node.
      
      When hot re-add a node, we will reuse the pgdat of it, so does the zone
      struct, and when add pages to the target zone, it will init the zone
      first (including the wait_table) if the zone is not initialized.  The
      judgement of zone initialized is based on zone->wait_table:
      
      	static inline bool zone_is_initialized(struct zone *zone)
      	{
      		return !!zone->wait_table;
      	}
      
      so if we do not set the zone->wait_table to *NULL* after free it, the
      memory hotplug routine will skip the init of new zone when hot re-add
      the node, and the wait_table still points to the freed memory, then we
      will access the invalid address when trying to wake up the waiting
      people after the i/o operation with the page is done, such as mentioned
      above.
      Signed-off-by: default avatarGu Zheng <guz.fnst@cn.fujitsu.com>
      Reported-by: default avatarTaku Izumi <izumi.taku@jp.fujitsu.com>
      Reviewed by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Tang Chen <tangchen@cn.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      3237299a
    • Johannes Berg's avatar
      cfg80211: wext: clear sinfo struct before calling driver · d42737ac
      Johannes Berg authored
      commit 9c5a18a3 upstream.
      
      Until recently, mac80211 overwrote all the statistics it could
      provide when getting called, but it now relies on the struct
      having been zeroed by the caller. This was always the case in
      nl80211, but wext used a static struct which could even cause
      values from one device leak to another.
      
      Using a static struct is OK (as even documented in a comment)
      since the whole usage of this function and its return value is
      always locked under RTNL. Not clearing the struct for calling
      the driver has always been wrong though, since drivers were
      free to only fill values they could report, so calling this
      for one device and then for another would always have leaked
      values from one to the other.
      
      Fix this by initializing the structure in question before the
      driver method call.
      
      This fixes https://bugzilla.kernel.org/show_bug.cgi?id=99691Reported-by: default avatarGerrit Renker <gerrit@erg.abdn.ac.uk>
      Reported-by: default avatarAlexander Kaltsas <alexkaltsas@gmail.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d42737ac
    • Jani Nikula's avatar
      drm/i915: Fix DDC probe for passive adapters · 10e6cc7b
      Jani Nikula authored
      commit 3f5f1554 upstream.
      
      Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI
      devices, as they do not have a sink device in them to respond to any AUX
      traffic. When probing these dongles over the DDC, sometimes they will
      NAK the first attempt even though the transaction is valid and they
      support the DDC protocol. The retry loop inside of
      drm_do_probe_ddc_edid() would normally catch this case and try the
      transaction again, resulting in success.
      
      That, however, was thwarted by the fix for [1]:
      
      commit 9292f37e
      Author: Eugeni Dodonov <eugeni.dodonov@intel.com>
      Date:   Thu Jan 5 09:34:28 2012 -0200
      
          drm: give up on edid retries when i2c bus is not responding
      
      This added code to exit immediately if the return code from the
      i2c_transfer function was -ENXIO in order to reduce the amount of time
      spent in waiting for unresponsive or disconnected devices. That was
      possible because the underlying i2c bit banging algorithm had retries of
      its own (which, of course, were part of the reason for the bug the
      commit fixes).
      
      Since its introduction in
      
      commit f899fc64
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Tue Jul 20 15:44:45 2010 -0700
      
          drm/i915: use GMBUS to manage i2c links
      
      we've been flipping back and forth enabling the GMBUS transfers, but
      we've settled since then. The GMBUS implementation does not do any
      retries, however, bailing out of the drm_do_probe_ddc_edid() retry loop
      on first encounter of -ENXIO. This, combined with Eugeni's commit, broke
      the retry on -ENXIO.
      
      Retry GMBUS once on -ENXIO on first message to mitigate the issues with
      passive adapters.
      
      This patch is based on the work, and commit message, by Todd Previte
      <tprevite@gmail.com>.
      
      [1] https://bugs.freedesktop.org/show_bug.cgi?id=41059
      
      v2: Don't retry if using bit banging.
      
      v3: Move retry within gmbux_xfer, retry only on first message.
      
      v4: Initialize GMBUS0 on retry (Ville).
      
      v5: Take index reads into account (Ville).
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85924
      Cc: Todd Previte <tprevite@gmail.com>
      Tested-by: Oliver Grafe <oliver.grafe@ge.com> (v2)
      Tested-by: default avatarJim Bride <jim.bride@linux.intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      10e6cc7b
    • Peter Hutterer's avatar
    • Aaro Koskinen's avatar
      pata_octeon_cf: fix broken build · 3a9d9b48
      Aaro Koskinen authored
      commit 4710f2fa upstream.
      
      MODULE_DEVICE_TABLE is referring to wrong driver's table and breaks the
      build. Fix that.
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@nokia.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      3a9d9b48
    • Axel Lin's avatar
      irqchip: sunxi-nmi: Fix off-by-one error in irq iterator · cb88e31d
      Axel Lin authored
      commit febe0696 upstream.
      
      Fixes: 6058bb36 'ARM: sun7i/sun6i: irqchip: Add irqchip driver for NMI controller'
      Signed-off-by: default avatarAxel Lin <axel.lin@ingics.com>
      Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
      Cc: Carlo Caione <carlo@caione.org>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Link: http://lkml.kernel.org/r/1433684009.9134.1.camel@ingics.comSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      cb88e31d
    • Jiang Liu's avatar
      virtio_pci: Clear stale cpumask when setting irq affinity · 9ca6d164
      Jiang Liu authored
      commit 210d150e upstream.
      
      The cpumask vp_dev->msix_affinity_masks[info->msix_vector] may contain
      staled information when vp_set_vq_affinity() gets called, so clear it
      before setting the new cpu bit mask.
      Signed-off-by: default avatarJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      [ luis: backported to 3.16:
        - file rename: virtio_pci_common.c -> virtio_pci.c ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9ca6d164
    • Nadav Haklai's avatar
      ata: ahci_mvebu: Fix wrongly set base address for the MBus window setting · a782ad86
      Nadav Haklai authored
      commit e96998fc upstream.
      
      According to the Armada 38x datasheet, the window base address
      registers value is set in bits [31:4] of the register and corresponds
      to the transaction address bits [47:20].
      
      Therefore, the 32bit base address value should be shifted right by
      20bits and left by 4bits, resulting in 16 bit shift right.
      
      The bug as not been noticed yet because if the memory available on
      the platform is less than 2GB, then the base address is zero.
      
      [gregory.clement@free-electrons.com: add extra-explanation]
      
      Fixes: a3464ed2 (ata: ahci_mvebu: new driver for Marvell Armada 380
      AHCI interfaces)
      Signed-off-by: default avatarNadav Haklai <nadavh@marvell.com>
      Reviewed-by: default avatarOmri Itach <omrii@marvell.com>
      Signed-off-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a782ad86
    • David Woodhouse's avatar
      iommu/vt-d: Fix passthrough mode with translation-disabled devices · 359effb0
      David Woodhouse authored
      commit 4ed6a540 upstream.
      
      When we use 'intel_iommu=igfx_off' to disable translation for the
      graphics, and when we discover that the BIOS has misconfigured the DMAR
      setup for I/OAT, we use a special DUMMY_DEVICE_DOMAIN_INFO value in
      dev->archdata.iommu to indicate that translation is disabled.
      
      With passthrough mode, we were attempting to dereference that as a
      normal pointer to a struct device_domain_info when setting up an
      identity mapping for the affected device.
      
      This fixes the problem by making device_to_iommu() explicitly check for
      the special value and indicate that no IOMMU was found to handle the
      devices in question.
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      359effb0
    • David Woodhouse's avatar
      iommu/vt-d: Allow RMRR on graphics devices too · f4d657ec
      David Woodhouse authored
      commit 18436afd upstream.
      
      Commit c875d2c1 ("iommu/vt-d: Exclude devices using RMRRs from IOMMU API
      domains") prevents certain options for devices with RMRRs. This even
      prevents those devices from getting a 1:1 mapping with 'iommu=pt',
      because we don't have the code to handle *preserving* the RMRR regions
      when moving the device between domains.
      
      There's already an exclusion for USB devices, because we know the only
      reason for RMRRs there is a misguided desire to keep legacy
      keyboard/mouse emulation running in some theoretical OS which doesn't
      have support for USB in its own right... but which *does* enable the
      IOMMU.
      
      Add an exclusion for graphics devices too, so that 'iommu=pt' works
      there. We should be able to successfully assign graphics devices to
      guests too, as long as the initial handling of stolen memory is
      reconfigured appropriately. This has certainly worked in the past.
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f4d657ec
  2. 17 Jun, 2015 4 commits
  3. 16 Jun, 2015 1 commit
  4. 12 Jun, 2015 15 commits
  5. 11 Jun, 2015 8 commits