1. 20 Oct, 2017 2 commits
    • Thierry Reding's avatar
      gpu: host1x: syncpt: Request syncpoints per client · 617dd7cc
      Thierry Reding authored
      Rather than request syncpoints for a struct device *, request them for a
      struct host1x_client *. This is important because subsequent patches are
      going to break the assumption that host1x will always be the parent for
      devices requesting a syncpoint. It's also a more natural choice because
      host1x clients are really the only ones that will know how to deal with
      syncpoints.
      
      Note that host1x clients are always guaranteed to be children of host1x,
      regardless of their location in the device tree.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      617dd7cc
    • Thierry Reding's avatar
      gpu: host1x: Use of_device_get_match_data() · 6a341fdf
      Thierry Reding authored
      Avoid some boilerplate by calling of_device_get_match_data() instead of
      open-coding the equivalent in the driver.
      
      While at it, shuffle around some code to avoid unnecessary local
      variables.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      6a341fdf
  2. 28 Sep, 2017 7 commits
  3. 27 Sep, 2017 14 commits
  4. 26 Sep, 2017 2 commits
  5. 25 Sep, 2017 15 commits
    • Nicolai Stange's avatar
      PCI: Fix race condition with driver_override · 9561475d
      Nicolai Stange authored
      The driver_override implementation is susceptible to a race condition when
      different threads are reading vs. storing a different driver override.  Add
      locking to avoid the race condition.
      
      This is in close analogy to commit 62655397 ("driver core: platform:
      fix race condition with driver_override") from Adrian Salido.
      
      Fixes: 782a985d ("PCI: Introduce new device binding path using pci_dev.driver_override")
      Signed-off-by: default avatarNicolai Stange <nstange@suse.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: stable@vger.kernel.org	# v3.16+
      9561475d
    • Suniel Mahesh's avatar
      cpufreq: dt: Fix sysfs duplicate filename creation for platform-device · d477bf3a
      Suniel Mahesh authored
      ti-cpufreq and cpufreq-dt-platdev drivers are registering platform-device
      with same name "cpufreq-dt" using platform_device_register_*() routines.
      This is leading to build warnings appended below.
      
      Providing hardware information to OPP framework along with the platform-
      device creation should be done by ti-cpufreq driver before cpufreq-dt
      driver comes into place.
      
      This patch add's TI am33xx, am43 and dra7 platforms (which use opp-v2
      property) to the blacklist of devices in cpufreq-dt-platform driver to
      avoid creating platform-device twice and remove build warnings.
      
      [    2.370167] ------------[ cut here ]------------
      [    2.375087] WARNING: CPU: 0 PID: 1 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x58/0x78
      [    2.383112] sysfs: cannot create duplicate filename '/devices/platform/cpufreq-dt'
      [    2.391219] Modules linked in:
      [    2.394506] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.13.0-next-20170912 #1
      [    2.402006] Hardware name: Generic AM33XX (Flattened Device Tree)
      [    2.408437] [<c0110a28>] (unwind_backtrace) from [<c010ca84>] (show_stack+0x10/0x14)
      [    2.416568] [<c010ca84>] (show_stack) from [<c0827d64>] (dump_stack+0xac/0xe0)
      [    2.424165] [<c0827d64>] (dump_stack) from [<c0137470>] (__warn+0xd8/0x104)
      [    2.431488] [<c0137470>] (__warn) from [<c01374d0>] (warn_slowpath_fmt+0x34/0x44)
      [    2.439351] [<c01374d0>] (warn_slowpath_fmt) from [<c03459d0>] (sysfs_warn_dup+0x58/0x78)
      [    2.447938] [<c03459d0>] (sysfs_warn_dup) from [<c0345ab8>] (sysfs_create_dir_ns+0x80/0x98)
      [    2.456719] [<c0345ab8>] (sysfs_create_dir_ns) from [<c082c554>] (kobject_add_internal+0x9c/0x2d4)
      [    2.466124] [<c082c554>] (kobject_add_internal) from [<c082c7d8>] (kobject_add+0x4c/0x9c)
      [    2.474712] [<c082c7d8>] (kobject_add) from [<c05803e4>] (device_add+0xcc/0x57c)
      [    2.482489] [<c05803e4>] (device_add) from [<c0584b74>] (platform_device_add+0x100/0x220)
      [    2.491085] [<c0584b74>] (platform_device_add) from [<c05855a8>] (platform_device_register_full+0xf4/0x118)
      [    2.501305] [<c05855a8>] (platform_device_register_full) from [<c067023c>] (ti_cpufreq_init+0x150/0x22c)
      [    2.511253] [<c067023c>] (ti_cpufreq_init) from [<c0101df4>] (do_one_initcall+0x3c/0x170)
      [    2.519838] [<c0101df4>] (do_one_initcall) from [<c0c00eb4>] (kernel_init_freeable+0x1fc/0x2c4)
      [    2.528974] [<c0c00eb4>] (kernel_init_freeable) from [<c083bcac>] (kernel_init+0x8/0x110)
      [    2.537565] [<c083bcac>] (kernel_init) from [<c0107d18>] (ret_from_fork+0x14/0x3c)
      [    2.545981] ---[ end trace 2fc00e213c13ab20 ]---
      [    2.551051] ------------[ cut here ]------------
      [    2.555931] WARNING: CPU: 0 PID: 1 at lib/kobject.c:240 kobject_add_internal+0x254/0x2d4
      [    2.564578] kobject_add_internal failed for cpufreq-dt with -EEXIST, don't try to register
      things with the same name in the same directory.
      [    2.577977] Modules linked in:
      [    2.581261] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W       4.13.0-next-20170912 #1
      [    2.590013] Hardware name: Generic AM33XX (Flattened Device Tree)
      [    2.596437] [<c0110a28>] (unwind_backtrace) from [<c010ca84>] (show_stack+0x10/0x14)
      [    2.604573] [<c010ca84>] (show_stack) from [<c0827d64>] (dump_stack+0xac/0xe0)
      [    2.612172] [<c0827d64>] (dump_stack) from [<c0137470>] (__warn+0xd8/0x104)
      [    2.619494] [<c0137470>] (__warn) from [<c01374d0>] (warn_slowpath_fmt+0x34/0x44)
      [    2.627362] [<c01374d0>] (warn_slowpath_fmt) from [<c082c70c>] (kobject_add_internal+0x254/0x2d4)
      [    2.636666] [<c082c70c>] (kobject_add_internal) from [<c082c7d8>] (kobject_add+0x4c/0x9c)
      [    2.645255] [<c082c7d8>] (kobject_add) from [<c05803e4>] (device_add+0xcc/0x57c)
      [    2.653027] [<c05803e4>] (device_add) from [<c0584b74>] (platform_device_add+0x100/0x220)
      [    2.661615] [<c0584b74>] (platform_device_add) from [<c05855a8>] (platform_device_register_full+0xf4/0x118)
      [    2.671833] [<c05855a8>] (platform_device_register_full) from [<c067023c>] (ti_cpufreq_init+0x150/0x22c)
      [    2.681779] [<c067023c>] (ti_cpufreq_init) from [<c0101df4>] (do_one_initcall+0x3c/0x170)
      [    2.690377] [<c0101df4>] (do_one_initcall) from [<c0c00eb4>] (kernel_init_freeable+0x1fc/0x2c4)
      [    2.699510] [<c0c00eb4>] (kernel_init_freeable) from [<c083bcac>] (kernel_init+0x8/0x110)
      [    2.708106] [<c083bcac>] (kernel_init) from [<c0107d18>] (ret_from_fork+0x14/0x3c)
      [    2.716217] ---[ end trace 2fc00e213c13ab21 ]---
      
      Fixes: edeec420 (cpufreq: dt-cpufreq: platdev Automatically create device with OPP v2)
      Signed-off-by: default avatarSuniel Mahesh <sunil.m@techveda.org>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d477bf3a
    • Hannes Reinecke's avatar
      scsi: scsi_transport_fc: set scsi_target_id upon rescan · 675195d0
      Hannes Reinecke authored
      When an rport is found in the bindings array there is no guarantee that
      it had been a target port, so we need to call fc_remote_port_rolechg()
      here to ensure the scsi_target_id is set correctly.  Otherwise the port
      will never be scanned.
      Signed-off-by: default avatarHannes Reinecke <hare@suse.com>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Tested-by: default avatarChad Dupuis <chad.dupuis@cavium.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      675195d0
    • Viresh Kumar's avatar
      PM / OPP: Call notifier without holding opp_table->lock · e4d8ae00
      Viresh Kumar authored
      The notifier callbacks may want to call some OPP helper routines which
      may try to take the same opp_table->lock again and cause a deadlock. One
      such usecase was reported by Chanwoo Choi, where calling
      dev_pm_opp_disable() leads us to the devfreq's OPP notifier handler,
      which further calls dev_pm_opp_find_freq_floor() and it deadlocks.
      
      We don't really need the opp_table->lock to be held across the notifier
      call though, all we want to make sure is that the 'opp' doesn't get
      freed while being used from within the notifier chain. We can do it with
      help of dev_pm_opp_get/put() as well. Let's do it.
      
      Cc: 4.11+ <stable@vger.kernel.org> # 4.11+
      Fixes: 5b650b38 "PM / OPP: Take kref from _find_opp_table()"
      Reported-by: default avatarChanwoo Choi <cw00.choi@samsung.com>
      Tested-by: default avatarChanwoo Choi <cw00.choi@samsung.com>
      Reviewed-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Reviewed-by: default avatarChanwoo Choi <cw00.choi@samsung.com>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e4d8ae00
    • Xin Long's avatar
      scsi: scsi_transport_iscsi: fix the issue that iscsi_if_rx doesn't parse nlmsg properly · c88f0e6b
      Xin Long authored
      ChunYu found a kernel crash by syzkaller:
      
      [  651.617875] kasan: CONFIG_KASAN_INLINE enabled
      [  651.618217] kasan: GPF could be caused by NULL-ptr deref or user memory access
      [  651.618731] general protection fault: 0000 [#1] SMP KASAN
      [  651.621543] CPU: 1 PID: 9539 Comm: scsi Not tainted 4.11.0.cov #32
      [  651.621938] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
      [  651.622309] task: ffff880117780000 task.stack: ffff8800a3188000
      [  651.622762] RIP: 0010:skb_release_data+0x26c/0x590
      [...]
      [  651.627260] Call Trace:
      [  651.629156]  skb_release_all+0x4f/0x60
      [  651.629450]  consume_skb+0x1a5/0x600
      [  651.630705]  netlink_unicast+0x505/0x720
      [  651.632345]  netlink_sendmsg+0xab2/0xe70
      [  651.633704]  sock_sendmsg+0xcf/0x110
      [  651.633942]  ___sys_sendmsg+0x833/0x980
      [  651.637117]  __sys_sendmsg+0xf3/0x240
      [  651.638820]  SyS_sendmsg+0x32/0x50
      [  651.639048]  entry_SYSCALL_64_fastpath+0x1f/0xc2
      
      It's caused by skb_shared_info at the end of sk_buff was overwritten by
      ISCSI_KEVENT_IF_ERROR when parsing nlmsg info from skb in iscsi_if_rx.
      
      During the loop if skb->len == nlh->nlmsg_len and both are sizeof(*nlh),
      ev = nlmsg_data(nlh) will acutally get skb_shinfo(SKB) instead and set a
      new value to skb_shinfo(SKB)->nr_frags by ev->type.
      
      This patch is to fix it by checking nlh->nlmsg_len properly there to
      avoid over accessing sk_buff.
      Reported-by: default avatarChunYu Wang <chunwang@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarChris Leech <cleech@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      c88f0e6b
    • Paul Burton's avatar
      irqchip/mips-gic: Use effective affinity to unmask · d9f82930
      Paul Burton authored
      Commit 7778c4b2 ("irqchip: mips-gic: Use pcpu_masks to avoid reading
      GIC_SH_MASK*") adjusted the way we handle masking interrupts to set &
      clear the interrupt's bit in each pcpu_mask. This allows us to avoid
      needing to read the GIC mask registers and perform a bitwise and of
      their values with the pending & pcpu_masks.
      
      Unfortunately this didn't quite work for IPIs, which were mapped to a
      particular CPU/VP during initialisation but never set the affinity or
      effective_affinity fields of their struct irq_desc. This led to them
      losing their affinity when gic_unmask_irq() was called for them, and
      they'd all become affine to cpu0.
      
      Fix this by:
      
       1) Setting the effective affinity of interrupts in
          gic_shared_irq_domain_map(), which is where we actually map an
          interrupt to a CPU/VP. This ensures that the effective affinity mask
          is always valid, not just after explicitly setting affinity.
      
       2) Using an interrupt's effective affinity when unmasking it, which
          prevents gic_unmask_irq() from unintentionally changing which
          pcpu_mask includes an interrupt.
      
      
      Fixes: 7778c4b2 ("irqchip: mips-gic: Use pcpu_masks to avoid reading GIC_SH_MASK*")
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Link: https://lkml.kernel.org/r/20170922062440.23701-3-paul.burton@imgtec.com
      d9f82930
    • Paul Burton's avatar
      irqchip/mips-gic: Fix shifts to extract register fields · a08588ea
      Paul Burton authored
      The MIPS GIC driver is incorrectly using __fls to shift registers,
      intending to shift to the least significant bit of a value based upon
      its mask but instead shifting off all but the value's top bit. It should
      actually be using __ffs to shift to the first, not last, bit of the
      value.
      
      Apparently the system I used when testing commit 3680746a
      ("irqchip: mips-gic: Convert remaining shared reg access to new
      accessors") and commit b2b2e584 ("irqchip: mips-gic: Clean up mti,
      reserved-cpu-vectors handling") managed to work correctly despite this
      issue, but not all systems do...
      
      Fixes: 3680746a ("irqchip: mips-gic: Convert remaining shared reg access to new accessors")
      Fixes: b2b2e584 ("irqchip: mips-gic: Clean up mti, reserved-cpu-vectors handling")
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Link: https://lkml.kernel.org/r/20170922062440.23701-2-paul.burton@imgtec.com
      a08588ea
    • James Smart's avatar
      nvme-fcloop: fix port deletes and callbacks · fddc9923
      James Smart authored
      Now that there are potentially long delays between when a remoteport or
      targetport delete calls is made and when the callback occurs (dev_loss_tmo
      timeout), no longer block in the delete routines and move the final nport
      puts to the callbacks.
      
      Moved the fcloop_nport_get/put/free routines to avoid forward declarations.
      
      Ensure port_info structs used in registrations are nulled in case fields
      are not set (ex: devloss_tmo values).
      Signed-off-by: default avatarJames Smart <james.smart@broadcom.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      fddc9923
    • James Smart's avatar
      nvmet-fc: ensure target queue id within range. · 0c319d3a
      James Smart authored
      When searching for queue id's ensure they are within the expected range.
      Signed-off-by: default avatarJames Smart <james.smart@broadcom.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      0c319d3a
    • James Smart's avatar
      nvmet-fc: on port remove call put outside lock · 3688feb5
      James Smart authored
      Avoid calling the put routine, as it may traverse to free routines while
      holding the target lock.
      Signed-off-by: default avatarJames Smart <james.smart@broadcom.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      3688feb5
    • Sagi Grimberg's avatar
      nvme-rdma: don't fully stop the controller in error recovery · e4d753d7
      Sagi Grimberg authored
      By calling nvme_stop_ctrl on a already failed controller will wait for the
      scan work to complete (only by identify timeout expiration which is 60
      seconds). This is unnecessary when we already know that the controller has
      failed.
      Reported-by: default avatarYi Zhang <yizhan@redhat.com>
      Signed-off-by: default avatarSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      e4d753d7
    • Sagi Grimberg's avatar
      nvme-rdma: give up reconnect if state change fails · 0a960afd
      Sagi Grimberg authored
      If we failed to transition to state LIVE after a successful reconnect,
      then controller deletion already started. In this case there is no
      point moving forward with reconnect.
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      0a960afd
    • Sagi Grimberg's avatar
      nvme-core: Use nvme_wq to queue async events and fw activation · 1a40d972
      Sagi Grimberg authored
      async_event_work might race as it is executed from two different
      workqueues at the moment.
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      1a40d972
    • James Smart's avatar
      nvme: fix sqhd reference when admin queue connect fails · 8cbd96a6
      James Smart authored
      Fix bug in sqhd patch.
      
      It wasn't the sq that was at risk. In the case where the admin queue
      connect command fails, the sq->size field is not set. Therefore, this
      becomes a divide by zero error.
      
      Add a quick check to bypass under this failure condition.
      Signed-off-by: default avatarJames Smart <james.smart@broadcom.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      8cbd96a6
    • Ilya Lesokhin's avatar
      IB/mlx5: Fix NULL deference on mlx5_ib_update_xlt failure · fbcd4983
      Ilya Lesokhin authored
      mlx5_ib_reg_user_mr called mlx5_ib_dereg_mr in case of MR population
      failure. This resulted in a NULL dereference as ibmr->device wasn't
      initialized yet.
      
      We address this by adding an internal dereg_mr function that can handle
      partially initialized MRs, and fixing clean_mr to work on partially
      initialized MRs.
      
      Fixes: ff740aef ("IB/mlx5: Decouple MR allocation and population flows")
      Signed-off-by: default avatarIlya Lesokhin <ilyal@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      fbcd4983