Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 15 11月, 2012 2 次提交
    • C
      firmware loader: Fix the concurrent request_firmware() race for kref_get/put · bd9eb7fb
      由 Chuansheng Liu 提交于 
      There is one race that both request_firmware() with the same
firmware name.

The race scenerio is as below:
CPU1                                                  CPU2
request_firmware() -->
_request_firmware_load() return err                   another request_firmware() is coming -->
_request_firmware_cleanup is called -->               _request_firmware_prepare -->
release_firmware --->                                 fw_lookup_and_allocate_buf -->
                                                      spin_lock(&fwc->lock)
...                                                   __fw_lookup_buf() return true
fw_free_buf() will be called -->                      ...
kref_put -->
decrease the refcount to 0
                                                      kref_get(&tmp->ref) ==> it will trigger warning
                                                                              due to refcount == 0
__fw_free_buf() -->
...                                                   spin_unlock(&fwc->lock)
spin_lock(&fwc->lock)
list_del(&buf->list)
spin_unlock(&fwc->lock)
kfree(buf)
                                                      After that, the freed buf will be used.

The key race is decreasing refcount to 0 and list_del is not protected together by
fwc->lock, and it is possible another thread try to get it between refcount==0
and list_del.

Fix it here to protect it together.
Acked-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: Nliu chuansheng <chuansheng.liu@intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bd9eb7fb
    • C
      firmware loader: Fix the race FW_STATUS_DONE is followed by class_timeout · ce2fcbd9
      由 Chuansheng Liu 提交于 
      There is a race as below when calling request_firmware():
CPU1                                   CPU2
write 0 > loading
mutex_lock(&fw_lock)
...
set_bit FW_STATUS_DONE                 class_timeout is coming
                                       set_bit FW_STATUS_ABORT
complete_all &completion
...
mutex_unlock(&fw_lock)

In this time, the bit FW_STATUS_DONE and FW_STATUS_ABORT are set,
and request_firmware() will return failure due to condition in
_request_firmware_load():
	if (!buf->size || test_bit(FW_STATUS_ABORT, &buf->status))
		retval = -ENOENT;

But from the above scenerio, it should be a successful requesting.
So we need judge if the bit FW_STATUS_DONE is already set before
calling fw_load_abort() in timeout function.

As Ming's proposal, we need change the timer into sched_work to
benefit from using &fw_lock mutex also.
Signed-off-by: Nliu chuansheng <chuansheng.liu@intel.com>
Acked-by: NMing Lei <ming.lei@canonical.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ce2fcbd9
  3. 10 11月, 2012 1 次提交
  5. 31 10月, 2012 2 次提交
  7. 26 10月, 2012 1 次提交
  9. 23 10月, 2012 4 次提交
  11. 22 10月, 2012 4 次提交
  13. 17 10月, 2012 1 次提交
    • D
      regmap: select REGMAP if REGMAP_MMIO and REGMAP_IRQ enabled · 5784ee4d
      由 Dong Aisheng 提交于 
      The regmap_mmio and regmap_irq depend on regmap core, if not select,
we may not compile regmap core and meet compiling errors as follows
if REGMAP_MMIO is selected by client drivers:
drivers/mfd/syscon.c:94:15: error: variable 'syscon_regmap_config' has initializer but incomplete type
drivers/mfd/syscon.c:95:2: error: unknown field 'reg_bits' specified in initializer
drivers/mfd/syscon.c:95:2: warning: excess elements in struct initializer [enabled by default]
drivers/mfd/syscon.c:95:2: warning: (near initialization for 'syscon_regmap_config') [enabled by default]
drivers/mfd/syscon.c:96:2: error: unknown field 'val_bits' specified in initializer
drivers/mfd/syscon.c:96:2: warning: excess elements in struct initializer [enabled by default]
drivers/mfd/syscon.c:96:2: warning: (near initialization for 'syscon_regmap_config') [enabled by default]
drivers/mfd/syscon.c:97:2: error: unknown field 'reg_stride' specified in initializer
drivers/mfd/syscon.c:97:2: warning: excess elements in struct initializer [enabled by default]
drivers/mfd/syscon.c:97:2: warning: (near initialization for 'syscon_regmap_config') [enabled by default]
drivers/mfd/syscon.c: In function 'syscon_probe':
drivers/mfd/syscon.c:124:2: error: invalid use of undefined type 'struct regmap_config'
drivers/mfd/syscon.c:125:2: error: implicit declaration of function 'devm_regmap_init_mmio' [-Werror=implicit-function-declaration]
drivers/mfd/syscon.c:125:17: warning: assignment makes pointer from integer without a cast [enabled by default]
cc1: some warnings being treated as errors

drivers/mfd/Kconfig:
config MFD_SYSCON
        bool "System Controller Register R/W Based on Regmap"
	depends on OF
	select REGMAP_MMIO
	help
	  Select this option to enable accessing system control registers
	    via regmap.
Signed-off-by: NDong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      5784ee4d
  15. 09 10月, 2012 2 次提交
    • W
      memory-hotplug: update memory block's state and notify userspace · e90bdb7f
      由 Wen Congyang 提交于 
      remove_memory() will be called when hot removing a memory device.  But
even if offlining memory, we cannot notice it.  So the patch updates the
memory block's state and sends notification to userspace.

Additionally, the memory device may contain more than one memory block.
If the memory block has been offlined, __offline_pages() will fail.  So we
should try to offline one memory block at a time.

