The copied sync_pt was activated immediately. If the sync_pt was
signaled before the entire merge was completed, the new fence's pt_list
could be iterated over while it is still in the process of being
created.
Moving the the sync_pt_activate call for all new sync_pts to after both
the sync_fence_copy_pts and the sync_fence_merge_pts calls ensure that
the pt_list is complete and immutable before it can be reached from the
timeline's active list.
Signed-off-by: Erik Gilling <konkers@android.com>
Move driver callbacks to fill strings instead of using seq_files. This
will allow those values to be used in a future tracepoint patch.
Change-Id: I9b706343e35b11124141fe520e520514a32003d2
Signed-off-by: Erik Gilling <konkers@android.com>
The previous fix only addressed waiting with a timeout.
Change-Id: I8ad735d2d0dfdd53592904e8a54f5689cb5eaa5e
Signed-off-by: Erik Gilling <konkers@android.com>
If a fence's pt is signaled before sync_fence_create is called, the fence
will never transition into the signaled state. This also address a tiny
race if a merged fence's pt after sync_fence_get_status checks it's status
and before fence->status is updated.
Change-Id: Ic8e292a323db26c6f04cb4757d920278b3125ff6
Signed-off-by: Erik Gilling <konkers@android.com>
Fence status is checked outside of locks in both sync_fence_wait and
sync_fence_poll. This patch adds propper barrier protection in these
cases to avoid seeing stale status.
Change-Id: I9d8b6ce6accb415e797df58068a1ccd54e6be445
Signed-off-by: Erik Gilling <konkers@android.com>
Check the return value of get_unused_fd to make sure a valid
file descriptor is returned.
Make sure to call put_unused_fd even if an error occurs before
the fd can be used.
Change-Id: I0fe8f78d9e30ecfc4d271c5d875424543dae2d0f
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
If a timeline is destroyed while fences still hold pts on it, the reworked
fence release handler can cause the timeline to be freed before all it's points
are freed.
Change-Id: I1cd8ddb638eded7db9db446ff6b37f3dd165d6c4
Signed-off-by: Erik Gilling <konkers@android.com>
If a fence is released while a timeline that one of it's pts is on is being
signaled, it is possible for that fence to be deleted before it is signaled.
This patch adds a refcount for internal references such as signaled pt
processing.
Change-Id: Ie8605e6fd2ac026c207220a03d84e1c1078ec719
Signed-off-by: Erik Gilling <konkers@android.com>
If the two fences being merged contain sync_pts from the same timeline,
those two pts will be collapsed into a single pt representing the latter
of the two.
Change-Id: Iced7ebb7e5a17a0c8b1a2969ba3388a4edb9ecaf
Signed-off-by: Erik Gilling <konkers@android.com>
Previously fence's pts were freed before the were the fence was removed from the
global fence list. This led to a race with the debugfs support where it would
iterate over sync_pts that had been freed.
Change-Id: Ia3ddbf77de42ca593fc2dc353b5d04e42ddf3946
Signed-off-by: Erik Gilling <konkers@android.com>
This is needed to allow modules to link against the sync subsystem
Change-Id: I15c1818de329f24e4113ef1d0923413b22fd0eff
Signed-off-by: Erik Gilling <konkers@android.com>
In order to allow drivers to cleanly handled teardown we need to allow them
to cancel pending async waits. To do this cleanly, we move allocation of
sync_fence_waiter to the driver calling sync_async_wait().
Change-Id: Ifcd95648be6ec07026d67f810070a4310f099989
Signed-off-by: Erik Gilling <konkers@android.com>
commit 58a34de7b1 upstream.
The power.deferred_resume can only be set if the runtime PM status
of device is RPM_SUSPENDING and it should be cleared after its
status has been changed, regardless of whether or not the runtime
suspend has been successful. However, it only is cleared on
suspend failure, while it may remain set on successful suspend and
is happily leaked to rpm_resume() executed in that case.
That shouldn't happen, so if power.deferred_resume is set in
rpm_suspend() after the status has been changed to RPM_SUSPENDED,
clear it before calling rpm_resume(). Then, it doesn't need to be
cleared before changing the status to RPM_SUSPENDING any more,
because it's always cleared after the status has been changed to
either RPM_SUSPENDED (on success) or RPM_ACTIVE (on failure).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7f321c26c0 upstream.
For devices whose power.no_callbacks flag is set, rpm_resume()
should return 1 if the device's parent is already active, so that
the callers of pm_runtime_get() don't think that they have to wait
for the device to resume (asynchronously) in that case (the core
won't queue up an asynchronous resume in that case, so there's
nothing to wait for anyway).
Modify the code accordingly (and make sure that an idle notification
will be queued up on success, even if 1 is to be returned).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2bbcb87883 upstream.
Stable note: Fixes https://bugzilla.novell.com/show_bug.cgi?id=721039 .
Without the patch, memory hot-add can fail for kernel configurations
that do not set CONFIG_SPARSEMEM_VMEMMAP.
(Resending as I am not seeing it in -next so maybe it got lost)
mm: memory hotplug: Check if pages are correctly reserved on a per-section basis
It is expected that memory being brought online is PageReserved
similar to what happens when the page allocator is being brought up.
Memory is onlined in "memory blocks" which consist of one or more
sections. Unfortunately, the code that verifies PageReserved is
currently assuming that the memmap backing all these pages is virtually
contiguous which is only the case when CONFIG_SPARSEMEM_VMEMMAP is set.
As a result, memory hot-add is failing on those configurations with
the message;
kernel: section number XXX page number 256 not reserved, was it already online?
This patch updates the PageReserved check to lookup struct page once
per section to guarantee the correct struct page is being checked.
[Check pages within sections properly: rientjes@google.com]
[original patch by: nfont@linux.vnet.ibm.com]
Signed-off-by: Mel Gorman <mgorman@suse.de>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Tested-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit fe6b91f470 upstream.
Disabling all runtime PM during system shutdown turns out not to be a
good idea, because some devices may need to be woken up from a
low-power state at that time.
The whole point of disabling runtime PM for system shutdown was to
prevent untimely runtime-suspend method calls. This patch (as1504)
accomplishes the same result by incrementing the usage count for each
device and waiting for ongoing runtime-PM callbacks to finish. This
is what we already do during system suspend and hibernation, which
makes sense since the shutdown method is pretty much a legacy analog
of the pm->poweroff method.
This fixes a recent regression on some OMAP systems introduced by
commit af8db1508f (PM / driver core:
disable device's runtime PM during shutdown).
Reported-and-tested-by: NeilBrown <neilb@suse.de>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Kostyantyn Shlyakhovoy <x0155534@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit eea915bb0d upstream.
This oops was reported recently:
firmware_loading_store+0xf9/0x17b
dev_attr_store+0x20/0x22
sysfs_write_file+0x101/0x134
vfs_write+0xac/0xf3
sys_write+0x4a/0x6e
system_call_fastpath+0x16/0x1b
The complete backtrace was unfortunately not captured, but details can be found
here:
https://bugzilla.redhat.com/show_bug.cgi?id=769920
The cause is fairly clear.
Its caused by the fact that firmware_loading_store has a case 0 in its
switch statement that reads and writes the fw_priv->fw poniter without the
protection of the fw_lock mutex. since there is a window between the time that
_request_firmware sets fw_priv->fw to NULL and the time the corresponding sysfs
file is unregistered, its possible for a user space application to race in, and
write a zero to the loading file, causing a NULL dereference in
firmware_loading_store. Fix it by extending the protection of the fw_lock mutex
to cover all of the firware_loading_store function.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 91a13c281d upstream.
Patch to fix the error message "directives may not be used inside a macro
argument" which appears when the kernel is compiled for the cris architecture.
Signed-off-by: Claudio Scordino <claudio@evidence.eu.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit af8db1508f upstream.
There may be an issue when the user issue "reboot/shutdown" command, then
the device has shut down its hardware, after that, this runtime-pm featured
device's driver will probably be scheduled to do its suspend routine,
and at its suspend routine, it may access hardware, but the device has
already shutdown physically, then the system hang may be occurred.
I ran out this issue using an auto-suspend supported USB devices, like
3G modem, keyboard. The usb runtime suspend routine may be scheduled
after the usb controller has been shut down, and the usb runtime suspend
routine will try to suspend its roothub(controller), it will access
register, then the system hang occurs as the controller is shutdown.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Acked-by: Ming Lei <tom.leiming@gmail.com>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
