1. 16 Jan, 2015 1 commit
    • Alex Williamson's avatar
      driver core: Fix unbalanced device reference in drivers_probe · bdf2a0db
      Alex Williamson authored
      commit bb34cb6bbd287b57e955bc5cfd42fcde6aaca279 upstream.
      
      bus_find_device_by_name() acquires a device reference which is never
      released.  This results in an object leak, which on older kernels
      results in failure to release all resources of PCI devices.  libvirt
      uses drivers_probe to re-attach devices to the host after assignment
      and is therefore a common trigger for this leak.
      
      Example:
      
      # cd /sys/bus/pci/
      # dmesg -C
      # echo 1 > devices/0000\:01\:00.0/sriov_numvfs
      # echo 0 > devices/0000\:01\:00.0/sriov_numvfs
      # dmesg | grep 01:10
       pci 0000:01:10.0: [8086:10ca] type 00 class 0x020000
       kobject: '0000:01:10.0' (ffff8801d79cd0a8): kobject_add_internal: parent: '0000:00:01.0', set: 'devices'
       kobject: '0000:01:10.0' (ffff8801d79cd0a8): kobject_uevent_env
       kobject: '0000:01:10.0' (ffff8801d79cd0a8): fill_kobj_path: path = '/devices/pci0000:00/0000:00:01.0/0000:01:10.0'
       kobject: '0000:01:10.0' (ffff8801d79cd0a8): kobject_uevent_env
       kobject: '0000:01:10.0' (ffff8801d79cd0a8): fill_kobj_path: path = '/devices/pci0000:00/0000:00:01.0/0000:01:10.0'
       kobject: '0000:01:10.0' (ffff8801d79cd0a8): kobject_uevent_env
       kobject: '0000:01:10.0' (ffff8801d79cd0a8): fill_kobj_path: path = '/devices/pci0000:00/0000:00:01.0/0000:01:10.0'
       kobject: '0000:01:10.0' (ffff8801d79cd0a8): kobject_cleanup, parent           (null)
       kobject: '0000:01:10.0' (ffff8801d79cd0a8): calling ktype release
       kobject: '0000:01:10.0': free name
      
      [kobject freed as expected]
      
      # dmesg -C
      # echo 1 > devices/0000\:01\:00.0/sriov_numvfs
      # echo 0000:01:10.0 > drivers_probe
      # echo 0 > devices/0000\:01\:00.0/sriov_numvfs
      # dmesg | grep 01:10
       pci 0000:01:10.0: [8086:10ca] type 00 class 0x020000
       kobject: '0000:01:10.0' (ffff8801d79ce0a8): kobject_add_internal: parent: '0000:00:01.0', set: 'devices'
       kobject: '0000:01:10.0' (ffff8801d79ce0a8): kobject_uevent_env
       kobject: '0000:01:10.0' (ffff8801d79ce0a8): fill_kobj_path: path = '/devices/pci0000:00/0000:00:01.0/0000:01:10.0'
       kobject: '0000:01:10.0' (ffff8801d79ce0a8): kobject_uevent_env
       kobject: '0000:01:10.0' (ffff8801d79ce0a8): fill_kobj_path: path = '/devices/pci0000:00/0000:00:01.0/0000:01:10.0'
       kobject: '0000:01:10.0' (ffff8801d79ce0a8): kobject_uevent_env
       kobject: '0000:01:10.0' (ffff8801d79ce0a8): fill_kobj_path: path = '/devices/pci0000:00/0000:00:01.0/0000:01:10.0'
      
      [no free]
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bdf2a0db
  2. 14 Nov, 2014 1 commit
    • Yijing Wang's avatar
      sysfs: driver core: Fix glue dir race condition by gdp_mutex · afb16d3e
      Yijing Wang authored
      commit e4a60d139060975eb956717e4f63ae348d4d8cc5 upstream.
      
      There is a race condition when removing glue directory.
      It can be reproduced in following test:
      
      path 1: Add first child device
      device_add()
          get_device_parent()
                  /*find parent from glue_dirs.list*/
                  list_for_each_entry(k, &dev->class->p->glue_dirs.list, entry)
                          if (k->parent == parent_kobj) {
                                  kobj = kobject_get(k);
                                  break;
                          }
                  ....
                  class_dir_create_and_add()
      
      path2: Remove last child device under glue dir
      device_del()
          cleanup_device_parent()
                  cleanup_glue_dir()
                          kobject_put(glue_dir);
      
      If path2 has been called cleanup_glue_dir(), but not
      call kobject_put(glue_dir), the glue dir is still
      in parent's kset list. Meanwhile, path1 find the glue
      dir from the glue_dirs.list. Path2 may release glue dir
      before path1 call kobject_get(). So kernel will report
      the warning and bug_on.
      
      This is a "classic" problem we have of a kref in a list
      that can be found while the last instance could be removed
      at the same time.
      
      This patch reuse gdp_mutex to fix this race condition.
      
      The following calltrace is captured in kernel 3.4, but
      the latest kernel still has this bug.
      
      -----------------------------------------------------
      <4>[ 3965.441471] WARNING: at ...include/linux/kref.h:41 kobject_get+0x33/0x40()
      <4>[ 3965.441474] Hardware name: Romley
      <4>[ 3965.441475] Modules linked in: isd_iop(O) isd_xda(O)...
      ...
      <4>[ 3965.441605] Call Trace:
      <4>[ 3965.441611]  [<ffffffff8103717a>] warn_slowpath_common+0x7a/0xb0
      <4>[ 3965.441615]  [<ffffffff810371c5>] warn_slowpath_null+0x15/0x20
      <4>[ 3965.441618]  [<ffffffff81215963>] kobject_get+0x33/0x40
      <4>[ 3965.441624]  [<ffffffff812d1e45>] get_device_parent.isra.11+0x135/0x1f0
      <4>[ 3965.441627]  [<ffffffff812d22d4>] device_add+0xd4/0x6d0
      <4>[ 3965.441631]  [<ffffffff812d0dbc>] ? dev_set_name+0x3c/0x40
      ....
      <2>[ 3965.441912] kernel BUG at ..../fs/sysfs/group.c:65!
      <4>[ 3965.441915] invalid opcode: 0000 [#1] SMP
      ...
      <4>[ 3965.686743]  [<ffffffff811a677e>] sysfs_create_group+0xe/0x10
      <4>[ 3965.686748]  [<ffffffff810cfb04>] blk_trace_init_sysfs+0x14/0x20
      <4>[ 3965.686753]  [<ffffffff811fcabb>] blk_register_queue+0x3b/0x120
      <4>[ 3965.686756]  [<ffffffff812030bc>] add_disk+0x1cc/0x490
      ....
      -------------------------------------------------------
      Signed-off-by: default avatarYijing Wang <wangyijing@huawei.com>
      Signed-off-by: default avatarWeng Meiling <wengmeiling.weng@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      afb16d3e
  3. 30 Oct, 2014 3 commits
  4. 05 Oct, 2014 1 commit
    • Mark Brown's avatar
      regmap: Fix handling of volatile registers for format_write() chips · 070fdd7a
      Mark Brown authored
      commit 5844a8b9d98ec11ce1d77610daacf3f0a0e14715 upstream.
      
      A previous over-zealous factorisation of code means that we only treat
      registers as volatile if they are readable. For most devices this is fine
      since normally most registers can be read and volatility implies
      readability but for format_write() devices where there is no readback from
      the hardware and we use volatility to mean simply uncacheability this means
      that we end up treating all registers as cacheble.
      
      A bigger refactoring of the code to clarify this is in order but as a fix
      make a minimal change and only check readability when checking volatility
      if there is no format_write() operation defined for the device.
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      Tested-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      070fdd7a
  5. 21 Jun, 2014 1 commit
  6. 16 Jun, 2014 1 commit
  7. 07 Jun, 2014 3 commits
    • Grant Likely's avatar
      drivercore: deferral race condition fix · f1c8467e
      Grant Likely authored
      commit 58b116bce13612e5aa6fcd49ecbd4cf8bb59e835 upstream.
      
      When the kernel is built with CONFIG_PREEMPT it is possible to reach a state
      when all modules loaded but some driver still stuck in the deferred list
      and there is a need for external event to kick the deferred queue to probe
      these drivers.
      
      The issue has been observed on embedded systems with CONFIG_PREEMPT enabled,
      audio support built as modules and using nfsroot for root filesystem.
      
      The following log fragment shows such sequence when all audio modules
      were loaded but the sound card is not present since the machine driver has
      failed to probe due to missing dependency during it's probe.
      The board is am335x-evmsk (McASP<->tlv320aic3106 codec) with davinci-evm
      machine driver:
      
      ...
      [   12.615118] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: ENTER
      [   12.719969] davinci_evm sound.3: davinci_evm_probe: ENTER
      [   12.725753] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card
      [   12.753846] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component
      [   12.922051] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component DONE
      [   12.950839] davinci_evm sound.3: ASoC: platform (null) not registered
      [   12.957898] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card DONE (-517)
      [   13.099026] davinci-mcasp 4803c000.mcasp: Kicking the deferred list
      [   13.177838] davinci-mcasp 4803c000.mcasp: really_probe: probe_count = 2
      [   13.194130] davinci_evm sound.3: snd_soc_register_card failed (-517)
      [   13.346755] davinci_mcasp_driver_init: LEAVE
      [   13.377446] platform sound.3: Driver davinci_evm requests probe deferral
      [   13.592527] platform sound.3: really_probe: probe_count = 0
      
      In the log the machine driver enters it's probe at 12.719969 (this point it
      has been removed from the deferred lists). McASP driver already executing
      it's probing (since 12.615118).
      The machine driver tries to construct the sound card (12.950839) but did
      not found one of the components so it fails. After this McASP driver
      registers all the ASoC components (the machine driver still in it's probe
      function after it failed to construct the card) and the deferred work is
      prepared at 13.099026 (note that this time the machine driver is not in the
      lists so it is not going to be handled when the work is executing).
      Lastly the machine driver exit from it's probe and the core places it to
      the deferred list but there will be no other driver going to load and the
      deferred queue is not going to be kicked again - till we have external event
      like connecting USB stick, etc.
      
      The proposed solution is to try the deferred queue once more when the last
      driver is asking for deferring and we had drivers loaded while this last
      driver was probing.
      
      This way we can avoid drivers stuck in the deferred queue.
      Signed-off-by: default avatarGrant Likely <grant.likely@linaro.org>
      Reviewed-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Tested-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Mark Brown <broonie@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f1c8467e
    • Vincent Stehlé's avatar
      topology: Fix compilation warning when not in SMP · ed04ce19
      Vincent Stehlé authored
      commit 53974e06603977f348ed978d75c426b0532daa67 upstream.
      
      The topology_##name() macro does not use its argument when CONFIG_SMP is not
      set, as it ultimately calls the cpu_data() macro.
      
      So we avoid maintaining a possibly unused `cpu' variable, to avoid the
      following compilation warning:
      
        drivers/base/topology.c: In function ‘show_physical_package_id’:
        drivers/base/topology.c:103:118: warning: unused variable ‘cpu’ [-Wunused-variable]
         define_id_show_func(physical_package_id);
      
        drivers/base/topology.c: In function ‘show_core_id’:
        drivers/base/topology.c:106:106: warning: unused variable ‘cpu’ [-Wunused-variable]
         define_id_show_func(core_id);
      
      This can be seen with e.g. x86 defconfig and CONFIG_SMP not set.
      Signed-off-by: default avatarVincent Stehlé <vincent.stehle@laposte.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ed04ce19
    • Mauro Ribeiro's avatar
      Samsung sources drop · 448817bd
      Mauro Ribeiro authored
      448817bd
  8. 04 Dec, 2013 1 commit
  9. 05 Oct, 2013 1 commit
    • Benson Leung's avatar
      driver core : Fix use after free of dev->parent in device_shutdown · 78421afd
      Benson Leung authored
      commit f123db8e9d6c84c863cb3c44d17e61995dc984fb upstream.
      
      The put_device(dev) at the bottom of the loop of device_shutdown
      may result in the dev being cleaned up. In device_create_release,
      the dev is kfreed.
      
      However, device_shutdown attempts to use the dev pointer again after
      put_device by referring to dev->parent.
      
      Copy the parent pointer instead to avoid this condition.
      
      This bug was found on Chromium OS's chromeos-3.8, which is based on v3.8.11.
      See bug report : https://code.google.com/p/chromium/issues/detail?id=297842
      This can easily be reproduced when shutting down with
      hidraw devices that report battery condition.
      Two examples are the HP Bluetooth Mouse X4000b and the Apple Magic Mouse.
      For example, with the magic mouse :
      The dev in question is "hidraw0"
      dev->parent is "magicmouse"
      
      In the course of the shutdown for this device, the input event cleanup calls
      a put on hidraw0, decrementing its reference count.
      When we finally get to put_device(dev) in device_shutdown, kobject_cleanup
      is called and device_create_release does kfree(dev).
      dev->parent is no longer valid, and we may crash in
      put_device(dev->parent).
      
      This change should be applied on any kernel with this change :
      d1c6c030Signed-off-by: default avatarBenson Leung <bleung@chromium.org>
      Reviewed-by: default avatarMing Lei <ming.lei@canonical.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      78421afd
  10. 08 Sep, 2013 2 commits
    • David Jander's avatar
      regmap: rbtree: Fix overlapping rbnodes. · 0c6471cc
      David Jander authored
      commit 4e67fb5f5e336250db944921e3c68057d6203034 upstream.
      
      Avoid overlapping register regions by making the initial blklen of a new
      node 1. If a register write occurs to a yet uncached register, that is
      lower than but near an existing node's base_reg, a new node is created
      and it's blklen is set to an arbitrary value (sizeof(*rbnode)). That may
      cause this node to overlap with another node. Those nodes should be merged,
      but this merge doesn't happen yet, so this patch at least makes the initial
      blklen small enough to avoid hitting the wrong node, which may otherwise
      lead to severe breakage.
      Signed-off-by: default avatarDavid Jander <david@protonic.nl>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      Signed-off-by: default avatarZhouping Liu <zliu@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0c6471cc
    • Russ Anderson's avatar
      drivers/base/memory.c: fix show_mem_removable() to handle missing sections · ea35d7d6
      Russ Anderson authored
      commit 21ea9f5ace3a7317cc3ba1fbc749758021a83136 upstream.
      
      "cat /sys/devices/system/memory/memory*/removable" crashed the system.
      
      The problem is that show_mem_removable() is passing a
      bad pfn to is_mem_section_removable(), which causes
      
          if (!node_online(page_to_nid(page)))
      
      to blow up.  Why is it passing in a bad pfn?
      
      The reason is that show_mem_removable() will loop sections_per_block
      times.  sections_per_block is 16, but mem->section_count is 8,
      indicating holes in this memory block.  Checking that the memory section
      is present before checking to see if the memory section is removable
      fixes the problem.
      
         harp5-sys:~ # cat /sys/devices/system/memory/memory*/removable
         0
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         BUG: unable to handle kernel paging request at ffffea00c3200000
         IP: [<ffffffff81117ed1>] is_pageblock_removable_nolock+0x1/0x90
         PGD 83ffd4067 PUD 37bdfce067 PMD 0
         Oops: 0000 [#1] SMP
         Modules linked in: autofs4 binfmt_misc rdma_ucm rdma_cm iw_cm ib_addr ib_srp scsi_transport_srp scsi_tgt ib_ipoib ib_cm ib_uverbs ib_umad iw_cxgb3 cxgb3 mdio mlx4_en mlx4_ib ib_sa mlx4_core ib_mthca ib_mad ib_core fuse nls_iso8859_1 nls_cp437 vfat fat joydev loop hid_generic usbhid hid hwperf(O) numatools(O) dm_mod iTCO_wdt ipv6 iTCO_vendor_support igb i2c_i801 ioatdma i2c_algo_bit ehci_pci pcspkr lpc_ich i2c_core ehci_hcd ptp sg mfd_core dca rtc_cmos pps_core mperf button xhci_hcd sd_mod crc_t10dif usbcore usb_common scsi_dh_emc scsi_dh_hp_sw scsi_dh_alua scsi_dh_rdac scsi_dh gru(O) xvma(O) xfs crc32c libcrc32c thermal sata_nv processor piix mptsas mptscsih scsi_transport_sas mptbase megaraid_sas fan thermal_sys hwmon ext3 jbd ata_piix ahci libahci libata scsi_mod
         CPU: 4 PID: 5991 Comm: cat Tainted: G           O 3.11.0-rc5-rja-uv+ #10
         Hardware name: SGI UV2000/ROMLEY, BIOS SGI UV 2000/3000 series BIOS 01/15/2013
         task: ffff88081f034580 ti: ffff880820022000 task.ti: ffff880820022000
         RIP: 0010:[<ffffffff81117ed1>]  [<ffffffff81117ed1>] is_pageblock_removable_nolock+0x1/0x90
         RSP: 0018:ffff880820023df8  EFLAGS: 00010287
         RAX: 0000000000040000 RBX: ffffea00c3200000 RCX: 0000000000000004
         RDX: ffffea00c30b0000 RSI: 00000000001c0000 RDI: ffffea00c3200000
         RBP: ffff880820023e38 R08: 0000000000000000 R09: 0000000000000001
         R10: 0000000000000000 R11: 0000000000000001 R12: ffffea00c33c0000
         R13: 0000160000000000 R14: 6db6db6db6db6db7 R15: 0000000000000001
         FS:  00007ffff7fb2700(0000) GS:ffff88083fc80000(0000) knlGS:0000000000000000
         CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
         CR2: ffffea00c3200000 CR3: 000000081b954000 CR4: 00000000000407e0
         Call Trace:
           show_mem_removable+0x41/0x70
           dev_attr_show+0x2a/0x60
           sysfs_read_file+0xf7/0x1c0
           vfs_read+0xc8/0x130
           SyS_read+0x5d/0xa0
           system_call_fastpath+0x16/0x1b
      Signed-off-by: default avatarRuss Anderson <rja@sgi.com>
      Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Reviewed-by: default avatarYasuaki Ishimatsu <isimatu.yasuaki@jp.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 avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ea35d7d6
  11. 15 Aug, 2013 1 commit
  12. 04 Aug, 2013 1 commit
  13. 18 Jun, 2013 1 commit
  14. 01 Jun, 2013 1 commit
  15. 23 May, 2013 1 commit
  16. 21 May, 2013 2 commits
  17. 12 May, 2013 2 commits
  18. 01 May, 2013 2 commits
  19. 29 Apr, 2013 4 commits
  20. 16 Apr, 2013 1 commit
    • Stephen Warren's avatar
      regmap: don't corrupt work buffer in _regmap_raw_write() · 5a08d156
      Stephen Warren authored
      _regmap_raw_write() contains code to call regcache_write() to write
      values to the cache. That code calls memcpy() to copy the value data to
      the start of the work_buf. However, at least when _regmap_raw_write() is
      called from _regmap_bus_raw_write(), the value data is in the work_buf,
      and this memcpy() operation may over-write part of that value data,
      depending on the value of reg_bytes + pad_bytes. At least when using
      reg_bytes==1 and pad_bytes==0, corruption of the value data does occur.
      
      To solve this, remove the memcpy() operation, and modify the subsequent
      .parse_val() call to parse the original value buffer directly.
      
      At least in the case of 8-bit register address and 16-bit values, and
      writes of single registers at a time, this memcpy-then-parse combination
      used to cancel each-other out; for a work-buffer containing xx 89 03,
      the memcpy changed it to 89 03 03, and the parse_val changed it back to
      89 89 03, thus leaving the value uncorrupted. This appears completely
      accidental though. Since commit 8a819ff8 "regmap: core: Split out in
      place value parsing", .parse_val only returns the parsed value, and does
      not modify the buffer, and hence does not (accidentally) undo the
      corruption caused by memcpy(). This caused bogus values to get written
      to HW, thus preventing e.g. audio playback on systems with a WM8903
      CODEC. This patch fixes that.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      5a08d156
  21. 12 Apr, 2013 3 commits
  22. 11 Apr, 2013 2 commits
  23. 10 Apr, 2013 2 commits
  24. 09 Apr, 2013 1 commit
    • Mark Brown's avatar
      regmap: Back out work buffer fix · 51a246aa
      Mark Brown authored
      This reverts commit bc8ce4 (regmap: don't corrupt work buffer in
      _regmap_raw_write()) since it turns out that it can cause issues when
      taken in isolation from the other changes in -next that lead to its
      discovery.  On the basis that nobody noticed the problems for quite some
      time without that subsequent work let's drop it from v3.9.
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      51a246aa
  25. 08 Apr, 2013 1 commit
    • Kay Sievers's avatar
      driver core: add uid and gid to devtmpfs · 3c2670e6
      Kay Sievers authored
      Some drivers want to tell userspace what uid and gid should be used for
      their device nodes, so allow that information to percolate through the
      driver core to userspace in order to make this happen.  This means that
      some systems (i.e.  Android and friends) will not need to even run a
      udev-like daemon for their device node manager and can just rely in
      devtmpfs fully, reducing their footprint even more.
      Signed-off-by: default avatarKay Sievers <kay@vrfy.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3c2670e6