Thus remove_memory() also check each memory block's state.  So there is no
need to check the memory block's state before calling remove_memory().
Signed-off-by: NWen Congyang <wency@cn.fujitsu.com>
Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Jiang Liu <liuj97@gmail.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e90bdb7f
    • W
      memory-hotplug: preparation to notify memory block's state at memory hot remove · a16cee10
      由 Wen Congyang 提交于 
      remove_memory() is called in two cases:
1. echo offline >/sys/devices/system/memory/memoryXX/state
2. hot remove a memory device

In the 1st case, the memory block's state is changed and the notification
that memory block's state changed is sent to userland after calling
remove_memory().  So user can notice memory block is changed.

But in the 2nd case, the memory block's state is not changed and the
notification is not also sent to userspcae even if calling
remove_memory().  So user cannot notice memory block is changed.

For adding the notification at memory hot remove, the patch just prepare
as follows:
1st case uses offline_pages() for offlining memory.
2nd case uses remove_memory() for offlining memory and changing memory block's
    state and notifing the information.

The patch does not implement notification to remove_memory().
Signed-off-by: NWen Congyang <wency@cn.fujitsu.com>
Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Jiang Liu <liuj97@gmail.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a16cee10
  17. 05 10月, 2012 1 次提交
  19. 04 10月, 2012 1 次提交
    • L
      firmware: teach the kernel to load firmware files directly from the filesystem · abb139e7
      由 Linus Torvalds 提交于 
      This is a first step in allowing people to by-pass udev for loading
device firmware.  Current versions of udev will deadlock (causing us to
block for the 30 second timeout) under some circumstances if the
firmware is loaded as part of the module initialization path, and this
is causing problems for media drivers in particular.

The current patch hardcodes the firmware path that udev uses by default,
and will fall back to the legacy udev mode if the firmware cannot be
found there.  We'd like to add support for both configuring the paths
and the fallback behaviour, but in the meantime this hopefully fixes the
immediate problem, while also giving us a way forward.

[ v2: Some VFS layer interface cleanups suggested by Al Viro ]
[ v3: use the default udev paths suggested by Kay Sievers ]
Suggested-by: NIvan Kalvachev <ikalvachev@gmail.com>
Acked-by: NGreg KH <gregkh@linuxfoundation.org>
Acked-by: NAl Viro <viro@zeniv.linux.org.uk>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Kay Sievers <kay@redhat.com>
Cc: Ming Lei <ming.lei@canonical.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      abb139e7
  21. 02 10月, 2012 1 次提交
  23. 27 9月, 2012 1 次提交
  25. 25 9月, 2012 1 次提交
  27. 23 9月, 2012 1 次提交
    • K
      PM / Runtime: let rpm_resume() succeed if RPM_ACTIVE, even when disabled, v2 · 6f3c77b0
      由 Kevin Hilman 提交于 
      There are several drivers where the return value of
pm_runtime_get_sync() is used to decide whether or not it is safe to
access hardware and that don't provide .suspend() callbacks for system
suspend (but may use late/noirq callbacks.)  If such a driver happens
to call pm_runtime_get_sync() during system suspend, after the core
has disabled runtime PM, it will get the error code and will decide
that the hardware should not be accessed, although this may be a wrong
conclusion, depending on the state of the device when runtime PM was
disabled.

Drivers might work around this problem by using a test like:

   ret = pm_runtime_get_sync(dev);
   if (!ret || (ret == -EACCES && driver_private_data(dev)->suspended)) {
      /* access hardware */
   }

where driver_private_data(dev)->suspended is a flag set by the
driver's .suspend() method (that would have to be added for this
purpose).  However, that potentially would need to be done by multiple
drivers which means quite a lot of duplicated code and bloat.

To avoid that we can use the observation that the core sets
dev->power.is_suspended before disabling runtime PM and use that
instead of the driver's private flag.  Still, potentially many drivers
would need to repeat that same check in quite a few places, so it's
better to let the core do it.

Then we can be a bit smarter and check whether or not runtime PM was
disabled by the core only (disable_depth == 1) or by someone else in
addition to the core (disable_depth > 1).  In the former case
rpm_resume() can return 1 if the runtime PM status is RPM_ACTIVE,
because it means the device was active when the core disabled runtime
PM.  In the latter case it should still return -EACCES, because it
isn't clear why runtime PM has been disabled.

Tested on AM3730/Beagle-xM where a wakeup IRQ firing during the late
suspend phase triggers runtime PM activity in the I2C driver since the
wakeup IRQ is on an I2C-connected PMIC.

[rjw: Modified whitespace to follow the file's convention.]
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      6f3c77b0
  29. 21 9月, 2012 1 次提交
  31. 20 9月, 2012 1 次提交
    • A
      PM: Prevent runtime suspend during system resume · 88d26136
      由 Alan Stern 提交于 
      This patch (as1591) moves the pm_runtime_get_noresume() and
pm_runtime_put_sync() calls from __device_suspend() and
device_resume() to device_prepare() and device_complete() in the PM
core.

The reason for doing this is to make sure that parent devices remain
at full power (i.e., don't go into runtime suspend) while their
children are being resumed from a system sleep.

The PCI core already contained equivalent code to serve the same
purpose.  The patch removes the duplicated code, since it is no longer
needed.  One of the comments from the PCI core gets moved into the PM
core, and a second comment is added to explain whe the _get_noresume
and _put_sync calls are present.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      88d26136
  33. 19 9月, 2012 2 次提交
  35. 17 9月, 2012 3 次提交
  37. 11 9月, 2012 1 次提交
  39. 10 9月, 2012 1 次提交
  41. 09 9月, 2012 1 次提交
  43. 07 9月, 2012 5 次提交
  45. 04 9月, 2012 2 次提交