1. 29 10月, 2019 1 次提交
  2. 19 9月, 2019 1 次提交
    • M
      driver core: Fix use-after-free and double free on glue directory · e1666bcb
      Muchun Song 提交于
      commit ac43432cb1f5c2950408534987e57c2071e24d8f upstream.
      
      There is a race condition between removing glue directory and adding a new
      device under the glue dir. It can be reproduced in following test:
      
      CPU1:                                         CPU2:
      
      device_add()
        get_device_parent()
          class_dir_create_and_add()
            kobject_add_internal()
              create_dir()    // create glue_dir
      
                                                    device_add()
                                                      get_device_parent()
                                                        kobject_get() // get glue_dir
      
      device_del()
        cleanup_glue_dir()
          kobject_del(glue_dir)
      
                                                      kobject_add()
                                                        kobject_add_internal()
                                                          create_dir() // in glue_dir
                                                            sysfs_create_dir_ns()
                                                              kernfs_create_dir_ns(sd)
      
            sysfs_remove_dir() // glue_dir->sd=NULL
            sysfs_put()        // free glue_dir->sd
      
                                                                // sd is freed
                                                                kernfs_new_node(sd)
                                                                  kernfs_get(glue_dir)
                                                                  kernfs_add_one()
                                                                  kernfs_put()
      
      Before CPU1 remove last child device under glue dir, if CPU2 add a new
      device under glue dir, the glue_dir kobject reference count will be
      increase to 2 via kobject_get() in get_device_parent(). And CPU2 has
      been called kernfs_create_dir_ns(), but not call kernfs_new_node().
      Meanwhile, CPU1 call sysfs_remove_dir() and sysfs_put(). This result in
      glue_dir->sd is freed and it's reference count will be 0. Then CPU2 call
      kernfs_get(glue_dir) will trigger a warning in kernfs_get() and increase
      it's reference count to 1. Because glue_dir->sd is freed by CPU1, the next
      call kernfs_add_one() by CPU2 will fail(This is also use-after-free)
      and call kernfs_put() to decrease reference count. Because the reference
      count is decremented to 0, it will also call kmem_cache_free() to free
      the glue_dir->sd again. This will result in double free.
      
      In order to avoid this happening, we also should make sure that kernfs_node
      for glue_dir is released in CPU1 only when refcount for glue_dir kobj is
      1 to fix this race.
      
      The following calltrace is captured in kernel 4.14 with the following patch
      applied:
      
      commit 726e4109 ("drivers: core: Remove glue dirs from sysfs earlier")
      
      --------------------------------------------------------------------------
      [    3.633703] WARNING: CPU: 4 PID: 513 at .../fs/kernfs/dir.c:494
                      Here is WARN_ON(!atomic_read(&kn->count) in kernfs_get().
      ....
      [    3.633986] Call trace:
      [    3.633991]  kernfs_create_dir_ns+0xa8/0xb0
      [    3.633994]  sysfs_create_dir_ns+0x54/0xe8
      [    3.634001]  kobject_add_internal+0x22c/0x3f0
      [    3.634005]  kobject_add+0xe4/0x118
      [    3.634011]  device_add+0x200/0x870
      [    3.634017]  _request_firmware+0x958/0xc38
      [    3.634020]  request_firmware_into_buf+0x4c/0x70
      ....
      [    3.634064] kernel BUG at .../mm/slub.c:294!
                      Here is BUG_ON(object == fp) in set_freepointer().
      ....
      [    3.634346] Call trace:
      [    3.634351]  kmem_cache_free+0x504/0x6b8
      [    3.634355]  kernfs_put+0x14c/0x1d8
      [    3.634359]  kernfs_create_dir_ns+0x88/0xb0
      [    3.634362]  sysfs_create_dir_ns+0x54/0xe8
      [    3.634366]  kobject_add_internal+0x22c/0x3f0
      [    3.634370]  kobject_add+0xe4/0x118
      [    3.634374]  device_add+0x200/0x870
      [    3.634378]  _request_firmware+0x958/0xc38
      [    3.634381]  request_firmware_into_buf+0x4c/0x70
      --------------------------------------------------------------------------
      
      Fixes: 726e4109 ("drivers: core: Remove glue dirs from sysfs earlier")
      Signed-off-by: NMuchun Song <smuchun@gmail.com>
      Reviewed-by: NMukesh Ojha <mojha@codeaurora.org>
      Signed-off-by: NPrateek Sood <prsood@codeaurora.org>
      Link: https://lore.kernel.org/r/20190727032122.24639-1-smuchun@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e1666bcb
  3. 09 8月, 2019 2 次提交
    • D
      drivers/base: Introduce kill_device() · c23106d4
      Dan Williams 提交于
      commit 00289cd87676e14913d2d8492d1ce05c4baafdae upstream.
      
      The libnvdimm subsystem arranges for devices to be destroyed as a result
      of a sysfs operation. Since device_unregister() cannot be called from
      an actively running sysfs attribute of the same device libnvdimm
      arranges for device_unregister() to be performed in an out-of-line async
      context.
      
      The driver core maintains a 'dead' state for coordinating its own racing
      async registration / de-registration requests. Rather than add local
      'dead' state tracking infrastructure to libnvdimm device objects, export
      the existing state tracking via a new kill_device() helper.
      
      The kill_device() helper simply marks the device as dead, i.e. that it
      is on its way to device_del(), or returns that the device was already
      dead. This can be used in advance of calling device_unregister() for
      subsystems like libnvdimm that might need to handle multiple user
      threads racing to delete a device.
      
      This refactoring does not change any behavior, but it is a pre-requisite
      for follow-on fixes and therefore marked for -stable.
      
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: "Rafael J. Wysocki" <rafael@kernel.org>
      Fixes: 4d88a97a ("libnvdimm, nvdimm: dimm driver and base libnvdimm device-driver...")
      Cc: <stable@vger.kernel.org>
      Tested-by: NJane Chu <jane.chu@oracle.com>
      Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Link: https://lore.kernel.org/r/156341207332.292348.14959761496009347574.stgit@dwillia2-desk3.amr.corp.intel.comSigned-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c23106d4
    • A
      driver core: Establish order of operations for device_add and device_del via bitflag · 7c43f84e
      Alexander Duyck 提交于
      commit 3451a495ef244a88ed6317a035299d835554d579 upstream.
      
      Add an additional bit flag to the device_private struct named "dead".
      
      This additional flag provides a guarantee that when a device_del is
      executed on a given interface an async worker will not attempt to attach
      the driver following the earlier device_del call. Previously this
      guarantee was not present and could result in the device_del call
      attempting to remove a driver from an interface only to have the async
      worker attempt to probe the driver later when it finally completes the
      asynchronous probe call.
      
      One additional change added was that I pulled the check for dev->driver
      out of the __device_attach_driver call and instead placed it in the
      __device_attach_async_helper call. This was motivated by the fact that the
      only other caller of this, __device_attach, had already taken the
      device_lock() and checked for dev->driver. Instead of testing for this
      twice in this path it makes more sense to just consolidate the dev->dead
      and dev->driver checks together into one set of checks.
      Reviewed-by: NDan Williams <dan.j.williams@intel.com>
      Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NAlexander Duyck <alexander.h.duyck@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7c43f84e
  4. 13 2月, 2019 1 次提交
  5. 21 7月, 2018 3 次提交
  6. 16 7月, 2018 2 次提交
    • B
      drivers: core: Remove glue dirs from sysfs earlier · 726e4109
      Benjamin Herrenschmidt 提交于
      For devices with a class, we create a "glue" directory between
      the parent device and the new device with the class name.
      
      This directory is never "explicitely" removed when empty however,
      this is left to the implicit sysfs removal done by kobject_release()
      when the object loses its last reference via kobject_put().
      
      This is problematic because as long as it's not been removed from
      sysfs, it is still present in the class kset and in sysfs directory
      structure.
      
      The presence in the class kset exposes a use after free bug fixed
      by the previous patch, but the presence in sysfs means that until
      the kobject is released, which can take a while (especially with
      kobject debugging), any attempt at re-creating such as binding a
      new device for that class/parent pair, will result in a sysfs
      duplicate file name error.
      
      This fixes it by instead doing an explicit kobject_del() when
      the glue dir is empty, by keeping track of the number of
      child devices of the gluedir.
      
      This is made easy by the fact that all glue dir operations are
      done with a global mutex, and there's already a function
      (cleanup_glue_dir) called in all the right places taking that
      mutex that can be enhanced for this. It appears that this was
      in fact the intent of the function, but the implementation was
      wrong.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      726e4109
    • S
      driver core: remove unnecessary function extern declare · 46d3a037
      Shaokun Zhang 提交于
      device_private_init is called only in core.c, extern declare is
      unnecessary and make it static.
      
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: "Rafael J. Wysocki" <rafael@kernel.org>
      Signed-off-by: NShaokun Zhang <zhangshaokun@hisilicon.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      46d3a037
  7. 09 7月, 2018 2 次提交
  8. 06 7月, 2018 2 次提交
  9. 14 6月, 2018 1 次提交
    • R
      PM / core: Fix supplier device runtime PM usage counter imbalance · 47e5abfb
      Rafael J. Wysocki 提交于
      If a device link is added via device_link_add() by the driver of the
      link's consumer device, the supplier's runtime PM usage counter is
      going to be dropped by the pm_runtime_put_suppliers() call in
      driver_probe_device().  However, in that case it is not incremented
      unless the supplier driver is already present and the link is not
      stateless.  That leads to a runtime PM usage counter imbalance for
      the supplier device in a few cases.
      
      To prevent that from happening, bump up the supplier runtime
      PM usage counter in device_link_add() for all links with the
      DL_FLAG_PM_RUNTIME flag set that are added at the consumer probe
      time.  Use pm_runtime_get_noresume() for that as the callers of
      device_link_add() who want the supplier to be resumed by it are
      expected to pass DL_FLAG_RPM_ACTIVE in flags to it anyway, but
      additionally resume the supplier if the link is added during
      consumer driver probe to retain the existing behavior for the
      callers depending on it.
      
      Fixes: 21d5c57b (PM / runtime: Use device links)
      Reported-by: NUlf Hansson <ulf.hansson@linaro.org>
      Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Cc: 4.10+ <stable@vger.kernel.org> # 4.10+
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      47e5abfb
  10. 14 5月, 2018 3 次提交
  11. 24 4月, 2018 1 次提交
  12. 28 2月, 2018 1 次提交
    • L
      driver core: Introduce device links reference counting · ead18c23
      Lukas Wunner 提交于
      If device_link_add() is invoked multiple times with the same supplier
      and consumer combo, it will create the link on first addition and
      return a pointer to the already existing link on all subsequent
      additions.
      
      The semantics for device_link_del() are quite different, it deletes
      the link unconditionally, so multiple invocations are not allowed.
      
      In other words, this snippet ...
      
          struct device *dev1, *dev2;
          struct device_link *link1, *link2;
      
          link1 = device_link_add(dev1, dev2, 0);
          link2 = device_link_add(dev1, dev2, 0);
      
          device_link_del(link1);
          device_link_del(link2);
      
      ... causes the following crash:
      
          WARNING: CPU: 4 PID: 2686 at drivers/base/power/runtime.c:1611 pm_runtime_drop_link+0x40/0x50
          [...]
          list_del corruption, 0000000039b800a4->prev is LIST_POISON2 (00000000ecf79852)
          kernel BUG at lib/list_debug.c:50!
      
      The issue isn't as arbitrary as it may seem:  Imagine a device link
      which is added in both the supplier's and the consumer's ->probe hook.
      The two drivers can't just call device_link_del() in their ->remove hook
      without coordination.
      
      Fix by counting multiple additions and dropping the device link only
      when the last addition is unwound.
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      [ rjw: Subject ]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ead18c23
  13. 12 2月, 2018 1 次提交
  14. 05 1月, 2018 1 次提交
    • S
      drivers: do not use print_symbol() · a52668c6
      Sergey Senozhatsky 提交于
      print_symbol() is a very old API that has been obsoleted by %pS format
      specifier in a normal printk() call.
      
      Replace print_symbol() with a direct printk("%pS") call.
      
      Link: http://lkml.kernel.org/r/20171211125025.2270-10-sergey.senozhatsky@gmail.com
      To: Andrew Morton <akpm@linux-foundation.org>
      To: Russell King <linux@armlinux.org.uk>
      To: Catalin Marinas <catalin.marinas@arm.com>
      To: Mark Salter <msalter@redhat.com>
      To: Tony Luck <tony.luck@intel.com>
      To: David Howells <dhowells@redhat.com>
      To: Yoshinori Sato <ysato@users.sourceforge.jp>
      To: Guan Xuetao <gxt@mprc.pku.edu.cn>
      To: Borislav Petkov <bp@alien8.de>
      To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      To: Thomas Gleixner <tglx@linutronix.de>
      To: Peter Zijlstra <peterz@infradead.org>
      To: Vineet Gupta <vgupta@synopsys.com>
      To: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: LKML <linux-kernel@vger.kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-c6x-dev@linux-c6x.org
      Cc: linux-ia64@vger.kernel.org
      Cc: linux-am33-list@redhat.com
      Cc: linux-sh@vger.kernel.org
      Cc: linux-edac@vger.kernel.org
      Cc: x86@kernel.org
      Cc: linux-snps-arc@lists.infradead.org
      Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      [pmladek@suse.com: updated commit message]
      Signed-off-by: NPetr Mladek <pmladek@suse.com>
      a52668c6
  15. 18 12月, 2017 1 次提交
  16. 08 12月, 2017 2 次提交
    • G
      driver core: Remove redundant license text · 32825709
      Greg Kroah-Hartman 提交于
      Now that the SPDX tag is in all driver core files, that identifies the
      license in a specific and legally-defined manner.  So the extra GPL text
      wording can be removed as it is no longer needed at all.
      
      This is done on a quest to remove the 700+ different ways that files in
      the kernel describe the GPL license text.  And there's unneeded stuff
      like the address (sometimes incorrect) for the FSF which is never
      needed.
      
      No copyright headers or other non-license-description text was removed.
      
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      32825709
    • G
      driver core: add SPDX identifiers to all driver core files · 989d42e8
      Greg Kroah-Hartman 提交于
      It's good to have SPDX identifiers in all files to make it easier to
      audit the kernel tree for correct licenses.
      
      Update the driver core files files with the correct SPDX license
      identifier based on the license text in the file itself.  The SPDX
      identifier is a legally binding shorthand, which can be used instead of
      the full boiler plate text.
      
      This work is based on a script and data from Thomas Gleixner, Philippe
      Ombredanne, and Kate Stewart.
      
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>
      Cc: William Breathitt Gray <vilhelm.gray@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Kate Stewart <kstewart@linuxfoundation.org>
      Cc: Philippe Ombredanne <pombredanne@nexb.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      989d42e8
  17. 25 10月, 2017 1 次提交
    • M
      locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns... · 6aa7de05
      Mark Rutland 提交于
      locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()
      
      Please do not apply this to mainline directly, instead please re-run the
      coccinelle script shown below and apply its output.
      
      For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
      preference to ACCESS_ONCE(), and new code is expected to use one of the
      former. So far, there's been no reason to change most existing uses of
      ACCESS_ONCE(), as these aren't harmful, and changing them results in
      churn.
      
      However, for some features, the read/write distinction is critical to
      correct operation. To distinguish these cases, separate read/write
      accessors must be used. This patch migrates (most) remaining
      ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following
      coccinelle script:
      
      ----
      // Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and
      // WRITE_ONCE()
      
      // $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch
      
      virtual patch
      
      @ depends on patch @
      expression E1, E2;
      @@
      
      - ACCESS_ONCE(E1) = E2
      + WRITE_ONCE(E1, E2)
      
      @ depends on patch @
      expression E;
      @@
      
      - ACCESS_ONCE(E)
      + READ_ONCE(E)
      ----
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: davem@davemloft.net
      Cc: linux-arch@vger.kernel.org
      Cc: mpe@ellerman.id.au
      Cc: shuah@kernel.org
      Cc: snitzer@redhat.com
      Cc: thor.thayer@linux.intel.com
      Cc: tj@kernel.org
      Cc: viro@zeniv.linux.org.uk
      Cc: will.deacon@arm.com
      Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      6aa7de05
  18. 20 10月, 2017 1 次提交
  19. 17 10月, 2017 1 次提交
  20. 29 8月, 2017 1 次提交
  21. 22 7月, 2017 2 次提交
  22. 07 7月, 2017 1 次提交
  23. 13 6月, 2017 1 次提交
    • J
      driver core: add helper to reuse a device-tree node · 4e75e1d7
      Johan Hovold 提交于
      Add a helper function to be used when reusing the device-tree node of
      another device.
      
      It is fairly common for drivers to reuse the device-tree node of a
      parent (or other ancestor) device when creating class or bus devices
      (e.g. gpio chips, i2c adapters, iio chips, spi masters, serdev, phys,
      usb root hubs). But reusing a device-tree node may cause problems if the
      new device is later probed as for example driver core would currently
      attempt to reinitialise an already active associated pinmux
      configuration.
      
      Other potential issues include the platform-bus code unconditionally
      dropping the device-tree node reference in its device destructor,
      reinitialisation of other bus-managed resources such as clocks, and the
      recently added DMA-setup in driver core.
      
      Note that for most examples above this is currently not an issue as the
      devices are never probed, but this is a problem for the USB bus which
      has recently gained device-tree support. This was discovered and
      worked-around in a rather ad-hoc fashion by commit dc5878ab ("usb:
      core: move root hub's device node assignment after it is added to bus")
      by not setting the of_node pointer until after the root-hub device has
      been registered.
      
      Instead we can allow devices to reuse a device-tree node by setting a
      flag in their struct device that can be used by core, bus and driver
      code to avoid resources from being over-allocated.
      
      Note that the helper also grabs an extra reference to the device node,
      which specifically balances the unconditional put in the platform-device
      destructor.
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4e75e1d7
  24. 26 5月, 2017 1 次提交
    • P
      kobject: support passing in variables for synthetic uevents · f36776fa
      Peter Rajnoha 提交于
      This patch makes it possible to pass additional arguments in addition
      to uevent action name when writing /sys/.../uevent attribute. These
      additional arguments are then inserted into generated synthetic uevent
      as additional environment variables.
      
      Before, we were not able to pass any additional uevent environment
      variables for synthetic uevents. This made it hard to identify such uevents
      properly in userspace to make proper distinction between genuine uevents
      originating from kernel and synthetic uevents triggered from userspace.
      Also, it was not possible to pass any additional information which would
      make it possible to optimize and change the way the synthetic uevents are
      processed back in userspace based on the originating environment of the
      triggering action in userspace. With the extra additional variables, we are
      able to pass through this extra information needed and also it makes it
      possible to synchronize with such synthetic uevents as they can be clearly
      identified back in userspace.
      
      The format for writing the uevent attribute is following:
      
          ACTION [UUID [KEY=VALUE ...]
      
      There's no change in how "ACTION" is recognized - it stays the same
      ("add", "change", "remove"). The "ACTION" is the only argument required
      to generate synthetic uevent, the rest of arguments, that this patch
      adds support for, are optional.
      
      The "UUID" is considered as transaction identifier so it's possible to
      use the same UUID value for one or more synthetic uevents in which case
      we logically group these uevents together for any userspace listeners.
      The "UUID" is expected to be in "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
      format where "x" is a hex digit. The value appears in uevent as
      "SYNTH_UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" environment variable.
      
      The "KEY=VALUE" pairs can contain alphanumeric characters only. It's
      possible to define zero or more more pairs - each pair is then delimited
      by a space character " ". Each pair appears in synthetic uevents as
      "SYNTH_ARG_KEY=VALUE" environment variable. That means the KEY name gains
      "SYNTH_ARG_" prefix to avoid possible collisions with existing variables.
      To pass the "KEY=VALUE" pairs, it's also required to pass in the "UUID"
      part for the synthetic uevent first.
      
      If "UUID" is not passed in, the generated synthetic uevent gains
      "SYNTH_UUID=0" environment variable automatically so it's possible to
      identify this situation in userspace when reading generated uevent and so
      we can still make a difference between genuine and synthetic uevents.
      Signed-off-by: NPeter Rajnoha <prajnoha@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f36776fa
  25. 09 4月, 2017 1 次提交
  26. 17 3月, 2017 1 次提交
  27. 02 3月, 2017 1 次提交
  28. 25 2月, 2017 1 次提交
  29. 14 1月, 2017 1 次提交
  30. 05 12月, 2016 1 次提交