initial
ipv6: Don't add routes to ipv6 disabled interfaces.

If the interface has IPv6 disabled, don't add a multicast or
link-local route since we won't be adding a link-local address.

author  Brian Haley <brian.haley@hp.com>
commit  64e724f62ab743d55229cd5e27ec8b068b68eb16
usb gadget: fix rndis regression

Restore some code that was wrongly dropped from the RNDIS
driver, and caused interop problems observed with OpenMoko.

The issue is with hardware which needs help conforming to part
of the USB 2.0 spec (section 8.5.3.2); some can automagically
send a ZLP in response to an unexpected IN, but not all chips
will do that.  We don't need to check the packet length ourselves
the way earlier code did, since the UDC must already check it.
But we do need to tell the UDC when it must force a short packet
termination of the data stage.

(Based on a patch from Aric D. Blumer <aric at sdgsystems.com>)
mm: fix handling of pagesets for downed cpus

commit 364df0ebfbbb1330bfc6ca159f4d6020efc15a12 upstream.

After downing/upping a cpu, an attempt to set
/proc/sys/vm/percpu_pagelist_fraction results in an oops in
percpu_pagelist_fraction_sysctl_handler().

If a processor is downed then we need to set the pageset pointer back to
the boot pageset.

Updates of the high water marks should not access pagesets of unpopulated
zones (those pointer go to the boot pagesets which would be no longer
functional if their size would be increased beyond zero).

Signed-off-by: Dimitri Sivanich <sivanich@sgi.com>
Signed-off-by: Christoph Lameter <cl@linux-foundation.org>
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
mm: pass correct mm when growing stack

commit 05fa199d45c54a9bda7aa3ae6537253d6f097aa9 upstream.

Tetsuo Handa reports seeing the WARN_ON(current->mm == NULL) in
security_vm_enough_memory(), when do_execve() is touching the
target mm's stack, to set up its args and environment.

Yes, a UMH_NO_WAIT or UMH_WAIT_PROC call_usermodehelper() spawns
an mm-less kernel thread to do the exec.  And in any case, that
vm_enough_memory check when growing stack ought to be done on the
target mm, not on the execer's mm (though apart from the warning,
it only makes a slight tweak to OVERCOMMIT_NEVER behaviour).

Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
cifs: remove bogus first_time check in NTLMv2 session setup code

commit 8a224d489454b7457105848610cfebebdec5638d upstream.

This bug appears to be the result of a cut-and-paste mistake from the
NTLMv1 code. The function to generate the MAC key was commented out, but
not the conditional above it. The conditional then ended up causing the
session setup key not to be copied to the buffer unless this was the
first session on the socket, and that made all but the first NTLMv2
session setup fail.

Fix this by removing the conditional and all of the commented clutter
that made it difficult to see.

Reported-by: Gunther Deschner <gdeschne@redhat.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
sctp: Fix skb_over_panic resulting from multiple invalid parameter errors (CVE-2010-1173) (v4)

commit 5fa782c2f5ef6c2e4f04d3e228412c9b4a4c8809 upstream.

Ok, version 4

Change Notes:
1) Minor cleanups, from Vlads notes

Summary:

Hey-
	Recently, it was reported to me that the kernel could oops in the
following way:

