/tools/perf/pmu-events/

href='/cgit.cgi/linux/net-next.git/'>summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorStephen Boyd <sboyd@codeaurora.org>2015-08-11 18:36:51 -0700
committerOlof Johansson <olof@lixom.net>2015-08-18 13:17:48 -0700
commit341a670abd1c086d44e09901f0ebee3dd86a60ba (patch)
tree4c060290e739e60326085f00f57ad1fa0bb6360e
parent509b642ec1cb161f0e9d349bb6bd416554955b3a (diff)
ARM64: dts: vexpress: Use assigned-clock-parents for sp810
The sp810 clk driver is calling the clk consumer APIs from clk_prepare ops to change the parent to a 1 MHz fixed rate clock for each of the clocks that the driver provides. Use assigned-clock-parents for this instead of doing it in the driver to avoid using the consumer API in provider code. This also allows us to remove the usage of clk provider APIs that take a struct clk as an argument from the sp810 driver. Cc: Pawel Moll <pawel.moll@arm.com> Cc: Linus Walleij <linus.walleij@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Olof Johansson <olof@lixom.net>
Diffstat
span='2' class='oid'>4b96156e3d1dd4dfd6039b7c219c9dc4616da52d /sound/firewire/digi00x/digi00x-transaction.c
parent1b1bc42c1692e9b62756323c675a44cb1a1f9dbd (diff)
percpu-refcount: fix reference leak during percpu-atomic transition
percpu_ref_tryget() and percpu_ref_tryget_live() should return "true" IFF they acquire a reference. But the return value from atomic_long_inc_not_zero() is a long and may have high bits set, e.g. PERCPU_COUNT_BIAS, and the return value of the tryget routines is bool so the reference may actually be acquired but the routines return "false" which results in a reference leak since the caller assumes it does not need to do a corresponding percpu_ref_put(). This was seen when performing CPU hotplug during I/O, as hangs in blk_mq_freeze_queue_wait where percpu_ref_kill (blk_mq_freeze_queue_start) raced with percpu_ref_tryget (blk_mq_timeout_work). Sample stack trace: __switch_to+0x2c0/0x450 __schedule+0x2f8/0x970 schedule+0x48/0xc0 blk_mq_freeze_queue_wait+0x94/0x120 blk_mq_queue_reinit_work+0xb8/0x180 blk_mq_queue_reinit_prepare+0x84/0xa0 cpuhp_invoke_callback+0x17c/0x600 cpuhp_up_callbacks+0x58/0x150 _cpu_up+0xf0/0x1c0 do_cpu_up+0x120/0x150 cpu_subsys_online+0x64/0xe0 device_online+0xb4/0x120 online_store+0xb4/0xc0 dev_attr_store+0x68/0xa0 sysfs_kf_write+0x80/0xb0 kernfs_fop_write+0x17c/0x250 __vfs_write+0x6c/0x1e0 vfs_write+0xd0/0x270 SyS_write+0x6c/0x110 system_call+0x38/0xe0 Examination of the queue showed a single reference (no PERCPU_COUNT_BIAS, and __PERCPU_REF_DEAD, __PERCPU_REF_ATOMIC set) and no requests. However, conditions at the time of the race are count of PERCPU_COUNT_BIAS + 0 and __PERCPU_REF_DEAD and __PERCPU_REF_ATOMIC set. The fix is to make the tryget routines use an actual boolean internally instead of the atomic long result truncated to a int. Fixes: e625305b3907 percpu-refcount: make percpu_ref based on longs instead of ints Link: https://bugzilla.kernel.org/show_bug.cgi?id=190751 Signed-off-by: Douglas Miller <dougmill@linux.vnet.ibm.com> Reviewed-by: Jens Axboe <axboe@fb.com> Signed-off-by: Tejun Heo <tj@kernel.org> Fixes: e625305b3907 ("percpu-refcount: make percpu_ref based on longs instead of ints") Cc: stable@vger.kernel.org # v3.18+
Diffstat (limited to 'sound/firewire/digi00x/digi00x-transaction.c')