log_possible_wakeup_reason() and stop_logging_wakeup_reasons() can race, as the
latter can be called from process context, and both can run on separate cores.
Change-Id: I306441d0be46dd4fe58c55cdc162f9d61a28c27d
Signed-off-by: Iliyan Malchev <malchev@google.com>
This node exports five values separated by space.
From left to right:
1. Amount of suspend/resume cycles
2. Amount of suspend abort cycles
3. Total time spent in suspend/resume process
4. Total time in suspend abort process
5. Total time spent sleep in suspend state
Change-Id: Ife188fd8386dce35f95fa7ba09fbc9d7e152db62
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
The old platform suspend_again callback overrides drivers' votes, such that if
it implemented and returns false, then we do not call the partialresume
handlers. When it doesn't exists or returns true, then we also query the
registered drivers for consensus.
When a device resumes from suspend, the suspend/resume code invokes
partialresume to check to see if the set of wakeup interrupts all have matching
handlers. If this is not the case, the PM subsystem can continue to resume as
before. If all of the wakeup sources have matching handlers, then those are
invoked in turn (and can block), and if all of them reach consensus that the
reason for the wakeup can be ignored, they say so to the PM subsystem, which
goes right back into suspend.
Signed-off-by: Iliyan Malchev <malchev@google.com>
Change-Id: Iaeb9ed78c4b5fb815c6e9c701233e703f481f962
Partial resume refers to the concept of not waking up userspace when the kernel
comes out of suspend for certain types of events that we wish to discard. An
example is a network packet that can be disacarded in the kernel, or spurious
wakeup event that we wish to ignore. Partial resume allows drivers to register
callbacks, one one hand, and provides hooks into the PM's suspend/resume
mechanism, on the other.
When a device resumes from suspend, the core suspend/resume code invokes
partialresume to check to see if the set of wakeup interrupts all have
matching handlers. If this is not the case, the PM subsystem can continue to
resume as before. If all of the wakeup sources have matching handlers, then
those are invoked in turn (and can block), and if all of them reach consensus
that the reason for the wakeup can be ignored, they say so to the PM subsystem,
which goes right back into suspend. This latter support is implemented in a
separate change.
Signed-off-by: Iliyan Malchev <malchev@google.com>
Change-Id: Id50940bb22a550b413412264508d259f7121d442
The wakeup_reason driver works by having a callback log_wakeup_reason(), be
called by the resume path once for each wakeup interrupt, with the irq number
as argument. It then saves this interrupt in an array, and reports it when
requested (via /sys/kernel/wakeup_reasons/last_resume_reason) and also prints
the information out in kmsg.
This approach works, but it has the deficiency that often the reported wakeup
interrupt, while correct, is not the interrupt truly responsible for the
wakeup. The reason for this is due to chained interrupt controllers (whether
in hardware or simulated in software). It could be, for example, that the
power button is wired to a GPIO handled by a single interrupt for all GPIOs,
which interrupt then determines the GPIO and maps this to a software interrupt.
Whether this is done in software, or by chaining interrupt controllers, the end
result is that the wakeup reason will show not the interrupt associated with
the power button, but the base-GPIO interrupt instead.
This patch reworks the wakeup_sources driver such that it reports those final
interrupts we are interested in, and not the intermediate (and not the base)
ones. It does so as follows:
-- The assumption is that generic_handle_irq() is called to dispatch all
interrupts; due to this, chained interrupts result in recursive calls of
generic_handle_irq().
-- We reconstruct the chains of interrupts that originate with the base wakeup
interrupt and terminate with the interrupt we are interested in by tracing
the calls to generic_handle_irq()
-- The tracing works by maitaining a per-cpu counter that is incremented with
each call to generic_handle_irq(); that counter is reported to the
wakeup_sources driver by a pair of functions, called
log_possible_wakeup_reason_start() and log_possible_wakeup_reason_complete().
The former is called before generic_handle_irq() handles the interrupt
(thereby potentially calling itself recusively) and the latter afterward.
-- The two functions mentioned above are complemented by log_base_wake_reason()
(renamed from log_wakeup_reason()), which is used to report the base wakeup
interrupts to the wakeup_reason driver.
-- The three functions work together to build a set of trees, one per base
wakeup reason, the leaves of which correspond to the interrupts we are
interesed in; these trees can be arbitratily complex, though in reality they
most often are a single node, or a chain of two nodes. The complexity
supports arbitrarily involved interrupt dispatch.
-- On resume, we build the tree; once the tree is completed, we walk it
recursively, and print out to kmesg the (more useful) list of wakeup
sources; simiarly, we walk the tree and print the leaves when
/sys/kernel/wakeup_reasons/last_resume_reason is read.
Signed-off-by: Iliyan Malchev <malchev@google.com>
Change-Id: If8acb2951b61d2c6bcf4d011fe04d7f91057d139
Alter the signature of irq_flow_handler_t to return true for those interrupts
whose handlers were invoked, and false otherwise. Also rework the actual
handlers, handle_.*_irq, to support the new signature.
Change-Id: I8a50410c477692bbcd39a0fefdac14253602d1f5
Signed-off-by: Iliyan Malchev <malchev@google.com>
Wakeup reason is set before driver resume handlers are called.
It is cleared before driver suspend handlers are called, on
PM_SUSPEND_PREPARE.
Change-Id: I04218c9b0c115a7877e8029c73e6679ff82e0aa4
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Signed-off-by: Iliyan Malchev <malchev@google.com>
Extends the last_resume_reason to log suspend abort reason. The abort
reasons will have "Abort:" appended at the start to distinguish itself
from the resume reason.
Change-Id: Id3c62fc0cb86ca2e05a69e40de040b94f32be389
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
Signed-off-by: Iliyan Malchev <malchev@google.com>
Extends the last_resume_reason to log suspend abort reason. The abort
reasons will have "Abort:" appended at the start to distinguish itself
from the resume reason.
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
Signed-off-by: Iliyan Malchev <malchev@google.com>
Change-Id: I3207f1844e3d87c706dfc298fb10e1c648814c5f
The query results are valid until the next PM_SUSPEND_PREPARE.
Change-Id: I6bc2bd47c830262319576a001d39ac9a994916cf
Signed-off-by: Iliyan Malchev <malchev@google.com>
This node epxorts two values separated by space.
From left to right:
1. time spent in suspend/resume process
2. time spent sleep in suspend state
Change-Id: I2cb9a9408a5fd12166aaec11b935a0fd6a408c63
Ensure the array for the wakeup reason IRQs does not overflow.
Change-Id: Iddc57a3aeb1888f39d4e7b004164611803a4d37c
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
Use rcu to free objects in wakeup_source_unregister(). These objects must
be allocated through wakeup_source_register().
Replacing synchronize_rcu() with call_rcu() allows multiple calls to
wakeup_source_unregister() to be combined into a single grace period.
CRs-Fixed: 845110
Change-Id: Ib4002db042cf63abb28e6b3df6e3c70c97043bd9
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
A driver or app may repeatedly request a wakeup source while the system
is attempting to enter suspend, which may indicate a bug or at least
point out a highly active system component that is responsible for
decreased battery life on a mobile device. Even when the incidence
of suspend abort is not severe, identifying wakeup sources that
frequently abort suspend can be a useful clue for power management
analysis.
In some cases the existing stats can point out the offender where there is
an unexpectedly high activation count that stands out from the others, but
in other cases the wakeup source frequently taken just after the rest of
the system thinks its time to suspend might not stand out in the overall
stats.
It is also often useful to have information about what's been happening
recently, rather than totals of all activity for the system boot.
It's suggested to dump a line about which wakeup source
aborted suspend to aid analysis of these situations.
Change-Id: Ie40356c0755d6898737d9415a367812f17a7532e
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
When legacy wakelock code was removed in commit
f85607a715a74c65db812cd3901022888257f966, some of the code
for moving calls to sys_sync() from suspend paths into a
workqueue item had not been properly removed. Specifically,
one of the call sites to suspend_sys_sync_wait() has been
mistakenly replaced with a call to sys_sync(), which is not
necessary because the corresponding instance of
suspend_sys_sync_queue() was already replaced with
sys_sync(). Clean up the remnants of the legacy wakelock
code by removing the extraneous call to sys_sync() and
restoring some of the surrounding printk statements that
had been moved to suspend_sys_sync_queue() and subsequently
lost.
CRs-Fixed: 498669
Change-Id: Ifb2ede7808560f456c824d3d6359a4541c51b73f
Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
The condition check in autosleep_store() is incorrect and prevents
/sys/power/autosleep from working as advertised. Fix that.
[rjw: Added the changelog.]
Change-Id: I231cc24fc3f245003dcf5053ff6a71eb69ffa273
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Git-commit: 040e5bf65e
Git-repo: git://codeaurora.org/kernel/msm.git
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
Add conditional compilation for touch event sysfs nodes. Otherwise,
if CONFIG_PM_SLEEP is not defined, there could be compilation errors.
Change-Id: I1ac7f284ec35eae2cfa076ef8e71c29ddc24817c
Signed-off-by: Amar Singhal <asinghal@codeaurora.org>
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
Make it possible to configure out the user space wakeup sources
garbage collector for debugging and default Android builds.
Change-Id: I85ca6caa92c8e82d863f0fa58d8861b5571c1b4a
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Arve Hjønnevåg <arve@android.com>
Git-commit: 4e585d25e1
Git-repo: git://codeaurora.org/kernel/msm.git
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
Make it possible to configure out the check against the limit of
user space wakeup sources for debugging and default Android builds.
Change-Id: I8f74d7c8391627df970d2df666938069b012e2fe
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Arve Hjønnevåg <arve@android.com>
Git-commit: c73893e2ca
Git-repo: git://codeaurora.org/kernel/msm.git
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
The config options HAS_WAKELOCK and WAKELOCK are
not needed any more since a wakeup sources-based
wakelock implementation will be used.
Change-Id: I4163f048c079ec3d10a02d9db16c3ca6fb5fd759
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
Android allows user space to manipulate wakelocks using two
sysfs file located in /sys/power/, wake_lock and wake_unlock.
Writing a wakelock name and optionally a timeout to the wake_lock
file causes the wakelock whose name was written to be acquired (it
is created before is necessary), optionally with the given timeout.
Writing the name of a wakelock to wake_unlock causes that wakelock
to be released.
Implement an analogous interface for user space using wakeup sources.
Add the /sys/power/wake_lock and /sys/power/wake_unlock files
allowing user space to create, activate and deactivate wakeup
sources, such that writing a name and optionally a timeout to
wake_lock causes the wakeup source of that name to be activated,
optionally with the given timeout. If that wakeup source doesn't
exist, it will be created and then activated. Writing a name to
wake_unlock causes the wakeup source of that name, if there is one,
to be deactivated. Wakeup sources created with the help of
wake_lock that haven't been used for more than 5 minutes are garbage
collected and destroyed. Moreover, there can be only WL_NUMBER_LIMIT
wakeup sources created with the help of wake_lock present at a time.
The data type used to track wakeup sources created by user space is
called "struct wakelock" to indicate the origins of this feature.
This version of the patch includes an rbtree manipulation fix from John Stultz.
Change-Id: Icb452cfd54362b49dcb1cff88345928a2528ad97
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NeilBrown <neilb@suse.de>
Git-commit: b86ff9820f
Git-repo: git://codeaurora.org/kernel/msm.git
[anursing@codeaurora.org: replace existing implementation, resolve
merge conflicts]
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
Android uses one wakelock statistics that is only necessary for
opportunistic sleep. Namely, the prevent_suspend_time field
accumulates the total time the given wakelock has been locked
while "automatic suspend" was enabled. Add an analogous field,
prevent_sleep_time, to wakeup sources and make it behave in a similar
way.
Change-Id: I4b9719d05da020757d7cc21ed3b52b7c32261bea
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Git-commit: 55850945e8
Git-repo: git://codeaurora.org/kernel/msm.git
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
Introduce a mechanism by which the kernel can trigger global
transitions to a sleep state chosen by user space if there are no
active wakeup sources.
It consists of a new sysfs attribute, /sys/power/autosleep, that
can be written one of the strings returned by reads from
/sys/power/state, an ordered workqueue and a work item carrying out
the "suspend" operations. If a string representing the system's
sleep state is written to /sys/power/autosleep, the work item
triggering transitions to that state is queued up and it requeues
itself after every execution until user space writes "off" to
/sys/power/autosleep.
That work item enables the detection of wakeup events using the
functions already defined in drivers/base/power/wakeup.c (with one
small modification) and calls either pm_suspend(), or hibernate() to
put the system into a sleep state. If a wakeup event is reported
while the transition is in progress, it will abort the transition and
the "system suspend" work item will be queued up again.
Change-Id: Ic3214de009c64feab606e93811bd442ccfc49d86
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NeilBrown <neilb@suse.de>
Git-commit: 7483b4a4d9
Git-repo: git://codeaurora.org/kernel/msm.git
[anursing@codeaurora.org: replace existing implementation, resolve
merge conflicts]
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
Add tracepoints to wakeup_source_activate and wakeup_source_deactivate.
Useful for checking that specific wakeup sources overlap as expected.
Change-Id: I1fa803411a11e50a4904fc97758dcbe39fa82516
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Git-commit: 6791e36c4a
Git-repo: git://codeaurora.org/kernel/msm.git
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
Wakeup statistics used by Android are slightly different from what we
have in wakeup sources at the moment and there aren't any known
users of those statistics other than Android, so modify them to make
it easier for Android to switch to wakeup sources.
This removes the struct wakeup_source's hit_cout field, which is very
rough and therefore not very useful, and adds two new fields,
wakeup_count and expire_count. The first one tracks how many times
the wakeup source is activated with events_check_enabled set (which
roughly corresponds to the situations when a system power transition
to a sleep state is in progress and would be aborted by this wakeup
source if it were the only active one at that time) and the second
one is the number of times the wakeup source has been activated with
a timeout that expired.
Additionally, the last_time field is now updated when the wakeup
source is deactivated too (previously it was only updated during
the wakeup source's activation), which seems to be what Android does
with the analogous counter for wakelocks.
Change-Id: Ifda34645ed321f12f7911b90b48408b58ee88fd6
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Git-commit: 30e3ce6dcb
Git-repo: git://codeaurora.org/kernel/msm.git
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
The current wakeup source deactivation code doesn't do anything when
the counter of wakeup events in progress goes down to zero, which
requires pm_get_wakeup_count() to poll that counter periodically.
Although this reduces the average time it takes to deactivate a
wakeup source, it also may lead to a substantial amount of unnecessary
polling if there are extended periods of wakeup activity. Thus it
seems reasonable to use a wait queue for signaling the "no wakeup
events in progress" condition and remove the polling.
Change-Id: I19bfca1a13fa3d7437c7207575a4ebde60ad25cd
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: mark gross <markgross@thegnar.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Git-commit: 60af106691
Git-repo: git://codeaurora.org/kernel/msm.git
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
Currently, the device suspend code in drivers/base/power/main.c
only checks if there have been any wakeup events, and therefore the
ongoing system transition to a sleep state should be aborted, during
the first (i.e. "suspend") device suspend phase. However, wakeup
events may be reported later as well, so it's reasonable to look for
them in the in the subsequent (i.e. "late suspend" and "suspend
noirq") phases.
Change-Id: Idc55bb84fd820c4f0b5e037186fb337daa612fb4
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Git-commit: 52d136cc2c
Git-repo: git://codeaurora.org/kernel/msm.git
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
Remove parts of code that use the legacy wakelock
implementation as we make the switch to the upstream
kernel's wakeup sources-based implementation.
Change-Id: Idab9e3dd54e8a256b059c88606c9368f7ddb1c1b
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
This reverts commit 8c880ff58fd257d3e9f20e04704cd9d1f3371fc7.
Reverting the change is required to allow for cleaner conflict
resolution as we move to the upstream kernel's wakeup sources
based wakelock implementation.
Change-Id: Ie14fe26a0fa244815dde7845330351beeef66f99
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
We are not going to use earlysuspend anymore.
Let's throw it out and use framebuffer notifier instead.
Change-Id: I7591e03dcfdb5ea95fd4671ddd143b1c47487640
Signed-off-by: Artem Borisov <dedsa2002@gmail.com>
* Fixes NPD when accessing /config/sdcardfs/packages_gid.list
Change-Id: I4b628ffab5e8a83642439661f97f720946f31daf
Signed-off-by: Paul Keith <javelinanddart@gmail.com>
Move sync_filesystem() after sb_prepare_remount_readonly(). If writers
sneak in anywhere from sync_filesystem() to sb_prepare_remount_readonly()
it can cause inodes to be dirtied and writeback to occur well after
sys_mount() has completely successfully.
This was spotted by corrupted ubifs filesystems on reboot, but appears
that it can cause issues with any filesystem using writeback.
CRs-Fixed: 627559
Change-Id: Ib417b59d39210aab2de4e5ae48b18129e8bc3e26
Cc: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
CC: Richard Weinberger <richard@nod.at>
Co-authored-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Andrew Ruder <andrew.ruder@elecsyscorp.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Git-commit: 807612db2f
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
This moves the code to adjust the gid/uid of lower filesystem
files under the mount flag derive_gid.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: I44eaad4ef67c7fcfda3b6ea3502afab94442610c
Bug: 63245673
Fix double free on error paths
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: I1c25a175e87e5dd5cafcdcf9d78bf4c0dc3f88ef
Bug: 65386954
Fixes: aa6d3ace42f9 ("mnt: Add filesystem private data to mount points")
Otherwise, lower_fs->ioctl() fails due to inode_owner_or_capable().
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Bug: 63260873
Change-Id: I623a6c7c5f8a3cbd7ec73ef89e18ddb093c43805
Add a simple read-only counter to super_block that indicates how deep this
is in the stack of filesystems. Previously ecryptfs was the only stackable
filesystem and it explicitly disallowed multiple layers of itself.
Overlayfs, however, can be stacked recursively and also may be stacked
on top of ecryptfs or vice versa.
To limit the kernel stack usage we must limit the depth of the
filesystem stack. Initially the limit is set to 2.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
(cherry picked from commit 69c433ed2e)
Bug: 32761463
Change-Id: I69b2fba2112db2ece09a1bf61a44f8fc4db00820
CVE-2014-9922
The mmap_sem lock does not appear to be protecting
anything, and has been removed in Samsung's more
recent versions of sdcardfs.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: I76ff3e33002716b8384fc8be368028ed63dffe4e
Bug: 63785372
Use the VFS mount_nodev instead of customized mount_nodev_with_options
and fix generic_shutdown_super to kill_anon_super because of set_anon_super
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Change-Id: Ibe46647aa2ce49d79291aa9d0295e9625cfccd80
smatch warns about the suspicious formatting in the last line of
open_flags_to_access_mode(). It turns out the only caller was deleted
over a year ago by "ANDROID: sdcardfs: Bring up to date with Android M
permissions:", so we can "fix" the function's formatting by deleting it.
Change-Id: Id85946f3eb01722eef35b1815f405a6fda3aa4ff
Signed-off-by: Greg Hackmann <ghackmann@google.com>
We must check that d_splice_alias was successful before using its
output.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Bug: 62390017
Change-Id: Ifda0a052fb3f67e35c635a4e5e907876c5400978
next_descendent did not properly handle the case
where the initial mount had no slaves. In this case,
we would look for the next slave, but since don't
have a master, the check for wrapping around to the
start of the list will always fail. Instead, we check
for this case, and ensure that we end the iteration
when we come back to the root.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Bug: 62094374
Change-Id: I43dfcee041aa3730cb4b9a1161418974ef84812e
If the inode is in the process of being evicted,
the top value may be NULL.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Bug: 38502532
Change-Id: I0b9d04aab621e0398d44d1c5dc53293106aa5f89
Move top, and the associated data, to its own struct.
This way, we can properly track refcounts on top
without interfering with the inode's accounting.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Bug: 38045152
Change-Id: I1968e480d966c3f234800b72e43670ca11e1d3fd
According to the following commits,
fs: icache RCU free inodes
vfs: fix the stupidity with i_dentry in inode destructors
sdcardfs_destroy_inode should be fixed for the fast path safety.
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Change-Id: I84f43c599209d23737c7e28b499dd121cb43636d
