net/rfkill/core.c: Avoid leaving freed data in a list

The list_for_each_entry loop can fail, in which case the list element is
not removed from the list rfkill_fds.  Since this list is not accessed by
the loop, the addition of &data->list into the list is just moved after the
loop.

The sematic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@@
expression E,E1,E2;
identifier l;
@@

*list_add(&E->l,E1);
... when != E1
    when != list_del(&E->l)
    when != list_del_init(&E->l)
    when != E = E2
*kfree(E);// </smpl>

Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rfkill: remove dead code

The following code is defined but never used.

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rfkill: add missing llseek

This is what happens when some company (hint: company name contains
3 letters and starts with "h") just adds some patches they'd like
to include but forget older ones.
net: return operator cleanup

Cherry-picked for this file only.

Change "return (EXPR);" to "return EXPR;"

return is not a function, parentheses are not required.

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
power: fix lcd resume taking long time with an ongoing file copy

This fixes the issue where LCD takes a long time to come back up
since the execution of backlight on and late_resume works by the
suspend worker thread is delayed due to one (or more) of the
sys_sync calls in early_suspend and suspend paths taking a long
time (sometimes 15sec or more) for the below reported scenario(s):

Scenario 1 (copy with usb connected):
1. plug usb
2. adb shell
3. busybox cp /sdcard/file1 /sdcard/file2 (copy >= 100MB file1
   in sdcard/emmc to file2 in sdcard/emmc)
4. press end key to suspend
5. press end key again and it takes a long time for LCD to come
   back up

Scenario 2 (background copy):
1. plug usb
2. adb shell
3. busybox cp /sdcard/file1 /sdcard/file2 & (copy >= 100MB file1
   in sdcard/emmc to file2 in sdcard/emmc)
4. disconnect usb
5. press end key to suspend
6. press end key again and it takes a long time for LCD to come
   back up

A more common form of Scenario 2 is for the user to just use the
copy function on the UI to copy large file(s).

We address this by moving sys_sync calls to a separate workqueue
and having a timeout polling based mechanism to bail out of suspend
in case of user invoking a wakeup event (like end key press) while
we are waiting for the sys_sync completion at the synchronization
point in suspend worker thread context.

CRs-Fixed: 283994
(cherry picked from commit 28244e07afcb5dc3bc6803432c4210745452b292)

Change-Id: Iec35dd7bdd7cf89e3c2608422e26cadf19bc28f2
Signed-off-by: Sunil Joseph <sunilj@codeaurora.org>
Signed-off-by: Raj Kushwaha <rajk@codeaurora.org>
power: fix suspend_sys_sync_wait()

Since the workqueue code deletes the work before executing it,
checking for no work item being currently queued to the workqueue
is not sufficient to guarantee that all the works have finished
execution.

Use a counter to guarantee that all the pending suspend_sys_sync()
works have finished execution before returning from
suspend_sys_sync_wait().

Change-Id: I2f1e0b622cc050aa287ee941c351d3ce3b47cfdf
CRs-Fixed: 293595
Signed-off-by: Pratik Patel <pratikp@codeaurora.org>
Signed-off-by: Raj Kushwaha <rajk@codeaurora.org>
PM: Back off suspend if repeated attempts fail

If 10 attempts to suspend either fail or immediately resume within
1 second, back off suspending for 5 seconds multiplied by the
number of consecutive backoffs.  That is, pause suspends for 5
seconds after the first 10 failures, 10 seconds after the next
10 failures, and so on.

Avoid continually trying to suspend in situations in which a
driver is repeatedly rejecting suspend or a pending wakeup
interrupt is not handled, burning CPU in the continuous suspend
attempts.

Change-Id: I32289676d95a307ea3aa5e78f6c126ca979c0fec
Signed-off-by: Todd Poynor <toddpoynor@google.com>
PM: wakelocks: Replace variable and constants names with CAF version
kernel: sched: Add wait_for_completion_io to BFS
mmc: Attribute the IO wait time properly in mmc_wait_for_req().

In mmc_wait_for_req() function, change the call wait_for_completion()
to wait_for_completion_io(). This change makes the kernel account for
wait time as I/O wait and through another configuration this I/O wait
is treated as busy which makes the acpu clock to scale up.

CRs-Fixed: 283420
Change-Id: If3de6325b7e4cf8141c808e5853f4fc2dbb4e3ec
Signed-off-by: Murali Palnati <palnatim@codeaurora.org>

Conflicts:

	drivers/mmc/core/core.c
msm: dma: Track waiting for requests as io_wait time

Using wait_for_completion_io instead of wait_for_completion improves the
kernel's statistics about time spent waiting for io.

Signed-off-by: Jeffrey Ohlstein <johlstei@quicinc.com>

Conflicts:

	arch/arm/mach-msm/dma.c
ashmem: fix deadlock when system is low on memory

When system is low on memory, allocating memory while holding the
ashmem_mutex may try to directly reclaim memory. Then ashmem_shrink()
is called in same thread. It will deadlock at acquiring ashmem_mutex.
This change lets ashmem_shrink() return failure if ashmem_mutex is not
available. Memory will be reclaimed from others.