<5> kernel BUG at net/core/skbuff.c:91!
<5> invalid operand: 0000 [#1]
<5> Modules linked in: sctp netconsole nls_utf8 autofs4 sunrpc iptable_filter
ip_tables cpufreq_powersave parport_pc lp parport vmblock(U) vsock(U) vmci(U)
vmxnet(U) vmmemctl(U) vmhgfs(U) acpiphp dm_mirror dm_mod button battery ac md5
ipv6 uhci_hcd ehci_hcd snd_ens1371 snd_rawmidi snd_seq_device snd_pcm_oss
snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_ac97_codec snd soundcore
pcnet32 mii floppy ext3 jbd ata_piix libata mptscsih mptsas mptspi mptscsi
mptbase sd_mod scsi_mod
<5> CPU:    0
<5> EIP:    0060:[<c02bff27>]    Not tainted VLI
<5> EFLAGS: 00010216   (2.6.9-89.0.25.EL)
<5> EIP is at skb_over_panic+0x1f/0x2d
<5> eax: 0000002c   ebx: c033f461   ecx: c0357d96   edx: c040fd44
<5> esi: c033f461   edi: df653280   ebp: 00000000   esp: c040fd40
<5> ds: 007b   es: 007b   ss: 0068
<5> Process swapper (pid: 0, threadinfo=c040f000 task=c0370be0)
<5> Stack: c0357d96 e0c29478 00000084 00000004 c033f461 df653280 d7883180
e0c2947d
<5>        00000000 00000080 df653490 00000004 de4f1ac0 de4f1ac0 00000004
df653490
<5>        00000001 e0c2877a 08000800 de4f1ac0 df653490 00000000 e0c29d2e
00000004
<5> Call Trace:
<5>  [<e0c29478>] sctp_addto_chunk+0xb0/0x128 [sctp]
<5>  [<e0c2947d>] sctp_addto_chunk+0xb5/0x128 [sctp]
<5>  [<e0c2877a>] sctp_init_cause+0x3f/0x47 [sctp]
<5>  [<e0c29d2e>] sctp_process_unk_param+0xac/0xb8 [sctp]
<5>  [<e0c29e90>] sctp_verify_init+0xcc/0x134 [sctp]
<5>  [<e0c20322>] sctp_sf_do_5_1B_init+0x83/0x28e [sctp]
<5>  [<e0c25333>] sctp_do_sm+0x41/0x77 [sctp]
<5>  [<c01555a4>] cache_grow+0x140/0x233
<5>  [<e0c26ba1>] sctp_endpoint_bh_rcv+0xc5/0x108 [sctp]
<5>  [<e0c2b863>] sctp_inq_push+0xe/0x10 [sctp]
<5>  [<e0c34600>] sctp_rcv+0x454/0x509 [sctp]
<5>  [<e084e017>] ipt_hook+0x17/0x1c [iptable_filter]
<5>  [<c02d005e>] nf_iterate+0x40/0x81
<5>  [<c02e0bb9>] ip_local_deliver_finish+0x0/0x151
<5>  [<c02e0c7f>] ip_local_deliver_finish+0xc6/0x151
<5>  [<c02d0362>] nf_hook_slow+0x83/0xb5
<5>  [<c02e0bb2>] ip_local_deliver+0x1a2/0x1a9
<5>  [<c02e0bb9>] ip_local_deliver_finish+0x0/0x151
<5>  [<c02e103e>] ip_rcv+0x334/0x3b4
<5>  [<c02c66fd>] netif_receive_skb+0x320/0x35b
<5>  [<e0a0928b>] init_stall_timer+0x67/0x6a [uhci_hcd]
<5>  [<c02c67a4>] process_backlog+0x6c/0xd9
<5>  [<c02c690f>] net_rx_action+0xfe/0x1f8
<5>  [<c012a7b1>] __do_softirq+0x35/0x79
<5>  [<c0107efb>] handle_IRQ_event+0x0/0x4f
<5>  [<c01094de>] do_softirq+0x46/0x4d

Its an skb_over_panic BUG halt that results from processing an init chunk in
which too many of its variable length parameters are in some way malformed.

The problem is in sctp_process_unk_param:
if (NULL == *errp)
	*errp = sctp_make_op_error_space(asoc, chunk,
					 ntohs(chunk->chunk_hdr->length));

	if (*errp) {
		sctp_init_cause(*errp, SCTP_ERROR_UNKNOWN_PARAM,
				 WORD_ROUND(ntohs(param.p->length)));
		sctp_addto_chunk(*errp,
			WORD_ROUND(ntohs(param.p->length)),
				  param.v);

When we allocate an error chunk, we assume that the worst case scenario requires
that we have chunk_hdr->length data allocated, which would be correct nominally,
given that we call sctp_addto_chunk for the violating parameter.  Unfortunately,
we also, in sctp_init_cause insert a sctp_errhdr_t structure into the error
chunk, so the worst case situation in which all parameters are in violation
requires chunk_hdr->length+(sizeof(sctp_errhdr_t)*param_count) bytes of data.

The result of this error is that a deliberately malformed packet sent to a
listening host can cause a remote DOS, described in CVE-2010-1173:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=2010-1173

I've tested the below fix and confirmed that it fixes the issue.  We move to a
strategy whereby we allocate a fixed size error chunk and ignore errors we don't
have space to report.  Tested by me successfully

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: android gadget: mass storage: Fix format issue for Vista Host

As part of formating the mass storage device, Host sends the INQUIRY
scsi command. As per the standard, the command length for this
command should be 6 bytes, whereas the Vista host sends 12 bytes.

When the command length of the command is not equal to the standard
length, the device sends a phase error as part of the status phase.
When the host receives a phase error, it re-enumerates, hence the
error.

If the command is INQUIRY, and the command length is 12 bytes,
treating this as a good command and not sending the phase error
to the host fixes this issue.

Signed-off-by: Velempati Chiranjeevi <c_cvelem@qualcomm.com>
Signed-off-by: Mike Lockwood <lockwood@android.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>
USB: function: add rndis support

From cm eclair/hero kernel.
pmem: Add PMEM_CACHE_FLUSH ioctl.
net: unix: force garbage collection if too many inflight sockets

Patch vulnerability discussed on lkml:

http://lkml.org/lkml/2010/11/25/8

Patch author:       Eric Dumazet
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>
Apply AUFS2 standalone patches.
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ønnevåg <arve@android.com>

    Replace HTC's lowmemorykiller with Google's.

    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>
arm: mm: Don't free prohibited memmap entries

The VM subsystem assumes that there are valid memmap entries to
the bank end aligned to MAX_ORDER_NR_PAGES. It will try and read
these page structs, and so we cannot free any memmap entries that
it may inspect.

Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Signed-off-by: Daniel Walker <dwalker@codeaurora.org>

Change-Id: I695198cf78d69cb5b279adcf376c6458d340da91
integrate bfq iosched

Signed-off-by: Wes Garner <wesgarner@gmail.com>
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>
lowmemorykiller: only check cache for thresholds

Since lowmemory killer only gets called when needed to satisfy memory
requirements, there is no need to check free memory before selecting
a process to kill. Instead, file backed memory is checked to allow
lowmemory thresholds to be used to balance between file caching and
process caching.
Note: It may be desireable to re-adjust low memory killer thresholds.

Change-Id: Iec661d6ce72b18aaaeab417f685e9880690eae57
Signed-off-by: Brian Steuer <bsteuer@codeaurora.org>
staging: ramzswap support

Enable compcache (ramzswap) compressed caching. Includes required swap notify
support by Nitin Gupta.