Android goes through suspend/resume very often (every few seconds when
on a busy wifi network with the screen off), and a significant portion
of the energy used to go in and out of suspend is spent in the
freezer. If a task has called freezer_do_not_count(), don't bother
waking it up. If it happens to wake up later it will call
freezer_count() and immediately enter the refrigerator.
Combined with patches to convert freezable helpers to use
freezer_do_not_count() and convert common sites where idle userspace
tasks are blocked to use the freezable helpers, this reduces the
time and energy required to suspend and resume.
Change-Id: I6ba019d24273619849af757a413271da3261d7db
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
All tasks can easily be frozen in under 10 ms, switch to using
an initial 1 ms sleep followed by exponential backoff until
8 ms. Also convert the printed time to ms instead of centiseconds.
Change-Id: I7b198b16eefb623c2b0fc45dce50d9bca320afdc
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
We shouldn't try_to_freeze if locks are held. Holding a lock can cause a
deadlock if the lock is later acquired in the suspend or hibernate path
(e.g. by dpm). Holding a lock can also cause a deadlock in the case of
cgroup_freezer if a lock is held inside a frozen cgroup that is later
acquired by a process outside that group.
History:
This patch was originally applied as 6aa9707099 and reverted in
dbf520a9d7 because NFS was freezing with locks held. It was
deemed better to keep the bad freeze point in NFS to allow laptops
to suspend consistently. The previous patch in this series converts
NFS to call _unsafe versions of the freezable helpers so that
lockdep doesn't complain about them until a more correct fix
can be applied.
Change-Id: Ib9d4299fb75a39e611b868be42e413909a994baa
[akpm@linux-foundation.org: export debug_check_no_locks_held]
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The only existing caller to debug_check_no_locks_held calls it
with 'current' as the task, and the freezer needs to call
debug_check_no_locks_held but doesn't already have a current
task pointer, so remove the argument. It is already assuming
that the current task is relevant by dumping the current stack
trace as part of the warning.
This was originally part of 6aa9707099 (lockdep: check that
no locks held at freeze time) which was reverted in
dbf520a9d7.
Change-Id: Idbaf1332ce6c80dc49c1d31c324c7fbf210657c5
Original-author: Mandeep Singh Baines <msb@chromium.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CIFS calls wait_event_freezekillable_unsafe with a VFS lock held,
which is unsafe and will cause lockdep warnings when 6aa9707
"lockdep: check that no locks held at freeze time" is reapplied
(it was reverted in dbf520a). CIFS shouldn't be doing this, but
it has long-running syscalls that must hold a lock but also
shouldn't block suspend. Until CIFS freeze handling is rewritten
to use a signal to exit out of the critical section, add a new
wait_event_freezekillable_unsafe helper that will not run the
lockdep test when 6aa9707 is reapplied, and call it from CIFS.
In practice the likley result of holding the lock while freezing
is that a second task blocked on the lock will never freeze,
aborting suspend, but it is possible to manufacture a case using
the cgroup freezer, the lock, and the suspend freezer to create
a deadlock. Silencing the lockdep warning here will allow
problems to be found in other drivers that may have a more
serious deadlock risk, and prevent new problems from being added.
Change-Id: I420c5392bacf68e58e268293b2b36068ad4df753
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
NFS calls the freezable helpers with locks held, which is unsafe
and will cause lockdep warnings when 6aa9707 "lockdep: check
that no locks held at freeze time" is reapplied (it was reverted
in dbf520a). NFS shouldn't be doing this, but it has
long-running syscalls that must hold a lock but also shouldn't
block suspend. Until NFS freeze handling is rewritten to use a
signal to exit out of the critical section, add new *_unsafe
versions of the helpers that will not run the lockdep test when
6aa9707 is reapplied, and call them from NFS.
In practice the likley result of holding the lock while freezing
is that a second task blocked on the lock will never freeze,
aborting suspend, but it is possible to manufacture a case using
the cgroup freezer, the lock, and the suspend freezer to create
a deadlock. Silencing the lockdep warning here will allow
problems to be found in other drivers that may have a more
serious deadlock risk, and prevent new problems from being added.
Change-Id: Ia17d32cdd013a6517bdd5759da900970a4427170
Signed-off-by: Colin Cross <ccross@android.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Add support for clocks CLOCK_REALTIME_ALARM and CLOCK_BOOTTIME_ALARM.
Change-Id: Iafc8445d3d7ffb35110c860f1607bf03f1edb895
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Similar to hrtimer_expires_remaining, return the amount of time
remaining until alarm expiry.
Change-Id: I8c57512d619ac66bcdaf2d9ccdf0d7f74af2ff66
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Start an alarmtimer with an expires time relative to the current time
of the associated clock.
Change-Id: Ifb5309a15e0d502bb4d0209ca5510a56ee7fa88c
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Similar to hrtimer_forward_now, move the expires time forward to an
interval from the current time of the associated clock.
Change-Id: I73fed223321167507b6eddcb7a57d235ffcfc1be
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Analogous to hrtimer_restart, restart an alarmtimer after the expires
time has already been updated (as with alarm_forward).
Change-Id: Ia2613bbb467404cb2c35c11efa772bc56294963a
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Arve Hjønnevåg reported numerous crashes from the
"BUG_ON(timer->state != HRTIMER_STATE_CALLBACK)" check
in __run_hrtimer after it called alarmtimer_fired.
It ends up the alarmtimer code was not properly handling
possible failures of hrtimer_try_to_cancel, and because
these faulres occur when the underlying base hrtimer is
being run, this limits the ability to properly handle
modifications to any alarmtimers on that base.
Because much of the logic duplicates the hrtimer logic,
it seems that we might as well have a per-alarmtimer
hrtimer, and avoid the extra complextity of trying to
multiplex many alarmtimers off of one hrtimer.
Thus this patch moves the hrtimer to the alarm structure
and simplifies the management logic.
Change-Id: I54b2d718ed1d39598e321eacf88c3335284d4cea
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Colin Cross <ccross@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Reported-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Check for idle time delta less than elapsed time delta, avoid
underflow computing active time.
Change-Id: I3e4c6ef1ad794eec49ed379c0c50fa727fd6ad28
Signed-off-by: Minsung Kim <ms925.kim@samsung.com>
Reschedule load sampling timer after timestamp of sample start taken,
hold spinlock across entire sequence to avoid preemption. Avoid the
WARN for zero time delta in the load sampling timer function.
Change-Id: Idc10a756f09141decb6df92669521a1ebf0dbc10
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Add checks for error return from cpufreq_frequency_table_target, and be
less noisy on the existing call with an error check. CPU hotplug and
system shutdown may cause this call to return -EINVAL.
Bug: 8613560
Change-Id: Id78d8829920462c0db1c7e14e717d91740d6cb44
Signed-off-by: Todd Poynor <toddpoynor@google.com>
We don't like CONFIG_MODULES anymore.
Connection tracker handling of large SIP fails.
Change-Id: Ie3c65aefcc6181752d6656c97e63035e5b5653ff
Signed-off-by: JP Abgrall <jpa@google.com>
Because there is not tool to consistently generate these config
fragments, lets keep the alphabetical instead of random.
Change-Id: I0f098f6be6bdd272544295a3d5a48d04411e4514
Signed-off-by: JP Abgrall <jpa@google.com>
Avoid holding ashmem_mutex across code that can page fault. Page faults
grab the mmap_sem for the process, which are also held by mmap calls
prior to calling ashmem_mmap, which locks ashmem_mutex. The reversed
order of locking between the two can deadlock.
The calls that can page fault are read() and the ASHMEM_SET_NAME and
ASHMEM_GET_NAME ioctls. Move the code that accesses userspace pages
outside the ashmem_mutex.
Bug: 9261835
Change-Id: If1322e981d29c889a56cdc9dfcbc6df2729a45e9
Signed-off-by: Todd Poynor <toddpoynor@google.com>
This will be a noop unless the KSM thread is enabled by userspace
Change-Id: Ia5fde14504cc0da50522e2f875d8d021f9e054ba
Signed-off-by: Rom Lemarchand <romlem@google.com>
When the system is low on memory, we want to shrink any cached
system memory ion is holding. Previously we were shrinking memory
in the page pools, but not in the deferred free list. This patch
makes it possible to shrink both. It also moves the shrinker
code into the heaps so they can correctly manage any caches they
might contain.
Change-Id: I177f587f999a5220eddbf7af94745aae736cac75
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
Add tracepoints to record the start and end of each mmc block
operation. This includes read, write, erase, secure erase,
trim, secure trim1 and secure trim 2, discard and
sanitize commands.
Change-Id: Ic5d1cbdb9adb940d8b1a2a13c73970023575df50
Signed-off-by: Ken Sumrall <ksumrall@android.com>
Trinity discovered that we fail to check all 64 bits of
attr.config passed by user space, resulting to out-of-bounds
access of the perf_swevent_enabled array in
sw_perf_event_destroy().
Introduced in commit b0a873ebb ("perf: Register PMU
implementations").
Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: davej@redhat.com
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Link: http://lkml.kernel.org/r/1365882554-30259-1-git-send-email-tt.rantala@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
- Change the logic to enable Power save mode for STA or P2P GC
- Fix protxstatus bug for corner case
- Reset uninitialized value for mac entry
- Remove dhd_wlfc_init/deinit in wl_android.c
- Fix IBSS mode
Change-Id: I4589e87eda456798eae48548261a1f7cb9542660
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
lowmemorykiller debug messages are inscrutable and mostly useful
for debugging the lowmemorykiller, not explaining why a process
was killed. Make the messages more useful by prefixing them
with "lowmemorykiller: " and explaining in more readable terms
what was killed, who it was killed for, and why it was killed.
The messages now look like:
[ 76.997631] lowmemorykiller: Killing 'droid.gallery3d' (2172), adj 1000,
[ 76.997635] to free 27436kB on behalf of 'kswapd0' (29) because
[ 76.997638] cache 122624kB is below limit 122880kB for oom_score_adj 1000
[ 76.997641] Free memory is -53356kB above reserved
A negative number for free memory above reserved means some of the
reserved memory has been used and is being regenerated by kswapd,
which is likely what called the shrinkers.
Change-Id: I1fe983381e73e124b90aa5d91cb66e55eaca390f
Signed-off-by: Colin Cross <ccross@android.com>
Bail out early if IRQs are disabled in do_page_fault or else
[14415.157266] BUG: sleeping function called from invalid context at arch/arm/mm/fault.c:301
Russell King's idea from
http://comments.gmane.org/gmane.linux.ports.arm.omap/59256
Signed-off-by: JP Abgrall <jpa@google.com>
- Add 2 files that contain the minimal and recommended kernel config
options respectively.
- Add a README to explain their purpose and how to use them to
generate a device config compatible with Android.
Change-Id: I3a4883f3b04d2820e90ceb3c4d02390d6458d6ce
Signed-off-by: Rom Lemarchand <romlem@google.com>
The high variable was sometimes used uninitialized
Change-Id: I2f51413fd2d063fdff325047e824dc8c749d9e0a
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
This change fixes the how the gpu_sched_switch timestamp field is formatted.
Signed-off-by: Jamie Gennis <jgennis@google.com>
Change-Id: I273234935254ed15772c9e561c9af20e480004ae
Allow CONFIG_BUILD_ARM_APPENDED_DTB_IMAGE_NAMES to specify
a space separated list of dtbs to append to the zImage,
and name the resulting file zImage-dtb
Change-Id: I36d9108a2349bdbb373e95076dcb1417d8c7dce6
Signed-off-by: Colin Cross <ccross@android.com>
Allocations from the ion heap need to be zeroed to protect userspace
from seeing memory belonging to other processes. First allocations
from this heap were not zero'd allowing users to see memory from other
processes on a warm reset.
Change-Id: I524a7b79cb76c390c870fcf8b30d213185fc85a0
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
functionfs was leaking request objects created by autoconfig.
Bug: 8659094
Change-Id: I641326cb5cb26e0a2ffa082cd2be2c21c66c38e5
Signed-off-by: Peter Korsgaard <peter.korsgaard@barco.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Benoit Goby <benoit@android.com>
- Check vndr pointer in case WPA Supplicant does not use probe_resp data
- Enable buf_key_b4_m4 to install the key after sending 4-way M4
(802.1x EAPOL 4-way handshake may fail on Multiple VSDB situation)
- Improve P2P tx frame stuff
Change-Id: I5a46ebb50b37fbe6f4380f6e4deb8925603a56be
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Some of the printks are in the packet handling path.
We now ratelimit the very unlikely errors to avoid
kmsg spamming.
Signed-off-by: JP Abgrall <jpa@google.com>
This reverts commit c93c85196e which is
commit 01c681d4c7 upstream.
It shouldn't have been applied to the 3.4-stable tree, sorry about that.
Reported-by: William Dauchy <wdauchy@gmail.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit fcd99434fb ]
Now that netdev_rx_handler_unregister contains synchronize_net(), we need
to call it outside of bond->lock, cause it might sleep. Also, remove the
already unneded synchronize_net().
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 4c51e53689 ]
This patch enables RX of jumbo frames for LAN7500.
Previously the driver would transmit jumbo frames succesfully but
would drop received jumbo frames (incrementing the interface errors
count).
With this patch applied the device can succesfully receive jumbo
frames up to MTU 9000 (9014 bytes on the wire including ethernet
header).
Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 76a0e68129 ]
skb->ip_summed should be CHECKSUM_UNNECESSARY when the driver reports that
checksums were correct and CHECKSUM_NONE in any other case. They're
currently placed vice versa, which breaks the forwarding scenario. Fix it
by placing them as described above.
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 00cfec3748 ]
commit 35d48903e9 (bonding: fix rx_handler locking) added a race
in bonding driver, reported by Steven Rostedt who did a very good
diagnosis :
<quoting Steven>
I'm currently debugging a crash in an old 3.0-rt kernel that one of our
customers is seeing. The bug happens with a stress test that loads and
unloads the bonding module in a loop (I don't know all the details as
I'm not the one that is directly interacting with the customer). But the
bug looks to be something that may still be present and possibly present
in mainline too. It will just be much harder to trigger it in mainline.
In -rt, interrupts are threads, and can schedule in and out just like
any other thread. Note, mainline now supports interrupt threads so this
may be easily reproducible in mainline as well. I don't have the ability
to tell the customer to try mainline or other kernels, so my hands are
somewhat tied to what I can do.
But according to a core dump, I tracked down that the eth irq thread
crashed in bond_handle_frame() here:
slave = bond_slave_get_rcu(skb->dev);
bond = slave->bond; <--- BUG
the slave returned was NULL and accessing slave->bond caused a NULL
pointer dereference.
Looking at the code that unregisters the handler:
void netdev_rx_handler_unregister(struct net_device *dev)
{
ASSERT_RTNL();
RCU_INIT_POINTER(dev->rx_handler, NULL);
RCU_INIT_POINTER(dev->rx_handler_data, NULL);
}
Which is basically:
dev->rx_handler = NULL;
dev->rx_handler_data = NULL;
And looking at __netif_receive_skb() we have:
rx_handler = rcu_dereference(skb->dev->rx_handler);
if (rx_handler) {
if (pt_prev) {
ret = deliver_skb(skb, pt_prev, orig_dev);
pt_prev = NULL;
}
switch (rx_handler(&skb)) {
My question to all of you is, what stops this interrupt from happening
while the bonding module is unloading? What happens if the interrupt
triggers and we have this:
CPU0 CPU1
---- ----
rx_handler = skb->dev->rx_handler
netdev_rx_handler_unregister() {
dev->rx_handler = NULL;
dev->rx_handler_data = NULL;
rx_handler()
bond_handle_frame() {
slave = skb->dev->rx_handler;
bond = slave->bond; <-- NULL pointer dereference!!!
What protection am I missing in the bond release handler that would
prevent the above from happening?
</quoting Steven>
We can fix bug this in two ways. First is adding a test in
bond_handle_frame() and others to check if rx_handler_data is NULL.
A second way is adding a synchronize_net() in
netdev_rx_handler_unregister() to make sure that a rcu protected reader
has the guarantee to see a non NULL rx_handler_data.
The second way is better as it avoids an extra test in fast path.
Reported-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jiri Pirko <jpirko@redhat.com>
Cc: Paul E. McKenney <paulmck@us.ibm.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
