Initial commit of HTC's sapphire-2.6.29-9cfb347e sources
Give the kernel it's own name
Remove all unneeded defconfigs
Apply 2.6.29.6 patchset
Apply 2.6.29.6 patchset
Add htc_wifi_nvs and htc_awb_cal to build
Add tiwlan1251 driver
Backport 2.6.31 scheduling updates (by ninpo)
Apply AUFS2 standalone patches (by cyanogen)
fs: pipe.c null pointer dereference

This patch fixes a null pointer exception in pipe_rdwr_open() which
generates the stack trace:

> Unable to handle kernel NULL pointer dereference at 0000000000000028 RIP:
>  [<ffffffff802899a5>] pipe_rdwr_open+0x35/0x70
>  [<ffffffff8028125c>] __dentry_open+0x13c/0x230
>  [<ffffffff8028143d>] do_filp_open+0x2d/0x40
>  [<ffffffff802814aa>] do_sys_open+0x5a/0x100
>  [<ffffffff8021faf3>] sysenter_do_call+0x1b/0x67

The failure mode is triggered by an attempt to open an anonymous
pipe via /proc/pid/fd/* as exemplified by this script:

=============================================================
while : ; do
   { echo y ; sleep 1 ; } | { while read ; do echo z$REPLY; done ; } &
   PID=$!
   OUT=$(ps -efl | grep 'sleep 1' | grep -v grep |
        { read PID REST ; echo $PID; } )
   OUT="${OUT%% *}"
   DELAY=$((RANDOM * 1000 / 32768))
   usleep $((DELAY * 1000 + RANDOM % 1000 ))
   echo n > /proc/$OUT/fd/1                 # Trigger defect
done
=============================================================

Note that the failure window is quite small and I could only
reliably reproduce the defect by inserting a small delay
in pipe_rdwr_open(). For example:

 static int
 pipe_rdwr_open(struct inode *inode, struct file *filp)
 {
       msleep(100);
       mutex_lock(&inode->i_mutex);

Although the defect was observed in pipe_rdwr_open(), I think it
makes sense to replicate the change through all the pipe_*_open()
functions.

The core of the change is to verify that inode->i_pipe has not
been released before attempting to manipulate it. If inode->i_pipe
is no longer present, return ENOENT to indicate so.

The comment about potentially using atomic_t for i_pipe->readers
and i_pipe->writers has also been removed because it is no longer
relevant in this context. The inode->i_mutex lock must be used so
that inode->i_pipe can be dealt with correctly.

Signed-off-by: Earl Chew <earl_chew@agilent.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
android: backport to 2.6.29

android: logger: Add new system log for framework/system log messages

Signed-off-by: San Mehat <san@google.com>

Staging: android: timed_gpio: Properly discard invalid timeout values.

The timed output device never previously checked the return value of sscanf,
resulting in an uninitialized int being passed to enable() if input value
was invalid.

Signed-off-by: Mike Lockwood <lockwood@android.com>

Staging: android: binder: Create dedicated workqueue for binder deferred work

Some drivers flush the global workqueue when closed. This would deadlock if
the last reference to the file was released from the binder.

Change-Id: Ifdabc0b383fecb20836d1bbb9786c632402a14e1
Signed-off-by: Arve Hj

oom: move oom_adj value from task_struct to signal_struct

Currently, OOM logic callflow is here.

    __out_of_memory()
        select_bad_process()            for each task
            badness()                   calculate badness of one task
                oom_kill_process()      search child
                    oom_kill_task()     kill target task and mm shared tasks with it

example, process-A have two thread, thread-A and thread-B and it have very
fat memory and each thread have following oom_adj and oom_score.

     thread-A: oom_adj = OOM_DISABLE, oom_score = 0
     thread-B: oom_adj = 0,           oom_score = very-high

Then, select_bad_process() select thread-B, but oom_kill_task() refuse
kill the task because thread-A have OOM_DISABLE.  Thus __out_of_memory()
call select_bad_process() again.  but select_bad_process() select the same
task.  It mean kernel fall in livelock.

The fact is, select_bad_process() must select killable task.  otherwise
OOM logic go into livelock.

And root cause is, oom_adj shouldn't be per-thread value.  it should be
per-process value because OOM-killer kill a process, not thread.  Thus
This patch moves oomkilladj (now more appropriately named oom_adj) from
struct task_struct to struct signal_struct.  it naturally prevent
select_bad_process() choose wrong task.

Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Paul Menage <menage@google.com>
Cc: David Rientjes <rientjes@google.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

lowmemorykiller: Don't try to kill the same pid over and over

  Under certain circumstances, a process can take awhile to
handle a sig-kill (especially if it's in a scheduler group with
a very low share ratio). When this occurs, lowmemkiller returns
to vmscan indicating the process memory has been freed - even
though the process is still waiting to die. Since the memory
hasn't actually freed, lowmemkiller is called again shortly after,
and picks the same process to die; regardless of the fact that
it has already been 'scheduled' to die and the memory has already
been reported to vmscan as having been freed.

  Solution is to check fatal_signal_pending() on the selected
task, and if it's already pending destruction return; indicating
to vmscan that no resources were freed on this pass.

Signed-off-by: San Mehat <san@google.com>

sched: Add a generic notifier when a task struct is about to be freed

This patch adds a notifier which can be used by subsystems that may
be interested in when a task has completely died and is about to
have it's last resource freed.

  The Android lowmemory killer uses this to determine when a task
it has killed has finally given up its goods.

Signed-off-by: San Mehat <san@google.com>

staging: android: lowmemkiller: Substantially reduce overhead during reclaim

This patch optimizes lowmemkiller to not do any work when it has an outstanding
kill-request. This greatly reduces the pressure on the task_list lock
(improving interactivity), as well as improving the vmscan performance
when under heavy memory pressure (by up to 20x in tests).

Note: For this enhancement to work, you need CONFIG_PROFILING

Signed-off-by: San Mehat <san@google.com>

staging: android: lowmemorykiller: Fix task_struct leak

As it turns out, the CONFIG_PROFILING interfaces leak a
task struct if the notifier chain returns NOTIFY_OK.. doh.

This patch reworks lowmemkiller to use the new generic task
free notifier chain.

Signed-off-by: San Mehat <san@google.com>

staging: android: lowmemorykiller: Remove bitrotted codepath

Now that we're murder-synchronous, this code path will never be
called (and if it does, it doesn't tell us anything useful other
than we killed a task that was already being killed by somebody
else but hadn't gotten its' signal yet)

Signed-off-by: San Mehat <san@google.com>

binder: Fix memory corruption via page aliasing

binder_deferred_release was not unmapping the page from the buffer
before freeing it, causing memory corruption.  This only happened
when page(s) had not been freed by binder_update_page_range, which
properly unmaps the pages.

This only happens on architectures with VIPT aliasing.

To reproduce, create a program which opens, mmaps, munmaps, then closes
the binder very quickly.  This should leave a page allocated when the
binder is released.  When binder_deferrred_release is called on the
close, the page will remain mapped to the address in the linear
proc->buffer.  Later, we may map the same physical page to a different
virtual address that has different coloring, and this may cause
aliasing to occur.

PAGE_POISONING will greatly increase your chances of noticing any
problems.

Change-Id: I6941bf212881b8bf846bdfda43d3609c7ae4892e

Signed-off-by: Christopher Lais <chris+android@zenthought.org>
Squished commit of Bluetooth fixes from Google

Bluetooth: Fix connection establishment with low security requirement

The Bluetooth 2.1 specification introduced four different security modes
that can be mapped using Legacy Pairing and Simple Pairing. With the
usage of Simple Pairing it is required that all connections (except
the ones for SDP) are encrypted. So even the low security requirement
mandates an encrypted connection when using Simple Pairing. When using
Legacy Pairing (for Bluetooth 2.0 devices and older) this is not required
since it causes interoperability issues.

To support this properly the low security requirement translates into
different host controller transactions depending if Simple Pairing is
supported or not. However in case of Simple Pairing the command to
switch on encryption after a successful authentication is not triggered
for the low security mode. This patch fixes this and actually makes
the logic to differentiate between Simple Pairing and Legacy Pairing
a lot simpler.

Based on a report by Ville Tervo <ville.tervo@nokia.com>

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Set general bonding security for ACL by default

This patch fixes double pairing issues with SSP.

It was observed that when pairing with SSP bluez asks confirmation
2 times.
http://www.spinics.net/lists/linux-bluetooth/msg02473.html

This also causes bug when we initiate SSP connection from Vista.

The reason is because bluetoothd does not store link keys since
ioctl  HCIGETAUTHINFO returns 0. Setting default general
bonding fixes these issues.

Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko.news@gmail.com>

Bluetooth: Enter active mode before establishing a SCO link.

When in sniff mode with a long interval time (1.28s) it can take 4+ seconds to
establish a SCO link. Fix by requesting active mode before requesting SCO
connection. This improves SCO setup time to ~500ms.

Bluetooth headsets that use a long interval time, and exhibit the long SCO
connection time include Motorola H790, HX1 and H17. They have a CSR 2.1 chipset

Verified this behavior and fix with host Bluetooth chipsets: BCM4329 and
TI1271.

Signed-off-by: Nick Pelly <npelly@google.com>

Bluetooth: Add ACL MTU, available buffers and total buffers to hci_conn_info.

This provides userspace debugging tools access to ACL flow control state.

Signed-off-by: Nick Pelly <npelly@google.com>

Bluetooth: Introduce L2CAP_LM_FLUSHABLE to allow flushing of ACL packets.

With Bluetooth 2.1 ACL packets can be flushable or non-flushable. This changes
makes the default ACL packet non-flushable, and allows selection of flushable
packets on a per-L2CAP socket basis with L2CAP_LM_FLUSHABLE.

Note the HCI Write Automatic Flush Timeout command also needs to be issued
to set the flush timeout to non-zero.

Need to featurize this change to Bluetooth 2.1 chipsets only before pushing
upstream.

Signed-off-by: Nick Pelly <npelly@google.com>

Bluetooth: Hack: Do not use power_save feature.

power_save is a feature to allow HID devices to control the sniff mode.
Unfortunately it also prevents us exiting sniff mode on some A2DP devices
that do not explicitly exit sniff mode themselves, resulting in skipping
audio.

Marcel is trying to finalize a setsockopt() API to control whether power_save
is enabled on a per socket basis. In the mean-time, turn off power_save for
Android, since we do not have official HID support, and this is causing
problems for A2DP which we do support.

(Note the power_save logic is reversed, 0 is on, 1 is off).

Change-Id: Ife4478055128b81669bf49308d2e2199e1aa11a1
Signed-off-by: Nick Pelly <npelly@google.com>

Bluetooth: Allow SCO/eSCO packet type selection for outgoing SCO connections.

__u16 sco_pkt_type is introduced to struct sockaddr_sco. It allows bitwise
selection of SCO/eSCO packet types. Currently those bits are:

0x0001 HV1 may be used.
0x0002 HV2 may be used.
0x0004 HV3 may be used.
0x0008 EV3 may be used.
0x0010 EV4 may be used.
0x0020 EV5 may be used.
0x0040 2-EV3 may be used.
0x0080 3-EV3 may be used.
0x0100 2-EV5 may be used.
0x0200 3-EV5 may be used.

This is similar to the Packet Type parameter in the HCI Setup Synchronous
Connection Command, except that we are not reversing the logic on the EDR bits.
This makes the use of sco_pkt_tpye forward portable for the use case of
white-listing packet types, which we expect will be the primary use case.

If sco_pkt_type is zero, or userspace uses the old struct sockaddr_sco,
then the default behavior is to allow all packet types.

Packet type selection is just a request made to the Bluetooth chipset, and
it is up to the link manager on the chipset to negiotiate and decide on the
actual packet types used. Furthermore, when a SCO/eSCO connection is eventually
made there is no way for the host stack to determine which packet type was used
(however it is possible to get the link type of SCO or eSCO).

sco_pkt_type is ignored for incoming SCO connections. It is possible
to add this in the future as a parameter to the Accept Synchronous Connection
Command, however its a little trickier because the kernel does not
currently preserve sockaddr_sco data between userspace calls to accept().

The most common use for sco_pkt_type will be to white-list only SCO packets,
which can be done with the hci.h constant SCO_ESCO_MASK.

This patch is motivated by broken Bluetooth carkits such as the Motorolo
HF850 (it claims to support eSCO, but will actually reject eSCO connections
after 5 seconds) and the 2007/2008 Infiniti G35/37 (fails to route audio
if a 2-EV5 packet type is negiotiated). With this patch userspace can maintain
a list of compatible packet types to workaround remote devices such as these.

Based on a patch by Marcel Holtmann.

Change-Id: I304d8fda5b4145254820a3003820163bf53de5a5
Signed-off-by: Nick Pelly <npelly@google.com>

Bluetooth: Hack: Don't dereference null pointer.

This avoids the S305 panic during incoming connection.

S305 sends PSM 25 L2CAP connection request before the L2CAP info response.
When we receive that info response we crash on null pointer here.

Bug: 2127637
Change-Id: Ib637516251f46fa9a9c87ac015dc2f27df5a27fd
Signed-off-by: Nick Pelly <npelly@google.com>

Bluetooth: Defer SCO setup if mode change is pending

Certain headsets such as the Motorola H350 will reject SCO and eSCO
connection requests while the ACL is transitioning from sniff mode
to active mode. Add synchronization so that SCO and eSCO connection
requests will wait until the ACL has fully transitioned to active mode.

< HCI Command: Exit Sniff Mode (0x02|0x0004) plen 2
    handle 12
> HCI Event: Command Status (0x0f) plen 4
    Exit Sniff Mode (0x02|0x0004) status 0x00 ncmd 1
< HCI Command:  Setup Synchronous Connection (0x01|0x0028) plen 17
    handle 12 voice setting 0x0040
> HCI Event: Command Status (0x0f) plen 4
    Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 12 packets 1
> HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 12 mode 0x00 interval 0
    Mode: Active
> HCI Event: Synchronous Connect Complete (0x2c) plen 17
    status 0x10 handle 14 bdaddr 00:1A:0E:50:28:A4 type SCO
    Error: Connection Accept Timeout Exceeded

Signed-off-by: Ron Shaffer <rshaffer@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Squashed set of commits for mutex adaptive spin
for 2.6.29 (Peter Zijlstra) -- this comes default in .31+
This is a combination of 6 commits.
mutex: small cleanup

Remove a local variable by combining an assingment and test in one.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Wes Garner <wesgarner@gmail.com>

mutex: preemption fixes

The problem is that dropping the spinlock right before schedule is a voluntary
preemption point and can cause a schedule, right after which we schedule again.

Fix this inefficiency by keeping preemption disabled until we schedule, do this
by explicity disabling preemption and providing a schedule() variant that
assumes preemption is already disabled.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Wes Garner <wesgarner@gmail.com>

mutex: implement adaptive spinning

Change mutex contention behaviour such that it will sometimes busy wait on
acquisition - moving its behaviour closer to that of spinlocks.

This concept got ported to mainline from the -rt tree, where it was originally
implemented for rtmutexes by Steven Rostedt, based on work by Gregory Haskins.

Testing with Ingo's test-mutex application (http://lkml.org/lkml/2006/1/8/50)
gave a 345% boost for VFS scalability on my testbox:

 # ./test-mutex-shm V 16 10 | grep "^avg ops"
 avg ops/sec:               296604

 # ./test-mutex-shm V 16 10 | grep "^avg ops"
 avg ops/sec:               85870

The key criteria for the busy wait is that the lock owner has to be running on
a (different) cpu. The idea is that as long as the owner is running, there is a
fair chance it'll release the lock soon, and thus we'll be better off spinning
instead of blocking/scheduling.

Since regular mutexes (as opposed to rtmutexes) do not atomically track the
owner, we add the owner in a non-atomic fashion and deal with the races in
the slowpath.

Furthermore, to ease the testing of the performance impact of this new code,
there is means to disable this behaviour runtime (without having to reboot
the system), when scheduler debugging is enabled (CONFIG_SCHED_DEBUG=y),
by issuing the following command:

 # echo NO_OWNER_SPIN > /debug/sched_features

This command re-enables spinning again (this is also the default):

 # echo OWNER_SPIN > /debug/sched_features

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Wes Garner <wesgarner@gmail.com>

mutex: set owner in mutex_lock() only

mutex_lock() sets the lock owner, no need to set it upfront in
__mutex_lock_common().

Inside __mutex_lock_common() we can cope with the case where the
successful acquirer got preempted by us before setting the owner
field: there is an explicit check in the spinning part where we read
the owner field optimistically.

The sleeping path won't use that field at all.

The debug code does owner checks only on unlock where the owner field
is garuanteed to be set by then.

[a.p.zijlstra@chello.nl: same for trylock]
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Wes Garner <wesgarner@gmail.com>

mutex: adaptive spin for debug too

Johannes' argumentation shows the flaw in mine and testing does indeed confirm
that the adaptive spin works just fine with the debug code.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Wes Garner <wesgarner@gmail.com>

mutex: adaptive spin performance tweaks

Ok, numbers first, incremental below:

* dbench 50 (higher is better):
spin        1282MB/s
v10         548MB/s
v10 no wait 1868MB/s

* 4k creates (numbers in files/second higher is better):
spin        avg 200.60 median 193.20 std 19.71 high 305.93 low 186.82
v10         avg 180.94 median 175.28 std 13.91 high 229.31 low 168.73
v10 no wait avg 232.18 median 222.38 std 22.91 high 314.66 low 209.12

* File stats (numbers in seconds, lower is better):
spin        2.27s
v10         5.1s
v10 no wait 1.6s

This patch brings v10 up to v10 no wait.  The changes are smaller than
they look, I just moved the need_resched checks in __mutex_lock_common
after the cmpxchg.

Signed-off-by: Chris Mason <chris.mason@oracle.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Wes Garner <wesgarner@gmail.com>
Revert "Squished commit of Bluetooth fixes from Google"

This reverts commit a235b77ebe1b0824fb191c284f4c04e103072021.
CFS sched tweak: Disbale NORMALIZED_SLEEPER
Backport code calculating idle time from 2.6.34
Fix for USB not being detected during boot on Froyo ROMs
Add The Brain Fuck Scheduler v0.318 by Con Kolivas
Update low memory killer from .32 (By Decad3nce)
Optimized ARM RWSEM algorithm

RWSEM implementation for ARM using atomic functions.
Heavily based on arch/sh/include/asm/rwsem.h

Signed-off-by: Ashwin Chaugule <ashwinc@codeaurora.org>