Change-Id: I3b6024d5477d37245f4ebde6d7069fb77af789ee
Signed-off-by: Yuanyuan Zhong <yuanyuan.zhong@gmail.com>
vmscan: move referenced VM_EXEC pages to active list

In commit 64574746, "vmscan: detect mapped file pages used only once",
Johannes Weiner, added logic to page_check_reference to cycle again
used once pages.

In commit 8cab4754, "vmscan: make mapped executable pages the first
class citizen", Wu Fengguang, added logic to shrink_active_list which
protects file-backed VM_EXEC pages by keeping them in the active_list if
they are referenced.

This patch adds logic to move such pages from the inactive list to the
active list immediately if they have been referenced. If a VM_EXEC page
is seen as referenced during an inactive list scan, that reference must
have occurred after the page was put on the inactive list. There is no
need to wait for the page to be referenced again.

Change-Id: I17c312e916377e93e5a92c52518b6c829f9ab30b
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
fs: mark_inode_dirty barrier fix

Filesystems appear to be using ->dirty_inode, expecting that the dirtying
operating is done and visible to all CPUs (eg. setting private inode dirty
bits, without any barriers themselves). So release the dirty "critical
section" with a barrier before calling ->dirty_inode.

Cost is not significantly changed, because we're just moving the barrier.
Those filesystems that do use ->dirty_inode should have to care slightly
less about barriers, which is a good thing.

Signed-off-by: Nick Piggin <npiggin@kernel.dk>
fs: add sync_inode_metadata

Add a new helper to write out the inode using the writeback code,
that is including the correct dirty bit and list manipulation.  A few
of filesystems already opencode this, and a lot of others should be
using it instead of using write_inode_now which also writes out the
data.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
sync_inode_metadata: fix comment

Use correct function name, remove incorrect apostrophe

Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
fs: simple fsync race fix

It is incorrect to test inode dirty bits without participating in the inode
writeback protocol. Inode writeback sets I_SYNC and clears I_DIRTY_?, then
writes out the particular bits, then clears I_SYNC when it is done. BTW. it
may not completely write all pages out, so I_DIRTY_PAGES would get set
again.

This is a standard pattern used throughout the kernel's writeback caches
(I_SYNC ~= I_WRITEBACK, if that makes it clearer).

And so it is not possible to determine an inode's dirty status just by
checking I_DIRTY bits. Especially not for the purpose of data integrity
syncs.

Missing the check for these bits means that fsync can complete while
writeback to the inode is underway. Inode writeback functions get this
right, so call into them rather than try to shortcut things by testing
dirty state improperly.

Signed-off-by: Nick Piggin <npiggin@kernel.dk>
fs: ext2 inode sync fix

There is a big fuckup with inode metadata writeback (I suspect in a lot
of filesystems, but I've only dared to look at a couple as yet).

ext2 relies on ->write_inode being called from sync_inode_metadata in
fsync in order to sync the inode. However I_DIRTY_SYNC gets cleared
after a call to this guy, and it doesn't actually write back and wait
on the inode block unless it is called for sync. This means that write_inode
from background writeback can kill the inode dirty bits without the data
getting to disk. Fsync will subsequently miss it.

The fix is for ->write_inode to dirty the buffers/cache, and then ->fsync to
write back the dirty data. In the full filesystem sync case, buffercache
writeback in the generic code will write back the dirty data. Other
filesystems could use ->sync_fs for this.

Signed-off-by: Nick Piggin <npiggin@kernel.dk>
lib/sha1: use the git implementation of SHA-1

For ChromiumOS, we use SHA-1 to verify the integrity of the root
filesystem.  The speed of the kernel sha-1 implementation has a major
impact on our boot performance.

To improve boot performance, we investigated using the heavily optimized
sha-1 implementation used in git.  With the git sha-1 implementation, we
see a 11.7% improvement in boot time.

10 reboots, remove slowest/fastest.

Before:

  Mean: 6.58 seconds Stdev: 0.14

After (with git sha-1, this patch):

  Mean: 5.89 seconds Stdev: 0.07

The other cool thing about the git SHA-1 implementation is that it only
needs 64 bytes of stack for the workspace while the original kernel
implementation needed 320 bytes.

Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Cc: Nicolas Pitre <nico@cam.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David S. Miller <davem@davemloft.net>
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
arm: remove "optimized" SHA1 routines

Since commit 1eb19a12bd22 ("lib/sha1: use the git implementation of
SHA-1"), the ARM SHA1 routines no longer work.  The reason? They
depended on the larger 320-byte workspace, and now the sha1 workspace is
just 16 words (64 bytes).  So the assembly version would overwrite the
stack randomly.

The optimized asm version is also probably slower than the new improved
C version, so there's no reason to keep it around.  At least that was
the case in git, where what appears to be the same assembly language
version was removed two years ago because the optimized C BLK_SHA1 code
was faster.

Reported-and-tested-by: Joachim Eastwood <manabian@gmail.com>
Cc: Andreas Schwab <schwab@linux-m68k.org>
Cc: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>